[policy, no patch] Proposed Drupal 7 contributor / maintainer workflow

This is a proposal for a workflow that the D7 maintainers will follow.

The aim is to empower community contribution, and enable bugs to be fixed in D7 quickly and efficiently without risking stability / regressions.

The workflow's not vastly different from the standard on d.o but we're proposing to use a few tags and some terminology to organise the work.

• Issues should only be marked as RTBC when they have appropriate tests (if not, set to "Needs Work" with the tag "needs tests") and they comply with the backport policy (tag: "Already in D8").
• Note that some issues only apply to the 7.x branch, and these do not need to be tagged "Already in D8".
• Not all issues require tests either, but anything non-trivial does.
• If you find an issue which has been marked as RTBC but doesn't meet these criteria, explain what needs to be done and mark it as "Needs Work".
• Maintainers review items which are marked RTBC.
• If a maintainer believes the patch is ready for a final review before being committed, they will add the tag "Pending Drupal 7 commit". Please do not use this tag if you are not a maintainer.
• Maintainers will also use the tag "Drupal 7 bugfix target" to mark issues we hope to include in the next bugfix release. Please do not use this tag if you are not a maintainer.
• When a patch has passed final review and is ready to be committed, it may be marked RTBM (Ready To Be Merged). It should be committed by another maintainer in due course.
• When a patch has been committed, tags such as "Pending Drupal 7 commit" and "Drupal 7 bugfix target" will be removed in order to keep those lists clean and useful.
• Each time a bugfix release is prepared, it will include everything committed since the last bugfix release.
• Security releases only include security fixes and are otherwise based on the most recent release.
• Release windows are typically on a Wednesday (see the release schedule). There will be a code freeze before the release; typically starting the Friday before. The aim of this is to avoid rushing changes into the release at the last minute which have not had any time to be tested in the dev branch, and which therefore risk introduces bugs or regressions.

Let us know what you think!