[documentation] [task] RFC: HOWTO: Enact change within the Drupal community

Fri Nov 11 15:52:00 UTC 2005

Issue status update for 
http://drupal.org/node/36603
Post a follow up: 
http://drupal.org/project/comments/add/36603

 Project:      Documentation
 Version:      <none>
 Component:    Misc
 Category:     tasks
 Priority:     normal
 Assigned to:  webchick
 Reported by:  webchick
 Updated by:   Eaton
 Status:       active

Trust.

There's a small -- very small -- set of people that can commit changes
to the core Drupal project. Dries is one of them. As a rule, he's very
skeptical of changes -- not because he thinks it's perfect, but because
he knows changes to core have a large 'footprint' on the coding
community.

There's a small core of people who can't commit changes directly to the
core, but are well-known and respected inside the drupal development
community for the quality of the code and their understanding of the
codebase. names like Ber Kessels, chx, killes, Adrian, and others will
come up a lot. This doesn't mean that they 'control' drupal, just that
Dries and the other core project-owners are much MORE likely to give a
patch the thumbs-up with the support of well-known folks. Also, a patch
is much LESS likely to go in if one of the well-known drupal folks finds
serious issues with it.

Mind you, even those folks don't always get their patches in. And
sometimes, patches go in despite the objections of those people if the
'core' project owners believe there's a very compelling reason.
Usually, the compelling reason boils down to: 'X is a serious problem,
Y uploaded a patch for it that works, and it is good enough. Submit a
subsequent patch if you feel strongly...'

As a general rule, though, if YOU are the only person to notice a
problem, or request a feature, and it doesn't catch the eye of one of
the core developers, it probably won't happen. Why? Dries and the other
core project owners believe that the CORE needs to be kept to code that
benefits the largest possible number of Drupal users. The answer is to
get in touch with other fulks in the Drupal community and lobby for it.
Pop into the #drupal-support or #drupal IRC channels, perhaps the
mailing list, and ask if there's anyone willing to test the patch. Ask
for advice on best ways to implement if necessary. 

Contributed modules, of course, are another story -- they depend a lot
on the individual maintainer.

Eaton

Previous comments:
------------------------------------------------------------------------

Sun, 06 Nov 2005 23:16:48 +0000 : webchick

I've had a few requests to turn this:
http://drupal.org/node/32495#comment-56881 (and some of the subsequent
comments) into a handbook page. I've created
http://drupal.org/node/36602 and would appreciate any comments on it. I
incorporated a few comments made by other individuals, like BobT's "own
the problem" and sepeck's "Welcome to the community," which I really
feel drive home the point I'm trying to make here.

I've left it in the revision queue for now just until a couple more
pairs of eyes have looked at it.

Thanks!

------------------------------------------------------------------------

Tue, 08 Nov 2005 06:33:03 +0000 : cel4145

I'm constantly playing catch up these days, so I'll be glad to take a
look at it in a day or two. Anything specific you want me to look at?
It's much easier to offer suggestions if you can tell me your concerns.

------------------------------------------------------------------------

Tue, 08 Nov 2005 07:46:43 +0000 : webchick

No problem, Charlie. There's no rush at all. Basically, I was hoping for
a couple people to look through it and make sure it makes its point
without being too acerbic. ;)

Thanks for the spelling fix too, Kobus!

------------------------------------------------------------------------

Tue, 08 Nov 2005 14:49:05 +0000 : cel4145

I think the tone is fine. 

I am wondering if it might be possible to work in the idea that this is
the best practice method which more experienced members of the community
already follow?

------------------------------------------------------------------------

Tue, 08 Nov 2005 15:21:04 +0000 : webchick

Cool, thank you. I've updated the paragraph just before the list of
"dos" to reflect your feedback.

------------------------------------------------------------------------

Tue, 08 Nov 2005 15:36:15 +0000 : shouchen

webchick,

Good handbook page.  My only concern with it is... if advice like this
is going to be published, the people who currently control what does
and does not get into CVS need to agree with it.  Sometimes, it seems
like people Inquire, Research, Propose, Refine, Be patient, and Do It
Themselves (submit a patch) and still feel unheard, etc.  (See
http://drupal.org/node/36688 for one example of this.)

Also, noticing all of the uncommited patches that are currently in the
system can lead to a feeling of "supplying a patch won't even help". 
There are even some "ready to be committed" patches that seem to be
approved by those in contro, but are weeks old and still not committed.
 (I'm referring to core, not contributed modules.  Although the same
situation applies there, even worse.)  I don't know the reason for all
of the uncommitted (core) patches, and I sure don't want to start a
flame war like the thread where your handbook page originated.  I know
Drupal is Open Source and developed for free in people's spare time...
I fully understand and accept that.

Your handbook page, to me, implies that submitting a patch will get an
issue resolved.  Perhaps you should explain that even after supplying a
patch, it is still necessary to be patient and understand that the
change implemented by your patch might not fit within the Drupal
roadmap.  And even if it does, it can take a while to get a patch
reviewed and committed.

Maybe things are being done backwards... coders all over the world are
trying to pull Drupal in their own direction... submitting patches that
go nowhere.  Instead, there should be visibility to the path that
Drupal's "steering committe" wants Drupal to take, so coders all over
the world can spend time pushing Drupal in the right direction??  That
seems like a much more effective use of time.

-Steve

------------------------------------------------------------------------

Thu, 10 Nov 2005 03:14:30 +0000 : webchick

Steve: Thanks for your feedback. That's a very fair point. I have
reiterated at the end that following these steps is no guarantee of
your ideas being implemented, only that they help increase the chances.

> Instead, there should be visibility to the path that
> Drupal's "steering committe" wants Drupal to take, so coders all over
> the world can spend time pushing Drupal in the right direction?? 
That
> seems like a much more effective use of time. 

This is difficult, because Drupal doesn't seem to have a "steering
committee" in my experience. Anyone can steer Drupal, though your
success is really dictated by how much you've already put into the
project and how well you communicate and consensus-build with other
people similarly trying to steer it. This may be just my experience
though. If there is a "formal" process by which decisions are reached
(beyond the The revision process [1] document, which I've now
referenced), please someone let me know so I can update the document to
reflect that. :)

[1] http://drupal.org/node/10261

------------------------------------------------------------------------

Fri, 11 Nov 2005 15:38:54 +0000 : ryooki

The steering committee is not Dries & development team?

------------------------------------------------------------------------

Fri, 11 Nov 2005 15:40:17 +0000 : shouchen

That is the group of people I was referring to when I used that term...
*somebody* must be steering it.  If not them, who??