[development] Drupal Enhancement Proposals (DEPs)

Tue Nov 15 01:13:12 UTC 2005

I will be trying to raise hundreds of thousands of dollars over the  
next year to support Drupal core development.  Having a working DEP  
process in place will make my job multitudes easier.

-Zack

On Nov 12, 2005, at 11:41 AM, Adrian Rossouw wrote:

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