We're now in feature freeze, and already past half-way towards achieving hard freeze. We've named our release wardens and I'm already hearing some discussions regarding sorting through packaging issues. We've got some work to do to get through the must-fix bugs, but given that we've had a short time since 0.42.2, I think even this will go smoothly.
The number to check out this time is the number of feature requests. We dropped the total from 471 a couple months ago to under 450 now, or from a ratio of 62% to under 50%. Quite a jump!
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, and help us really drive this number down. :-)
Bryce
Statistics Jun 1 Jul 1 Aug 1 Sep 1 Sep 15 ========== ====== ====== ====== ====== ====== Max Week's Rank on SourceForge: 38 35 3 23 43 Total SF Page Views 1,935,964 3,797,037 4,452,437 4,139,401 4,467,690 Total SF Downloads 254,647 283,789 378,712 448,994 474,659 Total Freshmeat URL Hits 19,149 19,809 21,261 22,422 22,766 Total Freshmeat Subscriptions 183 189 208 220 224 Lines of Code in src/: 374,180 376,319 389,945 404,800 544,033 Code lines 260,236 261,600 270,423 279,621 373,738 Comment line 67,136 67,724 70,478 73,904 108,863 Blank 53,443 53,651 55,698 57,937 73,408 Lines of Docs in doc/: 27,790 27,792 28,090 28,121 27,176 Lines of content in website: 42,490 42,700 44,483 44,732 45,246 Size of the Inkscape wiki: 26,729 28,525 34,890 34,847 34,847 Bugs open/total: 215/1223 196/1312 215/1445 250/1555 258/1591 Features open/total: 453/ 728 471/ 767 440/816 466/ 874 448/ 900 Patches open/total: 11/ 230 10/ 268 8/325 6/ 332 9/ 336 CVS Commits (as per inkscape-cvs) 12,040 12,372 12,915 13,423 13,936 Inkscape-devel membership: 179 188 200 217 217 Inkscape-announce membership: 202 217 236 274 278 Inkscape-user membership: 248 258 276 295 304 Inkscape-tester membership: 23 Num Translations: 33 33 33 33 33 Ave Translation Ratio: 47.8 48.6 54.6 54.9 50.2
Bryce Harrington wrote:
The number to check out this time is the number of feature requests. We dropped the total from 471 a couple months ago to under 450 now, or from a ratio of 62% to under 50%. Quite a jump!
I bet the decrease in the number of RFE is partly due to a more aggressive triaging, with some closed as duplicates.
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, and help us really drive this number down. :-)
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.
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
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?
Sounds like a good idea. It's practically impossible to keep track of all of them for any human being. All you need then is work out criteria for evaluation of priorites.
Alexandre
On Fri, Sep 16, 2005 at 05:15:23PM +0400, Alexandre Prokoudine wrote:
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
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?
Sounds like a good idea. It's practically impossible to keep track of all of them for any human being. All you need then is work out criteria for evaluation of priorites.
I like this idea too. Would either or both of you like to organize a bug party for this weekend?
Bryce
Bryce Harrington wrote:
On Fri, Sep 16, 2005 at 05:15:23PM +0400, Alexandre Prokoudine wrote:
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
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?
Sounds like a good idea. It's practically impossible to keep track of all of them for any human being. All you need then is work out criteria for evaluation of priorites.
I like this idea too. Would either or both of you like to organize a bug party for this weekend?
This weekend is too soon, how about the next one?
On Sat, Sep 17, 2005 at 02:25:47PM +0300, Nicu Buculei wrote:
Bryce Harrington wrote:
On Fri, Sep 16, 2005 at 05:15:23PM +0400, Alexandre Prokoudine wrote:
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
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?
Sounds like a good idea. It's practically impossible to keep track of all of them for any human being. All you need then is work out criteria for evaluation of priorites.
I like this idea too. Would either or both of you like to organize a bug party for this weekend?
This weekend is too soon, how about the next one?
Sure, that would work. What do you think needs to be done to organize it?
Bryce
Bryce Harrington wrote:
On Sat, Sep 17, 2005 at 02:25:47PM +0300, Nicu Buculei wrote:
Bryce Harrington wrote:
On 9/16/05, Nicu Buculei <nicu@...398...> wrote:
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?
I like this idea too. Would either or both of you like to organize a bug party for this weekend?
This weekend is too soon, how about the next one?
Sure, that would work. What do you think needs to be done to organize it?
The first thing would be to find a time interval when at least a few people with experience on Inkscape and bug tracker will be available on the channel. It should allow people from different time zones to participate. I don't have experience with this and can't say what an optimal duration is.
Then we should popularize the event. I think it should be announced on users list, front page, blogs and friendly mailing lists, like OCAL or Scribus. If we want to make it a big event the we can put even an announcement on gnomedesktop.org.
Also, we should make a wiki page with rules and instructions, like "if a bug report is one release old/one month old, we can't reproduce it and don't have any follow-up from the poster, it can be closed". We need some rules for marking a bug as "won't fix" or "not a bug", and what is harder, rules for rejecting RFEs - we were polite and accepted any RFE, but to be honest, there are some request which *never* will be implemented, like "Inkscape as Eclipse plugin" (http://sourceforge.net/tracker/index.php?func=detail&aid=1116021&gro...)
On Sun, Sep 18, 2005 at 12:19:22PM +0300, Nicu Buculei wrote:
Bryce Harrington wrote:
Sure, that would work. What do you think needs to be done to organize it?
The first thing would be to find a time interval when at least a few people with experience on Inkscape and bug tracker will be available on the channel. It should allow people from different time zones to participate. I don't have experience with this and can't say what an optimal duration is.
IIRC, when we set up the Scribus meeting we found that around 9-10am PST seemed to work well.
Also, I think if we made it an all day event, then people could join or leave as desired, so we'd just need to be sure it fit the times when folks would be able to work.
Maybe we could say it's going to be an all-weekend event, but we will set aside two 4-hour periods each day when we guarantee there will be developers on channel. Looking at yesterday's irc log, it looks like 8-12 PST was fairly active, and then again from 16-20. How do those periods sound?
Then we should popularize the event. I think it should be announced on users list, front page, blogs and friendly mailing lists, like OCAL or Scribus. If we want to make it a big event the we can put even an announcement on gnomedesktop.org.
Good ideas. Probably for the first one it might be good to start with just our existing community, but for future ones it'd be valuable to advertise it more widely.
Would you like to go ahead and draft up an announcement in Wiki for this? We should probably aim to get word out no later than Wednesday.
Also, we should make a wiki page with rules and instructions, like "if a bug report is one release old/one month old, we can't reproduce it and don't have any follow-up from the poster, it can be closed". We need some rules for marking a bug as "won't fix" or "not a bug", and what is harder, rules for rejecting RFEs - we were polite and accepted any RFE, but to be honest, there are some request which *never* will be implemented, like "Inkscape as Eclipse plugin" (http://sourceforge.net/tracker/index.php?func=detail&aid=1116021&gro...)
Yeah. I bet the best place for this is the Reporting Bugs page.
Do you think there should be specific tasks we'd ask them to do, or just sort of a free-for-all bug finding/fixing party?
Bryce
Bryce Harrington wrote:
On Sun, Sep 18, 2005 at 12:19:22PM +0300, Nicu Buculei wrote:
Bryce Harrington wrote:
Sure, that would work. What do you think needs to be done to organize it?
The first thing would be to find a time interval when at least a few people with experience on Inkscape and bug tracker will be available on the channel. It should allow people from different time zones to participate. I don't have experience with this and can't say what an optimal duration is.
IIRC, when we set up the Scribus meeting we found that around 9-10am PST seemed to work well.
This is 17-18 UTC, yes, I think is OK
Also, I think if we made it an all day event, then people could join or leave as desired, so we'd just need to be sure it fit the times when folks would be able to work.
I don't think we have so many bugs so a full week-end will be needed, let start with just one day and seeing the results will know how to organize a future one.
Maybe we could say it's going to be an all-weekend event, but we will set aside two 4-hour periods each day when we guarantee there will be developers on channel. Looking at yesterday's irc log, it looks like 8-12 PST was fairly active, and then again from 16-20. How do those periods sound?
So 16-20 UTC and 0-4 UTC of the next day, looks like both periods are good for US and at least the first one for Europe, I'm OK with that.
Then we should popularize the event. I think it should be announced on users list, front page, blogs and friendly mailing lists, like OCAL or Scribus. If we want to make it a big event the we can put even an announcement on gnomedesktop.org.
Good ideas. Probably for the first one it might be good to start with just our existing community, but for future ones it'd be valuable to advertise it more widely.
Would you like to go ahead and draft up an announcement in Wiki for this? We should probably aim to get word out no later than Wednesday.
I'll work on this today.
Also, we should make a wiki page with rules and instructions, like "if a bug report is one release old/one month old, we can't reproduce it and don't have any follow-up from the poster, it can be closed". We need some rules for marking a bug as "won't fix" or "not a bug", and what is harder, rules for rejecting RFEs - we were polite and accepted any RFE, but to be honest, there are some request which *never* will be implemented, like "Inkscape as Eclipse plugin" (http://sourceforge.net/tracker/index.php?func=detail&aid=1116021&gro...)
Yeah. I bet the best place for this is the Reporting Bugs page.
Do you think there should be specific tasks we'd ask them to do, or just sort of a free-for-all bug finding/fixing party?
I'll go with a free-for-all with a preference for old reports, is our first so we want it simple and easy.
In the meantime I got an additional ideea of the requirements: it would be good for us to define a target build of Inkscape to be used in testing (to see if old bugs are still present or features were implemented) such as 0.42.2, a CVS build or a 0.43 RC. This target should have binaries for as much platforms as possible.
Nicu Buculei wrote:
Bryce Harrington wrote:
Would you like to go ahead and draft up an announcement in Wiki for this? We should probably aim to get word out no later than Wednesday.
I'll work on this today.
Here is a first, rough draft, fell free to add/improve: http://wiki.inkscape.org/cgi-bin/wiki.pl?BugParty
Nicu Buculei wrote:
Nicu Buculei wrote:
Bryce Harrington wrote:
Would you like to go ahead and draft up an announcement in Wiki for this? We should probably aim to get word out no later than Wednesday.
I'll work on this today.
Here is a first, rough draft, fell free to add/improve: http://wiki.inkscape.org/cgi-bin/wiki.pl?BugParty
The page is up for a couple of days now, has anyone reviewed it? (I saw no major editing on it despite the fact it contained some errors I corrected myself recently) Should I go ahead and put the announcement?
On Wed, Sep 21, 2005 at 04:16:46PM +0300, Nicu Buculei wrote:
Nicu Buculei wrote:
Nicu Buculei wrote:
Bryce Harrington wrote:
Would you like to go ahead and draft up an announcement in Wiki for this? We should probably aim to get word out no later than Wednesday.
I'll work on this today.
Here is a first, rough draft, fell free to add/improve: http://wiki.inkscape.org/cgi-bin/wiki.pl?BugParty
The page is up for a couple of days now, has anyone reviewed it? (I saw no major editing on it despite the fact it contained some errors I corrected myself recently)
I've reviewed it and made a few copyediting improvements. I think it looks good, but it would be worth having a third person also do a review to see if anything else was missed.
Should I go ahead and put the announcement?
First let's make sure at least a few developers are willing to volunteer time this day to help folks. I will definitely be there, so that's one. :-) Who else?
Nicu, perhaps you could ask a few of the developers on chat, that might not be following this thread?
Bryce
On Sun, 18 Sep 2005, Nicu Buculei wrote:
...
what is harder, rules for rejecting RFEs - we were polite and accepted any RFE, but to be honest, there are some request which *never* will be implemented, like "Inkscape as Eclipse plugin"
I recommend a stock response that politely but firmly makes it clear we have limited resources, no paid developers, no one compelled to work on any features and with all due respect we thank you for feedback but must close reports which cannot reasonably be expected to implemented.
I'm sure with a litte effort you could come up with something better. I've already started using some stock responses (because I was so annoyed by the bad reports I was having difficulty staying polite). Feel free to come up with better versions and I'll be happy to remove mine.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 9/19/05, Alan Horkan <horkana@...44...> wrote:
On Sun, 18 Sep 2005, Nicu Buculei wrote:
... what is harder, rules for rejecting RFEs - we were polite and accepted any RFE, but to be honest, there are some requests which *never* will be implemented, like "Inkscape as Eclipse plugin"
I recommend a stock response that politely but firmly makes it clear we have limited resources, no paid developers, no one compelled to work on any features and with all due respect we thank you for feedback but must close reports which cannot reasonably be expected to implemented.
See http://wiki.inkscape.org/cgi-bin/wiki.pl?OtherGoals ; and we should add some non-goals there and in the FAQ sheet.
IMHO there are features (such as features better implemented as extensions, features better in the Gimp ...) which should not go into Inkscape even if we had unlimited resources!
Ben
Ben Fowler wrote:
On 9/19/05, Alan Horkan <horkana@...44...> wrote:
On Sun, 18 Sep 2005, Nicu Buculei wrote:
... what is harder, rules for rejecting RFEs - we were polite and accepted any RFE, but to be honest, there are some requests which *never* will be implemented, like "Inkscape as Eclipse plugin"
I recommend a stock response that politely but firmly makes it clear we have limited resources, no paid developers, no one compelled to work on any features and with all due respect we thank you for feedback but must close reports which cannot reasonably be expected to implemented.
See http://wiki.inkscape.org/cgi-bin/wiki.pl?OtherGoals ; and we should add some non-goals there and in the FAQ sheet.
IMHO there are features (such as features better implemented as extensions, features better in the Gimp ...) which should not go into Inkscape even if we had unlimited resources!
Yes, this was also my intention: give a stock response, but after that close the feature, it has no point to remain in the tracker. Is a risk because this action can upset the submitter, but this is why I think we should add a good explanation before closing.
On Fri, Sep 16, 2005 at 12:02:55PM +0300, Nicu Buculei wrote:
Bryce Harrington wrote:
The number to check out this time is the number of feature requests. We dropped the total from 471 a couple months ago to under 450 now, or from a ratio of 62% to under 50%. Quite a jump!
I bet the decrease in the number of RFE is partly due to a more aggressive triaging, with some closed as duplicates.
Certainly that's the case; it's good to see the number come down none-the-less.
Bryce
participants (5)
-
Alan Horkan -
Alexandre Prokoudine -
Ben Fowler -
Bryce Harrington -
Nicu Buculei