Jira cleanup sprint?
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
Jira cleanup sprint?
by Andrea Aime-4
::
Rate this Message:
Hi,
chatting a bit in person and on IRC with other developers there seems to be consesus that our Jira bug tracker needs a cleanup. If one look at the report of outstanding issues at http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+resolution+%3D+Unresolved+ORDER+BY+key+ASC%2C+updated+DESC discomfort is probably the first reaction: there are almost 1000 open issues! The this is, a number of those issues should not be there and are just polluting the tracker. Some example categories: - issues that have been fixed already but not closed (maybe they were duplicates of another issue, maybe the code just changed, for unrelated reasons, in a way that the issue cannot be reproduced anymore). - very old issues that do not have the necessary data to be reproduced and the reporter has long gone - improvements that are just not going to happen (e.g. "running WFS cite tests over shapefiles", which is actually impossible with WFS 1.1 ones) It would be nice to organize a sprint to cleanup the situation. Of course developers should participate, but it would be nice to have some users join the fray as well, I guess there should be some jiras that just need checking if the bug is still there and that's something a user may be able to do as well. Open questions: - is there enough people interested? Raise your hand - where shall we do it? My suggestion is over the net, organizing one in a physical location could prove challenging - when shall we do it, how long? If we do it online, I was thinking 3 days long, a Friday, Saturday and Sunday. Friday would allow people that can participate during their normal working hours to join, and the weekend to allow anybody else to participate as well (nobody is asking to participate for 3 days long, 1 hour on any of those days is good too!) - how do we proceed? How do we split the jiras to be reviewed and check progress? Hmm... I guess we could just go on a first come, first served basis? We keep an shared editor on etherpad with a list of all the jiras, and when one starts looking into a specific jira, he writes his name besides it. When the ispection is done the issue is either marked as processed, or a note is added telling why the jira could not be processed (e.g., not enough info, someone with greater expertise needs to look into it, or would just take too much time to verify it and we are leaving it for the last part of the sprint, etc). Hopefully this would allow us to reduce the number of invalid issues significantly. We might not be able to check all of the 1000 issues during the sprint, but it would be at least nice to check the first few hundreds, the oldest ones, since they are the most likely to be invalid after years of being open. For the issues that are in need of further feedback we could just ask the reporter for it, and close as invalid all those that did not receive the necessary feedback within a week from the sprint. What do you think? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Jira cleanup sprint?
by Ľubomír Varga
::
Rate this Message:
Iam in. Give some contact info at the end of discusion and Ill join for about
2 or 3 hours minimally. I like jabber, but irc is also my friend. On Thursday 05 November 2009 13:07:24 Andrea Aime wrote: > Hi, > chatting a bit in person and on IRC with other developers > there seems to be consesus that our Jira bug tracker > needs a cleanup. > > If one look at the report of outstanding issues at > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=pro >ject+%3D+GEOS+AND+resolution+%3D+Unresolved+ORDER+BY+key+ASC%2C+updated+DESC > discomfort is probably the first reaction: there are > almost 1000 open issues! > > The this is, a number of those issues should not be there > and are just polluting the tracker. Some example categories: > - issues that have been fixed already but not closed (maybe > they were duplicates of another issue, maybe the code just > changed, for unrelated reasons, > in a way that the issue cannot be reproduced anymore). > - very old issues that do not have the necessary data to > be reproduced and the reporter has long gone > - improvements that are just not going to happen (e.g. > "running WFS cite tests over shapefiles", which is actually > impossible with WFS 1.1 ones) > > It would be nice to organize a sprint to cleanup the situation. > Of course developers should participate, but it would be nice > to have some users join the fray as well, I guess there should > be some jiras that just need checking if the bug is still there > and that's something a user may be able to do as well. > > Open questions: > - is there enough people interested? Raise your hand > - where shall we do it? My suggestion is over the net, > organizing one in a physical location could prove > challenging > - when shall we do it, how long? If we do it online, I was > thinking 3 days long, a Friday, Saturday and Sunday. > Friday would allow people that can participate during their > normal working hours to join, and the weekend to allow anybody > else to participate as well (nobody is asking to participate > for 3 days long, 1 hour on any of those days is good too!) > - how do we proceed? How do we split the jiras to be reviewed > and check progress? Hmm... I guess we could just go on a > first come, first served basis? > We keep an shared editor on etherpad with a list of all the > jiras, and when one starts looking into a specific jira, > he writes his name besides it. When the ispection is > done the issue is either marked as processed, or a note is > added telling why the jira could not be processed (e.g., > not enough info, someone with greater expertise needs to > look into it, or would just take too much time to verify it > and we are leaving it for the last part of the sprint, etc). > > Hopefully this would allow us to reduce the number of > invalid issues significantly. > We might not be able to check all of the 1000 issues > during the sprint, but it would be at least nice to check > the first few hundreds, the oldest ones, since they are the > most likely to be invalid after years of being open. > > For the issues that are in need of further feedback we could > just ask the reporter for it, and close as invalid all those > that did not receive the necessary feedback within a week > from the sprint. > > What do you think? > > Cheers > Andrea Odborník na všetko je zlý odborník. Ja sa snažím byť výnimkou potvrdzujúcou pravidlo. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Jira cleanup sprint?
by cholmez
::
Rate this Message:
/me raises hand.
3 days actually feels long to me. I've actually spent time in the past doing exactly this, and I'm pretty sure I'd get through at least 50-100 issues in an hour. I may be faster than most for knowing what's there pretty well, and I aim at the easy ones when I do it. I think a friday/saturday could be good, and perhaps check at the end of saturday to see if sunday feels worth doing. I imagine few people would just show up for sunday. But I like the split of one work day and one off day - I'd try to put in a couple hours on saturday. The rest of your suggestions are great. 2009/11/5 Ľubomír Varga <luvar@...> Iam in. Give some contact info at the end of discusion and Ill join for about ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Jira cleanup sprint?
by David Winslow-5
::
Rate this Message:
On 11/05/2009 09:19 AM, Chris Holmes wrote:
/me raises hand.I'd be in too. -- David Winslow OpenGeo - http://opengeo.org/ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Jira cleanup sprint?
by Justin Deoliveira-6
::
Rate this Message:
Great idea, I am definitely interested. A workflow I could see working
well would be two teams. A non dev team that actually does most of the jira mangling, doing the actual clean up in the tracker. And then a dev team who basically just works through a ticket queue. If we do plan to actually do a lot of bug fixing then I think three days sounds appropriate. -Justin Andrea Aime wrote: > Hi, > chatting a bit in person and on IRC with other developers > there seems to be consesus that our Jira bug tracker > needs a cleanup. > > If one look at the report of outstanding issues at > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+resolution+%3D+Unresolved+ORDER+BY+key+ASC%2C+updated+DESC > discomfort is probably the first reaction: there are > almost 1000 open issues! > > The this is, a number of those issues should not be there > and are just polluting the tracker. Some example categories: > - issues that have been fixed already but not closed (maybe > they were duplicates of another issue, maybe the code just > changed, for unrelated reasons, > in a way that the issue cannot be reproduced anymore). > - very old issues that do not have the necessary data to > be reproduced and the reporter has long gone > - improvements that are just not going to happen (e.g. > "running WFS cite tests over shapefiles", which is actually > impossible with WFS 1.1 ones) > > It would be nice to organize a sprint to cleanup the situation. > Of course developers should participate, but it would be nice > to have some users join the fray as well, I guess there should > be some jiras that just need checking if the bug is still there > and that's something a user may be able to do as well. > > Open questions: > - is there enough people interested? Raise your hand > - where shall we do it? My suggestion is over the net, > organizing one in a physical location could prove > challenging > - when shall we do it, how long? If we do it online, I was > thinking 3 days long, a Friday, Saturday and Sunday. > Friday would allow people that can participate during their > normal working hours to join, and the weekend to allow anybody > else to participate as well (nobody is asking to participate > for 3 days long, 1 hour on any of those days is good too!) > - how do we proceed? How do we split the jiras to be reviewed > and check progress? Hmm... I guess we could just go on a > first come, first served basis? > We keep an shared editor on etherpad with a list of all the > jiras, and when one starts looking into a specific jira, > he writes his name besides it. When the ispection is > done the issue is either marked as processed, or a note is > added telling why the jira could not be processed (e.g., > not enough info, someone with greater expertise needs to > look into it, or would just take too much time to verify it > and we are leaving it for the last part of the sprint, etc). > > Hopefully this would allow us to reduce the number of > invalid issues significantly. > We might not be able to check all of the 1000 issues > during the sprint, but it would be at least nice to check > the first few hundreds, the oldest ones, since they are the > most likely to be invalid after years of being open. > > For the issues that are in need of further feedback we could > just ask the reporter for it, and close as invalid all those > that did not receive the necessary feedback within a week > from the sprint. > > What do you think? > > Cheers > Andrea > > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Jira cleanup sprint?
by Andrea Aime-4
::
Rate this Message:
Justin Deoliveira ha scritto:
> Great idea, I am definitely interested. A workflow I could see working > well would be two teams. A non dev team that actually does most of the > jira mangling, doing the actual clean up in the tracker. And then a dev > team who basically just works through a ticket queue. > > If we do plan to actually do a lot of bug fixing then I think three days > sounds appropriate. Ha ha, it seems we are thinking three different things :-) Chris wit his "50-100 jira checks per hour" (1 checks per minute, wow) is probably thinking about doing a fast scan of the issues and close those that you already know have been solved by just very quickly scanning the contents (and also mark somehow the ones that you're sure haven't been closed). And just skip anything that you're doubtful about. This mode is effective but can be used only by a developer that knows very well GS and its history. I was thinking more of 3-5 checks per hour instead, but then again I was thinking about jiras where you actually have to try and reproduce the problem to see if it's still there: it's the mode you have to get into when you just don't know if the problem is still there or not. This mode can be tackled by anyone. Then there are the incomplete reports. For those we just have to ask for more details, and if they don't come, we close the report the week after as "invalid" or "cannot reproduce". This is tricky, judging whether there is enough information is hard, there might be enough for a developer but not enough for a user trying to reproduce. The actual bug fixing, I was not planning to do. Even with the easy ones I don't think one can close much more than 8-10 a day (at least, that's how much I close in my best bug fixing day, and of course avoiding hard to fix issues that can take two days per fix). Looking at the history of the last 300 days: http://jira.codehaus.org/secure/ConfigureReport.jspa?projectOrFilterId=project-10311&periodName=daily&daysprevious=300&cumulative=false&versionLabels=none&selectedProjectId=10311&reportKey=com.atlassian.jira.plugin.system.reports%3Acreatedvsresolved-report&Next=Next one can see that we never had a day in which more than 18 issues were fixed, those days are few and far apart, and involved the effort of multiple developers. Here is the 18 fixes in a day one for example: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+resolutiondate+%3E%3D+2009-04-15+AND+resolutiondate+%3C%3D+%222009-04-15+23%3A59%22+ORDER+BY+assignee+ASC%2C+key+DESC Soo, to sum up, what about we do the sprint so that: - the first half a day it's developers going thru the existing issues real fast and close the obvious ones, and mark the know to be still open ones - then everybody jumps in and we check the others that we're not sure about? I guess it would be nice to have a shared spreadsheet to keep track of who's doing what and how the state of each jira changed (it would make for nice statistics at the end too, so that we can summarize the results of the work). Something like etherpad, but with a grid :) If we cannot find one, a shared etherpad will do as well. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
|
|
Re: Jira cleanup sprint?
by David Winslow-5
::
Rate this Message:
On 11/06/2009 04:28 AM, Andrea Aime wrote:
> Justin Deoliveira ha scritto: > >> Great idea, I am definitely interested. A workflow I could see working >> well would be two teams. A non dev team that actually does most of the >> jira mangling, doing the actual clean up in the tracker. And then a dev >> team who basically just works through a ticket queue. >> >> If we do plan to actually do a lot of bug fixing then I think three days >> sounds appropriate. >> > Ha ha, it seems we are thinking three different things :-) > > Chris wit his "50-100 jira checks per hour" (1 checks per minute, wow) > is probably thinking about doing a fast scan of the issues and close > those that you already know have been solved by just very quickly > scanning the contents (and also mark somehow the ones that you're > sure haven't been closed). And just skip anything that you're doubtful > about. > This mode is effective but can be used only by a developer that knows > very well GS and its history. > > I was thinking more of 3-5 checks per hour instead, but then again > I was thinking about jiras where you actually have to try and > reproduce the problem to see if it's still there: it's the mode you > have to get into when you just don't know if the problem is still > there or not. > This mode can be tackled by anyone. > > Then there are the incomplete reports. For those we just have to > ask for more details, and if they don't come, we close the report > the week after as "invalid" or "cannot reproduce". > This is tricky, judging whether there is enough information is > hard, there might be enough for a developer but not enough for a user > trying to reproduce. > > The actual bug fixing, I was not planning to do. Even with the easy > ones I don't think one can close much more than 8-10 a day (at least, > that's how much I close in my best bug fixing day, and of course > avoiding hard to fix issues that can take two days per fix). > Looking at the history of the last 300 days: > http://jira.codehaus.org/secure/ConfigureReport.jspa?projectOrFilterId=project-10311&periodName=daily&daysprevious=300&cumulative=false&versionLabels=none&selectedProjectId=10311&reportKey=com.atlassian.jira.plugin.system.reports%3Acreatedvsresolved-report&Next=Next > one can see that we never had a day in which more than 18 issues > were fixed, those days are few and far apart, and involved the > effort of multiple developers. Here is the 18 fixes in a day one > for example: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+GEOS+AND+resolutiondate+%3E%3D+2009-04-15+AND+resolutiondate+%3C%3D+%222009-04-15+23%3A59%22+ORDER+BY+assignee+ASC%2C+key+DESC > > Soo, to sum up, what about we do the sprint so that: > - the first half a day it's developers going thru the existing > issues real fast and close the obvious ones, and mark the > know to be still open ones > - then everybody jumps in and we check the others that > we're not sure about? > > I guess it would be nice to have a shared spreadsheet to keep > track of who's doing what and how the state of each jira changed > (it would make for nice statistics at the end too, so that > we can summarize the results of the work). > Something like etherpad, but with a grid :) > If we cannot find one, a shared etherpad will do as well. > > Cheers > Andrea that take more than a minute to investigate. As for the shared spreadsheet, Google Docs spreadsheets can be collaboratively edited[1], and they can import an Excel spreadsheet (which Confluence could generate for us.) -- David Winslow OpenGeo - http://opengeo.org/ [1] http://www.youtube.com/watch?v=KpcgRlXe40k ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@... https://lists.sourceforge.net/lists/listinfo/geoserver-devel |
| Free embeddable forum powered by Nabble | Forum Help |
