Re: Update to SC Manager page, with video tutorials

The issue certainly needs to have a link to the forked branch that contains the changes that are being integrated.

In a straightforward case there is a proposal issue, and after some discussion on different bits of it the SC manager creates the forked branch and links to the branch from the issue. People take a look at the fork and there are no issues with it, so the SC manager creates a pull request and once that is done, closes the original issue, and linking to the pull request in the closing message.

If there are comments and changes from that point on, they can be made in the pull request and the SC manager can address the changes that are needed there.


Andrew Kirkpatrick
Group Product Manager, Standards and Accessibility

From: David MacDonald <<>>
Date: Friday, December 16, 2016 at 16:32
To: Andrew Kirkpatrick <<>>
Cc: WCAG <<>>
Subject: Re: Update to SC Manager page, with video tutorials

I'm not sure how we are proceeding with SC proposals. When we fork, the issues list doesn't follow the fork apparently... and that is where the SC are currently located ... Should we just make a page up in the forked version with the proposed SC, or should we add it to the WCAG 2 where we think it should go?

David MacDonald

CanAdapt Solutions Inc.

Tel:  613.235.4902



  Adapting the web to all users

            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

On Fri, Dec 16, 2016 at 3:27 PM, Andrew Kirkpatrick <<>> wrote:
I’ve updated the SC managers page ( and added two tutorials for using GitHub.

The first is dealing with how to fork the WCAG 2.1 repo so you will have a version that is outside of the official W3C repo.
Why is this needed?: Only a few people have rights to edit the W3C/WCAG21 repository, so if someone other than Michael/Josh/me want to they need to make edits separately and then submit a request (a pull request) that the changes that they made in their version (their forked version) are integrated into the main repository.

The second video is dealing with how to use branches in GitHub.
Why is this needed?: When you submit a pull request, you are asking that the changes made in your forked version be integrated into the main repository. If you just work with the main (master) branch and add two SC’s and correct 5 spelling errors and submit a pull request then the group isn’t able to accept just one of the SC in the pull request. As a result, we are asking that SC managers create a new branch in their fork for each SC. That way you will be able to submit a pull request that is focused on just the SC and can be accepted without bringing in other content that may not be approved yet.

I’m working on additional videos to help – suggestions for topics appreciated. Also, I’m not a professional voice artist, audio engineer, or training video developer, so if you are thinking that the production quality could be better, you’re probably right…  Nonetheless, I hope these help.


Andrew Kirkpatrick
Group Product Manager, Standards and Accessibility

Received on Monday, 19 December 2016 14:18:46 UTC