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 21:29:38 GMT
On 8/14/05, Ross Gardler <rgardler@apache.org> wrote:
> Tim Williams wrote:
> > On 8/13/05, Ross Gardler <rgardler@apache.org> wrote:
> >
> 
> ...
> 
> >>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].
> 
> It is this overwhelmed feeling that I refer to. Jira is no use at
> present because there are just too many unorganised issues. Just dumped
> into rough version groups.
> 
> Jira has powerful filtering facilities, email notification (although it
> seems to be broken right now), XML feeds and the like. We should utilise
> it to keep track of what we *should* be doing. For example, would it be
> useful to encourage users and devs to vote for issues?
> 
> > The page, http://forrest.apache.org/forrest-issues.html doesn't help
> > me either.
> 
> Because it is generated from Jira and so suffers the same problem - it
> *should* be useful.
> 
> > I think what we need is a separate "Roadmap" document.
> 
> Jira can be used to manage that roadmap for us. However, David and I
> talked about "Roadmaps" at ApacheCon. We felt that the term Roadmap
> implies we *will* implement things in a given order. We need to be wary
> of that as individual devs needs change.
> 
> Of course, there is a very strong argument for having a document that
> gives an idea of what will be in the next version. Jira should be used
> to create that last of issues.
> 
> I often use the 0.8-dev roadmap as my starting point in
> Jira:http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolutionIds=-1&pid=12310000&fixfor=12310040
> 
> The problem with this is that most issues are not well classified (in
> terms of priority) and there is no distinction between bugs,
> improvements, taks etc.
> 
> Would it help to create a number of filters that would give better
> "roadmap" documents from Jira
> 
> >  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 agree there is a need for such an organisation, but I would rather see
> us utilising Jira in order to facilitate its management.
> 
> Jira as powerful linking between issues. There is nothing to stop us
> creating a High level issue that links to the lower level implementation
> issues. We can then export all "high level" issue descriptions to create
> the "roadmap" document you describe. Jira will then help us create links
> between all the dependant buds, issues, tasks etc.
> 
> 
> >  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.
> 
> I agree to the benefit, but my approach would be different:
> 
> In Jira you assign the issue to yourself, this signals that you are
> working on it. I added the interactive forrest issue to the tracker
> precisely so that someone can do that.
> 
> Having an external "roadmap" document requires people to keep that up to
> date as well - unlikely ;-) It will be hard enough to get people to
> assign issues to themselves.
> 
> > 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.
> 
> Yes, I agree with this too. But again creating a document means we need
> to manage the document. I believe it would be better to use Jira the way
> it should be used nd generate this document from it - that is what
> http://forrest.apache.org/forrest-issues.html  was supposed to be.
> 
> > 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.
> 
> Again, why not use Jira for this recording? Discussions still happen on
> list, but conclusions are put in jira where issues can be linked, cross
> referenced and assignments can be tracked.
> 
> > 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)
> 
> 0.8 is done when the number of outstanding issues for 0.8 is 0. This is
> one thing we *have* been using Jira for. But the problem is we have, in
> the past, only turned our attention to Jira when we are getting a
> release ready. So it only makes sense in those last stages.
> 
> > 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.
> 
> I would think it is the way we are using Jira that is the problem, not
> Jira itself.
> 
> Do my comments above go any way of convincing people of this or am I
> "barking up the wrong tree" (is that an UK or a universal saying? it's
> about dogs chasing cats so I suppose it could be universal)

Yes, I guess this is a case of me not really "understanding" JIRA's
power.  Your reply here has caused me to look at JIRA in a new way.  I
always thought of it as just a simple bug-tracker but now that I took
another spin around it with your comments in mind, I see how it might
be possible to use it to manage exactly what I described above. 
Essentially using a filter for Version=0.8 AND
IssueType=NewFeature_OR_Improvement get's close to what I wanted
(though knowing this, we should strive for better titling and
grammar).  Then for specific more granular issues, just create
sub-tasks on the feature.    In other words, I think you're barking up
the right tree, it just took some time to click for me.  Of course,
while it automates the creation of the Roadmap I spoke of, it would
need another document (or an expansion of the issues one) to describe
how to properly use JIRA.

I'm not sure about universal, but it's a saying in the U.S. too;)
--tim

Mime
View raw message