Skip to content

WG Responsibilities

Overview

Each major stage of the open-source process is reviewed by a WG or committee to ensure a base level of consensus. The specific group that is required to provide consensus and the level of consensus required dependent upon the standardization path adopted for the project.

Example

An NTCIP experimental specification can be approved at the NTCIP WG level for all stages while an NTCIP standard requires Joint Committee approval for the project approval and release approval.

The stages within the open-source process include:

  • project approval
  • issue prioritization
  • pull-request approval
  • release approval

Committee Requirement

When starting a project, the committee shall:

  • Identify a responsible working group
  • Identify one or more maintainers

Update style

WG Requirement

The WG shall define the time within which the maintainer is expected to triage and respond to submitted comments.

Project Approval

An appropriate WG or committee shall approve the formation of a project prior to establishing the SDO GitHub repository for the project.

The appropriate WG or committee should be identified in policies adopted by any SDO adopting the ITS Open-Source Process.

Note

A contributor can establish their own GitHub repository for the project before formal approval to allow WG members to gain a better idea of what is being proposed.

NTCIP Guidance

NTCIP 8001 identifies the appropriate WG or committee for NTCIP open-source projects.

Project Tailoring

The WG shall tailor parameters for the project, including:

  1. the project schedule
  2. the time within which the maintainer is expected to triage and respond to submitted issues and discussion items
  3. whether the project is to use the mike version control system and, if so, which versions are to be maintained within this system

Note

Standards should always use a version control system to maintain historic versions of a standard. However, this process can also be used to maintain informative websites that might not need to provide historic versions.

Example

The list of versions maintained can include: - every release approved by the WG (with latest pointing to the most recently approved version) - every pre-release since the last release - other designated interim releases (e.g., UCD versions)

Issue Prioritization

A WG should oversee the prioritization of significant issues for each of its open-source projects.

A WG may provide guidance to its maintainer as to what constitutes a significant issue and how various issues should be handled.

Note

Many issues can be prioritized by the maintainer without involving the WG; however, when major issues arise that affect the direction of the project, it is best to obtain direction from the WG to ensure resources are managed properly.

Pull-Request Approval

The WG responsible for the open-source project shall approve each pull request prior to its merge into the SDO repository.

The WG responsible for the open-source project shall establish its policies on what constitutes a pull-request approval.

Note

A pull-request approval typically requires simple majority with no sustained objections.

GitHub Guidance

This can be achieved by requiring a minimum number of approvals within GitHub among a designated set of voting members.

Approve Releases

The WG responsible for the open-source project shall approve each version of a project prior to it being tagged as a release.

The WG responsible for the open-source project shall establish its policies on what constitutes a release approval.

Note

Releases can be made from any branch, not just the main branch.

Example

A release approval can be as simple as WG consensus or can require a formal ballot according to the processes adopted by the full committee.