forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Using Jira and branches for Project Management
Date Sun, 14 Aug 2005 20:55:50 GMT
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)

Ross

Mime
View raw message