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 [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
