[development] Drupal Enhancement Proposals (DEPs)

Sat Nov 12 19:41:42 UTC 2005

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I need to preface this by saying that I don't think our current  
community processes are 'broken' per se, since they have
obviously brought us this far, however I have noticed some areas in  
which there could be improvement and I would like
to make some suggestions towards getting a smoother development cycle  
for all of us. My primary interest with this
proposal is to foster co-operation, and allow us to better manage the  
project in the future.

I feel that one of the primary problems we have is that there is not  
enough co-operation between different developers,
and I feel that this problem stems from lack of communication. Up to  
this point, communication has been strictly
informal. This has the benefit of not tying up people doing ground  
work, and is essentially an extension of our
'talk is silver, code is gold' mantra. And this is great. Good  
working code is our primary goal, and it has suited
our goals up to this point perfectly.

The problem with this however is, that it does not scale. With one,  
or even two people on the project it might work, but the
moment you get more than that involved, communication becomes a lot  
more work than it should be.
The other problem is that communication on projects like these tend  
to be on a personal level, and the only way
to get more developers involved in the project is either through  
direct requests, or constant badgering on the forums/irc.

Even if you do get someone else interested, getting that person up to  
date on the goals and status of the project , and to become a  
contributing
member is still a lot of work. Also, the only way for an external  
developer to become involved in such an on-going project is
to search the forums, find people who might even be remotely  
interested in the same thing, go talk to people on irc, see if anything
is being done in whichever direction they intend to work in. It's a  
lot of work, and most developers don't bother. They end up
re-inventing the wheel, because it's really hard for them to get  
accurate information about what's going on in the Drupal community.

What I would like to suggest, is that we introduce a proposal system,  
whereby we create an official proposal document for
any large changes we undertake as a community. This process would be  
modelled on the jabber.org JEP process, which
in turn is modelled on the IETF process.

What we would essentially do is create a document, that has an  
official number, a status and an owner. This document
would be modelled on JEPs (http://www.jabber.org/jeps/jep-0143.html),  
and would explain the basic goals of the project,
reasoning behind it, requirements, security considerations and so forth.

How I imagine the basic workflow would be, is that someone writes a  
proposal, in the correct format, that gets published as a draft.
At a certain point the draft then gets sent to drupal-devel, and  
developer comments are factored in. Then it gets published on
Drupal.org, and user comments get factored in. At this point, we have  
a proposed DEP, and anyone who has any interest
in working towards that knows what has been decided to be the best  
approach, who is working on it, and what is the status of it.

Another thing that led me to this conclusion, was the recent  
discussion about the formation of the 'theme team', which I felt
was not actually aligned with our goals. We already have a theme  
forum, which doesn't see much action, since I think
the informal communication has proven to not be adequate.

What the proposal structure would do, is allow us to create SIG's  
(special interest groups), whose purpose would be to
foster discussion, and create proposals with a certain goal in mind  
(ie: theme sig, usability sig, localisation sig, etc.)

Benefits :
    For Developers :
      Lessens duplicated efforts.
      Has a summary of the current status of things.
      Allows us to collaboratively map out what we are working towards.
      It's an actual spec, and although there is such a thing as  
feature creep, at least we know when it's 'done'

    For Documentation :
       Provides reference information for the design and  
implementation of features.

   For End Users :
       A more transparent view of where we are heading, what changes  
we are making and why.
       More eyes, which might bring up more issues, helping the  
design along.
       Get them more involved with the project, without having to  
wade through the forums.

  For Investors :
      Allows investors to see projects within the community and  
financially support the right people towards meeting their goals.
      Creates a common process to interface commercial and community  
developers with each other.
      Reverse bounties.

  For Dries :
      Allows for more accurate roadmaps. (ie: DEPs 0341 and 0342 are  
destined to be in the next release)
      Knowing the status of things.

  For all of us :
      Gives us a better map of people's interests.
      More visibility to what you are busy doing, and it might make  
you some money.

One thing I should say, is that I am not trying to stop us from  
developing the way we are now, it's not broken,
i'm not trying to fix it. What I am saying is that we could make this  
more formal path available, to allow us to
collaborate more effectively on things.

I am also not trying to bog down what we do. Implementing for now  
could simply be a book page that
we maintain as we are involved in the project. I have some ideas in  
the future to expand the integration
in a meaningful way, but that's probably a topic for a DEP of it's own.

Just because we are documenting what we are doing, doesn't mean we  
can't write code while we're doing it.
We're obviously going to have times when we have a couple of  
different implimentations of the same thing
competing with each other, provided they are different enough  
approaches... but that's healthy.

I am also not saying that we will get this right the first time, but  
what I propose is that we set up such a process
and then create a DEP 0001 which is the dep handling the community  
process, and after every release we
review it again and make revisions based on what worked and what  
didn't. I really feel that if we decide on
a method we need to stick with it for a while though.

So these are some of my thoughts, and I would love to have the  
community's opinion on the idea.

- --
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDdkV3gegMqdGlkasRAr+aAKCoGKZ8hnqtqDm658DJBX5USTQ0fgCeI1tw
rY2I2L6dSV6MBGuO767Jazk=
=Z4mD
-----END PGP SIGNATURE-----