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

Reply via email to