forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Using Jira and branches for Project Management
Date Sun, 14 Aug 2005 19:24:17 GMT
On 8/13/05, Ross Gardler <rgardler@apache.org> wrote:
> We are getting larger as a developer base. As a consequence there is an
> increasing tendencies for small numbers of devs to work on different
> sections of the code base. As a result we are becoming a little
> disorganised - one virtual team not knowing what the other is doing.
> 
> It is impossible to keep up with all the discussions on list and
> understand exactly what needs to be done/discussed to complete a job.
> 
> With the natural come and go of developers as other commitments keep
> them away from Forrest for a while we end up with partially complete
> functionality.
> 
> Recently we had a discussion about using branches witin our development
> to ensure only complete functionlaity is in Trunk. This, ultimately,
> seems like a great idea and we need to action it, see [1] and the
> subsequent discussion in [2].
> 
> [1] http://marc.theaimsgroup.com/?l=forrest-dev&m=111968323717620&w=2
> [2] http://marc.theaimsgroup.com/?l=forrest-dev&m=111970514323568&w=2
> 
> (we need to document this thread as part of our project participation
> guidelines)
>
> In addition to this it is important that we keep track of what is going
> on in terms of strategy. There are so many great ideas here in Forrest
> that we simply can't implement them all.
> 
> Jira is the tool for keeping track of this stuff so that we can track
> and prioritise things. However I'm not too sure what the best way of
> utilising this resource is. DOes anyone have an experiences to share?

These aren't so much "experiences" as they are just thought.

If you're talking about "strategy" then I don't think JIRA is the
right tool for the job.  Ideally I suppose one might use the "version"
filter to get an idea of what each version will contain, but frankly,
as one who looks at our JIRA quite often, I am overwhelmed by it and
am unable to see the forrest;) for the trees [or issues].

The page, http://forrest.apache.org/forrest-issues.html doesn't help
me either. I think what we need is a separate "Roadmap" document.  Not
to duplicate JIRA stuff but to provide them in a higher,
"feature"-level view rather than the granular, issue-level view that
we currently have.  I think this could help us in a few ways:
1) It would allow devs to "know" what other devs are working -- not to
hold them accountable, just so that we know if someone has actually
picked up the ball and ran with certain features.  For example, I
didn't follow it that closely but the "interactive Forrest" menu was
discussed but we've don't really know (or i don't) if someone has
taken it up or not.

2) It would provide our users with a good idea of where we're heading.
This allows them to make better decisions on whether to use Forrest or
now (e.g., oh, i can see they're planning on getting this
functionality that I need in the next version, great).  And it allows
them to provide input if there's a feature that they really need.

3) It would give us a standard way of documenting some of the
"strategic" discussions that happen on the list. Then after each
release we could have a couple threads that revise the roadmap as
needed for the next release based on itches at the time.

4) It would answer a question I've been having lately -- how do we
know when 0.8, 0.9, etc. is "done" and ready for release?  Having a
feature list would allow us to check off sets of features, thus
knowing that we're ready for release when all of the issues associated
with the features are resolved.  (i suppose there's an implicit or
explicity mapping between features and jira issues)

I guess, I just think JIRA is not well suited for allowing people to
get their mind around the big picture of where we might be heading. 
We give them the little pieces in JIRA and they have to kind of piece
it together on their own.  In order to ensure we don't duplicate any
JIRA stuff, such a Roadmap document would essentially be bulleted
feature list stuff rather than specific low-level enhancements, almost
a "marketing-style" spin on things instead of techy issues.

--tim

Mime
View raw message