Working Group Operations (wg ops)
This team is for everyone involved in managing OMF working groups. We don't have formal meetings yet.
- Mailing list [email protected]
- Mailing list archive
- OMF Bylaws 2019
- OMF Mission/Vision 2019
- OMF Plans 2019
- MDS release guidelines
- MDS release guidelines slidedeck
- MDS release notes, all releases
- MDS contributor guidelines
| project | version | release date | features | code | meetings |
|---|---|---|---|---|---|
| OMF | ??? | ??? | arch landscape | ??? | N/A |
| mds provider services - city services | 0.3.1 | 21 May 2019 | 0.3.1 feature plans - release notes - 28 milestone issues and PRs | 0.3.x branch | N/A |
| mds provider services - city services | 0.3.2 | 27 Jun 2019 | release notes - 11 milestone issues and PRs | 0.3.x branch | N/A |
| mds provider services - city services | 0.4.0 | 31 Oct 2019 | release notes - 55 milestone issues and PRs | MDS master branch | N/A |
| mds provider services | 0.4.1 | ??? | arch landscape - milestone issues and PRs | under development MDS dev branch | bi-weekly meetings |
| mds city services | 0.4.1 | ??? | arch landscape - milestone issues and PRs | under development MDS dev branch | bi-weekly meetings |
| mds provider services | 0.5.0 | ??? | arch landscape - milestone issues and PRs | under development MDS dev branch | bi-weekly meetings |
| mds city services | 0.5.0 | ??? | arch landscape - milestone issues and PRs | under development MDS dev branch | bi-weekly meetings |
| mds core | 0.0.3 | 10 Sept 2019 | N/A | release/0.0.3 branch | N/A |
| mds core | 0.0.4 | 03 Oct 2019 | N/A | master branch | N/A |
| mds core | ??? | ??? | arch landscape | under development develop branch | bi-weekly meetings |
| mds compliance mobile | ??? | ??? | arch landscape | under development master branch | bi-weekly meetings |
| Lacuna mds-core | ??? | ??? | N/A | under development develop branch | N/A |
The project operates on a six-week release cycle for both major updates (0.x) and patches (0.x.y). In general, major updates (0.x) are expected no more than once per quarter. The release cycle is broken down as follows:
week 1-2 - proposals Contributors submit proposals for inclusion in the release cycle in the form of pull requests and issues tagged. If known, note what release you intended a proposal for in its description. Maintainers will tag appropriate pull requests and issues with the Milestone for the upcoming release. Proposals should come with enough explanation to allow all stakeholders to understand intent and implementation strategy.
weeks 3-9 - consensus building, refinement, and implementation Contributors will provide feedback on proposals. Where possible, discussion will happen via GitHub. Weekly calls will support dialog around more complex or controversial issues. By the end of week 4, all active proposals must be in the form of a pull request. Proposals can be withdrawn or split apart for inclusion in future releases.
week 10-11 - decision making The week will start with an in-person/web conference work session for all contributors to review and discuss current proposals. Goal is to achieve consensus where possible, or to clearly articulate areas of disagreement where not. Minor changes may be accepted at this stage if they bring contributors to consensus.
At the conclusion of week 9, the release partner will review all items for which consensus was not reached and provide a recommended release plan to maintainers for approval. Any remaining approved pull requests will be merged, and a maintainer or release partner will open a pull request containing release notes for the proposed release.
week 12 - release
Documentation will be updated, release notes will be merged, a tag will be created and master updated to point to it, and the new version will be formally released. See Release Checklist for details about the release process.
The release announcements and process schedule will be communicated via mds-announce Google Group. People wishing to stay informed should join the group for updates. Timing of web conference and in person work sessions will be communicated via mds-announce as well.
The following best practices are intended to create clarity around each release cycle:
- Categorize issues and PRs under an associated [Milestone][mds-milestones] for the release
- Assign a due date for said Milestone that aligns with proposed release date
- Pull requests and release notes should include a summary of the major changes / impacts associated with the change or release
- Proposed changes should come in the form of PRs to give the community ample awareness and time for feedback
