Skip to content

Working Group Operations (wg ops)

sean roberts edited this page Mar 13, 2020 · 32 revisions

This team is for everyone involved in managing OMF working groups

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

Working Group Communication and Workflow

How to run a meeting:

  • Use the meeting template off the wiki for each new meeting agenda
  • The OMF public calendar is where the meetings are published. Verify the meeting information there is correct.
  • Publish the meeting agenda to the mailing list at least one day before the meeting
  • As each meeting is starting ask for one person to takes notes and ask the rest to add their names to the attendance section of the wiki page
  • After each meeting, the chair updates next meeting date on the top of the wiki page

Working Group Leadership:

  • Each WG is administered by a WG Steering Committee (“WGSC”)
  • The WG Steering Committee members can be an employee or representative of a Member of the Foundation, must be nominated by the Member who employs or engages them, and serve subject to the consent of that Member.
  • WGSC shall elect one or two chairs from among its members, who serve at the pleasure of the WGSC members 
  • WGSC composed of five Contributors
  • WGSC is responsible for assigning maintainer and reviewer roles to Contributors of the WG, and determining the status of Deliverables.

How to run the working group day to day:

  • The release announcements and process schedule will be communicated via mds-announce
  • Deliverables from a WG are developed by its Contributors
  • Maintainers review and approval of contributions
  • Contributors fork the repository, make their PR on the OMF repository
  • Chairs and maintainers triage the backlog of issues and PRs
  • 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
  • Monthly, the chair publishes the coming month meeting schedule

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
Clone this wiki locally