Re: process for second pull request

The chairs are aware that this is a tricky process to keep up with - 
thanks for the overview Alastair. Regarding Leonies comment about the 
outcome of calls and how to track that, as e'one cannot make a call - if 
there were relevant outputs these could be included as comments by the 
SC manager within the issues or the PR (whatever is relevant).

HTH

Josh

> Alastair Campbell <mailto:acampbell@nomensa.com>
> 13 February 2017 at 10:08
>
> Well, that is a problem already. If it is on the pull request then 
> everything can be included there:
>
> - Link to the previous issue page at the top;
> - Comments from the survey or call can be added as comments on the PR, 
> e.g. https://github.com/w3c/wcag21/pull/100#issuecomment-278184960
> - Updates to the pull request (i.e. new commits) still go into the 
> same pull request.
> - The description at the top of the PR should be kept up to date with 
> the latest SC text.
>
> It does take time for the SC manager gather everything into one place, 
> but I can’t see a better alternative at the moment. At least now I (as 
> SC manager) can edit the description on the PR so anyone coming to it 
> can see the latest text.
>
> Cheers,
>
> -Alastair
>
> Léonie Watson <mailto:tink@tink.uk>
> 13 February 2017 at 09:58
>
>
> The problem is that the discussion is then scattered between the 
> original Github issue, n number of PR threads, plus a conference call 
> or two and quite possibly some discussion on the email list.
>
>
>
> Léonie
> Alastair Campbell <mailto:acampbell@nomensa.com>
> 10 February 2017 at 11:00
>
> Because Jim put up all the LVTF SCs as issues, we had the problem of 
> the SC manager not being able to update the description, and it made 
> Jim a bottleneck for updates. (He was good at making updates, but it 
> just added another step across timezones.)
>
> So long as the SC manager makes the pull request, they should be able 
> to keep the description up to date, e.g:
> https://github.com/w3c/wcag21/pull/100
>
> I think that’s the best approach… unless SC managers can’t do the pull 
> request?
>
> -Alastair
>
> Léonie Watson <mailto:tink@tink.uk>
> 10 February 2017 at 10:35
> This may not work for WCAG, but in case it helps..
>
> A project I work on has a Github issue for each thing to be reviewed. 
> The content to be reviewed is the first comment in the issue. Whenever 
> the draft is updated (based on Github comments or feedback from other 
> sources), the first comment in the thread is edited to reflect the 
> changed content.
>
>
> Providing the SC manager is able to edit the issue thread, they would 
> be the ones responsible for updating the draft SC in response to 
> feedback from different places. It does mean that one person has to be 
> responsible for updating the draft, but the advantage is that all 
> comments are kept in the one thread, instead of split over the 
> original issue and multiple subsequent PR threads. It also means there 
> is only ever one definitive place where the content to be reviewed can 
> be found.
>
>
>
>
> Léonie
> Andrew Kirkpatrick <mailto:akirkpat@adobe.com>
> 9 February 2017 at 23:00
> We are also worried about tracking all the comments so people can find 
> them. Please feel free to advice on that too!
>
> This is one of the advantages of not opening a second pull request – 
> the comments stay with the pull request. There is a transition when 
> the pull request is made in that the comments initially were in the 
> issue, but once the pull request is opened:
>
> 1) the issue should be closed, and a link to the pull request added to 
> the issue
> 2) Comments should be made on the pull request and not on the issue.
>
> Thanks,
> AWK
>
>
> ---- On Thu, 09 Feb 2017 21:29:10 +0200 *Andrew 
> Kirkpatrick<akirkpat@adobe.com <mailto:akirkpat@adobe.com>>* wrote ----
>
>

-- 
Joshue O Connor
Director | InterAccess.ie