Readme should document expectations of for New PR template and New Issue template (order, optionality, etc.)

[cookiecrook]

The New Issue and New PR templates are a great addition, but the expectations should be documented in the Readme or elsewhere. For example, which aspects are non-optional, and in what order should they be completed? e.g. It would be bad to file/fix an engine bug tracker if the related ARIA PR was rejected, so when should this happen?

As an example, I left some relevant items blank in the template for PR #1860 b/c I think there is an appropriate order to completing them. I'll add a starting point below as a second comment. Please feel free to edit it.

[cookiecrook]

I thought the blank items in PR #1860 should probably be added in sequence. For example:

1. Discuss Issue and Review Spec PR
2. Add the related AccName tracker once Spec PR review approved?
3. Add the APG tracker, but don’t complete it until after implementations update.
4. Merge Spec and AccName PRs simultaneously?
5. Parallel tasks following merge?
   • Add web engine implementation trackers.
   • Add WPT trackers, tests, or both?
   • Add validator tracker?
6. Complete APG issue?

[spectranaut]

I think you mean:

1. Discuss/review Issue

[cookiecrook]

1. Discuss/review Issue

"Discuss Issue and Review Spec PR"

In the example used, #1860 we already have a PR, but I am not sure the Engine Implementation bugs should be filed until the WG approves of the proposed change.

[spectranaut]

I believe at the last couple process discussions, we decided that implementations should happen before the change lands. This follows more in the lines of a TC39/ECMAScript proposal, which have to have implementations in order to merge the proposal into the specification. During implementation, there might be feedback or changes that need to be made to the specification. Personally, I have had feedback during implementation of ARIA change.

I'd like to consider any normative PR is a "feature proposal", and a requirement be at least one (or should we say two?) implementations in a browser and implementation commitments from the remaining browsers before we merge. This will make ARIA more of an evergreen spec, and more accurately represent what is actually implemented, which we might like to move to in the future.

[spectranaut]

Also, a lot of this process is already documented here: https://github.com/w3c/aria/wiki/ARIA-WG-Process-Document

But I can update it based on this discussion, and also add a link in the README