Skip to content

Technical FAQs

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

Contents

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