Re: Proposal for WCAG 2.1 editing / review process

+1 this looks good and should be easier to follow.

On Mon, Mar 13, 2017 at 7:44 PM, White, Jason J <jjwhite@ets.org> wrote:

> +1 likewise from me.
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Monday, March 13, 2017 7:05 PM
> *To:* Michael Cooper <cooper@w3.org>
> *Cc:* AG WG <w3c-wai-gl@w3.org>
> *Subject:* Re: Proposal for WCAG 2.1 editing / review process
>
>
>
> I think this makes sense.
>
> +1
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
> On Mon, Mar 13, 2017 at 2:20 PM, Michael Cooper <cooper@w3.org> wrote:
>
> I've been working with Andrew on ways to make the WCAG 2.1 source easier
> to manage proposals for SC. This still uses GitHub features, but should
> simplify some aspects of it and make it more possible for people to share
> the effort. I've set up a demonstration of what the files would look like
> at:
>
> https://github.com/w3c/wcag21/tree/structure_proposal/guidelines
>
> You see new subdirectories for "sc" and "terms" which contain files for
> each proposal - one file for each success criterion or term. The 2.1 stuff
> is in a "21" subdirectory to make it easier to find them among the 2.0
> stuff, which is in a 20 subdirectory. These files are included into the
> main guidelines document via a script include feature.
>
> To work on a success criterion, you would edit the file for the particular
> SC (and any terms if needed) - which is just a snippit of HTML. To help
> separate all the various pieces of work, you would also edit in a branch
> that just has the edits for that one SC. In the issue proposal for the SC,
> it would point (at the top of the issue) to the right place, so people know
> for sure where the latest version is both for review and for editing. We
> would give everyone in the WG access to edit these files, so we don't have
> the problem we've been having with people being unable to update the
> proposal with the latest version.
>
> To show what these files look like, the first one alphabetically is:
>
> https://github.com/w3c/wcag21/blob/structure_proposal/
> guidelines/sc/21/accidental-activation.html
>
> This is the file where edits to the proposals would be made. To see what
> the proposal looks like without raw HTML and the GitHub cruft, you can
> access the rawgit version of that same file:
>
> https://rawgit.com/w3c/wcag21/structure_proposal/guidelines/
> sc/21/accidental-activation.html
>
> We would make sure links to those are easy to find, and point to them from
> issues and surveys. SC managers would be able to update the proposal as
> needed, so we could designate these as the "current version" and avoid the
> questions we have now about where the latest version actually sits. Anybody
> in the WG would be able to pitch in and help out if needed. Once the
> content in these files was approved by the WG, we would simply merge them
> into the editors' draft (the editors would manage the process of making the
> include happen in the right place).
>
> This proposal still uses GitHub, which I know is challenging, but I think
> is nonetheless a lot easier:
>
>    - People can see rendered versions of proposed SC edits rather than
>    having to read HTML source;
>    - We can reference the files as the official "latest version" so
>    people don't have to look around through issue comments to find it;
>    - We can use the git history to easily look at older versions of the
>    proposal if needed;
>    - People can edit either online or locally;
>    - We don't have to deal with pull requests (and fragmentation of
>    comments);
>    - It's easier to find the right thing to edit rather than working with
>    the whole guidelines file as people had to do in the previous round;
>    - The permissions would be set so other people in the WG can help out
>    if people have tool difficulty.
>
> I wanted to give people an opportunity to look at this and see if it would
> help our process. It's not perfect, there are still complexities, but I
> think this structure allows us to support people around the complexities
> better. If we decide to go ahead with this structure, I'll set things up
> further so all the working branches exist and the issues are set up to
> point to the right place, so people can just continue work using this
> structure.
>
> Michael
>
>
>
> ------------------------------
>
> This e-mail and any files transmitted with it may contain privileged or
> confidential information. It is solely for use by the individual for whom
> it is intended, even if addressed incorrectly. If you received this e-mail
> in error, please notify the sender; do not disclose, copy, distribute, or
> take any action in reliance on the contents of this information; and delete
> it from your system. Any other use of this e-mail is prohibited.
>
> Thank you for your compliance.
> ------------------------------
>