[development] Very concerned over Drupal's core development

[Dries Buytaert]

I think catch hits a lot of good points about how our reward and trust
system could be improved.  I'm all for better profile pages, giving
credit where credit is due, and providing better visibility into who
is working on what.  It might be useful to provide a "Reviewer rating"
or "Reviewer score" -- something which could be an incentive for more
people to review patches.  Maybe this can be accomplished through some
project module extensions?  I'm not sure what the best approach would
be, but it is worthy of a discussion.


On Mon, Apr 20, 2009 at 10:30 PM, Nathaniel Catchpole
<catch56 at googlemail.com> wrote:
> On Mon, Apr 20, 2009 at 8:38 PM, Sam Boyer
>
>> Hear hear for that. Nothing like the knowledge that if you commit a screw-up,
>> it'll be noted by core devs within hours (if not minutes), which any self-
>> respecting dev would find at least a smidge humiliating.
>>
>
> This is interesting, because I find it really comforting that we
> manage to pick up screw-ups both before and after commit, especially
> mine, maybe I'm not self-respecting enough. I don't really like the
> experience of coming across an issue which just got committed and have
> to mark it code needs work (sometimes with rollback patch ready if
> it's really, really bad) - but when people do it to me I don't get
> offended or overly humiliated - I'm just glad it never made it into a
> final release.
>
> Actually I think a big part of the problem is this perception that
> core is hard and contrib is easy, personally I find the contrib
> workflow really hard.
>
> A lot of people's first attempt to contribute to Drupal is often when
> they apply for a CVS account to contribute back a module. A lot of
> companies view that as their primary way to contribute back resources
> as well. What we end up with is 4,000 projects of very varying
> quality, and the projects which /everyone/ uses - Views, CCK etc. are
> crying out for people to help in their issue queues - not just writing
> and reviewing patches at a high level, but answering support requests,
> closing out duplicates, stuff like that.
>
> One issue with this is the way our user profiles work in terms of
> highlighting contributions. I'd been contributing to core for more
> than a year before I got a CVS account, and that was when one of my
> core patches removed a slice of user.module on the condition it was
> maintained in contrib. So for a long time I never had any projects
> listed on my profile page, nor any entries in 'track code'. I've still
> only got commit access on a handful of projects, and don't actively
> maintain any of them - a situation I'm quite happy with. However if I
> posted a couple of crappy modules and committed loads of tiny patches
> to them, then to the casual observer that'd make the user profile look
> a lot beefier.
>
> The only way that code contributions to core get measured is when Greg
> Knaddison parses commit logs and puts everything into a spreadsheet
> once or twice a year - our commit model also completely breaks sites
> like ohloh. Personally I'd really like better statistics on how many
> people are reviewing/submitting patches, getting them committed etc.
> since it'd at least help to spot clear trends when having discussions
> like these. And I think it'd be a bit of incentive to review and post
> patches more if there was some way of having that data recorded more
> firmly than just in commit messages themselves.
>
> There was talk of having 'issue queue maintainers' without actual
> commit access for contrib projects as well - for people who answer
> lots of support requests and write documentation etc. Similar issue
> and it goes two ways. Identifying the people who you need to speak to
> about a particular area is hard unless you know who they are.
> Identifying what any particular individual is doing is hard unless you
> trawl through their tracker. There ought to be better ways to deal
> with this than filing patches to add people to maintainers.txt and
> having to write big long lists of names in commit messages (then what
> if you forgot someone or spell their name wrong).
>
> Nat
>



-- 
Dries Buytaert :: http://buytaert.net/