Proposal for managing GitHub issues & comments

I'd like to propose a paradigm shift in the way the group is currently managing GitHub issues.  My aim is to increase momentum of productive discussion and resolution.  I do not claim that this is a solution to tool usage problems for certain disabilities or personal preference, but hope members agree it is a calculated step in the right direction.

Michael's proposal addresses a few very key issues, but the problems stemming from a long thread of comments on one GitHub issue per SC remain.  There are many months of discussion left as everyone knows, so these problems are going to get much worse by sticking to this restriction.  I propose we shed it, and allow issues to be raised for each distinct concern related to the current repository, which is fundamentally how most issue trackers are setup to function.  Some advantages are:

*       Shorter, more focused comment threads hopefully much easier to read

*       Sub-issues much less likely to be missed or not addressed

*       "Easy" issues can be quickly resolved and closed, leaving the WG and task force calls to focus on the list of current feedback

*       Reviewers do not waste time reading historical comments already addressed in the current SC version (since these should be in a closed issue)

*       Number (and type) of open issues per SC provides a simple readiness metric

Issue management can then be handled using labels and milestones:

1.       Create labels for each SC short name, and assign to issues accordingly.  This allows anyone to easily see the distinct issues that have been raised regarding a particular criterion, and which are open or closed.  Links can be provided in the wiki table to these custom searches.  It also allows better tracking of issues that may affect multiple criteria, e.g. a common glossary definition, since multiple labels can be applied to one issue.

2.       Create 3-4 labels to indicate the category of a raised issue, such as:

a.       Editorial: Spelling, grammar, glossary links, general structure, or anything else that does not raise an issue with the SC concept (these should be able to be addressed quickly and online only so as to not waste call time)

b.      Conflict: Issue raised is related to conflict, overlap, or redundancy with another existing or proposed SC

c.       Implementation: Issue raises questions about implementation, e.g. technology independence, too restrictive, etc.

d.      Testability: Issue specifically relates to problems with the testing method

3.       Consider also using milestones related to our 2.1 release timetable.  The difficult topic of how to assign issues to milestones I'll leave to the chairs (you're welcome), but this would certainly help reviewers prioritize where they spend their time.

Write access to a repo is needed to manage labels so it is important to increase the number of people with sufficient permissions, otherwise still many issues may go unaddressed.  These same users would also need to make sure to pay attention to closing and merging duplicate issues as with any other large open source projects.

Of course, the major disadvantage of such an approach is the risk of high volume and bloat, but in my opinion the advantages outweigh this risk.
If the group decides to take this or a similar route, We might ask that users troll their existing GitHub and/or survey comments for criteria in the FPWD, and create new issues for each distinct problem to be addressed, taking care not to duplicate.  Appropriate labels can be applied and then the original SC issue closed and future workflow revolves around the new issues.

Thoughts?

Steve