[development] Drupal Enhancement Proposals (DEPs)
zacker at skylinepublicworks.com
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.
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
> 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
> 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
> 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
> 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)
> -----END PGP SIGNATURE-----
More information about the development