Re: Co-ordinating feedback

On 07/12/2016 4:40 AM, Alastair Campbell wrote:
>
> > Could you set this up in a wiki or some other highly accessible 
> application that will at least generate proper HTML table markup?
>
> Hi Jason,
>
> Sure, it was the concept rather than format I was worried about. The 
> only thing is that wiki format for tables is really delicate, so 
> having lots of people edit the same page could lead to some terrible 
> markup!
>
> Before launching in on this (and having had sleep now), perhaps I 
> should give github a chance? (Nudging *Michael*, who thought we might 
> be able enabled editing of the issue by the assignee.)
>
I want to talk through options with the chairs and come back with a 
proposal. I think editing the issue directly has some problems:

  * It seems you have to have owner access to be able to edit the
    original issue, if you're not the one who filed it. Typically we
    don't give owner access to so many people.
  * Editing the original issue destroys history, as I don't think GitHub
    archives old versions for issues.
  * Issues are probably not the best way to store the richer structure
    we're using anyways. It works, but when it gets time for editing I
    think it's complex.

An alternate proposal has been to simply add new versions of the SC as 
new comments on the proposal. That preserves history but will make it 
hard to follow the comment thread I think.

I think we need to come up with another approach - put the SC in the 
wiki and have the issue point to it, or set up a way to edit the SC as 
individual pages within GitHub and have the issue point to those. That 
in turn might require us to set up branches, protect the working 
branches, etc. I plan to discuss this with the chairs tomorrow and see 
if we can come up with something we think will work.
>
> The concept was to make sure some people were looking at each SC, draw 
> a line under a round of reviews, and have a new round with refined SCs.
>
> In github terms I think that would mean:
>
> -Setup a milestone (perhaps “Review round 1” or similar), set all 
> current issues to that milestone;
>
> -Direct people to review SCs with the least comments [1];
>
> -If reviewers are happy with the SC (or a revised version in the 
> comments), they add a positive comment to say so.
>
> -If reviewers think there are issues, add comments about that.
>
> -The SC manager can rebut the comments or refine the SC in the comments.
>
> -SCs which need discussion are raised as agenda items for the weekly 
> call. (E.g. I would raise the contrast one for next week, as there is 
> a critical concept that needs to be accepted for it to work.)
>
> -Once every SC has comments or thumbs up from (say) 5 people, we start 
> a new milestone.
>
> I’m not sure if it would be best to setup new issues for each SC and 
> close the old one, or transfer them across milestones? I suspect it 
> would be best to start a new issue for the SC, and link back to the 
> previous one at the top for historical discussion, but we could 
> probably do either on a case by case basis depending on how different 
> the SC is at the end of the round.
>
> It is also possible to construct searches such as: every SC I haven’t 
> commented on, which will help spread it around.
>
On the whole this proposal for process sounds good.
>
> My github-foo is not strong, especially around how milestones work, so 
> this is only an idea. Does it seem reasonable?
>
My github-foo isn't the greatest either, but I can say a little. I'm not 
sure if the milestones feature really helps us, because GitHub only 
counts an issue towards having reached the milestone when the issue is 
closed. If we're expecting various review rounds, that might not be the 
process we want. It might be that tags serve better, or that we'll have 
to do some of the progress tracking outside of the GitHub interface. 
Andrew loves spreadsheets...

Michael
>
> Cheers,
>
> -Alastair
>
> 1] 
> https://github.com/w3c/wcag21/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc 
>
>
> 2] Everything I haven’t commented on is: “is:issue is:open 
> -commenter:alastc”
>