First of all excellent well thought out post Andrea.
I spent a good 20 mins with Jira trying to sort out
- a what was holding up the 2.0-RC2
- what people were working on
And was not very successful.
I think you hit the nail on the head about using critical to manage
what shows up and controls the release process.
I have used the text goals; combined with a blockers from jira to
manage geotools releases in the past; But I am not sure if it was
helpful to anyone other then me (http://docs.codehaus.org/display/GEOTOOLS/2.5.x
). You can see that for the current release I have not updated the
notes (http://docs.codehaus.org/display/GEOTOOLS/2.6.x). One thing I
would like to do is start managing technical debpt on individual pages
that can follow the current release page ...
Back on track - I am more interested in what is going on and who needs
help. One idea we have on the udig list is similar to the "what is up"
section of the geoserver IRC meetings. We send out an email (mostly
PSC members; but also anyone with an active project) covering the
usual "scrum" questions 1) what are you up to 2) tasks on your plate
3) impediments
Could we consider this in order to cover the "what is going on"
questions; as well as keeping a page of notes as you suggest.
On the same topic of communication there are a couple of pages that
people visit to see what is going on and tp ask for help:
- Roadmap
- Mailing Lists
I would like recommend Axios, CampToCamp, GeoSolutions, LISAsoft,
OpenGeo, Refractions, Where Group etc.. are visible as part of these
two pages. Chris helped me tidy up (well delete backstory from) the http://geoserver.org/display/GEOS/Roadmap+Ideas
page but it is pretty useless; as nobody will ever find it. In a
similar manner a single Support page could cover mailing lists and
commercial support. Indeed the commercial support page also has a lot
of backstory.
There is one other trick that udig has - we modified out bug tracker
to show two things:
- issues that have a patch attached
- issues that are incomplete or need to be verified be fore a
developer can work on them (or even look at them)
Finally we have a separation between "resolved" and "closed" that is
very helpful. We resolve an issue when the developer has made a fix;
and leave it in the resolved state (it is listed on a wiki page) for a
tester to close. You asked how to involve the user community in the
release process - and this is a technique we have used. Finally we do
use the "in progress" state which can be useful.
Jody
PS. I also want to say I respect Justin's call to duck out of playing
release cop - it is not a very reward roll; even if it has proven very
valuable.
On 16/09/2009, at 6:38 PM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
So unless someone else wants to take this on I don't plan to send any
more road map update emails, or work for any sort of structure into
the
short term road map. Which sort of leaves us in an undefined and
arbitrary state in terms of release dates. But I am sure the
community
will figure it out as it has in the past.
If you like I can try to take this on. But I also think I'd like to
see
it done differently.
Basing all the planning just on Jira feels like micro-managing things.
I don't see a problem with a developer putting a blocker in one
week before the release if he's also up to fixing the blocker in time,
and I don't really believe we can make people adjust all of the
priorities in jira to make it become a roadmapping tool.
It also feels odd that we have to push up to critical the issues
to communicate we actually want to do them by a certain release.
An issue might be minor by its nature but one might be finding it fun
and work on it on a boring hour in the weekend.
In general I'd prefer to see some goals set in text format instead,
somewhere in a wiki page. This plays a lot better with major releases
where there is a ton of jiras going on under a small number of
wider topics and gives us an idea of what is going on without the need
to turn each point 1-1 into a jira issue.
An example of what it could look like (made up):
------------------------------------------------------------------
The 1.7.7 release is focused on bug fixing and minor new features.
The features worked on are url mangling overhaul and map rotation.
Link to issues fixed so far: ...
Link to issues still scheduled: ...
The 2.0-rc2 release is focused on bringing stability to the
UI and catalog and improving the mapping abilities of the
complex feature support, plus eventual speedup needed to compete
in the FOSS4G benchmarking shootout.
Link to issues fixed so far: ...
Link to issues still scheduled: ...
The following major features are being worked on but did not
find an exact scheduling for a release:
- hibernate catalog, by Simone and Emanuele
- resource/publishing split
- restconfig graduation to core
- wps module
- ...
-----------------------------------------------------------------
Once a week we can post a summary of what happened with links
to all the jiras closed during the week (since we get no notification
about that), if any module moved location (graduations)
and a check about which jiras might be blocking an
incoming release.
Plus we invite people to improve the release
summary and to talk about what major new features are being
worked on for the future.
I think this would make the system more amenable to changes
and more interesting to whoever is reading the roadmap
page?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart
your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
