Skip to content

Working Group Operations (wg ops)

Jump to bottom
sean roberts edited this page Feb 6, 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

OMF Release

TBD

OMF Mobility-Data-Specification project

A project of the Open Mobility Foundation (OMF), is a set of Application Programming Interfaces (APIs) focused on dockless e-scooters, bicycles and carshare. Inspired by projects like GTFS and GBFS, the goals of MDS are to provide a standardized way for municipalities or other regulatory agencies to ingest, compare and analyze data from mobility service providers, and to give municipalities the ability to express regulation in machine-readable formats.

MDS-core project

LADOT MDS implementation for contribution to the Open Mobility Foundation. It represents what is currently up and running for Los Angeles production MDS as well as new features under development. Includes the following:

A current LADOT implementation of all MDS endpoints Development versions of mds-audit, mds-policy, and mds-compliance MDS logging (mds-logger), daily metrics (mds-daily) and Google sheet reporting app for technical compliance.

  • City Services working group manages the mds-core project, email [email protected] and email archive
  • Next release TBD
  • Release 0.0.4, publish date of 03 Oct 2019, with unknown 0.0.4 features
  • Release 0.0.3, publish date of 10 Sept 2019, with unknown 0.0.3 features

MDS compliance mobile project

Project used to verify that the data provided to MDS by mobility service providers actually matches what's happening on the street.

Currently this takes two forms: 1) Monitoring Vehicle Compliance as Reported by Providers 2) Auditing Vehicle Trips

OMF Privacy, Security, and Transparency Committee

Advise the Foundation on principles and practices that ensure the secure handling of mobility data

Mobility Data Specification 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

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

omf-mds-github-footer

MDS Wiki Home

MDS Links

Working Groups

2.1.0 Release

2.0.0 Release Plan

1.2.0 Release Plan

1.1.0 Release Plan

1.0.0 Release Plan

0.4.1 Release Planning Meetings

0.4.0 Release Planning Meetings

0.3.2 and earlier Release Planning Meetings

Clone this wiki locally