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 Documentation

1. OMF Bylaws 2019
2. OMF Mission/Vision 2019
3. OMF Plans 2019
4. MDS release guidelines
5. MDS release guidelines slidedeck
6. MDS release notes, all releases
7. MDS contributor guidelines

OMF Release

TBD

OMF MDS Provider and MDS City Services wg

• MDS Provider email [email protected] and email archive
• MDS City Services email [email protected] and email archive
• Release 0.3.1, published on 21 May 2019, with 0.3.1 feature plans
  • release notes
  • 28 milestone issues and PRs
  • 0.3.x branch
• Release 0.3.2, published on 27 Jun 2019, with unknown 0.3.2 features
  • release notes
  • 11 milestone issues and PRs
  • 0.3.x branch
• Release 0.4.0, published on 31 Oct 2019, with unknown 0.4.0 features
  • release notes
  • 55 milestone issues and PRs
  • MDS master branch
• Release 0.4.1, planned publish date of 01 Mar 2020, with unknown 0.4.1 features
  • release notes TBD
  • milestone issues and PRs
  • under development MDS dev branch
  • bi-weekly meetings
• Release 0.5.0, planned publish date of 24 Jun 2020, with unknown 0.5.0 features
  • release notes TBD
  • milestone issues and PRs

MDS-core project

• Release 0.0.3, publish date of 10 Sept 2019, with unknown 0.0.3 features
  • release notes TBD
  • milestone issues and PRs TBD
  • release/0.0.3 branch
• Release 0.0.4, publish date of 03 Oct 2019, with unknown 0.0.4 features
  • release notes TBD
  • milestone issues and PRs TBD
  • master branch
• Next release TBD
  • under development develop branch

MDS compliance mobile project

• Next release TBD
  • under development master branch

OMF Privacy, Security, and Transparency Committee

• Privacy, Security, and Transparency Committee email [email protected] and email archive

Working Group Release Schedule

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.

Working Group Communication and Workflow

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

Daily triage issues PRs for labels milestones

• Review the project backlog for unassigned issues and PRs
• It should be obvious in most cases which API and change type the item should be assigned
• Allow the working group chairs to assign items to a milestone

Labels, milestones (for issues, PRs)

Each issue and PR has these tag options:

API type: Most have either one of these labels

• agency
• policy
• provider

Change type: Most have either one of these labels

• bug
• enhancement
• documentation

Other: These are one offs that only a few get assigned

• JSON Schema
• question
• state-machine
• OMF Transfer

Operations: These are one offs that only a few get assigned

• admin
• duplicate
• wontfix

Each issue and PR must have one of these milestones:

• 0.4.1
• 0.5.0
• Future