>How Many Votes is Enough?

>A common item I have read in various newsgroups for eclipse, is for the community to vote for a bug. If it gets enough votes, it’s more than likely to get addressed sooner rather than later. While I think this practice works in theory, I’m not necessarily convinced it’s working in reality.

The reality is that the items that the Adopters and the Foundation Members want, get higher precedence than those items that the community wants. Asking the community to vote for a bug doesn’t necessarily work, especially when a community member is limited on the number of votes they can have per project. Some projects have this set pretty high, others have it set very low. I’m not sure what the rational is on limiting the number of votes, but that is what community members have to live with.

So, just for fun, I took a look at the Web Tools Project, only because that is where I spend most of my time as both a community member and a committer on the XSL Tools project. I did a quick bugzilla search on all Non-Enhancement requests, that had votes. Here is the bug list.

There are a total of 191 open new, assigned, or reopened bugs that have at least 1 vote. Theoretically, with the way that WTP can crank out bug fixes at times, all 191 could possibly be fixed in one Milestone. Now that is only in theory, and it actually won’t happen.

The bigger question is do all the bugs with at least 1 vote, get higher precedence than bugs with no votes? How many votes does it take to get a bug noticed and on the radar to be fixed? Just curious how other projects are handling community related requests and prioritizing them compared to the Adopter and Foundation member requests? I would hope that all Adopter and Foundation member requests also go through bugzilla.

Advertisements
This entry was posted in eclipse. Bookmark the permalink.

3 Responses to >How Many Votes is Enough?

  1. >I’m not sure why we ask for votes either. The bugs that the committers need/want obviously get precedence. That’s followed by bugs that have patches attached. In general, I don’t think any of the committers look at the votes. There may be exceptions.You need to see this from the committer’s point of view and what motivates them. Usually the directions from their employers comes first. And after that, there isn’t much time left to do much else.

  2. David Carver says:

    >While the majority of committers are paid, there are quite a few that aren’t paid to work on Eclipse related projects. I happen to be one of those that gets very little time devoted from my employer to working on eclipse related items. Everything I do is basically after hours.I think in general though there needs to be a happy medium between what is best for the employers and what is best for the community. Where that line is, is always a difficult balancing act. My personal philosophy is that bug fixes should come ahead of feature enhancements, but again I’m probably in the minority on this.

  3. Lee Anne says:

    >I understand the reality that Doug states about the bugs that committers need/want getting precedence.I also live in the pain of trying to explain to my colleagues who are Eclipse adopters (RCP) why a bug which they voted for is not getting fixed.What I’d appreciate seeing is where there is direction from the committers’ employers, that the votes from their employers are registered in the vote count on the bug. Or by discussion in the bug that reflects why it is getting committer resource attention vs another bug that might have 6 votes and not getting any work done on it from one release to the next.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s