What is going to happen to my core patches once they're RTBC?

As of September 28, catch has commit access to Drupal 8. This is the first change in co-maintainers in a while, so how does it affect the RTBC queue?

• Dries will still be committing patches to both Drupal 7 and Drupal 8.
• webchick will still be committing patches to Drupal 7, and Drupal 8 patches that need backport to Drupal 7 (and occasionally other Drupal 8 patches, especially things that fix the testbot etc.)
• Gabor will still be committing patches to Drupal 6.
• catch will only commit patches to Drupal 8.

There are a few guidelines that I (catch) am going to try and follow regarding the RTBC queue. None of these are strict rules and they may well be subject to change:

1. Keep it short

   Ideally I'd like the 8.x RTBC queue to contain fewer than 25 issues if possible and never have more than 50, which is where the Drupal.org pager kicks in. As I write this there are only four RTBC issues, so that has been going well.

2. Minimum 3-5 days in RTBC
   

   I'll also try to leave a window of at least 3-5 days for any patch that's not trivial before committing it, especially if it's the first time that issue has been at RTBC. People who keep an eye on the RTBC queue can use this time to perform a final review and/or knock things back to needs work before they're committed. Note that Dries and webchick may handle this differently, and we can always re-open issues for follow-ups and/or roll-backs to repair breakage.

3. Maximum 4 weeks in RTBC without a review from a committer
   At the other end, I'll try to make sure no patch stays in the RTBC queue for more than 4 weeks without at least being reviewed by me. To keep that manageable I'm going to prioritize the RTBC queue above my other Drupal core activities, (like reviewing other patches or working on my own).

4. Working with webchick

   Patches that need a backport to Drupal 7 to fix major or critical bugs, but might not be smooth (i.e. anything with a UI change, string change, API tweaks etc.) I'll try to discuss with webchick and/or assign the issues to her before committing to Drupal 8, so that we don't have to do version ping pong for those issues.

5. Avoiding conflict of interest

   Patches for Drupal 8 that I authored, was the main reviewer, or marked RTBC are going to be assigned to Dries and/or webchick, since otherwise I'm committing my own patches (bad), or committing straight from needs review (also bad). It will usually be OK for someone to review the patch again, confirm the RTBC, and unassign it. Depending on the patch, I may decide to re-assign the patch again if I'm still not comfortable committing it myself for whatever reason.

6. Working with Dries
   I'm not sure which patches I'm going to punt to Dries for a final look yet. Two so far were changing the default theme to 'stark' and using that for the minimal profile, and removing the Garland theme from core. So the likely candidates include anything that removes major features or radically changes new user experience. Those issues will be made transparent by using the 'assigned' field so they don't get lost.