Re: [Inkscape-devel] Inkscape stats 9/15/05
Ben Fowler wrote:
I would respectfully disagree with both of the substantive points in this thread(!):
But you forgot to reply to the list ;)
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
Bryce Harrington wrote:
[ snip ]
Where the project needs help right now is in closing bugs. We have our bug tracker quite well under control, but there are 258 open bugs, and it would be wonderful if we could cut that down significantly before the 0.43 release. If you can code, please check out if you can help close one or two, ...
I am sitting on three patches, waiting for a thaw so that I can commit without endangering other's activities. There was never much of a thaw after 0.42!
Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release.
Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle.
I suspect that I am missing something ...
Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over.
Ideally this should be based on the importance to the end-user rather than priority or ease of fixing. (High priority and easy to fix bugs should most certainly be fast tracked, but again, at the beginning or in the middle of a release cycle).
Other projects keep from time to time some events called "bug party", when people clean the bug/feature tracker, collaborating over IRC and closing as much as possible as DUPLICATE, WON'T FIX, INVALID, RESOLVED or prioritizing. It may have the benefit of attracting new contributors and giving non-developers a way to contribute.
What do you think about the opportunity/usefulness of such a bug party?
At 258 bugs and 448 RFEs the number may be small enough and the action not needed.
I wholeheartedly agree with these data and your suggestions, until the last line, where there is the implication that 250 open bugs is a small number. Really, we should be aiming at zero bugs, and should have 10 or fewer open ones.
I said "may be" because I really don't know what we should consider a large or small number of bugs, compared with larger projects like Mozilla or OOo, 258 open bugs is very little.
I would urge every effort to getting non-coders interested in triaging bugs and assigning priorities at all times. It is especially helpful to have end-users prioritising bugs, as bugs which do not impact the user community can be left to a future when there is more time.
I also note that many of the open bugs refer to the Windows operating system, and unless those they are easily reproducible they may never get seen by a developer unless the user community can get behind them and insist that (some of) such bugs are indeed important.
Well, it may also be the case some of those bugs can't be reproduced at all or referring to old versions of Inkscape and can be simply closed.
Finally, if we are going to have hundreds of open bugs, we should consider an even/odd policy, and do 'bug fixes only' for even numbered releases ...
That may not desirable if we have a large number of RFEs and/or features which developers are interested in. Certainly in the proprietary world, there are products which have benefitted from a period of stability in which six months of the developers time was spent on stabilisation, performance and bug fixing rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
Ben
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
I said "may be" because I really don't know what we should consider a large or small number of bugs, compared with larger projects like Mozilla or OOo, 258 open bugs is very little.
But that number is growing by approximately 50 every release. And for most part, this is not a healthy growth. By this I mean that most of the new bugs are unclear, unreproducible, undocumented, duplicate, etc. It's with addressing this, not bug fixing proper, that we really need everyone's help.
On Fri, 16 Sep 2005, bulia byak wrote:
Date: Fri, 16 Sep 2005 13:18:39 -0300 From: bulia byak <buliabyak@...400...> To: Nicu Buculei <nicu@...398...> Cc: Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
I said "may be" because I really don't know what we should consider a large or small number of bugs, compared with larger projects like Mozilla or OOo, 258 open bugs is very little.
But that number is growing by approximately 50 every release. And for most part, this is not a healthy growth. By this I mean that most of the new bugs are unclear, unreproducible, undocumented, duplicate, etc. It's with addressing this, not bug fixing proper, that we really need everyone's help.
Ban anonymous reports immediately.
Zero tolerance isn't something I'm normally in favour of but I think anonymous reports are great big waste of time to put it bluntly.
Wont solve anything but will at least reduce the quantity of crappy bug reports and make me less reluctant to spend time fleshing out the other requests into something easier for the developers to work with.
- Alan
On 9/16/05, Alan Horkan <horkana@...44...> wrote:
Ban anonymous reports immediately.
In my experience, the quality of a report does not directly depend on its anonymity.
bulia byak wrote:
On 9/16/05, Alan Horkan <horkana@...44...> wrote:
Ban anonymous reports immediately.
In my experience, the quality of a report does not directly depend on its anonymity.
I'm not sure that banning is the solution, because for me it's not the quality that I take issue with. It's the inability to follow up. We have a number of bugs that anonymous people report, yet they never respond once we start investigating it (and that usually is us responding to the initial report with questions).
So, perhaps we have a policy in place that if they don't respond within a month of our "inquiry" or suggestion, it is closed with the assumption that the bug is fixed or no longer relevant.
Just my .02
-Josh
On 9/16/05, Joshua A. Andler <joshua@...533...> wrote:
So, perhaps we have a policy in place that if they don't respond within a month of our "inquiry" or suggestion, it is closed with the assumption that the bug is fixed or no longer relevant.
That sounds sensible, and it's more or less what we've been doing.
Date: Fri, 16 Sep 2005 16:20:28 -0300 From: bulia byak <buliabyak@...400...> To: Joshua A. Andler <joshua@...533...> Cc: Alan Horkan <horkana@...44...>, Inkscape ML inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape stats 9/15/05
On 9/16/05, Joshua A. Andler <joshua@...533...> wrote:
So, perhaps we have a policy in place that if they don't respond within a month of our "inquiry" or suggestion, it is closed with the assumption that the bug is fixed or no longer relevant.
That sounds sensible, and it's more or less what we've been doing.
but what we are doing requires more people, people we dont seem to have?
- Alan
On Fri, Sep 16, 2005 at 02:41:35PM +0300, Nicu Buculei wrote:
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
Bryce Harrington wrote:
Where the project needs help right now is in closing bugs. We have our bug tracker quite well under control, but there are 258 open bugs, and it would be wonderful if we could cut that down significantly before the 0.43 release. If you can code, please check out if you can help close one or two, ...
I am sitting on three patches, waiting for a thaw so that I can commit without endangering other's activities. There was never much of a thaw after 0.42!
Due to the summer of code students, it was our intent to push out 0.43 pretty quickly. However, I think there might have been some confusion in that between the 0.42.0 release and 0.42.2, CVS HEAD was open for 0.43 work for about a month.
Ideally, the tree should be open just after a release for new work including patches for minor bugs, also for developers' prized features, as there will be a period for stabilisation before the next release.
Just before a release, the emphasis should be on testing, packaging and to a lesser extent on 'blocking bugs'. Cutting down the number of open bugs by commiting is highly likely to expose other bugs or problems with the code that require stabilisation and should be done (IMHO) early in the release cycle.
I suspect that I am missing something ...
What you describe is pretty much how we work. I think you might have come in at the middle, and the 0.42.2 patch release might have been confusing.
Personally, I would suggest that some manageable number bugs (somewhere between 10 an 50 given the number of developers) are marked as must fix before 0.43 and patches for other bugs (the 'minor bugs' I mentioned above) are held over.
Ideally this should be based on the importance to the end-user rather than priority or ease of fixing. (High priority and easy to fix bugs should most certainly be fast tracked, but again, at the beginning or in the middle of a release cycle).
Yes, we go through two bug fixing phases; the first we set a point goal and accept any bug fixes, and discourage feature work, in order to allow the codebase to stabilize. The second is a hard freeze, where identify a set of up to a dozen 'must fix' bugs and limit CVS commit access to two 'release wardens'. During that phase all work must be sent to them as patches for review and integration, and they provide a tight final quality control before we go ahead and branch the release. This ensures we as a project place maximum focus on QC ahead of a release.
I wholeheartedly agree with these data and your suggestions, until the last line, where there is the implication that 250 open bugs is a small number. Really, we should be aiming at zero bugs, and should have 10 or fewer open ones.
I said "may be" because I really don't know what we should consider a large or small number of bugs, compared with larger projects like Mozilla or OOo, 258 open bugs is very little.
I'd love to see us have zero bugs, but of course there's a balance between being perfect and releasing regularly. ;-)
Where we've been drawing the line is achieving zero bugs that lead to crashes or data corruption. Cosmetic bugs, usability issues, and incompatibilities are also important, but getting all those solved is more of a long term objective.
I would urge every effort to getting non-coders interested in triaging bugs and assigning priorities at all times. It is especially helpful to have end-users prioritising bugs, as bugs which do not impact the user community can be left to a future when there is more time.
Yup, we do this quite regularly, and we've gotten quite a few good volunteers to help with this prioritization work. Of course, we could always use a few more! Both bugs and RFEs need some prioritization effort right now.
I also note that many of the open bugs refer to the Windows operating system, and unless those they are easily reproducible they may never get seen by a developer unless the user community can get behind them and insist that (some of) such bugs are indeed important.
I think you'll find as you get involved with the bug efforts that we actually do get remarkably good participation from the user community in replicating bug reports and in validating fixes. This has been especially true for some of the bugs related to localization. I think we actually have a fair number of Win32 devs, and we're even starting to see some OSX-based devs, however I think we could really use more of each.
Finally, if we are going to have hundreds of open bugs, we should consider an even/odd policy, and do 'bug fixes only' for even numbered releases ...
Actually, we started doing this semi-officially with the 0.42 release. 0.43 is being considered a bit more development-oriented, and 0.44 will be considered a more aggressive bug-killing release. If you're strongly interested in seeing us get our bug count down closer to zero, I'd definitely encourage you to jump in on the 0.44 release. I'd love to see us cut our current open bug count in half at least (we've done it before, I think we could do it again.)
That may not desirable if we have a large number of RFEs and/or features which developers are interested in. Certainly in the proprietary world, there are products which have benefitted from a period of stability in which six months of the developers time was spent on stabilisation, performance and bug fixing rather than new features. Ideally we need to know whether the user community would vote for quality and bug fixes or new features ...
Of course, keep in mind that as an open source project, the personal desires of the participants play a very large role in determining what the project as a whole focuses on. A commercial organization can force its developers to work on whatever it wants, but with Inkscape since we're volunteer driven and since we put a high value on keeping things fun, the project doesn't work that way.
I think we actually get better productivity and make most efficient use of our resources by letting people work on what interests them rather than trying to drive it top-down. I think enough of us get top-down driving from work. ;-) I think when the developer has the freedom to work on what they feel the urge to work on, they enjoy the work more, and spend more of their time on it. It usually turns out that the bugs still get fixed, the features still get implemented, just maybe not quite in the order you'd have planned for. Looking back over our roadmap for the past couple years, I see that the stuff we wanted to achieve has been getting done quite rapidly, even though (or because?) we don't give out assignments or require weekly status reports or whatnot.
Ultimately, in my view, while we love our users, their input regarding prioritization of bugs and features is probably less worthwhile than just having them interact directly with the developers and let the developers' personal judgement be what sets the priorities. Ideally, if a user has a need that is a high priority, the best solution is to encourage her to contribute towards that thing - even if she doesn't code, there's still plenty of ways she can help, through testing, bug analysis, creation of mockups for new features, writing documentation, and so forth. It often turns out that once you put in some time yourself towards some issue, it builds momentum as others take interest and chip in where they see they can help, and before you know it the bug's fixed or the feature's implemented, and everyone's had a bunch of fun. :-)
Bryce
participants (5)
-
Alan Horkan -
Bryce Harrington -
bulia byak -
Joshua A. Andler -
Nicu Buculei