* We establish a goal: e.g., within two months of opening of HEAD, we apply or turn down 80 to 90 percent of patches that are two months or more old (and apply some promising newer ones as well).

* At opening of HEAD, we (e.g., a set of volunteers) review the patch list and identify priority patches to be worked through quickly.

* Patches from this list are applied if (a) one skilled developer (other than the primary submitter!) affirms successful testing and (b) a week has passed without new problems being identified.

I agree with this approach. Too many good ideas are dropped on the floor. Either because the process is slow (due to lack of time from core developers or otherwise), or because we as a whole are overzealous. A decision to either accept or drop a patch must be clearly so. We cannot expect that Dries be the judge of every patch, nor can we accept a few +1 and a few -1 to be the final word. There has to be a clear Yes or No on a patch, and if No, we have to say why No clearly, and whether it is the functionality that is the issue, or the implementation (user interface, coding, security, ..etc.) This has to happen in a speedy manner, and not drag on till we have 100+ patches pending. In other cases, we remove functionality from site admins and users (e.g. the "Remember me" was taken away in 4.5) for the sake of a puritan goal: "not having too options". This goes back to a suggestion earlier (I think it was by Nedjo) of forming quasi committees to decide on patches. Drupal is growing fast, and going into many areas that we never imagined at its inception (e.g. ecommerce, ourmedia, ....etc.), the user base is growing fast, and the developers are also growing. Guys, I am not criticising anyone in particular, if anything it is self critisim of what we all are. We have done a lot of great things, and we need to adjust to the above changes in a positive way.