On Jul 3, 2007, at 7:52 AM, Dries Buytaert wrote:
http://www.computerworlduk.com/technology/hardware/processors/ news-analysis/index.cfm?articleid=604 Makes for an interesting read, and shows what might be ahead of us.
The "web of trust" that is described in that article sounds like it is already informally implemented by Dries and the other committers. For example, Dries would trust a review of a theme-related issue by Earl Miles more than he would trust my review of the same issue (since I'm new.) That's perfectly natural. The issue then becomes: how do patch developers get the attention of committers or of the committer's web of trust? The only current method is to get it marked RTBC. But then those developers get frustrated as their issues languish in an RTBC queue that is the / self-described/ last step. Obviously, RTBC is completely mis-named considering how committers are treating that status. To fix the problem from the persepctive of a non-web-of-trust developer and to alleviate the work load of committers reviewing not- actaully-RTBC issues, I would propose that: 1.) the current "patch (ready to be committed)" be renamed to "patch (ready for final review)". This is ESSENTIAL to, at the very least, re-align new developers expectations. 2.) the web of trust be formalized and those developers get a new permission to upgrade an issue from "patch (ready for final review)" to a new, restricted "patch (ready to be committed)" status. (requires project* mod) Additionally: 3.) patches that are not marked "code needs work" or "to be ported" be periodically and automatically checked to make sure they still apply without FAILing. (requires infrastructure resources :-( ) Others (like Fernando and Earnie) have proposed a voting system or a merit/karma-based system, but, as Dries said, Drupal is not a democracy, so those systems would still be out of alignment with how core committers are working. We need a solution that naturally aligns new developers expectations with how core development is actually done. - John