You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The following process (originally developed by the Technology Architecture Task Force) is recommended for management of GitHub issues during the development of a ToIP deliverable (such as a specification, template, white paper, etc.)

This process is recommended for issues management even if the deliverable itself is not in GitHub. For example, for a Google doc, any issue that cannot adequately be handled by a comment thread (or whose discussion and resolution should be more permanent and visible) can use this process provided that the GitHub concept of a PR (pull request) is turned into some agreed-upon final action on the Google doc.

Process

  1. The Working Group or Task Force ("group") shall appoint an Editors team who will take on the job of reviewing GitHub issues and proposing when an issue is ready for closure.
    1. The members of this team should be published on the group's home page and also acknowledged in the final deliverable for their extra contribution as Editors.
  2. The Editors shall agree on a set of labels to prioritize issues for resolution (see below).
  3. While any group member can and should apply those labels to issues, the Editors shall ensure that labels are applied consistently, fairly, and timely.
  4. If an issue appears to require in-depth discussion and analysis, the Editors shall propose (or solicit) a subgroup to tackle that issue and come back to the group with a proposed resolution. This subgroup shall:
    1. Self-organize on their choice of communication channel (e.g., Slack multi-person direct message group or new Slack channel), hold Zoom meetings, and/or use one or more Google docs in the ToIP WG folder space to do their work.
    2. Develop an approach to solving the issue (along the lines of an ISO "Technical Report", i.e., issue mandate, technical policy, high-level requirements and expected outcomes)
    3. Return with a proposal (text and diagrams) for resolution of the issue (along the lines of an ISO "Technical Spec"). Ideally the proposal is written up in a form that can be: a) turned easily into a PR (for a GitHub document), or b) copy-and-pasted as a revision to a Google doc or other deliverable format.
  5. When the Editors believe there is consensus about the proposed resolution of an issue, they will apply the label last-call-for-close to that issue.
  6. Once that label has been applied, a group member MUST object within 5 calendar days to reopen discussion of the issue.
  7. If there is no objection within 5 calendar days, the proposed resolution will be applied to the deliverable by one of the Editors and the issue will be closed with no further discussion.

Issue Labels

The following set of labels are recommended as a starter set that can be augmented by additional group- or deliverable- specific labels.

  • priority-1
  • priority-2
  • priority-3
  • defer-to-V2
  • editorial
  • substantial
  • correction
  • needs-special-group
  • needs-proposal
  • needs-PR
  • PR-exists
  • last-call-to-close


  • No labels