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

Fri Nov 11 17:53:41 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:   webchick
 Status:       active

I should clarify too that that document is not intended to be geared
merely toward low-level code changes or handbook updates. It applies to
nearly *any* problem within the community you can think of. All it
basically outlines is a process for communicating with people and
building support for an idea, and this is applicable regardless if
you're trying to add a period to the end of a sentence on one of the
handbook pages, or trying to convince Dries to add a contrib module to
Drupal.org.

webchick

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??

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

Fri, 11 Nov 2005 15:52:00 +0000 : Eaton

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.

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

Fri, 11 Nov 2005 17:00:13 +0000 : jt6919

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 [2], and this thread
http://drupal.org/node/37238 [3].

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.

[2] http://drupal.org/node/34623\" target=\"_blank
[3] http://drupal.org/node/37238\" target=\"_blank

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

Fri, 11 Nov 2005 17:49:20 +0000 : webchick

Thanks, Eaton. That's what I was trying to say, but you were of course
much more eloquent. :)

jt6919 - re: your quote, there are a few things you could do which
would help:

1. Submit an issue to the Documentation project [4] about INSTALL.txt,
stating your issues with it. If possible, this should be backed up with
examples of "here are the types of questions that I've seen a lot of new
people get tripped up with [forum post links]" and hopefully even
accompanied by proposed changes to the text. That last bit is crucial
because a) it shows that you took initiative to actually help find a
solution to a problem, rather than merely pointing it out, and b) it
gives the rest of the documentation team a very concrete example of
what your idea entails, so there's no guesswork about what you mean.
Doing this will give the documentation team (and anyone else who wants
to provide feedback) a chance to read the proposed changes over,
discuss about how best to go about doing this, propose their own ideas
on how to improve it, etc. And hopefully at the end, we can generate a
patch to INSTALL.txt and mark it for inclusion in Drupal 4.7.

2. Read up more on the Install system overview [5], a project which
Adrian is currently spear-heading. Find out if there are any areas in
which you can lend assistance (even if you're not a coder, something as
"simple" as gathering up a list of requirements could possibly be very
helpful).

3. A lot of people aren't that crazy about a newbie forum, for a
variety of reasons (the primary being that it sort of segments new
users into their own corner and there are many, many examples of people
who thought themselves newbies and would probably have stuck to the
newbie forum instead reading the other forums and gleaning lots of
great info, and even helping out other newbies!). But if you have a
community you can point to where the newbie forum has been a huge
success, and the specific reasons why it would work better here, and
how to address the concerns by people who feel that it would result in
segmentation of the community, feel free to propose it (this is what I
personally feel has been lacking in previous proposals). Similarly, if
you can come up with a list of appropriate handbook pages for each
forum section to have links to, submit an issue to the Drupal.org
maintenance project [6], and if they're sound ideas, hopefully someone
can get those implemented.

[4] http://drupal.org/node/add/project_issue/documentation
[5] http://drupal.org/install-system-overview
[6] http://drupal.org/node/add/project_issue/drupal_org_maintenance

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

Fri, 11 Nov 2005 17:51:52 +0000 : Eaton

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