-----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-----
Thanks Adrian for putting forward this well considered proposal. I support the idea of introducing a formalized process for presenting and working through major proposed enhancements. I personally find it challenging to keep abreast of the various proposals that are working their way through our current processes, proposals that often are scattered among various email discussions, project issues, forum discussions, etc. Formalized presentation in a predictable place, with revisions so it's clear what's current, designated status, etc., sounds really great to me.
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.
We could start by setting the number of characters per line to 80, or a bit less. :p
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.
I don't find that the communication is a burden yet. The number of people to communicate with on a given topic is still small.
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.
That is true. And even then it mostly fails. Why? Because everybody has his pet issues with Drupal. That is not a bad thing, because it ensures that things get pushed by some individuals. To get other individuals to join them in their effort is a very difficult thing to do, as I can tell you from several years of experience. And frankly, I don't see this changing.
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.
I disagree. Once some code comes forward there usually is some issue created and all you need to do is read the contained information. People who are not willign to do that won't read lenghty proposals either.
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.
It would have helped to convince me if you had chosen an example of less intimidating length and complexity. But I guess you didn't. :p Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Nov 2005, at 10:32 PM, Gerhard Killesreiter wrote:
That is true. And even then it mostly fails. Why? Because everybody has his pet issues with Drupal. That is not a bad thing, because it ensures that things get pushed by some individuals. To get other individuals to join them in their effort is a very difficult thing to do, as I can tell you from several years of experience. And frankly, I don't see this changing. Because people don't know what they are getting themselves into. Take for example all the people working on the relationship system. Would they have started working together were it not for that issue ?
How easy is it to get to the conclusion of that thread and know exactly where development is now. How do you know what still needs to be done. How do you know who's involved without taking mental inventory.
I disagree. Once some code comes forward there usually is some issue created and all you need to do is read the contained information. People who are not willign to do that won't read lenghty proposals either. But the person who wants to fund development in this direction might not be able to read those threads as easily, but be willing to pay people who know what they want to implement and why , actual cash money.
It would have helped to convince me if you had chosen an example of less intimidating length and complexity. I'm going to be writing some proposals myself once I've nailed down to what I believe the format should be. The first one is going to be about the crazy idea I had for the variable_set function yesterday.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDdnTUgegMqdGlkasRAtmqAKDRXtCl5xX0xPSBwZCpe3Mpmjj6JgCgjRz5 cA6Gk/5vqbXHADI/x4886v0= =JFr5 -----END PGP SIGNATURE-----
+1 on the DEP idea On 11/12/05, Adrian Rossouw <adrian@bryght.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12 Nov 2005, at 10:32 PM, Gerhard Killesreiter wrote:
That is true. And even then it mostly fails. Why? Because everybody has his pet issues with Drupal. That is not a bad thing, because it ensures that things get pushed by some individuals. To get other individuals to join them in their effort is a very difficult thing to do, as I can tell you from several years of experience. And frankly, I don't see this changing. Because people don't know what they are getting themselves into. Take for example all the people working on the relationship system. Would they have started working together were it not for that issue ?
How easy is it to get to the conclusion of that thread and know exactly where development is now. How do you know what still needs to be done. How do you know who's involved without taking mental inventory.
I disagree. Once some code comes forward there usually is some issue created and all you need to do is read the contained information. People who are not willign to do that won't read lenghty proposals either. But the person who wants to fund development in this direction might not be able to read those threads as easily, but be willing to pay people who know what they want to implement and why , actual cash money.
It would have helped to convince me if you had chosen an example of less intimidating length and complexity. I'm going to be writing some proposals myself once I've nailed down to what I believe the format should be. The first one is going to be about the crazy idea I had for the variable_set function yesterday.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFDdnTUgegMqdGlkasRAtmqAKDRXtCl5xX0xPSBwZCpe3Mpmjj6JgCgjRz5 cA6Gk/5vqbXHADI/x4886v0= =JFr5 -----END PGP SIGNATURE-----
-- Best regards, Herman Webley
Completely agree with Adrian. We do need this. Only I would ask that this formal proccess doesn't mean too much administrative overhead for every new project. So, basically, a new section to know other people's 'big plans' and see easily 'who's working on what' would do. If we have one html page for each project and one 'coordinator' that maintains that page, keeps a list of related queued patches, and the people involved, that would be a good start point. For the rest, the patch queue and the forum will do. One of the main problems I see with the patch queue is that it's not practical at all when trying to get big patches in. The work it takes to have the patch up to date with HEAD, while people is reviewing it is really overwhelming. So what if we took some snapshot of the core as the starting point for each of this projects, and once the code has been reviewed and polished enough by the people involved in that particular project, we update it for head once as 'ready to be committed', and... ? Cheers, Jose
Jose A. Reyero wrote:
Completely agree with Adrian. We do need this. Me too.
The work it takes to have the patch up to date with HEAD, while people is reviewing it is really overwhelming. What Adrian is suggesting is facilitating better collaboration, helping to spread the work of making big changes.
So what if we took some snapshot of the core Sounds like just as much work, just in a different order.
A more structured approach to making big changes should allow for agreement on what would likely go into core prior to the code being completed, it should help shorten the review process. With that and better collaboration 'chasing HEAD'* should be less of a problem. * (you at the back, stop sniggering) -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
On Sunday 13 November 2005 06:09 am, Adrian Simmons wrote:
* (you at the back, stop sniggering)
I didn't say anything! I was just thinking that this might be a good idea. A. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods.
I like Adrian's idea of formalizing the development communications process for Core. The 'Issues' mechanism is suited for small and focused changes, but not really appropriate for large scale changes that cut across many modules / projects and/or have significant API changes. Discussions on a mailing list or IRC are ephemeral and/or divergent - it's hard to go to a single source for history, status, and proposed changes. I think that the proposed DEP process (though it will involve more overhead) will make teams and projects visible and accountable, and enable ownership of projects. It may also help to define roles for participants who might be willing but feeling that they don't know where to jump in. Djun
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12 Nov 2005, at 11:54 PM, Jose A. Reyero wrote:
Completely agree with Adrian. We do need this.
Only I would ask that this formal proccess doesn't mean too much administrative overhead for every new project. So, basically, a new section to know other people's 'big plans' and see easily 'who's working on what' would do. If we have one html page for each project and one 'coordinator' that maintains that page, keeps a list of related queued patches, and the people involved, that would be a good start point. For the rest, the patch queue and the forum will do. Exactly. I don't want us to be designing software around this.
One of the main problems I see with the patch queue is that it's not practical at all when trying to get big patches in.
This is the other thing DEPs do, they split big patches into seperate tasks, each with their own ticket. Or atleast, theoretically.
The work it takes to have the patch up to date with HEAD, while people is reviewing it is really overwhelming. This is why i want to move to supplying subversion repositories for each of the large projects. It worked great with Forms. But now we're getting too deep into future architecture development again.
So what if we took some snapshot of the core as the starting point for each of this projects, and once the code has been reviewed and polished enough by the people involved in that particular project, we update it for head once as 'ready to be committed', and... ?
That's why you have a seperate repository. =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDdm+kgegMqdGlkasRAoj7AJ4sIiZQKuZuvWwSqncELsn7OInafwCgwDY4 Tegd866gXPJdct7Z1WlcFJE= =v547 -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
So what if we took some snapshot of the core as the starting point for each of this projects, and once the code has been reviewed and polished enough by the people involved in that particular project, we update it for head once as 'ready to be committed', and... ?
That's why you have a seperate repository. =)
Right after sending the email I realised that what I was describing is already invented and is called 'branches' :-) We don't really need a separate repository for each of these projects, but the ability to create branches. Maybe if it's not practical to have too many branches in the main repository -I don't know too much about cvs administration and permissions-, we could have a new repository -better svn-, in which we mirror the main one, and have a more relaxed commit policy, and the ability to create branches. Actually I could keep a branch -kind of- in a folder in my sandbox. Only I don't know whether it will be too much for the current cvs repository if we all start to create our own branches like that.
Jose A. Reyero wrote:
We don't really need a separate repository for each of these projects, but the ability to create branches. If we were using SVN, maybe - but right now using a seperate repository allows the use of SVN instead of CVS :)
That's more than just SVN is better than CVS ranting, in the early stages of projects where files often get renamed 'svn rename filename' is a lot easier than CVS. But point taken. Branches can be merged. Then again I guess you could have a vendor branch in the separate SVN repository and merge with that before creating the final patch. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
I support this. It's time. The devel list is becoming less and less useful every week. We need a way to collaborate on architecture without all that "+1" and "path alias" bickering.
On Sat, 12 Nov 2005 19:28:09 -0500 Moshe Weitzman <weitzman@tejasa.com> wrote:
I support this. It's time. The devel list is becoming less and less useful every week. We need a way to collaborate on architecture without all that "+1" and "path alias" bickering.
+1 on this DEP *evil grin* And here is how we work currently: I use wiki (freelinking+books) and http://www.webschuur.com/node/272 this simple template. The first two h3s are for the client. The rest for me/the techies. Once that page grows big, I make it into subpages. The fist two paragraphs also serve as (starter of) end user help. It has proven to work very well! Yet is far less (yes) administrative overhead then maintaining issue-threads and patches. (Its our think first do later philosofy) Ber -- Bèr Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com
At 9:41 PM +0200 12/11/05, Adrian Rossouw wrote:
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.
The JEP structure looks pretty heavy handed. It might also be worth considering some of the features of PEPs. http://www.python.org/peps/pep-0001.html ...R.
On 11/12/05 8:29 PM, Richard Archer wrote:
At 9:41 PM +0200 12/11/05, Adrian Rossouw wrote:
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.
The JEP structure looks pretty heavy handed. It might also be worth considering some of the features of PEPs.
http://www.python.org/peps/pep-0001.html
...R.
Ahh. yeah PEPs are good as well, I keep pointing Adrian (and others) to PEAR's PEPr : http://pear.php.net/pepr/pepr-overview.php ... which is kind of a formalized "+1" process ... which I think would be fairly easy to get used to. Notice the overview page gives a real easy quick look at whats upcoming / in progress /etc. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Adrian proposed a general "get people together and work in the same direction" idea. Peps are more like "ive got this and that working and i'd like to get it in", os it seems to me. I am more for a place to work together on new ideas. I really liked that part of Adrians proposal. If, whether or when that causes more administrative overhead, we can sort that out. But IMNSHO going for a "tackle this issue together" system is what we should aim for, in the first place. It is what got that form API in. It is what holds back Those Big Issues from leveraging from yadiyadia level to Real Code Level, think drupal.css, think taxonomy.module cleanup, think CCK ideals, think install API. etcetc. I firmly beleive we reached a level where we can no longer deal with Big Changes, unless we form subgroups. Which, again, is what I got, this is all about. I hope so in any way. If this is only about getting more structured and more official administration in place, then I think we should at least start that "subgroup thingy" project rolling, now. Administration might help, but a place to work efficient, quick, efficient and dedicated, on a certain issue helps much much more, IMNSHO. Ber On Mon, 14 Nov 2005 10:22:23 -0500 James Walker <walkah@walkah.net> wrote:
On 11/12/05 8:29 PM, Richard Archer wrote:
At 9:41 PM +0200 12/11/05, Adrian Rossouw wrote:
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.
The JEP structure looks pretty heavy handed. It might also be worth considering some of the features of PEPs.
http://www.python.org/peps/pep-0001.html
...R.
Ahh. yeah PEPs are good as well, I keep pointing Adrian (and others) to PEAR's PEPr : http://pear.php.net/pepr/pepr-overview.php ... which is kind of a formalized "+1" process ... which I think would be fairly easy to get used to.
Notice the overview page gives a real easy quick look at whats upcoming / in progress /etc.
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
-- Bèr Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com
On 14 Nov 2005, at 20:46, Ber Kessels wrote:
It is what got that form API in. It is what holds back Those Big Issues from leveraging from yadiyadia level to Real Code Level, think drupal.css, think taxonomy.module cleanup, think CCK ideals, think install API. etcetc.
Erm, the CCK plans are pretty well documented. They have been for about a year. Similarly, the install API has been documented too. Your examples show that central documentation is no guarantee for success (however they are often a necessary step).
I firmly beleive we reached a level where we can no longer deal with Big Changes, unless we form subgroups. Which, again, is what I got, this is all about. I hope so in any way.
I firmly believe in people organizing themselves, and empowering them to do so. I do not believe in forcing people to write proposals. There are much larger projects than Jabber, Xaraya, PEAR or Python that are known to be successful without having proposals. Two random examples are the Linux kernel and KDE. Feel free to write a proposal for the drupal.css or taxonomy.module clean up, or to get consensus before you start writing code. I'm cool with that. It's just not mandatory. -- Dries Buytaert :: http://www.buytaert.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 1:07 AM, Dries Buytaert wrote:
On 14 Nov 2005, at 20:46, Ber Kessels wrote:
It is what got that form API in. It is what holds back Those Big Issues from leveraging from yadiyadia level to Real Code Level, think drupal.css, think taxonomy.module cleanup, think CCK ideals, think install API. etcetc.
Erm, the CCK plans are pretty well documented. They have been for about a year. Similarly, the install API has been documented too. Your examples show that central documentation is no guarantee for success (however they are often a necessary step).
I agree. DEP's should not be required, but are a tool which can, and should be used for larger tasks. I would also like to see DEPs used to pool our ideas together, so that you can develop and spec enhancements that you might not personally have a chance to develop fully, but which other people might be interested in working on. Writing a DEP is at least providing a solid starting point for someone else to expand on and develop from. Also, all DEPs won't be developed, but something that has a DEP has a higher chance of being developed than something which doesn't have it. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDeSlqgegMqdGlkasRArKfAJ0VoCT6sigkkg0/rW9tjdqfb2tVUACgxAhs zo1V5hHT5Gqm3rEJwyrAkkY= =XRUf -----END PGP SIGNATURE-----
On 11/14/05 6:07 PM, Dries Buytaert wrote:
On 14 Nov 2005, at 20:46, Ber Kessels wrote:
It is what got that form API in. It is what holds back Those Big Issues from leveraging from yadiyadia level to Real Code Level, think drupal.css, think taxonomy.module cleanup, think CCK ideals, think install API. etcetc.
Erm, the CCK plans are pretty well documented. They have been for about a year. Similarly, the install API has been documented too. Your examples show that central documentation is no guarantee for success (however they are often a necessary step).
Hrm. this is a good point ... and has made me rethink my position a bit. The thing biggest thing I think i'd like to see come from this idea, is a centralized mechanism for doing such organizing. My reasoning is this - using myself as an example - there are several "bigger projects" underway, that I know of because I'm pretty involved in the community, but I'm not directly involved in them all... however, they will have fairly large impact on my work (thinking of CCK and install , e.g.). Therefore, it would be really nice to have a place where i could go to check up on the projects (and, perhaps, discover some new ones). The community is becoming very large for any one person to keep tabs on it all... this might help, no? But you're right. I withdraw my previous requirement comment. I think the important thing is not that DEPs are required - because then we end up in the rathole of *which* changes require DEPs. However, central organization would be very helpful. And i mean beyond "but it's all on drupal.org". As wonderful as steven's search patches are... it's not quite a one page overview :P
I firmly beleive we reached a level where we can no longer deal with Big Changes, unless we form subgroups. Which, again, is what I got, this is all about. I hope so in any way.
I firmly believe in people organizing themselves, and empowering them to do so. I do not believe in forcing people to write proposals. There are much larger projects than Jabber, Xaraya, PEAR or Python that are known to be successful without having proposals. Two random examples are the Linux kernel and KDE.
This is incredibly well said. But i do think empowering the proposals could prove to be very... well... powerful. but, who am I kidding... I'd be the first to whine about having to write these things :P The other thing - and I realize now it's a bit tangential - but I'd like to see a more transparent contributer approval process. but , i'll leave that for another thread some day...
Feel free to write a proposal for the drupal.css or taxonomy.module clean up, or to get consensus before you start writing code. I'm cool with that. It's just not mandatory.
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
James Walker wrote:
The other thing - and I realize now it's a bit tangential - but I'd like to see a more transparent contributer approval process. but , i'll leave that for another thread some day...
I think having the applicants write some multi-volumen application proposal in advance of evalutating their application would be very effective in lowering the number of applications. So I am all for it. :) Cheers, Gerhard
On 11/14/05 8:00 PM, Gerhard Killesreiter wrote:
James Walker wrote:
The other thing - and I realize now it's a bit tangential - but I'd like to see a more transparent contributer approval process. but , i'll leave that for another thread some day...
I think having the applicants write some multi-volumen application proposal in advance of evalutating their application would be very effective in lowering the number of applications. So I am all for it. :)
this is indeed a (healthy?) side effect. it's not just about lowering the number of applications, but trying to maintain a higher level of applications... i'm also passively curious - of our 300+ cvs contributors how many stay active? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
James Walker wrote:
On 11/14/05 8:00 PM, Gerhard Killesreiter wrote:
James Walker wrote:
The other thing - and I realize now it's a bit tangential - but I'd like to see a more transparent contributer approval process. but , i'll leave that for another thread some day...
I think having the applicants write some multi-volumen application proposal in advance of evalutating their application would be very effective in lowering the number of applications. So I am all for it. :)
this is indeed a (healthy?) side effect. it's not just about lowering the number of applications, but trying to maintain a higher level of applications... i'm also passively curious - of our 300+ cvs contributors how many stay active?
Good question. First of all we are just three short of 400 approved accounts. The cvs admin screen only shows the date of the first, the most recent commit, and the total of commits. There are quite a few accounts (146!) that were never used. I wonder if that is correct. Ax Kollmorgen used to run cvsmonitor at drupal.kollm.org, but apparently he only does that for core nowadays. Cheers, Gerhard
James Walker wrote:
On 11/14/05 8:00 PM, Gerhard Killesreiter wrote:
I think having the applicants write some multi-volumen application proposal in advance of evalutating their application would be very effective in lowering the number of applications. So I am all for it. :)
this is indeed a (healthy?) side effect. it's not just about lowering the number of applications, but trying to maintain a higher level of applications... i'm also passively curious - of our 300+ cvs contributors how many stay active?
I'd wager it has no effect on module developers at all, but increases the number of people who get involved with core. Certainly I'm not about to spend time on core hacking when I'm not sure if the Magic Hand of Dries(tm) will approve it in the end. Obviously if he doesn't, I'm wasting my time. But if I'm contributing to an agreed project, that worry no longer applies. I don't mind having stuff sent back if it's wrongly formatted, but I would mind having something for core written and then rejected as not something Dries wants to commit for some other reason. [Maybe Dries never does that. I have no idea one way or another. That, in its own way, is yet another reason for this idea to go forward.] jh
Ha! It sounds we are all saying the same thing. * We would like a central place where people can work on dedicated tasks. * We don't want to add extra administration by making stuff like deps required. * We do want to get all the noses into one direction by giving the infratstructure (wiki?) to write down some stuff and to inform others what this dedicated task is about. So lets get some action: * SVN server? Or are we going to use sandboxen in CVS? * Wiki or handbooks? On drupal.org or on a dedicated site (devel.drupal.org or so)? * Who will get all this rolling? Anyone volunteering to write a dep (*harhar*) for this work-thingy? Ber On Mon, 14 Nov 2005 19:47:28 -0500 James Walker <walkah@walkah.net> wrote:
On 11/14/05 6:07 PM, Dries Buytaert wrote:
On 14 Nov 2005, at 20:46, Ber Kessels wrote:
It is what got that form API in. It is what holds back Those Big Issues from leveraging from yadiyadia level to Real Code Level, think drupal.css, think taxonomy.module cleanup, think CCK ideals, think install API. etcetc.
Erm, the CCK plans are pretty well documented. They have been for about a year. Similarly, the install API has been documented too. Your examples show that central documentation is no guarantee for success (however they are often a necessary step).
Hrm. this is a good point ... and has made me rethink my position a bit. The thing biggest thing I think i'd like to see come from this idea, is a centralized mechanism for doing such organizing. My reasoning is this - using myself as an example - there are several "bigger projects" underway, that I know of because I'm pretty involved in the community, but I'm not directly involved in them all... however, they will have fairly large impact on my work (thinking of CCK and install , e.g.). Therefore, it would be really nice to have a place where i could go to check up on the projects (and, perhaps, discover some new ones).
The community is becoming very large for any one person to keep tabs on it all... this might help, no?
But you're right. I withdraw my previous requirement comment. I think the important thing is not that DEPs are required - because then we end up in the rathole of *which* changes require DEPs. However, central organization would be very helpful. And i mean beyond "but it's all on drupal.org". As wonderful as steven's search patches are... it's not quite a one page overview :P
I firmly beleive we reached a level where we can no longer deal with Big Changes, unless we form subgroups. Which, again, is what I got, this is all about. I hope so in any way.
I firmly believe in people organizing themselves, and empowering them to do so. I do not believe in forcing people to write proposals. There are much larger projects than Jabber, Xaraya, PEAR or Python that are known to be successful without having proposals. Two random examples are the Linux kernel and KDE.
This is incredibly well said. But i do think empowering the proposals could prove to be very... well... powerful. but, who am I kidding... I'd be the first to whine about having to write these things :P
The other thing - and I realize now it's a bit tangential - but I'd like to see a more transparent contributer approval process. but , i'll leave that for another thread some day...
Feel free to write a proposal for the drupal.css or taxonomy.module clean up, or to get consensus before you start writing code. I'm cool with that. It's just not mandatory.
-- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
-- Bèr Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 Nov 2005, at 2:10 PM, Ber Kessels wrote:
* Who will get all this rolling? Anyone volunteering to write a dep (*harhar*) for this work-thingy?
I've already volunteered to write a DEP. I just have to find the time to do so. I will make it a relatively simple on though. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDeeGWgegMqdGlkasRAuYYAKC+nhIO+KMQWyzL7xkwP/YHStjz/wCfSP7r hvj7ldDVFG2kaWZZbefpX4U= =Uj6J -----END PGP SIGNATURE-----
But IMNSHO going for a "tackle this issue together" system is what we should aim for, in the first place. Yes, and the documentation, ideas place, the rest will be a good side effect of this.
I firmly beleive we reached a level where we can no longer deal with Big Changes, unless we form subgroups. Which, again, is what I got, this is all about. I hope so in any way. Subgroups as in tagreted development, I suppose. The way the form api was developed.
I don't like the idea of formalising as in adding a formal layer. This will definitely scare people off. Or just piss them off. Please, keep the "technocrats" away :) Generally I'm all for such proposal, regardless the name. Because they could be helpful to keep yourself informed. A reference point and a contacts point. Vlado
Hmm, some misunderstanding. I'm to blame! On Tue, 15 Nov 2005 10:08:43 +0000 vlado <vlado@dikini.net> wrote:
Subgroups as in tagreted development, I suppose. The way the form api was developed.
Yup. I firmly beleive that people can organise themselves. Just hand them some tools to do so and it'l happen.
I don't like the idea of formalising as in adding a formal layer. This will definitely scare people off. Or just piss them off. Please, keep the "technocrats" away :)
Neither do I, nor does Dries (or so i got from his previous post). Just set up some tools and groups like the ones tackling the forms API can get themselves going.
Generally I'm all for such proposal, regardless the name. Because they could be helpful to keep yourself informed. A reference point and a contacts point.
-- Bèr Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com
+1 from me too. It is about time we look at requirements early in the process, and discuss them and get agreement on them before we are too far off in coding. The mantra "code is gold and talk is silver" is often taken to extremes, and have undersirable effects. Adrian mentioned Jabber as an example. I will mention another CMS that written in PHP and MySQL: Xaraya has a format RFC process (Request for Comment). Here are some of them: http://xaraya.com/index.php/documentation/72 For small things, the patch process can still be used. For anything that is a bit more elaborate (e.g. forms API), we need the DEP process in place.
On Mon, Nov 14, 2005 at 12:35:05AM -0500, Khalid B wrote:
For small things, the patch process can still be used. For anything that is a bit more elaborate (e.g. forms API), we need the DEP process in place.
I think the process should be optional at the start. Let it evolve into something required if it is working. -Neil
Having DEPs can be a good thing, however, I won't make it a requirement. - If you think that working out a detailed proposal or design document would benefit your project, by all means, write one. - If you think that is what it takes to coordinate people that want to contribute to your project, by all means, write one. Nothing stops you from taking that path: - Occasionally, we've seen written proposals and task lists; the CCK being the most prominent example. See http://drupal.org/cck-status. - Occasionally, we've seen roadmap documents; Ber strongly believed in maintaining a Drupal 4.6 roadmap (not supported by me). See http:// drupal.org/node/12202. -- Dries Buytaert :: http://www.buytaert.net/
On Mon, 14 Nov 2005 10:50:07 +0100 Dries Buytaert <dries@buytaert.net> wrote:
- Occasionally, we've seen roadmap documents; Ber strongly believed in maintaining a Drupal 4.6 roadmap (not supported by me). See http:// drupal.org/node/12202.
To elaborate on this: I meant it as an experiment. To see if we could get something in place that all mayor projects seem to have: a place where humans can read whats happening. The experiment was a success, because the outcome is very clear: * Users want this very badly * We dont have an infrastructure (i.e. code) to maintain something like this easy * We dont have engineers and developers around who are willing to spend the time and effort to maintain their (or others) statuses on such a place. [1] * So we failed to maintain such a place. Ber [1] This should be either by the developers themselves, or by those who understand the code and technical (drupal) jargon well enough to rephrase a set of patchesm or a module into one sentence. It is a very hard thing to do. Apparently (that roadmap was never up to date) too hard for our current way of doing stuff. -- Bèr Kessels Drupal services bler.webschuur.com www.webschuur.com ber@jabber.webschuur.com
On 11/14/05 4:50 AM, Dries Buytaert wrote:
Having DEPs can be a good thing, however, I won't make it a requirement.
This is pretty big... I think it loses considerable effect if it's not part of the mandatory workflow... Part of the idea was to centralize the process and make it uniform project-wide. If you look at the examples where Adrian is drawing most of the ideas from (i.e. Jabber's JEPs or, one I like - PEAR's PEPr) - there is a centralized overview of what can / will be implemented. I.E. if it's not there, it can safely be presumed nobody is working on it. I understand that it's hard to introduce something like this on such a large community right now... but I think it would be hugely beneficial to have something slightly more formal in place... It's not a process we're gonna agree on overnight, but I think it's one we should work towards. my $0.02 (CAD) -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
It's not a process we're gonna agree on overnight, but I think it's one we should work towards.
if need to be, I can write docs on what I plan, that's OK. And while I know there is no clear cut answer here, what's the "size" of the change when you need to roll such a doc? Or, simply, it's "big change" and we rely on common sense? Regards NK
On 11/14/05 12:35 AM, Khalid B wrote:
For small things, the patch process can still be used. For anything that is a bit more elaborate (e.g. forms API), we need the DEP process in place.
Of course! obviously not every little feature request will go through this process, or the project as a whole will come grinding to a halt. But exactly, major API changes, new modules , etc should. (I personally think DEPs should be required for all new contrib modules - and thus new CVS accounts). -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Overall I think this is a good idea. On Sat, Nov 12, 2005 at 09:41:42PM +0200, Adrian Rossouw wrote:
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.
I think we should keep proposals written clearly and concisely. The longer something is, the less people will want to read it.
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.
Is this the best order- developers followed by users? I'm guessing it should be flexible. API changes go to developers first; functionality changes go to users first. -Neil
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-----
Zack Rosen wrote:
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
two hundred thousand for me and my family would really help out. thanks zack. in all seriousness, it would be helpful to get a list from civicspace and bryght and all those who funnel money into the project. the list would itemize infrastructure improvements that would help their fundraising efforts. if you construct such a list, please post the link the infrastructure mailing list. -moshe
participants (19)
-
Adrian Rossouw -
Adrian Simmons -
Anguo -
Ber Kessels -
Dries Buytaert -
Gerhard Killesreiter -
Herman Webley -
James Walker -
John Handelaar -
Jose A. Reyero -
Karoly Negyesi -
Khalid B -
Moshe Weitzman -
Nedjo Rogers -
neil＠civicspacelabs.org -
puregin -
Richard Archer -
vlado -
Zack Rosen