Re: Proposal for managing GitHub issues & comments

Jason wrote:
> The only way to make this tractable is with an issue tracking tool. It used to be Bugzilla; now it’s GitHub;

Thanks Jason, I needed to be reminded of that concept. 

We have several systems, I think it is more important the process is clear than which tool(s) we are using.

Taking a little step back, I think the process (or user journey) is essentially:
1. Person (“Reviewer”) see an announcement or link,
2. Reviewer goes to the FPWD, and finds an SC of interest (or is directed to one), and wants to:
  2a. Find out more (e.g. more explanation of the SC text, benefits and/or test method), and/or
  2b. Comment.
3. SC manager / AGWG assesses comment.
  3a. Possible amendments to the SC / documentation.
  3b. Respond to the comment.
4. Publish next version.

And back to 1.

There are several key features needed for that:
- A place to list the new SCs, linking to the descriptions & place to comment. 
- An (easy to read) place to read about one SC, with it's related material.
- A comment system, i.e. a bug-tracking type system.

I think we have to use Github for the output, that's how specs are created, so that covers the list (i.e. the FPWD). It will need two links per SC: Where the extended description is, and where to comment (which will be the same for all of them I think? The github wcag21 new-issue page).

For reading the SC text and material I think we should be flexible, it should be a link to the most suitable place for the SC manager (or someone helping) to maintain it. That could be the wiki, a github issue, a github doc (like MATF used in the run up). I'm not against using Google docs for the place to read about an SC, but I think that makes the next step of comments and comment-management more difficult.

For comments I don't think we should tie them to the SC document itself, they need to be independent so we can mark them as duplicates, related, tag per version, close etc. Github is a lot better than Bugzilla! If each comment is a github issue, there could be a lot of them, but we can act on them each independently, reference previous issues etc.

If a comment/issue is resolved the SC manager can update the 'reading place' as they go along fairly ad-hoc, but they (or a nominee) will need to then update the SC text in the spec.

I think that's compatible with Michael's approach, but adding options for where the reading material is?

Cheers,

-Alastair

Received on Thursday, 16 March 2017 00:04:18 UTC