RFC: HOWTO: Enact change within the Drupal community

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.

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?

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

The steering committee is not Dries & development team?

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

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.

I am grateful to have found this thread, and I believe that this page will be a wecomed part of the handbook and one of the formerly "missing pages". I know this thread is for review of that document, but my question is how to enact change on a larger level. Basically your document is a blueprint for getting involved into the current scheme of patches or documentation (handbook). What if you don't agree with the way the handbook itself or forums are setup and you want to change that?

examples of this complaint can be found in this thread http://drupal.org/node/34623, and this thread http://drupal.org/node/37238.

I believe the heart of this to be things like this:

A simple fix is to rewrite the install.txt with the download distribution. Beyond setup, the last steps are merely administration (user permissions) and customizing themes. From there it just says "consult the handbook at drupal.org". ?!? Judging from the rash of newbie questions I think you could add 6 more steps or more....how to get started, start with this guide, here's some php snippets, here's how to submit content, here's how to configure input formats, here's how to setup roles, here's how taxonomy works...

Another way to do it is to rip a page out of the Macromedia usability playbook...have a setup wizard on initial install. Once Drupal is installed - run a one time setup wizard - "what do you want do to (blog, community, ecommerce, book authoring, etc.)?". The wizard helps you configure and setup your site, and what isn't covered at least has a direct link - for more information go to this handbook at drupal.org.

beyond this I also believe that a newbie forum, or all areas pointing directly to proper handbook pages (including help, forms, intall info, etc), or even a simple "submit your tip here" - to be parsed into a handbook page by a maintenence group later would largely stem the tide of complaints by both newbies and veteran Drupal users.

What if you don't agree with the way the handbook itself or forums are setup and you want to change that?

As a general rule, those sorts of suggestions are much better received from those who have established credibility within the drupal community, have demonstrated that they understand the way it CURRENTLY works, can articulate what specifically would be better and why, and can demonstrate that a nontrivial number of people feel the same way.

It's the way most OSS projects tend to work. It has strengths and weaknesses.