Draft approach to split ARIA repository

Just to kick-start discussion here's a draft approach for how we should 
split the ARIA repository.

  * We will still need a repository for common elements, and perhaps
    from which to organize formal publications using sub-repositories. I
    think it will be simplest if we use the current "aria" repository
    for that.
  * Another reason to keep that repository as the "common" one is we'll
    want to update the gh-pages versions to say "this has moved, look
    there". We'd probably do that wit the source as well (i.e., the
    version that loads in rawgit).
  * The consensus as I understand it is to have one repository per spec,
    and manage versions within that repository via branches. Thus we
    would need the following new repositories (in addition to the
    aria-practices one already created):
      o aria-spec
      o dpub-aria
      o graphics-aria
      o core-aam
      o accname-aam
      o html-aam
      o svg-aam
      o graphics-aam
      o css-aam
      o dpub-aam
  * Each repository would have commit access only to people actively
    working on the spec in that repository. I just discovered it's
    possible to give certain people the ability to give commit access to
    others without having to go through me, so we can designate a lead
    editor in each repository to have that privilege (with a couple
    cautions about making sure the patent policy integrity is maintained
    etc.). (For now the common repository would probably keep everyone
    with commit access so you can add or edit things like CSS, in
    coordination with everyone else of course.)
  * For references to things in the common repository or other
    repositories, such as scripts and images or links to sections of
    other specs, I'm inclined to suggest we use relative links. They
    just have to point one directory higher than they used to. For me,
    this makes things easier when working offline, but requires having
    local clones of any other repository you need to reference, and
    assumes the clones are at sibling directory levels to each other.
    Some may say absolute links are preferred though, so we may need to
    debate pros / cons of both approaches.
  * I think some of the scripts will need to be updated to account for
    the new structure. My guess is they are simple updates, but I'm not
    100% sure on that.
  * I'm not quite sure how long a migration to a new repository takes.
    I'm guess migrating the commit history is easy, but it might be a
    manual process to migrate issues etc. We'll need to determine a
    reasonable amount of time for the migration and then have a
    moratorium on edits while the migration is carried out. Quite
    possibly we can do it spec by spec and not need a moratorium on the
    others not currently being migrated, though that may not be the case
    if the scripts will have to change at the same time and break things
    if things migrate piece by piece.
  * I'm not sure if it's better to have a single person, such as me, do
    the migration at scheduled times, or if we should have a lead editor
    for each spec migrate their own. That depends on a balance between
    how likely you think I am to make mistakes, vs. what the learning
    curve and time impact is for several people to have to go through
    the process. Either way, we need to decide on that to proceed with
    the plan.
  * I think each new repository should be free to set its own practices
    for source format, branches, accepting pull requests, tools, etc.
    However we should continue to share best practices among the editors
    and I hope end up with the repositories being in general similar to
    each other with these practices.

Send input by email if you like, and this is on the agenda to discuss in 
tomorrow's editors' meeting.

Michael