As this project attracts more people now that it is active again, we could use some guidance on contributing. I've personally stepped on @awwright 's toes about five times already and I'm sure it's getting just as tiresome for him as it is for me. Things that should go in a contributor's guide:

• How do we resolve issues?

  • How do we indicate that one is accepted, and can move to PR?
  • How do we indicate that one is rejected
  • How do we resolve a conflict- it's clear that there are irreconcilable camps (e.g. $merge/$patch)
  • Closing "orphaned" issues after a "last call" period (two weeks?)'
  • Should implementors implement proposals to try them out, or should we wait until the issue is accepted to some degree?

• Pull requests

  • Any specific requirements?
  • Document that three approvals are required for (new keywords? changes to behavior?)
  • Who is eligible to give approvals?
  • Document that all PRs other than trivial bug fixes will be left open a minimum of 2 weeks
  • Should spec and meta-schema changes always be in the same PR? (I say yes)

• Release process

  • Are some things in-scope vs out-of-scope for the next draft? How do we tell?
  • Is there any way for the community to escalate something in priority? What are good reasons to do so?
  • How do we know when a draft is about to be published?
  • What, if any, additional rules exist during the final pre-publication period?

There's probably more, but these are things that have already come up.