I agree with Earl and Darrel, many patches are derailed with endless debates. The question is whether that is good or bad, because the context is missing. I can't speak much about the past, but is it possible that core's development process changed drastically? We introduced an awesome testing framework that ought to increase the quality of code that is committed to core. However, we are still introducing new core bugs (take "FAIL." [1] as an example), despite being reviewed by many eyeballs and having tests. I think this is caused by the steadily increasing complexity of Drupal core - and - by a lack of reviewers that *really* understand core, use-cases in contrib, many sub-systems (not one), and all implications of a core patch. This is the real issue (I believe) Karoly wanted to raise originally. I am not sure whether sub-system maintenance teams will lead to an improvement of this situation. Completely contrary to this proposal, I think our issue is that we are lacking the opposite of domain experts: Drupal core contributors/maintainers/reviewers who understand every single bit of core and potential implications of a changed bit. For the sake of clarity, I have revised Dries' "Drupal learning curve" graph, because I think the important part - the part we are really talking about - is missing: http://www.unleashedmind.com/files/drupal-learning-curve.png Adding new people above the "Core contributor" threshold is what we are mostly doing currently. However, it is my impression that there are very, very few people above the "Trustworthy for core maintainers" treshold. Even less, if you only count people who are known to be "trustworthy" for more than one sub-system. It is possible that you counted only one person (or less?) when climbing up the further tresholds. Maybe that is the issue we are facing? Patches languish in the queue for ages, because some sub-system maintainers subsequently chime in, each one needs own treatment, other contributors chime in, trying to understand the issue, the patch is re-rolled all over again, a branch maintainer shows up who questions the entire approach, and finally the patch may or may not be committed -- still lacking review by someone who understands all changes and implications of the patch. Given all other proposals in this thread, my guess is that adding more maintainers to core might really be a step in the right direction: Handing out responsibility (that comes with a fair amount of power) to core contributors who are already known to be trustworthy (in more than one area) will most likely let them advance in other areas, climbing up the "treshold-ladder" - not only, because people will start to ask about reviews/commits for arbitrary patches. Equally, this action could be done now. [1] http://drupal.org/node/446742 Thanks, sun (who hopes to have reached macro-level with these thoughts)