[development] #drupal and #drupal-contribute split (Was: Re: Proposal: Move all dev support off this list to new StackExchange site)

[Randy Fay]

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,
etc.

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
effectively.

-Randy

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...
URL: http://lists.drupal.org/pipermail/development/attachments/20110320/64bd1d7f/attachment.html