[development] Very concerned over Drupal's core development

[Nathaniel Catchpole]

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