New workflow for Auto-WCAG

Hi auto-wcag'ers,

We are expecting some new stuff to come our way pretty soon. With the ACT
Rules format maturing, we expect several companies will start sharing their
rules. These will likely come our way, which will require us to have a
better throughput. To solve this, I've proposed a new workflow:

----------- Copy from: https://github.com/auto-wcag/auto-wcag/issues/14
Step 1: Creating the proposal in an Issue

Every rule is designed by a team of two or three people. They do their work
in a github issue. This means that every activity is represented by an open
issue on Github. The first post of an issue contains the proposal they are
working on. In subsequent posts, discussions are held, and as they are
resolved, the draft at the top of the issue is updated. Once the group is
done with the proposal, a pull request is created, and the issue is closed.
Step 2: Propose a change in a Pull Request

When a proposal in step 1 is done, a pull request is created to update the
rule in _drafts. This gives the rest of auto-WCAG the opportunity to
respond to the proposal. At this point one of three things can happen:

   1.

   Editorial comments can be resolved immediately by updating the pull
   request.
   2.

   For any comments that can't be resolved immediately, a new issue is
   created. Once the review period of the pull request has passed, the pull
   request is merged in. The team working on this rule continues working on
   the new issue that was created, going back to step 1.
   3.

   If no comments come in, the issue can be merged in after the review
   period. If the authors feel the rule is read for publication, after they
   merged the PR into draft, they can open a new PR, wich must have "FINAL" in
   the PR name, to move the rule from _drafts to _rules. This will publish
   the rule. The rule needs at least 3 approved votes before it can be
   merged from people who weren't the editors. If new comments come in, the PR
   must be closed without merging, and a new issue is created to work on the
   fix.

Pruning Issues and PRs

At every auto-WCAG call, inactive issues and PRs are reviewed. If an issue
/ PR hasn't been updated since the last auto-WCAG call it will be closed.
This is to ensure that issues and PRs don't get stale, and so that it's
always clear at a glance what is being worked on. Issues closed for this
reason are given the stale flag, and can be reopened if a new team is
interested to work on it.

----------

I'm hoping this will make it much easier for us to work on things more
efficiently, and to rely less on Monthly calls to get things resolved. If
you're not yet a collaborator in the auto-wcag Github project, please send
me your account name so I can add you.

If you aren't currently working on any rules and would like to do so,
please send me an e-mail, and we'll see what we can do.

Regards,

-- 
*Wilco Fiers*
Senior Accessibility Engineer - Co-facilitator WCAG-ACT - Chair Auto-WCAG