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