Initial commit

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,38 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Desktop (please complete the following information):**
+ - OS: [e.g. iOS]
+ - Browser [e.g. chrome, safari]
+ - Version [e.g. 22]
+
+**Smartphone (please complete the following information):**
+ - Device: [e.g. iPhone6]
+ - OS: [e.g. iOS8.1]
+ - Browser [e.g. stock browser, safari]
+ - Version [e.g. 22]
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/ISSUE_TEMPLATE/meeting.md

@@ -0,0 +1,54 @@
+# [PROJECT NAME] TSC Meeting - <%= date.toFormat("MMMM d, yyyy") %>
+
+## Date/Time
+
+| Timezone | Date/Time |
+|----------|-----------|
+<%= [
+  'America/Los_Angeles',
+  'America/Denver',
+  'America/Chicago',
+  'America/New_York',
+  'Europe/London',
+  'Europe/Amsterdam',
+  'Asia/Shanghai',
+  'Asia/Tokyo',
+].map((zone) => {
+  return `| ${zone} | ${date.setZone(zone).toFormat('EEE dd-MMM-yyyy HH:mm (hh:mm a)')} |`
+}).join('\n') %>
+
+Or in your local time:
+* https://www.timeanddate.com/worldclock/?iso=<%= date.toFormat("yyyy-MM-dd'T'HH:mm:ss") %>
+
+All meetings are listed on the project calendar at https://lists.openmainframeproject.org/calendar, subject to the mailing lists you are subscribed to.
+
+### Conference call details
+
+_fill in Zoom details_
+
+### Meeting recordings
+
+_fill in recording details_
+
+## Attendance
+
+### Voting member rollcall:
+
+_fill in voting members as a checklist_
+
+### Other Attendees
+
+
+## Agenda
+
+Extracted from **<%= agendaLabel %>** labelled issues and pull requests from **<%= owner %>/<%= repo %>** prior to the meeting.
+
+* Project updates ( list at https://github.com/openmainframeproject/tac#tac-projects )
+<%= agendaIssues.map((i) => {
+  return `* ${i.title} [#${i.number}](${i.html_url})`
+}).join('\n') %>
+
+## Action Items
+
+
+## Notes

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -0,0 +1,29 @@
+# Description
+
+Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
+
+Fixes # (issue)
+
+## Type of change
+
+Please delete options that are not relevant.
+
+- [ ] Bug fix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+
+# How Has This Been Tested?
+
+Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
+
+# Checklist:
+
+- [ ] My code follows the style guidelines of this project
+- [ ] I have performed a self-review of my own code
+- [ ] I have commented my code, particularly in hard-to-understand areas
+- [ ] I have made corresponding changes to the documentation
+- [ ] My changes generate no new warnings
+- [ ] I have added tests that prove my fix is effective or that my feature works
+- [ ] New and existing unit tests pass locally with my changes
+- [ ] Any dependent changes have been merged and published in downstream modules

.github/workflows/create_agenda.yml

@@ -0,0 +1,18 @@
+# TODO: 'schedules' will need to be updated to coincide with the meeting frequency
+
+name: Schedule TSC meetings
+on:
+  workflow_dispatch:
+#  schedule:
+#    - cron: '0 0 * * *'
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: pkgjs/meet
+      with:
+        token: ${{ secrets.GITHUB_TOKEN }}
+        schedules: 2020-05-14T17:00:00.0Z/P4W
+        createWithin: P1D
+        issueTitle: "TSC Meeting <%= date.toFormat('yyyy-MM-dd') %>"
+        agendaLabel: meeting-agenda

.github/workflows/repolinter.yml

@@ -0,0 +1,23 @@
+name: Weekly Lint repository
+on: 
+  schedule:
+    - cron: "0 0 * * 0"
+  workflow_dispatch:
+
+jobs:
+  repo-lint:
+    name: "repolint"
+    runs-on: ubuntu-latest
+    steps:
+      - name: "Checkout repo"
+        uses: actions/[email protected]
+        with:
+          fetch-depth: 0
+      - name: "Install Node.js"
+        uses: actions/setup-node@v1
+        with:
+          node-version: '12.x'
+      - name: "Install repolinter"
+        run: npm install -g todogroup/repolinter#080524e48d60f211895c3d7271133a4f2f9bf3c4
+      - name: "Run repolinter"
+        run: repolinter lint --dryRun -g $GITHUB_SERVER_URL/$GITHUB_REPOSITORY

.github/workflows/send_agenda.yml

@@ -0,0 +1,16 @@
+name: Send TSC meeting agenda to email list
+on:
+  issues:
+    types: [opened]
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: timheuer/issue-notifier@v1
+      env:
+        SENDGRID_API_KEY: ${{ secrets.SENDGRID_API_KEY }}
+      with:
+        fromMailAddress: '[email protected]'
+        toMailAddress: '[MAILING LIST EMAIL]'
+        subject: 'TSC meeting agenda'
+        labelsToMonitor: 'meeting'

.gitignore

@@ -0,0 +1,27 @@
+# General
+.DS_Store
+.AppleDouble
+.LSOverride
+
+# Icon must end with two \r
+Icon
+
+# Thumbnails
+._*
+
+# Files that might appear in the root of a volume
+.DocumentRevisions-V100
+.fseventsd
+.Spotlight-V100
+.TemporaryItems
+.Trashes
+.VolumeIcon.icns
+.com.apple.timemachine.donotpresent
+
+# Directories potentially created on remote AFP share
+.AppleDB
+.AppleDesktop
+Network Trash Folder
+Temporary Items
+.apdisk
+

CHANGELOG.md

@@ -0,0 +1,14 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+### Added
+
+### Changed
+
+### Removed

CODE_OF_CONDUCT.md

@@ -0,0 +1 @@
+All	participants agree to abide by the Code of Conduct available at https://lfprojects.org/policies/code-of-conduct/. Please contact [email protected] to report any violations or concerns.

COMMITTERS.csv

@@ -0,0 +1 @@
+Name, Email, Github ID

CONTRIBUTING.md

@@ -0,0 +1,34 @@
+_Use this file to detail how to make a contribution to the project. The structure below is generally recommended, but can be changed to meet the needs of the project_
+
+# Contributing to PROJECT NAME
+
+Thank you for your interest in contributing to PROJECT NAME. This document explains our contribution process and procedures:
+
+* [How to Contribute a Bug Fix or Change](#How-to-Contribute-a-Bug-Fix-or-Change)
+* [Development Workflow](#Development-Workflow)
+* [Coding Style](#Coding-Style)
+
+For a description of the roles and responsibilities of the various members of the PROJECT NAME community, see the [governance policies], and for further details, see the project's [Technical Charter]. Briefly, Contributors are anyone who submits content to the project, Committers review and approve such submissions, and the Technical Steering Committee provides general project oversight.
+
+If you just need help or have a question, refer to [SUPPORT.md](SUPPORT.md).
+
+## How to Contribute a Bug Fix or Change
+
+To contribute code to the project, first read over the [governance policies] page to understand the roles involved. 
+
+Each contribution must meet the [coding style] and include..
+
+* Tests and documentation to explain the functionality.
+* Any new files have [copyright and license headers]
+* A [Developer Certificate of Origin signoff].
+* Submitted to the project as a pull request.
+
+PROJECT NAME is licensed under the [LICENSE NAME](LICENSE.md) license. Contributions should abide by that standard license.
+
+Project committers will review the contribution in a timely manner, and advise of any changes needed to merge the request.
+
+
+[governance policies]: GOVERNANCE.md
+[Technical Charter]: tsc/CHARTER.md
+[copyright and license headers]: https://github.com/lf-energy/tac/blob/main/process/contribution_guidelines.md#license
+[Developer Certificate of Origin signoff]: https://github.com/lf-energy/tac/blob/main/process/contribution_guidelines.md#contribution-sign-off

GOVERNANCE.md

@@ -0,0 +1,70 @@
+*NOTE: This document is intended to provide an example governance structure for any LF Energy Foundation project to consider as a starting point. All projects hosted by LF Energy Foundation are not bound by these governance polices, but in absence of any prior governance structure should consider this as a recommended structure*
+
+# Overview
+
+This project aims to be governed in a transparent, accessible way for the benefit of the community. All participation in this project is open and not bound to corporate affilation. Participants are bound to the project's [Code of Conduct].
+
+# Project roles
+
+## Contributor
+
+The contributor role is the starting role for anyone participating in the project and wishing to contribute code.
+
+# Process for becoming a contributor
+
+* Review the [Contribution Guidelines] to ensure your contribution is inline with the project's coding and styling guidelines.
+* Submit your code as a PR with the appropriate DCO signoff
+* Have your submission approved by the committer(s) and merged into the codebase.
+
+## Committer
+
+The committer role enables the contributor to commit code directly to the repository, but also comes with the responsibility of being a responsible leader in the community.
+
+### Process for becoming a committer
+
+* Show your experience with the codebase through contributions and engagement on the community channels.
+* Request to become a committer. To do this, create a new pull request that adds your name and details to the [Committers File] file and request existing committers to approve.
+* After the majority of committers approve you, merge in the PR. Be sure to tag the whomever is managing the GitHub permissions to update the committers team in GitHub.
+
+### Committer responsibilities
+
+* Monitor email aliases (if any).
+* Monitor Slack (delayed response is perfectly acceptable).
+* Triage GitHub issues and perform pull request reviews for other committers and the community.
+* Make sure that ongoing PRs are moving forward at the right pace or closing them.
+* In general continue to be willing to spend at least 25% of ones time working on the project (~1.25 business days per week).
+
+### When does a committer lose committer status
+
+If a committer is no longer interested or cannot perform the committer duties listed above, they
+should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of
+the committers per the voting process below.
+
+## Lead
+
+The project committers will elect a lead ( and optionally a co-lead ) which will be the primary point of contact for the project and representative to the TAC upon becoming an Active stage project. The lead(s) will be responsible for the overall project health and direction, coordination of activities, and working with other projects and committees as needed for the continuted growth of the project.
+
+# Release Process
+
+Project releases will occur on a scheduled basis as agreed to by the committers.
+
+# Conflict resolution and voting
+
+In general, we prefer that technical issues and committer membership are amicably worked out
+between the persons involved. If a dispute cannot be decided independently, the committers can be
+called in to decide an issue. If the committers themselves cannot decide an issue, the issue will
+be resolved by voting. The voting process is a simple majority in which each committer receives one vote.
+
+# Communication
+
+This project, just like all of open source, is a global community. In addition to the [Code of Conduct], this project will:
+
+* Keep all communucation on open channels ( mailing list, forums, chat ).
+* Be respectful of time and language differences between community members ( such as scheduling meetings, email/issue responsiveness, etc ).
+* Ensure tools are able to be used by community members regardless of their region.
+
+If you have concerns about communication challenges for this project, please contact the committers.
+
+[Code of Conduct]: CODE_OF_CONDUCT.md
+[Committers File]: COMMITTERS.csv
+[Contribution Guidelines]: CONTRIBUTING.md

INSTRUCTIONS.md

@@ -0,0 +1,15 @@
+# Instructions for using this template
+
+1) Review and update (README.md) and (tsc/README.md) with the [PROJECT NAME] and [PROJECT LOGO], as well as the contents for the various sections.
+2) To enable creating meeting agendas from GitHub issues, follow steps 3-5.
+3) In the [meeting agenda template](.github/ISSUE_TEMPLATE/meeting.md), update `[PROJECT NAME]` and add the TSC members under the ['Attendance' section](.github/ISSUE_TEMPLATE/meeting.md#attendance).
+4) Set the meeting date and time, along with the cadence in the [build agenda workflow](.github/workflows/build_agenda.yml) in the key `schedules:` that specifies a ISO-8601 interval. Examples for repeating:
+
+```
+# start 2020-04-22 at 16:00, repeat every 2 weeks
+schedules: 2020-04-22T16:00:00.0Z/P2W
+# start 2020-04-22 at 16:00, repeat every 7 days
+schedules: 2020-06-22T16:00:00.0Z/P7D
+```
+5) In the [send agenda workflow](.github/workflows/send_agenda.yml), update `[PROJECT NAME]` and `[MAILING LIST EMAIL]`. 
+6) Any items with the label `meeting` will be added to the agenda automatically when it is built the day prior to the meeting.