Hi, FYI about planning, Francois's team developped a useful Jira plugin [1]. It provides a planning dashboard.
Here is a sample project to see it live: http://www.greenpeppersoftware.com/jira/browse/BANK It is free for open source projects. If you think it could be great for Maven and Codehaus, just ping me. Cheers, Vincent [1] http://www.greenpeppersoftware.com/confluence/display/GH/Plugin 2007/8/1, Jason van Zyl <[EMAIL PROTECTED]>: > All looks good, my only comments are I think the notions in Scrum > like Sprints for a release are good like the idea of fixing the set > of issues and sticking with it for the Sprint. Sensible patterns and > there's already literature on that. So in any parts you're talking > about planning I think it might be good to defer to Scrum. > > To sustain any sort of visibility amongst us I think it would be wise > for us to mandate the use of Mylyn. I don't use Eclipse but I use > Eclipse for Mylyn. For anyone using Eclipse it's a no brainer, but I > don't use Eclipse 100% of the time but I use it for Mylyn. It makes > being diligent about issue management a lot easier. It also helps vet > duplicates, and generally makes planning easier. At least I've found > it to be a great boon after using it for quite a while now. > > As far as the workflow, are you actually going to try and encapsulate > that workflow in a JIRA workflow itself? I think that might be a bit > masochistic but any workflow that is not strictly enforced in the > tool is going to be hard to adhere to. > > On 1 Aug 07, at 12:48 PM 1 Aug 07, Brett Porter wrote: > > > Hi, > > > > A while back I promised to write up what we are doing with jira > > versions now, and finally got around to it. In the process, I came > > up with a couple of tweaks we could make (see "actions"). Here it > > is in point form - does everyone agree this is the process we are > > following now? Missing anything? > > > > - [ ] versions: > > - [ ] 2.0.8 - the next release, currently being worked on for the > > 2.0.x branch > > - [ ] 2.0.x - issues that are likely to be fixed in the 2.0.x > > series, but not yet scheduled > > - [ ] 2.1-alpha-1 - the next release, currently being worked on > > for > > trunk > > - [ ] 2.1-alpha-2 - the release after next, and so on > > - [ ] 2.1 - issues to fix by the 2.1 final release > > - [ ] 2.1.x - issues to list as "known issues" in 2.1, and to be > > fixed in the releases after 2.1. > > - [ ] 2.2 - issues to fix in the 2.2 release (not yet broken down > > as it is a future release) > > - [ ] 2.x - issues to fix in later 2.x releases (not yet > > scheduled) > > - [ ] Backlog - issues that have not been reviewed for a version > > assignment (and may be duplicates, won't fix, > > unreproducible, > > etc.) > > - [ ] Unscheduled - new issues that haven't been reviewed yet > > - [ ] actions > > - [ ] rename 2.1.x to 2.1 > > - [ ] create 2.1.x after 2.1 > > - [ ] rename 2.2.x to 2.2 > > - [ ] create 2.x > > - [ ] take a knife to 2.1 (currently 2.1.x) which has 254 issues > > - [ ] rename "Reviewed Pending Version Assignment" to "Backlog" > > - [ ] move all documentation issues either to the site project > > (this should all be done by now), or to a scheduled version > > (or the backlog) > > - [ ] create a shared jira and move the shared component issues to > > that. > > - [ ] workflow > > - [ ] for a new issue in unscheduled > > - [ ] should attempt to review them quickly and regularly > > - [ ] first action is to attempt to resolve reasonably > > (duplicate, won't fix if it's inappropriate, or > > incomplete if there is not enough detail) > > - [ ] double check priority and other details like affects > > version and component and prompt for more information if > > needed > > - [ ] all issues should have an affects version(s) and > > component(s) > > - [ ] assign a version depending on whether it's a bug or a > > feature, and what it's severity is > > - [ ] unless it is a regression in the current code, it should > > not be assigned to the current version > > - [ ] for an issue in backlog > > - [ ] periodically review issues related to other ongoing work > > to attempt to close duplicates or assign to an > > appropriate version > > - [ ] for an issue in the current release that could be bumped > > - [ ] should not be done if it's a blocker or a regression > > - [ ] can be done en masse for remaining issues when a release > > is called based on an agreed date and nothing left in > > scheduled features/blockers/regressions list > > - [ ] can be done for individual issues earlier than that if > > time runs short or priority becomes reduced > > - [ ] planning for the next release > > - [ ] during the previous release or after it's complete, > > planning for the next one should occur > > - [ ] should reasonably prevent adding new issues to a release > > once it becomes the current one (unless the issue is a > > blocker or regression) > > - [ ] create a new version and pull back from the generic > > bucket (for 2.1-alpha-2, these are taken from 2.1, for > > 2.0.8 they are taken from 2.0.x, for 2.1's first cut > > they > > are taken from 2.x). > > - [ ] use votes, priorities and effort/relatedness to other > > issues to determine which issues to schedule > > - [ ] closing an issue > > - [ ] if the resolution is other than "fixed", the fix for > > should be unset to make the release notes more accurate > > - [ ] if set to fixed, the fix for version MUST be set > > - [ ] documentation issues > > - [ ] documentation is versioned, while the project site is > > not > > - [ ] the project site should have it's own jira project > > - [ ] documentation issues should be scheduled like any other > > component of the system > > - [ ] working on issues > > - [ ] always assign to self before starting to avoid conflict > > and give a heads up > > - [ ] setting the issue in progress is preferable, esp. for a > > long running task, once the work is actually under way. > > - [ ] attempt to keep issues small and completable with a > > commit rather than leaving open (particularly with a > > dangling assignment that you are no longer working on) > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
