Re: how we handle JIRA versions

[Vincent Siveton <vi...@gmail.com>]

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 <ja...@maven.org>:
> 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org