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

Process

Process

1. Setup. First, the Working Group or Task Force ("group") needs to contact the ToIP Foundation Program Manager (currently Elisa Trevino) to request setup of a GitHub repo for the deliverable. The group should also request that Github Discussions be turned on for the repo so the Discussions feature is available to the group for Q&A or other discussions that are not necessarily issues (but can be easily converted into formal GitHub issues when needed).
2. Editors. The Working Group or Task Force ("group") shall appoint appoints an Editors team who will take on the job of reviewing GitHub issues and reviewing issues, assigning group members to an issue, and proposing when an issue is ready for closure.
   1. As a general rule, any one member of the Editors team can perform an action permitted under this role — it does not require consensus among all the Editors. However the Editors are trusted to use their judgement about when an action should be decided by consensus of the editors or consensus of the whole group.
   2. The members of this the Editor team should be published on the group's home page and also acknowledged in the final deliverable for their extra contribution.
3. Maintainers. The Editors shall in turn appoint a set of Maintainers who have the Github skills (and the necessary permissions) to accept PRs and publish versions of the deliverable. Typically a subset of the Editors serve as Maintainers, but all the Editors can serve in this role, or it can be assigned to others in the group.
4. Labels. The Editors shall should agree on a set of labels to categorize and prioritize issues for resolution (see the recommended starting list below). While any group member can and should be able to apply those labels to issues, it is the Editors shall job to ensure that labels are applied consistently, fairly, and timely.
5. Assignments. Any group member should be able to assign an issue to another group member. It is the Editors job to try to make sure issues have assignees, and that issues are assigned consistently, fairly, and timely. If an assignee is not progressing with an issue, the Editors can re-assign it as necessary.
6. Subgroups. If an issue appears to require in-depth discussion and analysis, the Editors shall should propose (or solicit) a subgroup to tackle that the issue and come back to the group with a proposed resolution. This subgroup shallshould:
   1. Self-organize on their choice of communication channel Keep as much of their discussion as possible within GitHub Issues — and, if necessary, Github Discussions. If any substantive discussions take place in other channels (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) or proposals are drafted outside of GitHub (e.g., in a Google doc), they must be copied into GitHub to create a permanent public audit trail.
   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 easily: 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.
7. Closure. When the Editors believe there is consensus about the proposed resolution of an issue, they will apply one of the Editors applies the label last-call-forto-close to that issue.
   1. Once that label has been applied, a group member MUST object to closure by making a comment on the issue within 5 calendar days to reopen discussion of the issue.
   2. If there is no objection within 5 calendar days, the proposed resolution
   will
   1. shall be applied to the deliverable by one of the
   Editors and
   1. Maintainers and one of the Editors shall close the issue
   will be closed
   1. with no further discussion.
   2. If there is an objection, the Editors will take it to a group meeting to reach final consensus on closure.

Issue Labels

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

...