[drupal-devel] more core comitters
Hello, Steven already pointed out that the patch queue is growing fast. nearly ten pages, now. Yes, closing them helps, but I found that a lot of issues are actually very good. Some are old, some can indeed be closed, some wont apply, but the average sits there with one or two +1s in em. I think tha that indicates tha two core comitters is just too little to handle the flow of incoming patches. So hereby I wuold like to ask the following people if they wuold be interested in becoming core committers. And -off course- what everyone, specially Dries, thinks of more/these people as potential core contributors? Gerhard, Moshe and John vanDyk. Please do not feel offenced if i did not mention you :) I think these people are good candidates, because they have a lot of available time, and because they, IMHO, are very carefull and precise in reviewing patches. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Gerhard, Moshe and John vanDyk.
When we were discussing this at IRC, I also suggested Gerhard and Moshe. I can not vote for or against jvandyk. If I'd need to choose only one, it'd be Moshe. No flame and no ill feelings toward anyone, really. This is a rather touchy issue, I do not want to offend anyone. Regards NK
On Thu, 28 Jul 2005, Karoly Negyesi wrote:
Gerhard, Moshe and John vanDyk.
I am not sure that it is a good idea to discuss this while Dries is officially away (I know he reads his mail, but still). We should discuss it, though. Cheers, Gerhard, who is not sure he wants to be on that list
Gerhard, Moshe and John vanDyk.
I'm flattered, but my track record in that area is pretty poor. (Look at the growing patch queue for my own modules!) At 6:51 PM +0200 7/28/05, Bèr Kessels wrote:
I think these people are good candidates, because they have a lot of available time
Thanks for the laugh, Bèr! :)
I would also not be displeased if Dries and Steven appointed a third committer in a non-democratic fashion. In other words, I trust them to make a good decision without getting involved in a community discussion. They probably already know who thinks the most like they do. It could be that a third core committer will ease the backlog enough. I'm sure that having more than three Gods in the Heavens would also start to strain the decision process and make coordination harder. Until we do something more formal and drastic, maybe the answer is just one more person on the team. In any case, I too think the need is there to expand the team, albeit by only the minimum needed amount. -Robert PS: where do you guys get so much available time?
I think these people are good candidates, because they have a lot of available time
Thanks for the laugh, Bèr! :)
I think that Gerhard and Moshe have both earned that right (or have bad karma / have to do penance, depending on your point of view :-) ) This does not mean that J van Dyke did not earn it, it just means that Gerhard is more noisy :-0 As for Moshe's time, my perception (which could be totally wrong) is that his time is not as available as Gerhard's.
On 28 Jul 2005, at 19:35, Robert Douglass wrote:
I would also not be displeased if Dries and Steven appointed a third committer in a non-democratic fashion. In other words, I trust them to make a good decision without getting involved in a community discussion. They probably already know who thinks the most like they do. It could be that a third core committer will ease the backlog enough. I'm sure that having more than three Gods in the Heavens would also start to strain the decision process and make coordination harder. Until we do something more formal and drastic, maybe the answer is just one more person on the team.
I said this before and I'll say it again: the problem is not the committing but the reviewing. If people would spend more time reviewing patches in a critical fashion, rather than semi-blindly adding a '+1' without testing, that would come a long way. I tend to ignore +1's unless I sense that the commenter put time and effort in evaluating a patch. Furthermore, as Robert points out, adding more committers is not going to make things easier -- it creates conflicts. I'm perfectly happy with the way things are and do not intend to add another core committer at this point. (That is not to say that Moshe and Gerhard aren't doing a great job. They'd be in my top 5.) Also, we're going to grow the server administration team so that should/could free up some of my time. Last but not least, I'll work my way through the patch queue once I'm back. With the server going down and the fundraise, the past weeks have been exceptionally busy -- especially behind the scenes. -- Dries Buytaert :: http://www.buytaert.net/
On Fri, 29 Jul 2005 08:27:06 +0200, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 28 Jul 2005, at 19:35, Robert Douglass wrote:
I would also not be displeased if Dries and Steven appointed a third committer in a non-democratic fashion.
[...]
I said this before and I'll say it again: the problem is not the committing but the reviewing. If people would spend more time reviewing patches in a critical fashion, rather than semi-blindly adding a '+1' without testing, that would come a long way.
Have the changes in project.module from http://drupal.org/node/17052 hit drupal.org yet? If so, could we use different statuses to make it clearer which patches have been reviewed? That could help make it clearer which patches are ready for commit and which still need reviewing (if that's even part of the problem). -- Tim Altman
On Fri, 29 Jul 2005, Tim Altman wrote:
On Fri, 29 Jul 2005 08:27:06 +0200, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 28 Jul 2005, at 19:35, Robert Douglass wrote:
I would also not be displeased if Dries and Steven appointed a third committer in a non-democratic fashion.
[...]
I said this before and I'll say it again: the problem is not the committing but the reviewing. If people would spend more time reviewing patches in a critical fashion, rather than semi-blindly adding a '+1' without testing, that would come a long way.
Ack. But there are other problems too, see other mail.
Have the changes in project.module from http://drupal.org/node/17052 hit drupal.org yet?
They did if that URL leads to what I think.
If so, could we use different statuses to make it clearer which patches have been reviewed? That could help make it clearer which patches are ready for commit and which still need reviewing (if that's even part of the problem).
Dries, Nedjo, and I intended to discuss the setup of additional statuses etc. but didn't find the time yet. If you or anybody has a good proposal to make, speak up. I think that the less statuses you add the better we'll like it. Cheers, Gerhard
Hello, Op vrijdag 29 juli 2005 08:27, schreef Dries Buytaert:
I said this before and I'll say it again: the problem is not the committing but the reviewing.
Dries. I sincerely hope you do not take this as personal critique. It was never meant that way! I think none of us commented here, because he or she thinks you are not doing a good job! I wanted to have this said first and for all. Same goes for Steven, who is also doing a great job!
If people would spend more time reviewing patches in a critical fashion, rather than semi-blindly adding a '+1' without testing, that would come a long way. I tend to ignore +1's unless I sense that the commenter put time and effort in evaluating a patch.
One of the main reasons for bringing this up, was that (from my mail stats) I saw an 29% increase of core patches (patch mails sent to the ML) after drupal.org came back up again. I checked these figures, for I had a feeling that we attracted more developers over that crash! :) #drupal has been busier with new faces then ever.
Furthermore, as Robert points out, adding more committers is not going to make things easier -- it creates conflicts.
I don't want to sound nitpicky. But we used to have three. Kjartan is not (as) active anymore, so part of me bringing this up was to get back to three core comitters, like in the old days. But also, as mentioned above. We are growing. And in a growing system sometimes we need changes. what those changes are should be discussed here, IMO.
I'm perfectly happy with the way things are and do not intend to add another core committer at this point. (That is not to say that Moshe and Gerhard aren't doing a great job. They'd be in my top 5.) Also, we're going to grow the server administration team so that should/could free up some of my time.
Yes. that was another reason why i wanted to bring this up. Again: no offence meant at all. But things like this can (and thus will!) happen again. Things that might put you and /or Steven on other issues for a while. I think the fact that the patch queue grew so rapidly when an emergency took place, indicates that we are undermanned.
Last but not least, I'll work my way through the patch queue once I'm back. With the server going down and the fundraise, the past weeks have been exceptionally busy -- especially behind the scenes.
I am confident that assigning these tasks, and maybe some moreother tasks in near future too, to others will have the same effect as more core contributers, though! Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Fri, 29 Jul 2005, Dries Buytaert wrote:
I said this before and I'll say it again: the problem is not the committing but the reviewing.
No, one affects the other. In the past weeks I haven't reviewed any patches because I knew that both you and Steven were too busy to commit them and that by the time you'd have the time, I'd need to look at the stuff again. This is discouraging. I am pretty sure others are thinking the same.
If people would spend more time reviewing patches in a critical fashion, rather than semi-blindly adding a '+1' without testing, that would come a long way.
This is a problem, too. Software development is a non-democratic process, people.
I tend to ignore +1's unless I sense that the commenter put time and effort in evaluating a patch.
See above for my reasons not to invest both. Contrary to what Bèr believes, I have no time to waste either.
Furthermore, as Robert points out, adding more committers is not going to make things easier -- it creates conflicts.
I am pretty sure that these can be minimized. We've had three core committers in the past and it worked.
I'm perfectly happy with the way things are and do not intend to add another core committer at this point.
I am not. Currently, if you are away, not much happens at the Drupal project.
(That is not to say that Moshe and Gerhard aren't doing a great job. They'd be in my top 5.)
*g* Some day I'd like to find out if your No. 1 is also my No. 1.
Also, we're going to grow the server administration team so that should/could free up some of my time.
Let's hope this.
Last but not least, I'll work my way through the patch queue once I'm back.
Maybe you could change your habits (or we redefine the statuses) wrt to this. I think you should mark issues active if they do have a patch attached but you are not likely to commit it for some technical or other reason. The patch queue would be much shorter.
With the server going down and the fundraise, the past weeks have been exceptionally busy -- especially behind the scenes.
That's true, too. Let's hope we do no t have any of this sort of problems in the future. Cheers, Gerhard
Op vrijdag 29 juli 2005 11:17, schreef Gerhard Killesreiter:
See above for my reasons not to invest both. Contrary to what Bèr believes, I have no time to waste either.
I am sorr if i made it sound like that. I merely mentioned you because I think you are very carefull and precise in your reviews and patches. Things a core contributer needs to be IMO. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 29 Jul 2005, at 11:17, Gerhard Killesreiter wrote:
I said this before and I'll say it again: the problem is not the committing but the reviewing.
No, one affects the other. In the past weeks I haven't reviewed any patches because I knew that both you and Steven were too busy to commit them and that by the time you'd have the time, I'd need to look at the stuff again. This is discouraging. I am pretty sure others are thinking the same.
If a patch is tested, reviewed and benchmarked it takes me one minute to process it. In such a scenario, I can commit up to 60 patches in an hour, or empty the patch queue in an evening. This won't happen as I often spend 30 minutes testing, reviewing and benchmarking a particular patch. Testing big patches like the node revision patch easily takes me 1 hour. The node revision patch could have been committed weeks ago if only enough people cared about it. Adding core committers doesn't help. Adding more status flags to the project issues makes a patch's status more explicit (good) but doesn't change the fact that we'll need to spend a couple hours testing the node revision patch.
I tend to ignore +1's unless I sense that the commenter put time and effort in evaluating a patch.
See above for my reasons not to invest both. Contrary to what Bèr believes, I have no time to waste either.
I'm perfectly happy with you -- or other people -- not investing time/ energy in reviewing patches. If you believe testing, reviewing and benchmarking patches is a waste of your time, then I guess I "waste" at least 2 hours of my time a day -- especially because many reviews go unanswered. Make no mistake, I'm happy to "waste" my time reviewing other people's work, including yours. :-) Saying that less gets done during my absence, just means that fewer patches get reviewed. If the node revision patch (our running example) was tested extensively, I could commit it from Italy. For example, I committed some patches earlier today. However, when I don't have the time it takes to test it (like now), it sometimes goes unreviewed, and hence, uncommitted.
I am pretty sure that these can be minimized. We've had three core committers in the past and it worked.
Not quite. Steven and Kjartan let me review their changes first. Steven only started to commit "independently" one year ago, and even now, he still consults me about bigger changes (and often, I consult him too). -- Dries Buytaert :: http://www.buytaert.net/
After reading the discussion thus far, it seems the bottleneck for development is the testing/reviewing/benchmarking of patches, not the amount of core contributers. So how about we create handbook page(s) describing standards or guidelines the core developers want to see in the commenting of the patches. This would hopefully help eliminate the '+1' comments and possibly prodive some useful documentation if a committed patch winds up causing problems. Also if we have certain conventions, we could have patch testing phases. For example, 'patch phase 1' would be an initial commit of a patch. 'Patch phase 2' would someone reviewing the patch to make sure its fits with drupal/PHP conventions, doesn't break drupal, and is still relevant to the version of Drupal the patch is for. 'Patch phase 3' would be comments on the testing of the patch, like how well it tackles the actual problem, how well it functions with/within the current system, and how well it is written (i.e. not a hack job). And 'patch phase 4' would be some simple benchmarking. If its clearly documented on how it should be done and presented, that would allow more people to help with patches, and letting the core contributters focus on the acutal numbers, instead having to make the numbers themselves. On 7/29/05, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 29 Jul 2005, at 11:17, Gerhard Killesreiter wrote:
I said this before and I'll say it again: the problem is not the committing but the reviewing.
No, one affects the other. In the past weeks I haven't reviewed any patches because I knew that both you and Steven were too busy to commit them and that by the time you'd have the time, I'd need to look at the stuff again. This is discouraging. I am pretty sure others are thinking the same.
If a patch is tested, reviewed and benchmarked it takes me one minute to process it. In such a scenario, I can commit up to 60 patches in an hour, or empty the patch queue in an evening. This won't happen as I often spend 30 minutes testing, reviewing and benchmarking a particular patch. Testing big patches like the node revision patch easily takes me 1 hour. The node revision patch could have been committed weeks ago if only enough people cared about it. Adding core committers doesn't help. Adding more status flags to the project issues makes a patch's status more explicit (good) but doesn't change the fact that we'll need to spend a couple hours testing the node revision patch.
I tend to ignore +1's unless I sense that the commenter put time and effort in evaluating a patch.
See above for my reasons not to invest both. Contrary to what Bèr believes, I have no time to waste either.
I'm perfectly happy with you -- or other people -- not investing time/ energy in reviewing patches. If you believe testing, reviewing and benchmarking patches is a waste of your time, then I guess I "waste" at least 2 hours of my time a day -- especially because many reviews go unanswered. Make no mistake, I'm happy to "waste" my time reviewing other people's work, including yours. :-) Saying that less gets done during my absence, just means that fewer patches get reviewed. If the node revision patch (our running example) was tested extensively, I could commit it from Italy. For example, I committed some patches earlier today. However, when I don't have the time it takes to test it (like now), it sometimes goes unreviewed, and hence, uncommitted.
I am pretty sure that these can be minimized. We've had three core committers in the past and it worked.
Not quite. Steven and Kjartan let me review their changes first. Steven only started to commit "independently" one year ago, and even now, he still consults me about bigger changes (and often, I consult him too).
-- Dries Buytaert :: http://www.buytaert.net/
Another good way to help out, is for the patchers themselves to check their patches. I always test my patches on as many systems I can. Usually on my own localhost (The free Xitami, MySQL express, PHP 4) and on a linux box (sometimes my own, sometimes a donated one). This way, I can confidently say that my patch was tested and worked on these various systems. Robin On 7/29/05, David Barnes <eglish@gmail.com> wrote:
After reading the discussion thus far, it seems the bottleneck for development is the testing/reviewing/benchmarking of patches, not the amount of core contributers. So how about we create handbook page(s) describing standards or guidelines the core developers want to see in the commenting of the patches. This would hopefully help eliminate the '+1' comments and possibly prodive some useful documentation if a committed patch winds up causing problems. Also if we have certain conventions, we could have patch testing phases. For example, 'patch phase 1' would be an initial commit of a patch. 'Patch phase 2' would someone reviewing the patch to make sure its fits with drupal/PHP conventions, doesn't break drupal, and is still relevant to the version of Drupal the patch is for. 'Patch phase 3' would be comments on the testing of the patch, like how well it tackles the actual problem, how well it functions with/within the current system, and how well it is written (i.e. not a hack job). And 'patch phase 4' would be some simple benchmarking.
If its clearly documented on how it should be done and presented, that would allow more people to help with patches, and letting the core contributters focus on the acutal numbers, instead having to make the numbers themselves.
On 7/29/05, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 29 Jul 2005, at 11:17, Gerhard Killesreiter wrote:
I said this before and I'll say it again: the problem is not the committing but the reviewing.
No, one affects the other. In the past weeks I haven't reviewed any patches because I knew that both you and Steven were too busy to commit them and that by the time you'd have the time, I'd need to look at the stuff again. This is discouraging. I am pretty sure others are thinking the same.
If a patch is tested, reviewed and benchmarked it takes me one minute to process it. In such a scenario, I can commit up to 60 patches in an hour, or empty the patch queue in an evening. This won't happen as I often spend 30 minutes testing, reviewing and benchmarking a particular patch. Testing big patches like the node revision patch easily takes me 1 hour. The node revision patch could have been committed weeks ago if only enough people cared about it. Adding core committers doesn't help. Adding more status flags to the project issues makes a patch's status more explicit (good) but doesn't change the fact that we'll need to spend a couple hours testing the node revision patch.
I tend to ignore +1's unless I sense that the commenter put time and effort in evaluating a patch.
See above for my reasons not to invest both. Contrary to what Bèr believes, I have no time to waste either.
I'm perfectly happy with you -- or other people -- not investing time/ energy in reviewing patches. If you believe testing, reviewing and benchmarking patches is a waste of your time, then I guess I "waste" at least 2 hours of my time a day -- especially because many reviews go unanswered. Make no mistake, I'm happy to "waste" my time reviewing other people's work, including yours. :-) Saying that less gets done during my absence, just means that fewer patches get reviewed. If the node revision patch (our running example) was tested extensively, I could commit it from Italy. For example, I committed some patches earlier today. However, when I don't have the time it takes to test it (like now), it sometimes goes unreviewed, and hence, uncommitted.
I am pretty sure that these can be minimized. We've had three core committers in the past and it worked.
Not quite. Steven and Kjartan let me review their changes first. Steven only started to commit "independently" one year ago, and even now, he still consults me about bigger changes (and often, I consult him too).
-- Dries Buytaert :: http://www.buytaert.net/
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
[See bottom of this email for two concrete proposals.] Gerhard:
I said this before and I'll say it again: the problem is not the committing but the reviewing.
No, one affects the other.
Absolutely. The issue of bottlenecks and problems with the code review and committing has been brought up repeatedly, there have been many good suggestions, but no significant changes have been made--and so the problem remains. After so many months of hearing it, the "everyone should just review more" pat response is beginning to sound like a mantra. Yes, it's a truism that more and better testing and reviewing by qualified developers is the key. But the question is, what steps are we going to take to bring that about? Aside from this mantra, which, I think it's obvious, does nothing to address the cause of the problem. Dries:
I guess I "waste" at least 2 hours of my time a day [testing and reviewing]
Why? Is it unrelated to the fact that that Dries (a) has a recognized role and position, (b) has a direct decision making role, and so knows his work will be used and not wasted? When we call for more core committers, we're not saying we need more people who can press a button when everything is all ready. We're saying, rather - or I am, anyway, as I have repeatedly over the past couple of years, but to no avail - that we need to bring more people into formal, recognized decision-making roles. Where are all these highly skilled, dedicated reviewers supposed to come from? The motivation to commit time and energy doesn't come from nowhere. It certainly doesn't come from the experience of investing gobs of time and energy only to have it sit there forever in limbo. That's what I hear Gerhard saying--and he couldn't be more correct. This sort of dedication comes, rather, from a feeling of recognition, membership, involvement, and a direct role in decision making. Dries:
Steven only started to commit "independently" one year ago
And what is the result of that experience? Is it better to have two "independent" committers than only one? Is there any reason to think that more wouldn't be a further improvement? I hear, repeadedly, concern from the project owners and some others about the drastic risks of opening up decision making. While understandable, I think this fear is pretty well entirely unfounded. My experience from another open source project I'm involved with (Mapbuilder, like Drupal founded by an individual who did much of the initial coding himself) is that bringing in more people as members and decision makers can be energizing and a great way to encourage involvement and draw on expertise. New committers have always been respectful and productive. Some, encouraged by their reception and finding a place in the project, go on to become major developers. In this case, quality comes from openness, involvement, and consultation, as opposed to strict central control. Here are two concrete steps that could actually address this ongoing issue and greatly strengthen the Drupal project rather than, once again, doing nothing and hoping the issue (and those raising it?) will go away. 1. Create a new group of "committers", with defined responsibilities, accountable to the owners. Around 4 or 5 initially would be a good number. This is a common role in open source projects. 2. Implement the issue status options I coded for the Project module, or some subset of them, providing a more nuanced process for designating the review status of issues. I provided with the module a default set of status options based on the long discussions we'd had and designed for use on drupal.org. While the patch has been accepted, we've not yet seen any changes on drupal.org.
When we call for more core committers, we're not saying we need more people who can press a button when everything is all ready. We're saying, rather - or I am, anyway, as I have repeatedly over the past couple of years, but to no avail - that we need to bring more people into formal, recognized decision-making roles.
Where are all these highly skilled, dedicated reviewers supposed to come from? The motivation to commit time and energy doesn't come from nowhere. It certainly doesn't come from the experience of investing gobs of time and energy only to have it sit there forever in limbo. That's what I hear Gerhard saying--and he couldn't be more correct.
This sort of dedication comes, rather, from a feeling of recognition, membership, involvement, and a direct role in decision making.
excellently stated.
When we call for more core committers, we're not saying we need more people who can press a button when everything is all ready. We're saying, rather - or I am, anyway, as I have repeatedly over the past couple of years, but to no avail - that we need to bring more people into formal, recognized decision-making roles.
Where are all these highly skilled, dedicated reviewers supposed to come from? The motivation to commit time and energy doesn't come from nowhere. It certainly doesn't come from the experience of investing gobs of time and energy only to have it sit there forever in limbo. That's what I hear Gerhard saying--and he couldn't be more correct.
This sort of dedication comes, rather, from a feeling of recognition, membership, involvement, and a direct role in decision making.
excellently stated.
First comes responsibilty then power IMHO. I have seen patches blindly committed by Dries, because there were good and deep reviews attached to the bug reports. As far as I see Drupal is open, having the possibilty to modify any details in a bug report is one of the pieces allowing you to drive the process to wherever you see fit. Goba
On 30 Jul 2005, at 18:16, Nedjo Rogers wrote:
2. Implement the issue status options I coded for the Project module, or some subset of them, providing a more nuanced process for designating the review status of issues. I provided with the module a default set of status options based on the long discussions we'd had and designed for use on drupal.org. While the patch has been accepted, we've not yet seen any changes on drupal.org.
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful: 1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback -- Dries Buytaert :: http://www.buytaert.net/
I assume these will be multi-select? Dries Buytaert wrote:
On 30 Jul 2005, at 18:16, Nedjo Rogers wrote:
2. Implement the issue status options I coded for the Project module, or some subset of them, providing a more nuanced process for designating the review status of issues. I provided with the module a default set of status options based on the long discussions we'd had and designed for use on drupal.org. While the patch has been accepted, we've not yet seen any changes on drupal.org.
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful:
1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback
-- Dries Buytaert :: http://www.buytaert.net/
On Sat, 30 Jul 2005, Robert Douglass wrote:
I assume these will be multi-select?
No, sorry.
Dries Buytaert wrote:
On 30 Jul 2005, at 18:16, Nedjo Rogers wrote:
2. Implement the issue status options I coded for the Project module, or some subset of them, providing a more nuanced process for designating the review status of issues. I provided with the module a default set of status options based on the long discussions we'd had and designed for use on drupal.org. While the patch has been accepted, we've not yet seen any changes on drupal.org.
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful:
1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback
To make clear, what we are talking about, we should name the new statuses as "patch (needs code review)" or similar. Initially I had hoped that we could add only a few new statuses, but after thinking a while, I couldn't find one to omit. What we need to discuss is who should be allowed to set which status. 1) which permissions should the plain vanilla drupal.org have? 2) how do we identify other groups that should have more access? Maybe we should first try to get away without introducing additional overhead. Cheers, Gerhard
On 30 Jul 2005, at 18:28, Dries Buytaert wrote:
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful:
1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback
OK, I setup 3 new categories: 1. patch (code needs review) 2. patch (code needs work) 3. patch (ready to be committed) We can refine or reword these later on. Right now, all patches default to 'patch (code needs review)' so we'll want to work our way to the patch queue and update the patches according to the new fields. Thoughts? -- Dries Buytaert :: http://www.buytaert.net/
OK, I setup 3 new categories:
1. patch (code needs review) 2. patch (code needs work) 3. patch (ready to be committed)
Great!
Thoughts?
Minor suggestion: change "fixed" to "applied", so that it covers feature requests as well. Beyond this, I'm thinking we could use taxonomy to give a more detailed idea. There are a number of criteria we use to designate if a patch should be accepted. I tried to summarize these in the handbook at http://drupal.org/node/10262. I suggest we create a new vocabulary on drupal.org, "project acceptance criteria", with something like the following values: * works as expected * supports Drupal aims * is current * addresses issues raised * well coded * demonstrated demand * broadly applicable * benefits justified and set project issues as its node type. The only problem would be tracking who made what changes, and why. This could be handled simply by logging in the issue comments, e.g., "Setting 'well coded'." Or we could introduce a helper module (taxonomy_node_log) that would automatically track term updates by time and user. Thoughts?
I suggest we create a new vocabulary on drupal.org, "project acceptance criteria", with something like the following values:
* works as expected * supports Drupal aims * is current * addresses issues raised * well coded * demonstrated demand * broadly applicable * benefits justified
and set project issues as its node type.
I don't mind doing this but at the same time I'd think it is easy enough to type out such comments in, well, the comments associated with the issue. That is what the reviews are for. -- Dries Buytaert :: http://www.buytaert.net/
On Sat, 30 Jul 2005 19:22:56 +0200, Dries Buytaert <dries@buytaert.net> wrote:
On 30 Jul 2005, at 18:28, Dries Buytaert wrote:
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful:
1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback
OK, I setup 3 new categories:
1. patch (code needs review) 2. patch (code needs work) 3. patch (ready to be committed)
We can refine or reword these later on. Right now, all patches default to 'patch (code needs review)' so we'll want to work our way to the patch queue and update the patches according to the new fields.
Thoughts?
It's best that we start by examining the way we work to make the statuses work for us. So, here's some of the common tasks related to project management at Drupal.org: 1) Report a bug or request an enhancement 2) Agree that a bug report is valid or that an enhancement is desireable 3) Agree to work on an issue 4) Demonstrate the direction of development to address an issue 5) Upload a patch 6) Review a patch 7) Commit a patch 8) Verify that a patch solved the reported problem or addresed the enhancement request Thus, I propose the following statuses, each aligned to a task above: 1) New 2) Confirmed 3) Assigned 4) Demo 5) Patched 6) Reviewed 7) Committed 8) Verified -- Tim Altman
Dries Buytaert wrote:
On 30 Jul 2005, at 18:28, Dries Buytaert wrote:
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful:
1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback
OK, I setup 3 new categories:
1. patch (code needs review) 2. patch (code needs work) 3. patch (ready to be committed)
We can refine or reword these later on. Right now, all patches default to 'patch (code needs review)' so we'll want to work our way to the patch queue and update the patches according to the new fields.
Thoughts?
These new options sure will be an improvement. The problem that still persist is the cycle of updating/reviewing/testing/approving, with some issues becoming long long threads to read, and also who takes the responsibility to update status for a patch, and whether you can trust that person's judgement or not. One way to address this could be approaching it as a rating system better than a simple 'status' field. I'm thinking of a 'moderation queue' like system, in which several users/reviewers could post their votes on a patch. Then you -or someone reviewing patches for final 'commit' could see it like: - 6 people are against this specific feature (list...) - 5 people thinks patch needs work (list: user1, user2,...) - 4 people thinks patch is ready to be committed (list....) Reviewers should be able too, to change their 'vote' on the patch once its been updated. Votes like 'ready to be committed' could be restricted, by role, to a reduced number of users. Or votes could be weighted depending on some 'trust level' assigned to each users. I know this 'rating system' wont be easy to implement. But once its up and running it coul be the killer feature for speeding up patch reviewing. You could also have some filter system, so only patches that already have a number of +1 reviews will have to catch your attention.
-- Dries Buytaert :: http://www.buytaert.net/
Hello, Can we now close this thread? Without becoming too political or theoretical: rogramming for an OSS system is not a democratic process. Essential it is more anarchistic: bugs are fixed ad-hoc. Code that is written is more valuable than the most brilliant idea that exists as idea only. So: whatever solutions are brought forward: voting systems, ratings, role-based value systems:Only in those places issues where work is done, and where attention of others is focussed, actual changes will take place. Rating, ranking voting cannot be coded in programs or systems. It just happens. Patches are committed whenever they are ready to. not just because the system tells it has a lot of points. Indeed, the mantra, above all, is more hands. All we can do, is make sure the work that these hands do does not get lost. For, IMO that was the main problem: a lot of good patches were waiting, but became somehow crufty. I am confident, though that the current renewed patch queue will bring some improvement. I would therefore like to see this thread and discussion be put to halt, untill the day that the current solutions prove to be insufficient, if that ever happens. Ber Op maandag 01 augustus 2005 16:50, schreef Jose A. Reyero:
Dries Buytaert wrote:
On 30 Jul 2005, at 18:28, Dries Buytaert wrote:
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful:
1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback
OK, I setup 3 new categories:
1. patch (code needs review) 2. patch (code needs work) 3. patch (ready to be committed)
We can refine or reword these later on. Right now, all patches default to 'patch (code needs review)' so we'll want to work our way to the patch queue and update the patches according to the new fields.
Thoughts?
These new options sure will be an improvement. The problem that still persist is the cycle of updating/reviewing/testing/approving, with some issues becoming long long threads to read, and also who takes the responsibility to update status for a patch, and whether you can trust that person's judgement or not.
One way to address this could be approaching it as a rating system better than a simple 'status' field. I'm thinking of a 'moderation queue' like system, in which several users/reviewers could post their votes on a patch. Then you -or someone reviewing patches for final 'commit' could see it like:
- 6 people are against this specific feature (list...) - 5 people thinks patch needs work (list: user1, user2,...) - 4 people thinks patch is ready to be committed (list....)
Reviewers should be able too, to change their 'vote' on the patch once its been updated. Votes like 'ready to be committed' could be restricted, by role, to a reduced number of users. Or votes could be weighted depending on some 'trust level' assigned to each users.
I know this 'rating system' wont be easy to implement. But once its up and running it coul be the killer feature for speeding up patch reviewing. You could also have some filter system, so only patches that already have a number of +1 reviews will have to catch your attention.
-- Dries Buytaert :: http://www.buytaert.net/ Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Yes, Ber, but what I wrote is not at all about decision making, nor democracy or anything like that Just about structuring the info so people taking decisions can have it all at first glance, thus saving some time. Regards, Jose Bèr Kessels wrote:
Hello,
Can we now close this thread?
Without becoming too political or theoretical: rogramming for an OSS system is not a democratic process. Essential it is more anarchistic: bugs are fixed ad-hoc. Code that is written is more valuable than the most brilliant idea that exists as idea only.
So: whatever solutions are brought forward: voting systems, ratings, role-based value systems:Only in those places issues where work is done, and where attention of others is focussed, actual changes will take place.
Rating, ranking voting cannot be coded in programs or systems. It just happens. Patches are committed whenever they are ready to. not just because the system tells it has a lot of points.
Indeed, the mantra, above all, is more hands. All we can do, is make sure the work that these hands do does not get lost. For, IMO that was the main problem: a lot of good patches were waiting, but became somehow crufty. I am confident, though that the current renewed patch queue will bring some improvement.
I would therefore like to see this thread and discussion be put to halt, untill the day that the current solutions prove to be insufficient, if that ever happens.
Ber
Op maandag 01 augustus 2005 16:50, schreef Jose A. Reyero:
Dries Buytaert wrote:
On 30 Jul 2005, at 18:28, Dries Buytaert wrote:
The patch is live on drupal.org. What remains to be done is defining new status values. Let's do that now. Here are some that could be useful:
1. Needs code review 2. Needs testing 3. Needs benchmarking 4. Needs update/work 5. Needs feedback
OK, I setup 3 new categories:
1. patch (code needs review) 2. patch (code needs work) 3. patch (ready to be committed)
We can refine or reword these later on. Right now, all patches default to 'patch (code needs review)' so we'll want to work our way to the patch queue and update the patches according to the new fields.
Thoughts?
These new options sure will be an improvement. The problem that still persist is the cycle of updating/reviewing/testing/approving, with some issues becoming long long threads to read, and also who takes the responsibility to update status for a patch, and whether you can trust that person's judgement or not.
One way to address this could be approaching it as a rating system better than a simple 'status' field. I'm thinking of a 'moderation queue' like system, in which several users/reviewers could post their votes on a patch. Then you -or someone reviewing patches for final 'commit' could see it like:
- 6 people are against this specific feature (list...) - 5 people thinks patch needs work (list: user1, user2,...) - 4 people thinks patch is ready to be committed (list....)
Reviewers should be able too, to change their 'vote' on the patch once its been updated. Votes like 'ready to be committed' could be restricted, by role, to a reduced number of users. Or votes could be weighted depending on some 'trust level' assigned to each users.
I know this 'rating system' wont be easy to implement. But once its up and running it coul be the killer feature for speeding up patch reviewing. You could also have some filter system, so only patches that already have a number of +1 reviews will have to catch your attention.
-- Dries Buytaert :: http://www.buytaert.net/
Regards, Bèr
Op dinsdag 02 augustus 2005 10:55, schreef Jose A. Reyero:
Yes, Ber, but what I wrote is not at all about decision making, nor democracy or anything like that
Sorry if it sounded like I commented on your mail specifically. I commented on the whole thread; by picking the last reply. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
I've rewritten the patch reviewing guidelines. I've tried to point out what you should be asking yourself when doing a review as well as describing some good practices that I've found help. Though it also doubles as a "should I submit my patch" guide, basically ;). http://drupal.org/node/772 Steven
participants (15)
-
Bèr Kessels -
David Barnes -
Dries Buytaert -
Dries Buytaert -
Gabor Hojtsy -
Gerhard Killesreiter -
John VanDyk -
Jose A. Reyero -
Karoly Negyesi -
Khalid B -
Nedjo Rogers -
Robert Douglass -
Robin Monks -
Steven Wittens -
Tim Altman