How to post bug reports and patches
Hi, This is my first post to this list so I will introduce myself first. My name is Markus Kalkbrenner. I'm developing software for more than 15 years and participating in open source projects since 7 years. Two years ago I started working with drupal and posted my first bug reports and patches. Currently I'm asking myself which is the right strategy to contribute patches and get them committed to CVS because most of the time I'm still working with drupal 5 and find bugs there. Just some examples: Posted 4 month ago for drupal 5.7: http://drupal.org/node/229411 node_view() incompatible to php5 I was asked to add more comments to my patch and drumm found out that the same bug still exists in drupal 6. So I added the comments but nothing happend. Neither in D5 nor in D6. Posted 3 month ago for drupal 5.8 http://drupal.org/node/287063 node_delete memory leak and wrong order of commands In a different bug I was told to post the bugs for drupal 6 to get them handled faster and finally backported to drupal 5. So I switched the version for this issue to D6 and added an additional patch for it. But no reaction. Posted 3 month ago for drupal 6.dev http://drupal.org/node/298768 Ensure that entries are written to watchdog table and http://drupal.org/node/298678 Impossible to lock two MySQL tables From my point of view these are two serious issues which are the reason for several other bug reports. I found them in drupal 5 but discovered that they still exist in D6 and D7. So I decided to post them for D6 because this is the current stable version. Unfortunately I didn't see any reaction so far. Please don't get me wrong. I really like drupal and will keep on contributing patches because I want to improve it. But maybe I'm doing something wrong or you just have no time to maintain the stable versions. So for me the current situation is like a "bad user experience". Markus
Please see http://drupal.org/node/10263. To the extent that is unclear, then ask. Note that all patches to core must be against HEAD when the bug still exists in HEAD. Thanks. On Thu, Oct 30, 2008 at 9:00 AM, Markus Kalkbrenner <markus.kalkbrenner@arcor.de> wrote:
Hi,
This is my first post to this list so I will introduce myself first. My name is Markus Kalkbrenner. I'm developing software for more than 15 years and participating in open source projects since 7 years. Two years ago I started working with drupal and posted my first bug reports and patches.
Currently I'm asking myself which is the right strategy to contribute patches and get them committed to CVS because most of the time I'm still working with drupal 5 and find bugs there.
Just some examples:
Posted 4 month ago for drupal 5.7: http://drupal.org/node/229411 node_view() incompatible to php5
I was asked to add more comments to my patch and drumm found out that the same bug still exists in drupal 6. So I added the comments but nothing happend. Neither in D5 nor in D6.
Posted 3 month ago for drupal 5.8 http://drupal.org/node/287063 node_delete memory leak and wrong order of commands
In a different bug I was told to post the bugs for drupal 6 to get them handled faster and finally backported to drupal 5. So I switched the version for this issue to D6 and added an additional patch for it. But no reaction.
Posted 3 month ago for drupal 6.dev http://drupal.org/node/298768 Ensure that entries are written to watchdog table and http://drupal.org/node/298678 Impossible to lock two MySQL tables
From my point of view these are two serious issues which are the reason for several other bug reports. I found them in drupal 5 but discovered that they still exist in D6 and D7. So I decided to post them for D6 because this is the current stable version. Unfortunately I didn't see any reaction so far.
Please don't get me wrong. I really like drupal and will keep on contributing patches because I want to improve it. But maybe I'm doing something wrong or you just have no time to maintain the stable versions. So for me the current situation is like a "bad user experience".
Markus
On Thursday 30 October 2008 14:39:19 Moshe Weitzman wrote:
Please see http://drupal.org/node/10263. To the extent that is unclear, then ask. Note that all patches to core must be against HEAD when the bug still exists in HEAD. Thanks. That page doesn't address the biggest problem I have trying to contribute; it literally takes months to get any reply whatsoever to a patch (I think in one case there was 6 months between reporting an issue with a patch and the first reply other than me updating the patch to keep working against HEAD (which I gave up doing after a couple of months)). So what is wrong with the current system that it can take this long?
Marijn
On Thu, Oct 30, 2008 at 8:18 AM, Marijn Kruisselbrink <m.kruisselbrink@student.tue.nl> wrote:
gave up doing after a couple of months)). So what is wrong with the current system that it can take this long?
The problem is that there is a very small set of people to commit patches. Those people are busy. So, they rely on reviews from other people to help them decide what to commit. Since there are not enough people who do reviews, the people who review code get wide respect from the community including the people that they help the most: the core committers. When the core committers see a patch by someone they respect (like a patch reviewer) the patch is more likely to get committed because of the respect and trust. So, it's very simple: 1. To get your patch committed quickly, you build trust and respect with the committers 2. To build trust and respect with the committers you review other people's patches 3. Repeat until there are no more bugs Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com
Most often patches are ignored when they are not relevant to the development version of Drupal. Bugs are sometimes labeled feature requests by maintainers who are not interested in fixes that only apply to older versions. In effect they're saying, This doesn't need to be fixed. You got it to work for you, and other people can wait for the next version of Drupal. Only a few core maintainers behave this way, probably because they are trying to shorten the patch queue, but their comments discourage other developers from getting involved. On Oct 30, 2008, at 10:18 AM, Marijn Kruisselbrink wrote:
That page doesn't address the biggest problem I have trying to contribute; it literally takes months to get any reply whatsoever to a patch (I think in one case there was 6 months between reporting an issue with a patch and the first reply other than me updating the patch to keep working against HEAD (which I gave up doing after a couple of months)). So what is wrong with the current system that it can take this long?
Marijn
After chatting with greggles, I should make clear that I can guess why core maintainers would do this because as a project maintainer I have been guilty of exactly the same thing. There are four bottlenecks in project maintenance: 1. People who complain outnumber people to read complaints. 2. People who read complaints outnumber people who provide patches. 3. People who provide patches outnumber people who review patches. 4. People who review patches outnumber people who commit patches. This means a maintainer spends a lot of time sifting through issues and trying to consolidate them to the few that are helpful. A maintainer's frustration is that most users focus on bottleneck 4 when the other three are just as important. On Oct 30, 2008, at 10:42 AM, Darren Oh wrote:
Most often patches are ignored when they are not relevant to the development version of Drupal. Bugs are sometimes labeled feature requests by maintainers who are not interested in fixes that only apply to older versions. In effect they're saying, This doesn't need to be fixed. You got it to work for you, and other people can wait for the next version of Drupal.
Only a few core maintainers behave this way, probably because they are trying to shorten the patch queue, but their comments discourage other developers from getting involved.
On Thu, 2008-10-30 at 11:07 -0400, Darren Oh wrote:
There are four bottlenecks in project maintenance:
1. People who complain outnumber people to read complaints. 2. People who read complaints outnumber people who provide patches. 3. People who provide patches outnumber people who review patches. 4. People who review patches outnumber people who commit patches.
A thought about widening bottleneck #3 that requires no technological innovation: Suppose I've submitted a patch that I'm keen to see reviewed and committed. Would it be socially acceptable to review two other patches (preferably related in some way and of a similar level of complexity) and ask the submitters of those patches to review my patch in return? You scratch my patch, I'll scratch yours. Although there would be no guarantee of my patch being reviewed by the other patch submitters, the fact that it might happen would give me more motivation to review patches. I'm a "enthusiast" who runs drupal sites in my spare time rather than doing at as a job. I've contributed to issues and submitted a few patches to modules and core, always in response to running into a bug myself. Although they're all small and fix minor issues, I feel quite proud of my patches, and am keen to see them grow up, mature and join the rest of the drupal code. Like an ambitious parent, I'm willing to put effort into helping my patch-children on in life. I'm guessing that there may be others who feel similarly. David (egfrith)
On Friday 31 October 2008 6:21:55 pm David Sterratt wrote:
On Thu, 2008-10-30 at 11:07 -0400, Darren Oh wrote:
There are four bottlenecks in project maintenance:
1. People who complain outnumber people to read complaints. 2. People who read complaints outnumber people who provide patches. 3. People who provide patches outnumber people who review patches. 4. People who review patches outnumber people who commit patches.
A thought about widening bottleneck #3 that requires no technological innovation: Suppose I've submitted a patch that I'm keen to see reviewed and committed. Would it be socially acceptable to review two other patches (preferably related in some way and of a similar level of complexity) and ask the submitters of those patches to review my patch in return?
You scratch my patch, I'll scratch yours.
Although there would be no guarantee of my patch being reviewed by the other patch submitters, the fact that it might happen would give me more motivation to review patches.
Such a thing already happens from time to time informally in IRC, especially between active "known" developers. It would probably be a bit gauche to try to do so in the issue queue directly, but "review swapping" via IRC is already common and could probably stand to become more so. The underlying problem I see is that in the case of many many patches, most people are simply not qualified to give a decent review. The amazing work that has gone into the automated testing server and simpletest module recently has, ironically, removed one of the main places where "random members of the crowd" can offer useful feedback; that is, "does this break stuff?" Coding style reviews most people can do if they're picky enough (and if you're not, then you should be), but substantive reviews of non-trivial patches requires a knowledge of the system being modified, whether it's a bug or a feature request. That's why the few people who seem to be able to intelligently review patches all over the system (and have time to do so) are worth their weight in gold. I've actually felt for some time that Drupal has reached a size and complexity where we need a more tiered maintainer system. Right now, Dries and Angie are the maintainers for D7, and based on the length of the recent-commit log[1] are doing a bang-up job. However, they keep saying that what we need is to not send stuff to them until it's *really* ready, vis, RTBC should be rock solid and not require effort on their part anymore. There is no one besides them, really, who is in a position to say when something really is "ready to be committed". That's where most projects bring in subsystem maintainers. As database system maintainer for D7, I read and respond to almost every issue that comes through the DB component queue. I've also spent time with Angie trying to work out a good way to optimize the workflow from me to her, so that patches that get past me bubble up to her quickly, she knows they're ready, she knows where we need feedback before we can continue, etc. I think we've got a decent system, but I'm sure it could be improved. The result, though, is that the pace at which work is getting done in the DB layer is improving. We need that for the rest of core, too. Now, I'm not saying that to in any way malign the other people listed in MAINTAINERS.txt. I am saying that there are far too people in MAINTAINERS.txt. Right now, there's 12 entries in MAINTAINERS.txt[2], and some are the same people repeated multiple times. There are 60 separate "components" listed for Drupal, most of them specific modules or subsystems. That leaves (oh I hate arithmetic) 48 sub-pieces of core that fall under the "The rest: Dries Buytaert", that is, left to random passers by to not just review but also keep consistent and uncrufty. Not all of those components needs a dedicated person just for that piece, of course, but right now there's simply far too many people taking "ownership" over parts of core, in any version. Hell, I can't even find someone to take ownership of the Postgres driver. :-) As an extreme example, Linus Torvalds almost never reviews individual patches anymore. The subsystem maintainers maintain their pieces, and then send rollups to Linus that he reviews en masse and/or accepts that the subsystem maintainer knows what he's doing and just commits it. Of course, Linux has an order (or two) of magnitude more code than Drupal and they're also using a distributed VCS that is designed for that workflow (and no, I am NOT trying to bring that debate up again so don't even start), but it is a datapoint we should consider. So the question then becomes how do we get more people willing to long-term adopt parts of core and actively maintain it, to the point that the core committers work mostly with the subsystem maintainers who in turn work with the issue queue for their part of core? How do we streamline that process, *and* attract the people who can handle that job? I don't have an answer for those questions yet (if I did, we'd have a Postgres maintainer by now), but I do believe those are the important questions to be asking. [1] http://drupal.org/project/issues?projects=3060&states=2 [2] http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=markup -- Larry Garfield larry@garfieldtech.com
On Fri, Oct 31, 2008 at 11:21 PM, David Sterratt > wrote:.
A thought about widening bottleneck #3 that requires no technological innovation: Suppose I've submitted a patch that I'm keen to see reviewed and committed. Would it be socially acceptable to review two other patches (preferably related in some way and of a similar level of complexity) and ask the submitters of those patches to review my patch in return?
You scratch my patch, I'll scratch yours.
A very large proportion (I wouldn't dare to say how many) of core patches are reviewed because a handful of us who hang out in irc trade patch reviews with each other on a regular basis. Sometimes this is a straight trade, more generally there's a handful of people who can be relied upon for decent reviews of core patches they might not have a personal interest in, and those people tend to get their patches reviewed faster too based on reputation (although our patches can still sit in the queue for weeks and weeks like anyone else's, that's how bad it is). If this sounds a bit cliquey, then that's because it is, but only by necessity. With over 400 issues needing review against Drupal 7 at the moment (and some of those issues might have 20 individual patches posted on them), it's one of few available ways to filter - and I say this as someone who's probably reviewed quite a bit more than 400 patches against Drupal 6 and 7. If you come into #drupal, and say 'I've got a few minutes spare to review patches, want to trade?", you'll find many willing and able people. While reviewing patches doesn't have the same obvious visibility as posting a new module for example, you'll get copious thanks if you review core patches, or patches against any of the major contributed modules - because development on both core and contrib is actively held up, sometimes stalled, by the lack of reviewers (see Daniel Kudwein's post to this list asking for reviews of Views 1.x patches - who reading this has used Views? How many have reviewed any patches in the Views issue queue? How many reading would like to get attention from one of the Views maintainers next time they have a support request?). So while it might appear a thankless task, this a misconception that we need to stamp out. We have more than enough contributed modules, we have a real shortage of people actively working on the ones that most people actually use. In answer to the original poster, while it's already been covered a bit, the main reason we don't appear to give much attention to the stable Drupal 5 and 6 branches, is because there's a policy of ensuring that bugs are fixed in HEAD (Drupal 7) first, then backported. This ensures that bugs fixed in 5 and 6 won't reappear when Drupal 7 is released, that changes made are consistent between all three branches, and that the bulk of work reviewing and refining patches can be done where there's the most active development going on. I'm not sure where this particular policy is documented, so for now at least, I've updated http://drupal.org/patch/submit to reflect it a bit. Having said that, there's still a shortage of people reviewing patches against Drupal 7, and even more against 5 and 6 - including the ones backported from 7. One thing which might help with 5/6 would be additional links to the issue queues from the 'contributors block' - at least critical/needs review. I don't know about everyone else, but those links are where I find patches to review unless I'm pointed to them directly, and patches for 5 and 6 don't show up there. Nat
On Saturday 01 November 2008 12:27:25 Nathaniel Catchpole wrote:
In answer to the original poster, while it's already been covered a bit, the main reason we don't appear to give much attention to the stable Drupal 5 and 6 branches, is because there's a policy of ensuring that bugs are fixed in HEAD (Drupal 7) first, then backported. This ensures that bugs fixed in 5 and 6 won't reappear when Drupal 7 is released, that changes made are consistent between all three branches, and that the bulk of work reviewing and refining patches can be done where there's the most active development going on.
Like I already said I'll respect that and I understand the motivation behind it. But there's also a different point of view which you should be aware of (and which is not limited to drupal). Over the years I met a lot of very skilled developers in the companies I worked for and I always encouraged them to not just fix bugs of open source components they use but to prepare patches and give their improvements back to the community. Every project should be lucky to receive patches from these kind of people with years of experience in software development. Especially if they use open source components in large scale environments a "normal" developer in an open source project probably never has a chance to face. They address issues especially in stable versions regarding performance, scalability or robustness. But in commercial projects you're always in a hurry. In such a situation you can't expect that someone who's willed to provide a patch reads a lot of howtos first, checks out an unstable development version which probably doesn't work, learns about all the api changes since the last stable release and finally tweaks the patch until it meets a project's style guide or keep it up to date until it gets applied. It's more like fire and forget. And it's up to the project to deal with this patch in terms of modifying it to meet the style guide or to find out if it's still relevant for the current development branch. And not everyone who posts a patch is interested to gain personal popularity from it. In this case it's not like that a maintainer does a favor to someone who provides a patch by accepting it. It's the other way around. More than once I got feedback that "it's not worth the effort" or that "it takes to much time" to give something back to the community which is disapointing. Again, please don't get me wrong. I really respect your work and understand the problems coming up with such a big community. And I'm absolutely not of the opinion that personally I'm a better developer than anybody else here! I just wanted to share my thoughts and the experiences I made over the years. And sometimes it's interesting to get some ideas from someone who's not so deeply involved. But unfortunately I also don't have a perfect solution in place ... BTW Damien Tournoud turned http://drupal.org/node/298768 from a D6 into a D7 issue. So sometimes it seems to work ;-) Markus
Am Donnerstag, 30. Oktober 2008 15:42:04 schrieb Darren Oh:
Most often patches are ignored when they are not relevant to the development version of Drupal. Bugs are sometimes labeled feature requests by maintainers who are not interested in fixes that only apply to older versions. In effect they're saying, This doesn't need to be fixed. You got it to work for you, and other people can wait for the next version of Drupal. I second that. I made the same experience.
In my company we're 10 developers working with drupal. But not anybody is using an unpatched version of drupal in his projects. In our repository we maintain different patches only for bugfixes for drupal's "stable" versions. And it's hard work to merge everthing every time a new drupal security/bugfix release comes out. From my point of such a popular project like drupal should better care about it's stable versions or branches. On the other hand I understand that in a open source project nobody could be forced to do something ... Markus
Thanks for your quick answer.
Please see http://drupal.org/node/10263. Quote: Be persistent. If you don't get any response right away, don't necessarily give up. If you're still convinced your idea has merit, find another way to present it
That's what I'm doing now ;-)
Note that all patches to core must be against HEAD when the bug still exists in HEAD. OK, I wasn't aware of this fact. I'll keep this in mind. But how could a serious issue be escalated if it only exists in a release branch and nobody reacts on a bug report for months. Should I use this list?
Markus
I've experienced the problem you describe many times. It depends on the maintainer for the version of Drupal. killes has been quick to apply fixes to Drupal 4.7. drumm seems to hope people that people will just stop using Drupal 5. Other core maintainers criticize patches for problems they are not interested in, then ignore the patches when they are fixed, apparently hoping the contributor will give up. The most common reason maintainers are not interested in a patch is that they are working on a new version of Drupal which makes the patch obsolete.
Just my two cents - while there are systemic reasons why this happens, the community needs to be able to see the issue purely from Markus's point of view. He seems to be a devoted Drupal developer who has put a lot of his time into developing patches only to see that they are not checked and not committed. That is to say, he has provided what he believes are solutions for various problems in several versions of Drupal, but there is nobody to actually apply them for the benefit of others. I am amazed he wrote such a polite and friendly message, asking what did he do wrong. I think it is not enough to be just defensive and say core maintainers are busy with Drupal 7 (thousands of people are using D5 and D6), advise to check other people's patches and they might check yours (I know it works that way, but I think it is not healthy; he already provided a service), or provide statistics on how many people complain and don't review (it is a fact it is easier and faster to spot problems than to solve them). I would be surprised if developers like Markus became a trifle discouraged from providing new patches. To summarize: this is just to show that the answers provided in this thread are unlikely to provide an efficient solution for developers like Markus. We must not be satisfied with such answers and keep searching more effective methods of recognizing and applying results of good coding. And I am sure we'll manage, for this is a marvellous community. Tomáš On Thu, Oct 30, 2008 at 2:50 PM, Darren Oh < darrenoh@sidepotsinternational.com> wrote:
I've experienced the problem you describe many times. It depends on the maintainer for the version of Drupal. killes has been quick to apply fixes to Drupal 4.7. drumm seems to hope people that people will just stop using Drupal 5. Other core maintainers criticize patches for problems they are not interested in, then ignore the patches when they are fixed, apparently hoping the contributor will give up. The most common reason maintainers are not interested in a patch is that they are working on a new version of Drupal which makes the patch obsolete.
Quoting Tomas Fulopp <tomi@vacilando.org>:
Just my two cents - while there are systemic reasons why this happens, the community needs to be able to see the issue purely from Markus's point of view. He seems to be a devoted Drupal developer who has put a lot of his time into developing patches only to see that they are not checked and not committed. That is to say, he has provided what he believes are solutions for various problems in several versions of Drupal, but there is nobody to actually apply them for the benefit of others. I am amazed he wrote such a polite and friendly message, asking what did he do wrong.
I think it is not enough to be just defensive and say core maintainers are busy with Drupal 7 (thousands of people are using D5 and D6), advise to check other people's patches and they might check yours (I know it works that way, but I think it is not healthy; he already provided a service), or provide statistics on how many people complain and don't review (it is a fact it is easier and faster to spot problems than to solve them). I would be surprised if developers like Markus became a trifle discouraged from providing new patches.
To summarize: this is just to show that the answers provided in this thread are unlikely to provide an efficient solution for developers like Markus. We must not be satisfied with such answers and keep searching more effective methods of recognizing and applying results of good coding. And I am sure we'll manage, for this is a marvellous community.
The only solution to the issue is for every development@drupal.org user to keep a watchful eye to http://drupal.org/project/issues?projects=3060&states=8&priorities=&categori... to review the patches submitted. Testing and watching for coding standards then setting the status to RTBC so that the committers can then have a look. I created myself a service that will notify me of the changes via an aggregated feed and notification by email of the changes. The feed is scheduled for once every ten minutes so that I keep up to date. Sure I might miss one or two that someone else has set to the status something else but then that one is already reviewed. If your interested, feel free to use the service with the understanding that the service is still in alpha/beta stage but the data is coming in like mad. There are between 5 to 50 requested reviews in a day. I can't get to them all. The service is hosted at http://r-feed.com and is accepting registrations for you convenience. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Could we add a Digg-like button to issues that would promote them to a popular issues page? On Oct 31, 2008, at 10:46 AM, Earnie Boyd wrote:
The only solution to the issue is for every development@drupal.org user to keep a watchful eye to http://drupal.org/project/issues?projects=3060&states=8&priorities=&categori... to review the patches submitted. Testing and watching for coding standards then setting the status to RTBC so that the committers can then have a look.
I created myself a service that will notify me of the changes via an aggregated feed and notification by email of the changes. The feed is scheduled for once every ten minutes so that I keep up to date. Sure I might miss one or two that someone else has set to the status something else but then that one is already reviewed.
If your interested, feel free to use the service with the understanding that the service is still in alpha/beta stage but the data is coming in like mad. There are between 5 to 50 requested reviews in a day. I can't get to them all. The service is hosted at http://r-feed.com and is accepting registrations for you convenience.
On Oct 31, 2008, at 8:42 AM, Darren Oh wrote:
Could we add a Digg-like button to issues that would promote them to a popular issues page?
Only if Dries or killes agree to let us turn on VotingAPI on drupal.org: http://drupal.org/node/42232#comment-967905 The code already exists for this: http://drupal.org/project/project_issue_voting but we can't deploy it until we get the green light for the VotingAPI requirement. I guess independent performance benchmarking and security audits of Voting API are the next step if anyone wants to help move this forward. Killes pushed the issue into the "redesign" category of the webmasters queue, but I think that's unhelpful. This isn't blocked on the redesign, it's blocked on making a decision to deploy the required code, which we're going to have to do anyway, sooner or later. Unlike many of the good ideas coming out of the redesign, this one is actually implemented and (IMHO) ready to deploy. -Derek (dww)
On Oct 31, 2008, at 9:07 AM, Derek Wright wrote:
Only if Dries or killes agree to let us turn on VotingAPI on drupal.org:
On Oct 31, 2008, at 9:07 AM, Chris Johnson wrote:
Claiming to know the "only" way to do something in an open source community (or just about in any circumstance) is arrogant, or blind, or defeatist, etc.
Sorry, I didn't mean to be arrogant, blind, or defeatist with my previous message. ;) If there's another way to get something deployed on d.o that won't be immediately disabled again, I'd love to hear it. In my experience, the only way code stays on d.o is if killes or Dries agree it should be there, which is what I meant by "only". Cheers, -Derek (dww)
Derek, My comments were definitely not directed at you! I'm your number 1 fan when it comes to the work you've done to support Drupal infrastructure and project management. ..chris On Fri, Oct 31, 2008 at 11:18 AM, Derek Wright <drupal@dwwright.net> wrote:
On Oct 31, 2008, at 9:07 AM, Derek Wright wrote:
Only if Dries or killes agree to let us turn on VotingAPI on drupal.org:
On Oct 31, 2008, at 9:07 AM, Chris Johnson wrote:
Claiming to know the "only" way to do something in an open source community (or just about in any circumstance) is arrogant, or blind, or defeatist, etc.
Sorry, I didn't mean to be arrogant, blind, or defeatist with my previous message. ;) If there's another way to get something deployed on d.o that won't be immediately disabled again, I'd love to hear it. In my experience, the only way code stays on d.o is if killes or Dries agree it should be there, which is what I meant by "only".
Cheers, -Derek (dww)
Can you guys give me the run down on how this is expected to help with newer contributors getting their work recognized? I see adding issue voting as just perpetuating the system we have now, where the most known/active contributors get their patches looked at by more people than new contributors. I see this as just pushing that problem one step further up the line, where now they'll get their issues 'dugg' more. I see this also as a potential distraction for patches that are important, but not exciting. I don't think things like documentation and coding standards would not fare too well in a voting contest, but that doesn't diminish their importance. Thanks, Brad Aten Design Group Phone: 303.831.0449 On Fri, Oct 31, 2008 at 10:30 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
Derek, My comments were definitely not directed at you! I'm your number 1 fan when it comes to the work you've done to support Drupal infrastructure and project management. ..chris
On Fri, Oct 31, 2008 at 11:18 AM, Derek Wright <drupal@dwwright.net> wrote:
On Oct 31, 2008, at 9:07 AM, Derek Wright wrote:
Only if Dries or killes agree to let us turn on VotingAPI on drupal.org:
On Oct 31, 2008, at 9:07 AM, Chris Johnson wrote:
Claiming to know the "only" way to do something in an open source community (or just about in any circumstance) is arrogant, or blind, or defeatist, etc.
Sorry, I didn't mean to be arrogant, blind, or defeatist with my previous message. ;) If there's another way to get something deployed on d.o that won't be immediately disabled again, I'd love to hear it. In my experience, the only way code stays on d.o is if killes or Dries agree it should be there, which is what I meant by "only".
Cheers, -Derek (dww)
On Fri, Oct 31, 2008 at 9:50 AM, Brad Bowman <brad@atendesigngroup.com> wrote:
Can you guys give me the run down on how this is expected to help with newer contributors getting their work recognized? I see adding issue voting as just perpetuating the system we have now, where the most known/active contributors get their patches looked at by more people than new contributors. I see this as just pushing that problem one step further up the line, where now they'll get their issues 'dugg' more.
I think the primary benefit would be that people who weren't in a position to offer technical commentary but are affected by the issue could vote for it to help raise its profile--especially for the issues that don't affect a majority of users. And they'd be able to do so in a way that doesn't clutter up a queue with +1 or me too comments.
I see this also as a potential distraction for patches that are important, but not exciting. I don't think things like documentation and coding standards would not fare too well in a voting contest, but that doesn't diminish their importance.
Those two are probably bad examples because they're the easiest type of patches to review and commit. But in general I don't see it being a huge problem because I'm guessing that you'll be able to rank the results of a search. andrew
On 31 Oct 2008, at 7:04 PM, andrew morton wrote:
I think the primary benefit would be that people who weren't in a position to offer technical commentary but are affected by the issue could vote for it to help raise its profile--especially for the issues that don't affect a majority of users. And they'd be able to do so in a way that doesn't clutter up a queue with +1 or me too comments.
Well. I think we should probably have a 'subscribe to this issue' feature, that doesn't involve adding a comment, and just displaying the number of subscribers would already be a pretty good metric of interest in a patch. (ie: it's something we could get for free, from a feature we should probably have already).
I disagree. Any patch, exciting or not, would be pushed up if many people needed it done. Same goes for documentation - if some help texts are underdeveloped, they will be brought to the visible light spectrum quicker. The only thing the voting does not favour are patches for the more obscure problems or features. That is obviously sad, but by definition fewer people will be affected it, and Drupal as a project will be still better off. But still, in theory even less needed patches would accumulate enough votes over time. Also, each committed important patch would move the less popular issues up the ranking queue. On Fri, Oct 31, 2008 at 5:50 PM, Brad Bowman <brad@atendesigngroup.com>wrote:
Can you guys give me the run down on how this is expected to help with newer contributors getting their work recognized? I see adding issue voting as just perpetuating the system we have now, where the most known/active contributors get their patches looked at by more people than new contributors. I see this as just pushing that problem one step further up the line, where now they'll get their issues 'dugg' more.
I see this also as a potential distraction for patches that are important, but not exciting. I don't think things like documentation and coding standards would not fare too well in a voting contest, but that doesn't diminish their importance.
Thanks, Brad Aten Design Group Phone: 303.831.0449
On Fri, Oct 31, 2008 at 10:30 AM, Chris Johnson <cxjohnson@gmail.com> wrote:
Derek, My comments were definitely not directed at you! I'm your number 1 fan when it comes to the work you've done to support Drupal infrastructure and project management. ..chris
On Fri, Oct 31, 2008 at 11:18 AM, Derek Wright <drupal@dwwright.net> wrote:
On Oct 31, 2008, at 9:07 AM, Derek Wright wrote:
Only if Dries or killes agree to let us turn on VotingAPI on
drupal.org:
On Oct 31, 2008, at 9:07 AM, Chris Johnson wrote:
Claiming to know the "only" way to do something in an open source community (or just about in any circumstance) is arrogant, or blind, or defeatist, etc.
Sorry, I didn't mean to be arrogant, blind, or defeatist with my
previous
message. ;) If there's another way to get something deployed on d.o that won't be immediately disabled again, I'd love to hear it. In my experience, the only way code stays on d.o is if killes or Dries agree it should be there, which is what I meant by "only".
Cheers, -Derek (dww)
I'll add that votingapi is already enabled on groups.drupal.org and the world did not burn down. It is used by the Knight Foundation group to rate proposals. This is why we need separate sites for project, docs, etc. These webmasters need to be as responsive as possible to their users, within reason. On Fri, Oct 31, 2008 at 12:07 PM, Derek Wright <drupal@dwwright.net> wrote:
On Oct 31, 2008, at 8:42 AM, Darren Oh wrote:
Could we add a Digg-like button to issues that would promote them to a popular issues page?
Only if Dries or killes agree to let us turn on VotingAPI on drupal.org:
http://drupal.org/node/42232#comment-967905
The code already exists for this:
http://drupal.org/project/project_issue_voting
but we can't deploy it until we get the green light for the VotingAPI requirement.
I guess independent performance benchmarking and security audits of Voting API are the next step if anyone wants to help move this forward. Killes pushed the issue into the "redesign" category of the webmasters queue, but I think that's unhelpful. This isn't blocked on the redesign, it's blocked on making a decision to deploy the required code, which we're going to have to do anyway, sooner or later. Unlike many of the good ideas coming out of the redesign, this one is actually implemented and (IMHO) ready to deploy.
-Derek (dww)
-----Original Message----- From: Derek Wright Sent: Friday, October 31, 2008 5:07 PM
Only if Dries or killes agree to let us turn on VotingAPI on drupal.org:
http://drupal.org/node/42232#comment-967905
The code already exists for this:
http://drupal.org/project/project_issue_voting
but we can't deploy it until we get the green light for the VotingAPI requirement.
Posted a review in the queue: http://drupal.org/node/328648
I guess independent performance benchmarking and security audits of Voting API are the next step if anyone wants to help move this forward. Killes pushed the issue into the "redesign" category of the webmasters queue, but I think that's unhelpful. This isn't blocked on the redesign, it's blocked on making a decision to deploy the required code, which we're going to have to do anyway, sooner or later.
Agreed. Issue voting can be implemented without a redesign. Daniel
I'm Fernando P. García, my nick is develCuy and I contributed some modules. Hope to contribute here too with at least a half of cent. Here we go: Cool! this is a key feature we need, because we need more feedback but people have no time for submit a comment but at least click or rating is welcome. I don't doubt there could be some issues about this voting features, but that occures on everything. Thanks for doing d.o to rock'n roll even more! Blessings! Daniel F. Kudwien wrote:
-----Original Message----- From: Derek Wright Sent: Friday, October 31, 2008 5:07 PM
Only if Dries or killes agree to let us turn on VotingAPI on drupal.org:
http://drupal.org/node/42232#comment-967905
The code already exists for this:
http://drupal.org/project/project_issue_voting
but we can't deploy it until we get the green light for the VotingAPI requirement.
Posted a review in the queue: http://drupal.org/node/328648
I guess independent performance benchmarking and security audits of Voting API are the next step if anyone wants to help move this forward. Killes pushed the issue into the "redesign" category of the webmasters queue, but I think that's unhelpful. This isn't blocked on the redesign, it's blocked on making a decision to deploy the required code, which we're going to have to do anyway, sooner or later.
Agreed. Issue voting can be implemented without a redesign.
Daniel
Voting might be a bit overkill. A way to subscribe could be the deciding factor in getting maintainers to pay more attention to a particular issue. The more subscribers, the higher up on the list. I read an issue lately where someone was integrating Flag module with Project module in order to allow people to subscribe. This sounds pretty ideal, especially since I'm such a fan of Flag module ;)
voting will not solve the problem , popularity factor is already one of causes of problem. The problem stems from lack of fair way of defining how critical a given issue is. Right now everything to do with D7 currently gets most attention, leaving the bugs in production releases with lack of attention from the community. There should be a queue based on a factor which defines fairness something like this , Secuity > known bug/patch > issue core > module Current Stable version ( 6) > last stable version (5) > development version (7) Of course there is also a need for some kind of accountability as why a patch for a bug in production version has not been committed for x.y.z time period. But we can ignore that ...being an open source project ;) . Currently new release is favored over resolving bugs in current release.
The on-going debate of pros and cons of issue/post/patch voting or subscription is largely hypothetical: neither camp has strong proofs they are right. (It is further clouded by the other part of the patch delay problem, which is lack of superbly experienced Drupal coders who actually are able to understand and intelligently review the more complicated patches.) But remember the other reason to install at least subscription to individual issues: we would get rid of all the "+1" and "subscribing" little posts that plague many threads and make them hardly readable. If then we had a way of selecting posts with patches sorted by number of subscribers, we'd be able to see what patches are most sorely needed to be reviewed and committed. Linking that to the d.o. menu would help a lot, too. In 6 months we can evaluate whether or not such issue subscription sorting helped the whole patch stalling situation. I believe it will, but even if it won't, it will be extremely useful. On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <crystalcube@yahoo.com> wrote:
voting will not solve the problem , popularity factor is already one of causes of problem. The problem stems from lack of fair way of defining how critical a given issue is. Right now everything to do with D7 currently gets most attention, leaving the bugs in production releases with lack of attention from the community.
There should be a queue based on a factor which defines fairness something like this , Secuity > known bug/patch > issue core > module Current Stable version ( 6) > last stable version (5) > development version (7)
Of course there is also a need for some kind of accountability as why a patch for a bug in production version has not been committed for x.y.z time period. But we can ignore that ...being an open source project ;) . Currently new release is favored over resolving bugs in current release.
I kind of remember the solution in priority queues, the problem was starvation, when an issue just keeps being pushed back indefinitely. Adding age of issue creation as a factor in the issue exposure should make sure this problem doesn't happen. After some time even the most uninteresting issue will eventually float above all others because it's been there for long. On Sat, Nov 1, 2008 at 2:19 PM, Tomas Fulopp <tomi@vacilando.org> wrote:
The on-going debate of pros and cons of issue/post/patch voting or subscription is largely hypothetical: neither camp has strong proofs they are right. (It is further clouded by the other part of the patch delay problem, which is lack of superbly experienced Drupal coders who actually are able to understand and intelligently review the more complicated patches.) But remember the other reason to install at least subscription to individual issues: we would get rid of all the "+1" and "subscribing" little posts that plague many threads and make them hardly readable. If then we had a way of selecting posts with patches sorted by number of subscribers, we'd be able to see what patches are most sorely needed to be reviewed and committed. Linking that to the d.o. menu would help a lot, too. In 6 months we can evaluate whether or not such issue subscription sorting helped the whole patch stalling situation. I believe it will, but even if it won't, it will be extremely useful.
On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <crystalcube@yahoo.com> wrote:
voting will not solve the problem , popularity factor is already one of causes of problem. The problem stems from lack of fair way of defining how critical a given issue is. Right now everything to do with D7 currently gets most attention, leaving the bugs in production releases with lack of attention from the community.
There should be a queue based on a factor which defines fairness something like this , Secuity > known bug/patch > issue core > module Current Stable version ( 6) > last stable version (5) > development version (7)
Of course there is also a need for some kind of accountability as why a patch for a bug in production version has not been committed for x.y.z time period. But we can ignore that ...being an open source project ;) . Currently new release is favored over resolving bugs in current release.
-- Ashraf Amayreh http://aamayreh.org
I think you've made an excellent point, Ashraf. This really would solve the problem of "uninteresting" issues getting solved as well. We'd only have to find a way or relating votes and time. Some kind of rigorous and simple equation. Any experience/suggestion there? On Mon, Nov 3, 2008 at 3:40 PM, Ashraf Amayreh <mistknight@gmail.com> wrote:
I kind of remember the solution in priority queues, the problem was starvation, when an issue just keeps being pushed back indefinitely.
Adding age of issue creation as a factor in the issue exposure should make sure this problem doesn't happen. After some time even the most uninteresting issue will eventually float above all others because it's been there for long.
On Sat, Nov 1, 2008 at 2:19 PM, Tomas Fulopp <tomi@vacilando.org> wrote:
The on-going debate of pros and cons of issue/post/patch voting or subscription is largely hypothetical: neither camp has strong proofs they are right. (It is further clouded by the other part of the patch delay problem, which is lack of superbly experienced Drupal coders who actually are able to understand and intelligently review the more complicated patches.) But remember the other reason to install at least subscription to individual issues: we would get rid of all the "+1" and "subscribing" little posts that plague many threads and make them hardly readable. If then we had a way of selecting posts with patches sorted by number of subscribers, we'd be able to see what patches are most sorely needed to be reviewed and committed. Linking that to the d.o. menu would help a lot, too. In 6 months we can evaluate whether or not such issue subscription sorting helped the whole patch stalling situation. I believe it will, but even if it won't, it will be extremely useful.
On Sat, Nov 1, 2008 at 10:28 AM, Vivek Puri <crystalcube@yahoo.com> wrote:
voting will not solve the problem , popularity factor is already one of causes of problem. The problem stems from lack of fair way of defining
how
critical a given issue is. Right now everything to do with D7 currently gets most attention, leaving the bugs in production releases with lack of attention from the community.
There should be a queue based on a factor which defines fairness something like this , Secuity > known bug/patch > issue core > module Current Stable version ( 6) > last stable version (5) > development version (7)
Of course there is also a need for some kind of accountability as why a patch for a bug in production version has not been committed for x.y.z time period. But we can ignore that ...being an open source project ;) . Currently new release is favored over resolving bugs in current release.
-- Ashraf Amayreh http://aamayreh.org
Letting people re-vote after a period of time might be better than an automated system. However, the idea of an equation was interesting, so I had to come up with one: (days x M + 1) x votes = weight M can be tuned to control the effect of time on an issue's weight. An M value of zero would mean that time does not affect the weight of an issue. Negative values of M would reduce the weight, and positive values would increase it. On Nov 4, 2008, at 6:18 AM, Tomas Fulopp wrote:
I think you've made an excellent point, Ashraf. This really would solve the problem of "uninteresting" issues getting solved as well. We'd only have to find a way or relating votes and time. Some kind of rigorous and simple equation. Any experience/suggestion there?
On Wed, Nov 5, 2008 at 1:59 AM, Darren Oh < darrenoh@sidepotsinternational.com> wrote:
Letting people re-vote after a period of time might be better than an automated system. However, the idea of an equation was interesting, so I had to come up with one:
(days x M + 1) x votes = weight
M can be tuned to control the effect of time on an issue's weight. An M value of zero would mean that time does not affect the weight of an issue. Negative values of M would reduce the weight, and positive values would increase it.
I would suggest adding a delay, such that the time doesn't contribute to the weight until some grace period (for example after the first week). I also wonder whether "days" should be since reported or since last updated.
On Nov 4, 2008, at 10:11 AM, Ryan Cross wrote:
On Wed, Nov 5, 2008 at 1:59 AM, Darren Oh <darrenoh@sidepotsinternational.com
wrote: Letting people re-vote after a period of time might be better than an automated system. However, the idea of an equation was interesting, so I had to come up with one:
(days x M + 1) x votes = weight
M can be tuned to control the effect of time on an issue's weight. An M value of zero would mean that time does not affect the weight of an issue. Negative values of M would reduce the weight, and positive values would increase it.
I would suggest adding a delay, such that the time doesn't contribute to the weight until some grace period (for example after the first week). I also wonder whether "days" should be since reported or since last updated.
The modified equation would be (M x (days - G) + 1) x votes = weight where G is the grace period in days. However, the point of voting is to give the community a way to promote issues, so I still think allowing people to re-vote periodically might be a better solution.
On Tuesday, 4. November 2008, Darren Oh wrote:
However, the point of voting is to give the community a way to promote issues, so I still think allowing people to re-vote periodically might be a better solution.
One possible way to achieve that goal: Bugzilla (at least in the version used on bugs.kde.org) grants each user a limited amount of votes for each project which the user can then assign as desired. If the user doesn't have any votes left, she needs to take them back from unimportant issues and reassign these votes to the more pressing ones. Combined with age multipliers, I think this might make for a voting system with a reasonable trade-off between popularity and necessity.
On Tue, Nov 4, 2008 at 4:04 PM, Jakob Petsovits wrote:
One possible way to achieve that goal: Bugzilla (at least in the version used on bugs.kde.org) grants each user a limited amount of votes for each project which the user can then assign as desired. If the user doesn't have any votes left, she needs to take them back from unimportant issues and reassign these votes to the more pressing ones.
Combined with age multipliers, I think this might make for a voting system with a reasonable trade-off between popularity and necessity.
This has been discussed elsewhere in the project metrics and redesign groups, and I think it's a good model to follow for this (and project reviews/voting if we introduce this later on). Nat
Just to make it clear, I think voting with the restriction of one person N votes is a good idea. I don't think prioritising issues by age is a good idea at all. Old issues are usually: 1.Not valid any more 2. Not interesting to many people 3. An absolute pig to fix requiring vast amounts of effort. And I say this as someone who personally has gone through many hundreds of old issues trying to sort the good from the bad in the past 18 months, not just for core, but for views, cck, location and panels. If you want to find old issues, you can look at any patch queue, and click on the last link of the pager, and there they'll be. If we have a sensible voting system, then some old issues will rise to the top, we don't need an extra 'how old it is' weight to this. For example, I personally don't care if user's can delete their old accounts or not, nor do all that many people given the relative number of responses vs. age for http://drupal.org/node/8 - an average of 14 posts per year. Nat On Tue, Nov 4, 2008 at 4:17 PM, Nathaniel Catchpole wrote:
On Tue, Nov 4, 2008 at 4:04 PM, Jakob Petsovits wrote:
One possible way to achieve that goal: Bugzilla (at least in the version used on bugs.kde.org) grants each user a limited amount of votes for each project which the user can then assign as desired. If the user doesn't have any votes left, she needs to take them back from unimportant issues and reassign these votes to the more pressing ones.
Combined with age multipliers, I think this might make for a voting system with a reasonable trade-off between popularity and necessity.
This has been discussed elsewhere in the project metrics and redesign groups, and I think it's a good model to follow for this (and project reviews/voting if we introduce this later on).
Nat
On Nov 4, 2008, at 8:47 AM, Nathaniel Catchpole wrote:
Just to make it clear, I think voting with the restriction of one person N votes is a good idea. I don't think prioritising issues by age is a good idea at all.
Good. ;)
If you want to find old issues, you can look at any patch queue, and click on the last link of the pager, and there they'll be.
Or click on the little grey arrow next to the "Last updated" column header to reverse the sort order. tablesort_sql(), you know... Cheers, -Derek (dww)
Thought about this some more. Allowing users to vote on issues is probably good for novice users, who do not deal with many issues at the same time. However, for the rest of us, who work on plenty of issues, it would take a considerable amount of time to constantly removing votes from closed issues and thinking about where to place votes next. Considering this, I would predict that this will be too much overhead for me. Furthermore, I would most probably like to see approx. 90% of all issues resolved, which I follow-up on or (re-)roll patches for. Long story short: I'd prefer a simple "flag" solution. Just collect flags (and also re-use them for "subscribing"), count them, and done. That way, everyone could flag the issues of interest, without having aforementioned overhead. Just a simple flag corresponding to "+1, good issue, me too, let's get this fixed". This would also account for the previously mentioned edge-cases: - Issues languishing in the queue for years are most probably flagged by *many* users (such as 8 or daylight saving time). - Same for killer features like DBTNG. - Same for critical bugs in stable releases like http://drupal.org/node/311626 or http://drupal.org/node/305653 Also, if users were allowed to place more than one vote on one issue and each user gets a fixed contingent of votes, the contingent would have to be per project IMO. With flags, we would not need such complex logic to allow a certain amount of votes per project. Lastly, if we re-use those flags to extend the "My issues" list, we would finally fix the "subscribing" issue-derailing issue. Daniel
On Tue, Nov 4, 2008 at 5:50 PM, Daniel F. Kudwien wrote:
Thought about this some more.
Allowing users to vote on issues is probably good for novice users, who do not deal with many issues at the same time. However, for the rest of us, who work on plenty of issues, it would take a considerable amount of time to constantly removing votes from closed issues and thinking about where to place votes next. Considering this, I would predict that this will be too much overhead for me. ssue.
Daniel
Personally I'd continue to work on issues pretty much the same as I do now, and would likely ignore both voting for issues, and the votes on them 99% of the time. I'd like to see the flag/subscriptions/my issues thing sorted - but that's a different thing entirely.
Nat
On Tuesday 04 November 2008 11:50:34 am Daniel F. Kudwien wrote:
Thought about this some more.
Allowing users to vote on issues is probably good for novice users, who do not deal with many issues at the same time. However, for the rest of us, who work on plenty of issues, it would take a considerable amount of time to constantly removing votes from closed issues and thinking about where to place votes next. Considering this, I would predict that this will be too much overhead for me.
That's an easy fix. Any time an issue is marked closed by cron, clear all votes on that issue. Then you get them back to reallocate elsewhere. It is probably possible (although probably annoying to do in project* D5) to also provide a page where you can see all of the votes you've cast on what issues and provide an easy way for you to modify them. -- Larry Garfield larry@garfieldtech.com
On Nov 4, 2008, at 11:54 PM, Larry Garfield wrote:
That's an easy fix. Any time an issue is marked closed by cron, clear all votes on that issue. Then you get them back to reallocate elsewhere.
We decided not to do it that way for a few reasons: a) If an issue was accidentally or prematurely marked 'closed', you'd lose all the vote data. Granted, the 2-week cron closer would rule out the accidental ones, so I guess it's less of a concern if you do it via cron. However, what about issues marked "duplicate", "won't fix", etc? If people aren't used to reclaiming their votes, then people will probably forget about votes "lost" to these other states... b) Dries said it would be a sense of accomplishment to visit the "issues you voted on" page, see stuff that was fixed/closed, and reclaim your votes.
It is probably possible (although probably annoying to do in project* D5) to also provide a page where you can see all of the votes you've cast on what issues and provide an easy way for you to modify them.
It already does this. Currently hard-coded and somewhat ugly: http://project.drupal.org/user/46549/project-issue-votes Easily converted into a view if someone was motivated to spend time on it: http://drupal.org/node/328689 Cheers, -Derek (dww)
Derek Wright wrote:
On Nov 4, 2008, at 11:54 PM, Larry Garfield wrote:
It is probably possible (although probably annoying to do in project* D5) to also provide a page where you can see all of the votes you've cast on what issues and provide an easy way for you to modify them. It already does this. Currently hard-coded and somewhat ugly:
http://project.drupal.org/user/46549/project-issue-votes
Easily converted into a view if someone was motivated to spend time on it:
I'm motivated to do it :), where can I start? Blessings!
I don't have a need for issue voting at this point. A subscribe feature would be more useful. Either way, I'd rather enable new features after we upgraded drupal.org to Drupal 6. I'd prefer to see new efforts go into the Drupal 6 version of the module. Upgrading drupal.org to Drupal 6 is going to have a much bigger impact that voting. 2008/11/6 "Fernando P. García" <fernandoparedesgarcia@gmail.com>:
Derek Wright wrote:
On Nov 4, 2008, at 11:54 PM, Larry Garfield wrote:
It is probably possible (although probably annoying to do in project* D5) to also provide a page where you can see all of the votes you've cast on what issues and provide an easy way for you to modify them.
It already does this. Currently hard-coded and somewhat ugly:
http://project.drupal.org/user/46549/project-issue-votes
Easily converted into a view if someone was motivated to spend time on it:
I'm motivated to do it :), where can I start?
Blessings!
-- Dries Buytaert :: http://buytaert.net/
For issue subscriptions, there's a patch, which needs review (of course) here: http://drupal.org/node/34496 On Thu, Nov 6, 2008 at 4:01 PM, Eric-Alexander Schaefer wrote:
Dries Buytaert schrieb:
I don't have a need for issue voting at this point. A subscribe feature would be more useful.
+1 (for easy issue subscription w/o a new comment)
Eric
On Nov 4, 2008, at 8:04 AM, Jakob Petsovits wrote:
Bugzilla (at least in the version used on bugs.kde.org) grants each user a limited amount of votes for each project which the user can then assign as desired. If the user doesn't have any votes left, she needs to take them back from unimportant issues and reassign these votes to the more pressing ones.
That's exactly how project_issue_voting.module already works. Age modifiers seem like needless complication, and something that's bound to make whatever performance concerns we have about running this on d.o even worse. Let's not over-complicate this problem to the point of making it infeasible to deploy... Cheers, -Derek (dww)
I disagree with Derek, Nat (nothing personal, I am sure you know that) and Bugzilla who prefer the limited vote number system. It introduces the need for an arbitrary value (how many votes per person is fair?) and discussions that would stem from it. Simple accumulative voting on issues (+1 system, one per user per issue) is a) simpler and therefore more elegant, and even more importantly: b) people use it intuitively already - they add those cluttering "Subscribing" messages because they have no other way of doing this. If limited vote was applied, bumping the issue by saying "Subscribing" would continue whenever one runs out of votes (even if such messages would not be counted as votes). Also, I think that old issues, even if they rise up due to accumulated votes (or age) can still be easily dismissed if necessary - by saying they need to be re-done against another version, etc, so I don't think that's a problem. Important - if age is included somehow as discussed above, it should be age since last comment in that thread. Means if somebody reacts in some way the added weight based on time is re-set to zero, which is fair because the patch contributors need to react on it. Otherwise even useless patches / issues would keep rising in the queue, despite all critique. Keep up the good ideas flowing, let's make the best system possible. On Tue, Nov 4, 2008 at 5:51 PM, Derek Wright <drupal@dwwright.net> wrote:
On Nov 4, 2008, at 8:04 AM, Jakob Petsovits wrote:
Bugzilla (at least in the version used on bugs.kde.org) grants each user
a limited amount of votes for each project which the user can then assign as desired. If the user doesn't have any votes left, she needs to take them back from unimportant issues and reassign these votes to the more pressing ones.
That's exactly how project_issue_voting.module already works.
Age modifiers seem like needless complication, and something that's bound to make whatever performance concerns we have about running this on d.o even worse. Let's not over-complicate this problem to the point of making it infeasible to deploy...
Cheers, -Derek (dww)
On Nov 4, 2008, at 9:09 AM, Tomas Fulopp wrote:
Simple accumulative voting on issues (+1 system, one per user per issue) is a) simpler and therefore more elegant, and even more importantly:
Not necessarily true. That's just your opinion.
b) people use it intuitively already - they add those cluttering "Subscribing" messages because they have no other way of doing this. If limited vote was applied, bumping the issue by saying "Subscribing" would continue whenever one runs out of votes (even if such messages would not be counted as votes).
That's going to happen anyway. Even if we add a way to subscribe or vote on issues without commenting, people will continue to post meaningless comments. This isn't an argument for or against any of the proposed changes.
Keep up the good ideas flowing, let's make the best system possible.
The best system possible is one that people can actually use. ;) Far too many threads about improving d.o in some way die at exactly this stage -- endless discussion, no action. In this case, there's already code that exists, was written by members of the security team, works, and is ready to deploy. If we go back to the drawing board now for another few months of speculation and bike-shedding about "the best system possible", I'll bet $20 that the code never materializes and none of it, even the stuff that already works, will be used. I'm not trying to be defeatist or stifle anyone's initiative, but in this case, I think it's time to invoke one of Drupal's oldest mantras: "Talk is silver, code is gold". Or something along the lines of "let not perfection be the barrier of progress" (or however that goes). How about we get the current thing running and see how it goes for a few months, and then have some actual data and experience to use to discuss further improvements? That approach seems to have served the "make the handbooks a wiki" experiment well, let's do it again. Cheers, -Derek (dww)
Derek Wright wrote:
How about we get the current thing running and see how it goes for a few months, and then have some actual data and experience to use to discuss further improvements? That approach seems to have served the "make the handbooks a wiki" experiment well, let's do it again.
Yep, and if we need to increase votes per user, or add some weighting or something, we'll be much better informed after seeing how it's worked for a while. So this begs the question, what remains to do before it gets deployed? Nat
On Nov 4, 2008, at 9:30 AM, Nathaniel Catchpole wrote:
So this begs the question, what remains to do before it gets deployed?
I already mentioned it earlier in the thread, but to reiterate: Get killes and/or Dries to say "yes" in this issue: http://drupal.org/node/42232 I have no idea what it would take to get them to say that, since to date, neither one has commented on the issue with any objections (other than when killes reclassified it to the "redesign" component without any accompanying text). /me shrugs -Derek (dww)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Wright schrieb:
On Nov 4, 2008, at 9:30 AM, Nathaniel Catchpole wrote:
So this begs the question, what remains to do before it gets deployed?
I already mentioned it earlier in the thread, but to reiterate:
Get killes and/or Dries to say "yes" in this issue:
I am deferring this to Dries, since he's the one who has to work with the outcome of this.
I have no idea what it would take to get them to say that, since to date, neither one has commented on the issue with any objections (other than when killes reclassified it to the "redesign" component without any accompanying text).
I was under the impression that we shouldn't complicate the redesign with adding such things now and rather look at it within the scope of the redesign. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkQi/wACgkQfg6TFvELooQ/kQCeK1V/q14tIvGdgdA0JWEdHEjU lGkAniqwEzAX68Ps3kBAfxou++eG8ckt =+1hg -----END PGP SIGNATURE-----
I've weighed my worries.. and the heaviest one is indeed that continued discussion (though I don't think it's been bike-shedding) will stifle the action. I admire the body of your work and comments, Derek, so if there are no better quickly achievable solutions I can agree with your proposal of going with what we have and improve further later. How can it be done and when? On Tue, Nov 4, 2008 at 6:23 PM, Derek Wright <drupal@dwwright.net> wrote:
On Nov 4, 2008, at 9:09 AM, Tomas Fulopp wrote:
Simple accumulative voting on issues (+1 system, one per user per issue)
is a) simpler and therefore more elegant, and even more importantly:
Not necessarily true. That's just your opinion.
b) people use it intuitively already - they add those cluttering
"Subscribing" messages because they have no other way of doing this. If limited vote was applied, bumping the issue by saying "Subscribing" would continue whenever one runs out of votes (even if such messages would not be counted as votes).
That's going to happen anyway. Even if we add a way to subscribe or vote on issues without commenting, people will continue to post meaningless comments. This isn't an argument for or against any of the proposed changes.
Keep up the good ideas flowing, let's make the best system possible.
The best system possible is one that people can actually use. ;) Far too many threads about improving d.o in some way die at exactly this stage -- endless discussion, no action. In this case, there's already code that exists, was written by members of the security team, works, and is ready to deploy. If we go back to the drawing board now for another few months of speculation and bike-shedding about "the best system possible", I'll bet $20 that the code never materializes and none of it, even the stuff that already works, will be used.
I'm not trying to be defeatist or stifle anyone's initiative, but in this case, I think it's time to invoke one of Drupal's oldest mantras: "Talk is silver, code is gold". Or something along the lines of "let not perfection be the barrier of progress" (or however that goes).
How about we get the current thing running and see how it goes for a few months, and then have some actual data and experience to use to discuss further improvements? That approach seems to have served the "make the handbooks a wiki" experiment well, let's do it again.
Cheers, -Derek (dww)
-----Original Message----- From: Derek Wright Sent: Tuesday, November 04, 2008 6:24 PM
The best system possible is one that people can actually use. ;) Far too many threads about improving d.o in some way die at exactly this stage -- endless discussion, no action. In this case, there's already code that exists, was written by members of the security team, works, and is ready to deploy. If we go back to the drawing board now for another few months of speculation and bike-shedding about "the best system possible", I'll bet $20 that the code never materializes and none of it, even the stuff that already works, will be used.
I'm not trying to be defeatist or stifle anyone's initiative, but in this case, I think it's time to invoke one of Drupal's oldest mantras: "Talk is silver, code is gold". Or something along the lines of "let not perfection be the barrier of progress" (or however that goes).
Not necessarily true either: http://drupal.org/project/flag Flag would also open up the possibility to use other flags for different purposes in the future. Think handbook pages, flagging comments for moderation, etc. It comes with decent Views integration, and is already available for 6.x, too. Lastly, if you really want to weigh flags like votes: http://drupal.org/project/flag_weights It is possible that a separate glue module might be required to integrate Flag with project* the same way like Project Issue Voting does. However, I'd be up for coding this simple helper, if required. Daniel
Quoting "Daniel F. Kudwien" <news@unleashedmind.com>:
Not necessarily true either: http://drupal.org/project/flag
The best flag for issues is RTBC status.
Flag would also open up the possibility to use other flags for different purposes in the future. Think handbook pages, flagging comments for moderation, etc. It comes with decent Views integration, and is already available for 6.x, too.
Lastly, if you really want to weigh flags like votes: http://drupal.org/project/flag_weights
Priority already gives a weight, we don't need another.
It is possible that a separate glue module might be required to integrate Flag with project* the same way like Project Issue Voting does. However, I'd be up for coding this simple helper, if required.
You ppl have wasted enough time on this. Go check a favorite issue, test it, then change the status as appropriate. Earnie -- http://r-feed.com - subscribe for email notice of a review waiting to happen.
On Nov 4, 2008, at 1:47 PM, Earnie Boyd wrote:
Quoting "Daniel F. Kudwien" <news@unleashedmind.com>:
Not necessarily true either: http://drupal.org/project/flag
The best flag for issues is RTBC status.
Could work, if RTBC were a vote rather than a flag that is either on or off for the whole issue.
On Nov 4, 2008, at 10:47 AM, Earnie Boyd wrote:
The best flag for issues is RTBC status.
You completely misunderstand what flag.module does and how it's relevant to this discussion. flag.module is the current candidate for best solution to http://drupal.org/node/34496 ("Allow (un) subscription to individual project issue"). -Derek (dww)
Quoting Derek Wright <drupal@dwwright.net>:
On Nov 4, 2008, at 10:47 AM, Earnie Boyd wrote:
The best flag for issues is RTBC status.
You completely misunderstand what flag.module does and how it's relevant to this discussion. flag.module is the current candidate for best solution to http://drupal.org/node/34496 ("Allow (un) subscription to individual project issue").
Ok, but the discussion is using flag to help prioritize the workflow. I don't disagree with that in total but unless more are willing to review, test and participate in the issues then this discussion is pointless. There are some bugs that just require a quick review of the coding to say this makes too much sense to not patch it and prioritization for this type of bug fix using flag makes no sense at all. We just need to get the sucker committed; therefore, the best flag for issues is RTBC. Using a socialization voting flag for feature requests would definitely be the thing to do. As long as the feature request doesn't already have a patch. Once an issue has a patch the reviewing and testing the patch is the only course of action that should be taken. Patches need reviewed, not voted on. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Fri, Oct 31, 2008 at 10:42 AM, Darren Oh < darrenoh@sidepotsinternational.com> wrote:
Could we add a Digg-like button to issues that would promote them to a popular issues page?
I think that's a good idea, and is one of the first new, novel ideas I've seen for addressing this problem in a long time. And I'm really glad to see such a positive, concrete suggestion. The benefit I see is that it more accurately represents the number of people impacted by a particular problem. Most of the time these threads devolve into useless arguments. Often, too many react defensively, by saying things like the "only" way to address this is to, e.g. review more patches. Using absolutist language like "only" (never, always, etc.) not only discourages new ideas but is demonstrably false. Claiming to know the "only" way to do something in an open source community (or just about in any circumstance) is arrogant, or blind, or defeatist, etc.
On Friday 31 October 2008 17:19:37 John VanDyk wrote:
Could we add a Digg-like button to issues that would promote them to a popular issues page?
Perhaps we're already collecting stats on most-visited issue pages? (I don't know if we are or not.)
These are good approaches. But I think they need some fine tuning. The main questions are who promotes an issue or who visited a page? It's possible that a trivial issue gets promoted and a really technical and serious issue won't be escalated simply because most of the users don't understand it. Markus
I think this is a very good idea - potentially accelerating testing and committing the most desperately needed patches. On Fri, Oct 31, 2008 at 4:42 PM, Darren Oh < darrenoh@sidepotsinternational.com> wrote:
Could we add a Digg-like button to issues that would promote them to a popular issues page?
On Oct 31, 2008, at 10:46 AM, Earnie Boyd wrote:
The only solution to the issue is for every development@drupal.org user
to keep a watchful eye to http://drupal.org/project/issues?projects=3060&states=8&priorities=&categori... to review the patches submitted. Testing and watching for coding standards then setting the status to RTBC so that the committers can then have a look.
I created myself a service that will notify me of the changes via an aggregated feed and notification by email of the changes. The feed is scheduled for once every ten minutes so that I keep up to date. Sure I might miss one or two that someone else has set to the status something else but then that one is already reviewed.
If your interested, feel free to use the service with the understanding that the service is still in alpha/beta stage but the data is coming in like mad. There are between 5 to 50 requested reviews in a day. I can't get to them all. The service is hosted at http://r-feed.com and is accepting registrations for you convenience.
Just to propose an alternative idea to the Digg-like voting system, how about restricting commiters to only working on specific issues? So instead of being a free-for-all where people just go in and pick and choose the issues that they find the most interesting, important, or fun, to work on (as this is largely personal opinion), have it setup so they can only work on issues assigned to them by some one with greater permissions then them. I know, from experience, that this is how many commercial software shops operate when it comes to bug reports and feature requests and it can be quite efficient. The only remaining issue is to make sure the proper issues are assigned, and assigned to the proper person. I personally feel a lot of the problems being discussed tend to stem from a free-for-all setup where people can work on whatever issues they like. Perhaps treating Drupal as a regular commercial product would be more beneficial (although I do like the voting idea, I haven't seen that idea proposed for something like this before). As a disclaimer, while I've been using Drupal for over a year, I'm still new to the list and have not been very active in the community yet, so there is a good chance I don't know what I'm talking about in regards to how bugs are currently handled. But from an outsiders perspective this is how it appears. Tomas Fulopp wrote:
I think this is a very good idea - potentially accelerating testing and committing the most desperately needed patches.
On Fri, Oct 31, 2008 at 4:42 PM, Darren Oh <darrenoh@sidepotsinternational.com <mailto:darrenoh@sidepotsinternational.com>> wrote:
Could we add a Digg-like button to issues that would promote them to a popular issues page?
On Oct 31, 2008, at 10:46 AM, Earnie Boyd wrote:
The only solution to the issue is for every development@drupal.org <mailto:development@drupal.org> user to keep a watchful eye to http://drupal.org/project/issues?projects=3060&states=8&priorities=&categori... <http://drupal.org/project/issues?projects=3060&states=8&priorities=&categories=&users=> to review the patches submitted. Testing and watching for coding standards then setting the status to RTBC so that the committers can then have a look.
I created myself a service that will notify me of the changes via an aggregated feed and notification by email of the changes. The feed is scheduled for once every ten minutes so that I keep up to date. Sure I might miss one or two that someone else has set to the status something else but then that one is already reviewed.
If your interested, feel free to use the service with the understanding that the service is still in alpha/beta stage but the data is coming in like mad. There are between 5 to 50 requested reviews in a day. I can't get to them all. The service is hosted at http://r-feed.com and is accepting registrations for you convenience.
On 31 Oct 2008, at 5:42 PM, Darren Oh wrote:
Could we add a Digg-like button to issues that would promote them to a popular issues page?
or or or , how about a fund that every patch you review that gets committed nets you credits toward beer. actually, i'm just being facetious , but perhaps making the 'developer cred' a bit more formal might help. Think of it like a 'did you find this review helpful' on imdb, which gives feedback to reviewers who give good reviews, and lends more weight to their reviews on whatever project. Same could be said for answering support requests. We already maintain statistics on active developers, and project usage, how about a method of encouraging people to give better reviews, and moving beyond having to know people personally before trusting their reviews, but instead gaining trust across all projects. For a large part, answering support requests and doing patch reviews (of patches not specifically related to any of your problems), can be a thankless and time consuming job. Perhaps we should be more visible about thanking and honoring those who help us become a better project. Doesn't have to be very complex, just a simple toggle rating on comments that answer specific questions, ideally only open to only the people who created the issue, or admin the project being posted to.
On Fri, Oct 31, 2008 at 8:10 AM, Tomas Fulopp <tomi@vacilando.org> wrote:
Just my two cents - while there are systemic reasons why this happens, the community needs to be able to see the issue purely from Markus's point of view. He seems to be a devoted Drupal developer who has put a lot of his time into developing patches only to see that they are not checked and not committed. That is to say, he has provided what he believes are solutions for various problems in several versions of Drupal, but there is nobody to actually apply them for the benefit of others. I am amazed he wrote such a polite and friendly message, asking what did he do wrong.
I think it is not enough to be just defensive and say core maintainers are busy with Drupal 7 (thousands of people are using D5 and D6), advise to check other people's patches and they might check yours (I know it works that way, but I think it is not healthy; he already provided a service), or provide statistics on how many people complain and don't review (it is a fact it is easier and faster to spot problems than to solve them). I would be surprised if developers like Markus became a trifle discouraged from providing new patches.
To summarize: this is just to show that the answers provided in this thread are unlikely to provide an efficient solution for developers like Markus. We must not be satisfied with such answers and keep searching more effective methods of recognizing and applying results of good coding. And I am sure we'll manage, for this is a marvellous community.
Tomáš
So what do you want from a bunch of volunteers? Some who take on the extraordinary responsibility of being the Drupal maintainer? Have you had to work on an issue queue? If you're really concerned about your patch or code, promote it. There are many other people vying for the committers' bandwidth, make it as easy as possible for them. Work to get your patch well vetted by your peers. Make sure it is up to coding standards, well documented, and includes tests. Make sure your issue accurately and succinctly sums up What is broken, how to reproduce the issue, you expected results, what the code is actually doing, and how your solution fixes the problem. Be thorough. .darrel.
On Fri, Oct 31, 2008 at 6:10 AM, Tomas Fulopp <tomi@vacilando.org> wrote:
I think it is not enough to be just defensive and say core maintainers are busy with Drupal 7 (thousands of people are using D5 and D6), advise to
Ok, let's accept your argument that it's not enough. So, what do we do? How would you say that you've solved the problem in your own queue(s)? http://drupal.org/project/issues/brilliant_gallery?projects=171445&states=8 I'd say that you haven't. Patches there are sitting for almost a _year_ in code needs review without response. Neither on the large scale nor on the small scale do we have a simple solution to this problem. There's been lots of great advice in this thread and amongst it all lies the basic answer: it takes work. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com
Greg, you've won a bet I did with myself that at least one person on this list would return to me with my own deficiencies :-) Yes, the BG issue queue is long as I am swamped with other deadlines. The thing you do not know is that I have not forgotten or given up on it, that it worries me, that I am grateful for every other person who helps me in there, that I will, definitely will, deal with anything outstanding in there as soon as I can. Your post however missed the larger point I carefully formulated in my post. On Fri, Oct 31, 2008 at 4:14 PM, Greg Knaddison - GVS < Greg@growingventuresolutions.com> wrote:
On Fri, Oct 31, 2008 at 6:10 AM, Tomas Fulopp <tomi@vacilando.org> wrote:
I think it is not enough to be just defensive and say core maintainers are busy with Drupal 7 (thousands of people are using D5 and D6), advise to
Ok, let's accept your argument that it's not enough. So, what do we do?
How would you say that you've solved the problem in your own queue(s)?
http://drupal.org/project/issues/brilliant_gallery?projects=171445&states=8
I'd say that you haven't. Patches there are sitting for almost a _year_ in code needs review without response.
Neither on the large scale nor on the small scale do we have a simple solution to this problem. There's been lots of great advice in this thread and amongst it all lies the basic answer: it takes work.
Regards, Greg
-- Greg Knaddison Denver, CO | http://knaddison.com | 303-800-5623 Growing Venture Solutions, LLC | http://growingventuresolutions.com
Tomas Fulopp wrote:
To summarize: this is just to show that the answers provided in this thread are unlikely to provide an efficient solution for developers like Markus. We must not be satisfied with such answers and keep searching more effective methods of recognizing and applying results of good coding. And I am sure we'll manage, for this is a marvellous community.
Well, you said it yourself: "it is a fact it is easier and faster to spot problems than to solve them" ...which seems like exactly what you've done here. :) Others have explained the realities of the community-driven development process in a community as large as ours, itemized the constraints and obstacles that exist (by necessity, to keep code quality high) to get patches in, and have tried to help Markus by offering tips to help that have also helped them get patches into core. If you have better ideas on how to manage the process more efficiently, obviously we'd love to hear them.
On Fri, 31 Oct 2008 11:36:35 -0400 Angela Byron <drupal-devel@webchick.net> wrote:
If you have better ideas on how to manage the process more efficiently, obviously we'd love to hear them.
Does anyone has some numbers about reviewers, maintainers and "patchers" behaviour? - Do most people prefer to submit/review patches to stable versions rather than development version? - Do maintainer respond quicker to patches submitted for the development version? - What is the average number of patches/review for each developer? I'm going to assume that: 1) proposed patches to stable are more than development 2) patchers are much more than reviewer 3) patches to development are committed faster Am I right? I think: 1) happens because people find easier to "live" on a stable release and they are writing a patch for a reasonably static code base that won't make their patch obsolete easily. And there is no chance that less than 20 maintainers can keep up with all the proposed patches before a new UNSTABLE hits the street. BTW I take this chances to say UNSTABLE releases are a very welcome addition. Thanks!!! 2) happens because a) it's more fun to write code than reviewing it b) it takes more responsibility to say "it works" than "it works for me". 3) It takes less responsibility to commit to a development version and... it is more fun. After all if you're a maintainer what's the fun of taking the responsibility of applying a patch to a problem that: is a feature but expose you to the risk of breaking something or is a fix to a bug you didn't experience? While a development version will always have its drawback maybe making easier to build up a development/testing environment and letting people understand where the "steering committee" and the development is going would help increasing the numbers of people getting involved in the new releases. A more detailed guide on "how to put up your testing environment for Drupal development" would help. That should take into account that development version is a moving target and suggest how to cope with it. I think learning how to cope with Drupal development branch is particularly important for a project like Drupal since it is used to make "great leap forward". That includes how to get information on what's going on. That's a place where DVCS may help... Reviewers live in limbo. Their work is important but there is no filter and there is no credit. Everybody can be a reviewer. In spite of increasing the number of reviewers I'd decrease them but give them more trust, credit and power. Patch queues frequently becomes very long democratic discussions... but very long... maybe there are too few BDFL. A voting system or just counting how many people are subscribed to an issue may give an idea to reviewers what are the hottest issues. I'd say that counting how many people are subscribed to an issue is a better thermometer. If you don't even want to be informed about what's going on for an issue I wouldn't say you're really interested. Somehow if the responsibility to commit to a stable version would be more shared across trustworthy credited people, maintainers may commit more frequently to stable. I think the project is missing "middle management". "Middle management" will also increase feedback to patcher. Even if their patch won't reach core at least there will be someone more "authoritative" explaining why. Ups this post was waiting in my draft queue... but it looks as a bad copy of what Larry just wrote... -- Ivan Sergio Borgonovo http://www.webthatworks.it
It's a fair question. When the Drupal community is at some 385,000+ people and there are some 5,500+ issues contending for attention, it can be difficult for the issues that you think are important to gain visibility. Some tips that should help, anyway: * File issues against the latest version of Drupal to have the problem. For example, if it happens in 6.x and 7.x, file it under 7.x instead; the latest version is always where most core developers are focusing, and once they get in to a later release, it's a lot easier to make the case for it belonging in earlier ones (and easier to commit the patch too, since it's already been vetted). * Hang out on IRC in #drupal, and watch for someone asking for a patch review. Tell them you'd be happy to review their patch if they could review yours. * We are always desperately short on patch reviewers. So if you consistently do awesome patch reviews as often as you can, and you will get escalated to the very tippy-top of the community karma scale very, very quickly. There are good tips about this at http://drupal.org/patch/review. Hope that helps, I'm about to get on a plane so didn't get a chance to look at those issues in particular, but these are some general tips. -Angie Markus Kalkbrenner wrote:
Hi,
This is my first post to this list so I will introduce myself first. My name is Markus Kalkbrenner. I'm developing software for more than 15 years and participating in open source projects since 7 years. Two years ago I started working with drupal and posted my first bug reports and patches.
Currently I'm asking myself which is the right strategy to contribute patches and get them committed to CVS because most of the time I'm still working with drupal 5 and find bugs there.
Just some examples:
Posted 4 month ago for drupal 5.7: http://drupal.org/node/229411 node_view() incompatible to php5
I was asked to add more comments to my patch and drumm found out that the same bug still exists in drupal 6. So I added the comments but nothing happend. Neither in D5 nor in D6.
Posted 3 month ago for drupal 5.8 http://drupal.org/node/287063 node_delete memory leak and wrong order of commands
In a different bug I was told to post the bugs for drupal 6 to get them handled faster and finally backported to drupal 5. So I switched the version for this issue to D6 and added an additional patch for it. But no reaction.
Posted 3 month ago for drupal 6.dev http://drupal.org/node/298768 Ensure that entries are written to watchdog table and http://drupal.org/node/298678 Impossible to lock two MySQL tables
From my point of view these are two serious issues which are the reason for several other bug reports. I found them in drupal 5 but discovered that they still exist in D6 and D7. So I decided to post them for D6 because this is the current stable version. Unfortunately I didn't see any reaction so far.
Please don't get me wrong. I really like drupal and will keep on contributing patches because I want to improve it. But maybe I'm doing something wrong or you just have no time to maintain the stable versions. So for me the current situation is like a "bad user experience".
participants (31)
-
"Fernando P. García" -
Adrian Rossouw -
andrew morton -
Angela Byron -
Ashraf Amayreh -
Brad Bowman -
Chris Johnson -
Daniel F. Kudwien -
Darrel O'Pry -
Darren Oh -
David Sterratt -
Derek Wright -
Dries Buytaert -
Earnie Boyd -
Eric-Alexander Schaefer -
Gerhard Killesreiter -
Greg Knaddison - GVS -
Ivan Sergio Borgonovo -
Jakob Petsovits -
Jerad Bitner -
John VanDyk -
Larry Garfield -
Marijn Kruisselbrink -
Markus Kalkbrenner -
Moshe Weitzman -
Nathaniel Catchpole -
Ryan Cross -
Steven Surowiec -
Tomas Fulopp -
Tomas Fulopp -
Vivek Puri