[Geoserver-devel] Jira cleanup sprint?

Andrea_Aime3 · November 5, 2009, 12:07pm

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.

Lubomir_Varga · November 5, 2009, 12:16pm

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.

Chris_Holmes1 · November 5, 2009, 2:19pm

/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@anonymised.com>

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@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

David_Winslow · November 5, 2009, 3:20pm

I’d be in too.

Justin_Deoliveira · November 6, 2009, 12:42am

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.

Andrea_Aime3 · November 6, 2009, 9:28am

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+>%3D+2009-04-15+AND+resolutiondate+<%3D+"2009-04-15+23%3A59"+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.

David_Winslow · November 6, 2009, 3:44pm

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+>%3D+2009-04-15+AND+resolutiondate+<%3D+"2009-04-15+23%3A59"+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

I also think it would be better to have the sprint focus on the tickets 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