[development] #drupal and #drupal-contribute split (Was: Re: Proposal: Move all dev support off this list to new StackExchange site)
antgiant+drupalDevel at gmail.com
Sun Mar 20 18:45:59 UTC 2011
As a very much outsider I found contributing to core to be impossible. I
found a bug in the core trigger module, created a patch to fix it and spent
the next 5 months chasing head without a single other person noticing before
giving up. In fact no one noticed it till at all till 11 months later and
only then because of a related patch I had
commented on. From that I gathered that contributing to core does in fact
involve one of two things. Being "known" or marking your patch critical.
I'd be thrilled to be proved wrong though.
For what it's worth contributing to the the core documentation was a
completely different experience. They were fast to respond and happy to
accept a patch.
On Sun, Mar 20, 2011 at 1:48 PM, Randy Fay <randy at randyfay.com> wrote:
> Agreed: The difficulty of contributing to core isn't really about where
> you're accepted or how much you're on IRC or what in-group you've joined.
> It's really about how hard the process is in general. You can spend an
> awful lot of time on something that's very small.. and it might get in or
> might not. Almost all my contributions were on the edge of triviality - I
> just found something I knew I could fix and fixed it. But they took *way*
> more work than a reasonable person would do to fix such a small thing.
> So there are two issues here:
> 1. How do we welcome new people and make them a part of the community and
> enable them to contribute and point them in the right direction for support,
> 2. Should the core contribution process somehow be made so it's more
> time-and-energy effective?
> My strategy for D8 (we'll see if it holds) is to stay out of core and focus
> on things that I have a little more control of and therefore can do more
> On Sun, Mar 20, 2011 at 11:11 AM, Earl Miles <merlin at logrus.com> wrote:
>> On 3/20/2011 10:00 AM, jeff at ayendesigns.com wrote:
>> > I agree. I would have loved to contribute directly to D7. I found a
>> > level of...discomfort overall. I've was coding when many of you were
>> > first learning to count, so it's not the php I'm uncomfortable with.
>> > I think part of it is coming upon a group that have been together so
>> > long that they're clique-ish, not meaning to be and not in a bad way,
>> > but they know their routine and topic and each other so well that
>> > everything is in shorthand, and it's great for being a voyeur but
>> > daunting to a new guy. The other part is some discomfort with the
>> > fast-paced immediacy of #drupal-contribute when combined with being a
>> > newbie to core, like jumping on a fast ride that's already moving.
>> > I would have felt more secure about it even with something as small as
>> > some color coding on open issues that signified "this one is probably
>> > good for a core newbie."
>> I suppose there is some clique-ish nature to that, but it's really more
>> about level of trust.
>> It's fully possible to get into the trusted group.
>> That said, it's not just about that. I find core development difficult.
>> I'm in the group. But it's a long, tedious process and you need
>> excellent debating skills and a lot of time that isn't spent all at
>> once, but is spent in dribs and drabs over the life of a patch. The more
>> complex the patch, the longer it will take.
>> Getting a 1 line change to core is pretty easy.
>> Changing 500 lines is pretty hard.
>> Our review process is incredibly difficult; reviewing is boring, and
>> tedious, and not rewarding. Not many people do it. Those who do it are
>> reviewing code primarily for style, because that's the easiest thing to
>> review. Doing a good code review requires understanding the bigger
>> picture, and there isn't a bigger picture anymore. Maybe there was once,
>> but Drupal has lost it, because there's no one who actually knows all of
>> Drupal anymore. The bigger picture is an organic mess of Chaos and each
>> reviewer has his or her own internal "bigger picture" that is reviewed to.
>> Sometimes the problem is just getting a reviewer. Sometimes the problem
>> is getting past a reviewer's pet peeves. Either way, the personal cost
>> to code for core is high, has always been high, and only gets higher. I
>> don't really see how that can change. Ideally we want to ensure quality
>> contributions, and and still be receptive to all developers, and those
>> two policies are at odds.
> Randy Fay
> Drupal Module and Site Development
> randy at randyfay.com
> +1 970.462.7450
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the development