You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/08/13 13:00:37 UTC
Using Jira and branches for Project Management
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?
Ross
Re: Using Jira and branches for Project Management
Posted by Ferdinand Soethe <fe...@apache.org>.
Tim Williams wrote:
> 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].
I have my doubts also.
> 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.
+1
> 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.
+1
> 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.
+1
How about some simple xml-schema to support maintaining that
documentation and a transformer to display that in various ways ...
> 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)
Well this seems a bit different from the approach taken in the past,
but I'd welcome it nevertheless.
--
Ferdinand Soethe
Re: Using Jira and branches for Project Management
Posted by David Crossley <cr...@apache.org>.
Tim Williams wrote:
> Ross Gardler wrote:
> > Tim Williams wrote:
> > >
> > > 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).
Yes we would need to continually review titles and
categorisation and descriptions.
> 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.
Cocoon use Bugzilla to create a roadmap and release schedule
by defining tasks and dependencies. Not sure if they still
actively do this.
http://wiki.apache.org/cocoon/ProjectManagement
> 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 made a change the other day so that our "Bugs and Issues"
navigation link goes via a local page, rather than directly
to Jira. That will let us explain how to use it and point
to some specific summaries. Not yet publshed, i will do that
later today.
-David
Re: Using Jira and branches for Project Management
Posted by Tim Williams <wi...@gmail.com>.
On 8/14/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > On 8/13/05, Ross Gardler <rg...@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
Re: Using Jira and branches for Project Management
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>Jira has powerful filtering facilities, email notification (although it
>>seems to be broken right now), ...
>
>
> I have it working with an experimental filter to
> notify me about any open issues with attachments.
>
> Are you not able to do personal notifications,
> or are you having trouble sending to dev@forrest?
I've been doing the same. at one point I was getting mails from my
filters, but they have stopped arriving. I'm sending them to my personal
address right now, the intention is to have a weekly summary going to
dev@forrest.
I'll have to take another look at why my mails have stopped if yours
still work.
Ross
Re: Using Jira and branches for Project Management
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
>
> Jira has powerful filtering facilities, email notification (although it
> seems to be broken right now), ...
I have it working with an experimental filter to
notify me about any open issues with attachments.
Are you not able to do personal notifications,
or are you having trouble sending to dev@forrest?
-David
Re: Using Jira and branches for Project Management
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Tim Williams wrote:
>
> >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)
We can always revise the list of features, to associate
some with a future release, thereby enabling a timely
release (see below).
Having the aims documented somehow, is definitely necessary.
> 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.
I disagree. We do not need the count of outstanding issues
to be zero. We can make a release with known issues.
We have always said we want to release early and often.
Unfortunately that hasn't happened, which causes the
need for a release.
We seem to have decided to make a release because
it is past time, then use one of our major milestones
to give a focus. We would reassess the list of issues,
delay some, then address any major outstanding issues,
then do the release.
> 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.
Yes, the use that we have made of Jira is okay
but there is much more that we could do.
> >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" ...
You are on target. I reckon that a blend of documentation
and issue tracker is required.
-David
Re: Using Jira and branches for Project Management
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Gav.... wrote:
> >
> >As well as this (Jira) atlassian.com has another fine looking product
> >http://www.atlassian.com/software/confluence/default.jsp
>
> My problem with both Jira and Confluence is that they are not Open
> Source. I would much rather see us using Open Source solutions. However,
> this is an Apachewide thing so I'm not about to start making such noises
> (too loudly).
>
> We have Jira, but we need not start using Confluence as well. I'd rather
> see us working on the projectInfo plugin to create the same kind of
> integration within Forrest produced document sets (using Daisy or Lenya
> as the CMS). This way we can do what we want rather than what they think
> we want.
>
> Speaking personally, I know I will put time into enhancing projectInfo
> but I will put no time into setting up and maintaining none Open Source
> products here at Forrest.
>
> Of course, if someone else does the set-up I will *use* whatever is there.
Gavin, please also see the recent dev@ discussion
about "wiki". The same would apply to "Confluence".
-David
Re: Using Jira and branches for Project Management
Posted by Ross Gardler <rg...@apache.org>.
Gav.... wrote:
> ----- Original Message -----
> From: "Gav...." <br...@brightontown.com.au>
> To: <de...@forrest.apache.org>
> Sent: Monday, August 15, 2005 11:38 PM
> Subject: Re: Using Jira and branches for Project Management
>
>
> |
> | ----- Original Message -----
> | From: "David Crossley" <cr...@apache.org>
> |
> || I also see a "Create Sub-task" on the left-hand menu, but
> || i don't know how to use it. Perhaps see Jira Help.
> |
> | Well, it does look very useful and in line with some of what has been
> | discussed.
> |
> | http://www.atlassian.com/software/jira/docs/v3.2/subtasks.html
> |
>
>
> As well as this (Jira) atlassian.com has another fine looking product
> http://www.atlassian.com/software/confluence/default.jsp
My problem with both Jira and Confluence is that they are not Open
Source. I would much rather see us using Open Source solutions. However,
this is an Apachewide thing so I'm not about to start making such noises
(too loudly).
We have Jira, but we need not start using Confluence as well. I'd rather
see us working on the projectInfo plugin to create the same kind of
integration within Forrest produced document sets (using Daisy or Lenya
as the CMS). This way we can do what we want rather than what they think
we want.
Speaking personally, I know I will put time into enhancing projectInfo
but I will put no time into setting up and maintaining none Open Source
products here at Forrest.
Of course, if someone else does the set-up I will *use* whatever is there.
Ross
Re: Using Jira and branches for Project Management
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Gav...." <br...@brightontown.com.au>
To: <de...@forrest.apache.org>
Sent: Monday, August 15, 2005 11:38 PM
Subject: Re: Using Jira and branches for Project Management
|
| ----- Original Message -----
| From: "David Crossley" <cr...@apache.org>
|
|| I also see a "Create Sub-task" on the left-hand menu, but
|| i don't know how to use it. Perhaps see Jira Help.
|
| Well, it does look very useful and in line with some of what has been
| discussed.
|
| http://www.atlassian.com/software/jira/docs/v3.2/subtasks.html
|
As well as this (Jira) atlassian.com has another fine looking product
http://www.atlassian.com/software/confluence/default.jsp
Confluence looks Wiki-like but seems to have so much going for it,
none more important than being able to integrate well with Jira.
http://www.atlassian.com/software/confluence/features/integration.jsp
I have downloaded Jira Enterprise and Confluence under Evaluation
license terms and will set it all up on my web server so you lot can
look at it and see what you think. Eval is 30 days so I better get
cracking.
If, after looking at confluence from the links above, you decide Forrest
does not need it then please let me know. (But I'll play anyway!)
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.10/73 - Release Date: 15/08/2005
Re: Using Jira and branches for Project Management
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "David Crossley" <cr...@apache.org>
| I also see a "Create Sub-task" on the left-hand menu, but
| i don't know how to use it. Perhaps see Jira Help.
Well, it does look very useful and in line with some of what has been
discussed.
http://www.atlassian.com/software/jira/docs/v3.2/subtasks.html
Specifically :-
Sub-task issues are usually used to split up a parent issue into a number of
tasks which can be assigned and tracked separately. Splitting issues into
smaller tasks often provides a better picture of the progress on the issue
and allows each party that needs to be involved in resolving the issue to
better understand what part of the process they are responsible for.
Sub-tasks have all the properties of regular issues such as summary,
reporter, assignee, fix versions, etc. Their "issue type" must be one of the
sub-task issue types rather than one of the regular issue types.
but the above URL explains it really well.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/2005
Re: Using Jira and branches for Project Management
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
> From: "Ross Gardler" <rg...@apache.org>
>
> |
> | 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?
>
> Will positive votes then help to (inadvertantly or not) prioritise an issue,
> will issues that receive null votes get put on the low-priority list ?
>
> | 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.
>
> There is the facility to create sub-tasks for an issue, is this what you
> mean?
Issues can be "linked" in various ways. So a parent issue
could be described, then others linked to it as dependencies.
I also see a "Create Sub-task" on the left-hand menu, but
i don't know how to use it. Perhaps see Jira Help.
> If not I think sub-tasking is worth looking into as it will lessen the
> amount of
> individual issues and related issues/tasks can all be grouped together.
> Having
> not seen a sub-task in action I can not see if sub-tasks can be individually
> assigned as well as the parent issues.
>
> | 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.
>
> Does this include everyone? Having not been here that long I was
> 'assuming' that only PMC and Commiters were to use that
> facility to either assign to themselves or to others. If I knew (being
> neither PMC nor Commiter) I could assign to myself I would
> have done so by now.
I think that "assigning" means something different.
When there is a patch attached to an issue, then a
committer will choose to apply the patch. They assign
the issue to themself to signify that other committers
should not also work on it. They apply the patch, then
set the issue to be "Unassigned" so that anyone else
can take over. This avoids duplication of effort.
I see that various committers have assigned issues
but they don't seem to be actively working on those.
It seems that only one person at a time can be assigned.
Perhaps we can find some additional way to declare that people
are doing long-term work on something. For example, we know from
the mailing list that Ron is working on the memory profiling
issue FOR-572. That should not stop others from working on it
but they should co-ordinate on the mailing list with Ron.
Perhaps using a "Comment" to say what we are doing and keep
reporting the status if it goes on for a long time.
Yes Gavin, only committers can delete, assign, link, etc.
-David
Re: Using Jira and branches for Project Management
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "Ross Gardler" <rg...@apache.org>
|
| 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?
Will positive votes then help to (inadvertantly or not) prioritise an issue,
will issues that receive null votes get put on the low-priority list ?
| 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.
There is the facility to create sub-tasks for an issue, is this what you
mean?
If not I think sub-tasking is worth looking into as it will lessen the
amount of
individual issues and related issues/tasks can all be grouped together.
Having
not seen a sub-task in action I can not see if sub-tasks can be individually
assigned as well as the parent issues.
| 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.
Does this include everyone? Having not been here that long I was
'assuming' that only PMC and Commiters were to use that
facility to either assign to themselves or to others. If I knew (being
neither PMC nor Commiter) I could assign to myself I would
have done so by now.
| 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
I agree, Jira is not being used to its ful potential.
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/2005
Re: Using Jira and branches for Project Management
Posted by Ferdinand Soethe <fe...@apache.org>.
Ross Gardler wrote:
> We need to be wary of that as individual devs needs change.
Perhaps we as a group should be just as wary of leaving certain issues
up to individual devs needs.
I thinks Forrest as a project would benefit a lot if we could have a
roadmap and agree on certain core issues that _will_ be in the next
release. Once that is agreed, solving these issues would be everybody's
job just as making the release is.
And if indeed nobody has the time, perhaps we need to postpone the
release.
> 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.
Sounds interesting ...
> 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.
Unfortunately true.
> 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)
> I would think it is the way we are using Jira that is the problem, not
> Jira itself.
You might be right. Time for me to do more work in Jira. Another great
topic for ApacheCon (how to use Jira for your project)
> 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)
No, I think the tree is right. Although we have a different proverb
for that (which I don't remember).
--
Ferdinand Soethe
Re: Using Jira and branches for Project Management
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 8/13/05, Ross Gardler <rg...@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
Re: Using Jira and branches for Project Management
Posted by Tim Williams <wi...@gmail.com>.
On 8/13/05, Ross Gardler <rg...@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
Re: stronger dev base before attract more users
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 8/16/05, David Crossley <cr...@apache.org> wrote:
>
>>Diwaker Gupta wrote:
>>
>>>Talking about users, what do people think of doing a survey of Forrest users.
>>
>>What would be the purpose of this survey?
>>
>>
>>>During the time that I've hung around the lists, I've noticed that often
>>>times people start in the user-list, then slowly migrate to the dev-list and
>>>some eventually end up as devs, which is just *great*.
>>>
>>>However, I do think that we need to put in some more efforts to publicize
>>>Forrest, make it more visible. Having an overlap between users and dev is not
>>>only good, but IMHO necessary, but we still need to expand our user base.
>>
>>We need to be a little careful about this. At the moment
>>we do not have sufficient developers to support a rush
>>of new users. That will take time away from doing development.
>>
>>I prefer to not publicize too widely at this stage,
>>rather let the base grow by itself.
>>
>>When we are ready to make a fanfare, then the ASF Public
>>Relations Committee will help us to do that properly.
>
>
> +1, I personally think we should have a 1.0 release before
> concentrating on promoting it.
+1
Ross
Re: stronger dev base before attract more users
Posted by Tim Williams <wi...@gmail.com>.
On 8/16/05, David Crossley <cr...@apache.org> wrote:
> Diwaker Gupta wrote:
> >
> > Talking about users, what do people think of doing a survey of Forrest users.
>
> What would be the purpose of this survey?
>
> > During the time that I've hung around the lists, I've noticed that often
> > times people start in the user-list, then slowly migrate to the dev-list and
> > some eventually end up as devs, which is just *great*.
> >
> > However, I do think that we need to put in some more efforts to publicize
> > Forrest, make it more visible. Having an overlap between users and dev is not
> > only good, but IMHO necessary, but we still need to expand our user base.
>
> We need to be a little careful about this. At the moment
> we do not have sufficient developers to support a rush
> of new users. That will take time away from doing development.
>
> I prefer to not publicize too widely at this stage,
> rather let the base grow by itself.
>
> When we are ready to make a fanfare, then the ASF Public
> Relations Committee will help us to do that properly.
+1, I personally think we should have a 1.0 release before
concentrating on promoting it.
--tim
stronger dev base before attract more users
Posted by David Crossley <cr...@apache.org>.
Diwaker Gupta wrote:
>
> Talking about users, what do people think of doing a survey of Forrest users.
What would be the purpose of this survey?
> During the time that I've hung around the lists, I've noticed that often
> times people start in the user-list, then slowly migrate to the dev-list and
> some eventually end up as devs, which is just *great*.
>
> However, I do think that we need to put in some more efforts to publicize
> Forrest, make it more visible. Having an overlap between users and dev is not
> only good, but IMHO necessary, but we still need to expand our user base.
We need to be a little careful about this. At the moment
we do not have sufficient developers to support a rush
of new users. That will take time away from doing development.
I prefer to not publicize too widely at this stage,
rather let the base grow by itself.
When we are ready to make a fanfare, then the ASF Public
Relations Committee will help us to do that properly.
-David
Re: Release early, release often(Re: Using Jira and branches for
Project Management)
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 8/16/05, Ross Gardler <rg...@apache.org> wrote:
>
>>David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>
>>>>Diwaker Gupta wrote:
>>>>
>>>>
>>>>
>>>>>IMHO, we do not practice "release early, release often", often enough :)
>>>
>>>[ snip ]
>>>
>>>
>>>
>>>>I think we are all in agreement with this. So lets plan a 0.8 milestone
>>>>1 release. On one of the major features in 0.8 will be Locationmaps.
>>>
>>>
>>>What is meant by a "milestone" release, and why not just call
>>>it 0.8 final? Then get on with 0.9 which will be forrest:views.
>>>I do not see the need for this M1 and M2 stuff.
>>
>>That is fine by me as long as it doesn't upset the forrest:views people.
>>I don't want to give the impression that I'm proposing pushing
>>forrest:views back.
>>
>>Mind you since locationmap was originally committed during the 0.5
>>development cycle it's release is overdue a little more than
>>forrest:views ;-)
>>
>>Are others OK with doing a 0.8 with the locationmap and doing a 0.9 with
>>forrest:views?
>
>
> I gather this is a departure from the suggestion the other day that a
> release is cooked when 0 or few issues left in JIRA?
Well I was a little unclear about this statement. David partially
clarified what I intended to say. The truth is we sometimes reduce the
count to 0 by reassigning issues to later releases.
I think the point is that at present we do not classify our issues well.
We tend to lump them into a fix version without considering their impact
on the overall strategy of Forrest development.
We also don't give enough priority to bugs in existing functionality,
you can see this in the fact that my suggested milestones don't mention
bugs that should be fixed for 0.8 (this needs addressing)
> I'm not sure
> what features should qualify for a new release but locationmap seems
> to be widely useful or visible so I'm not sure that it rates the
> distinction of a "key feature" driving the release. I don't have a
> problem with it, just think this is a lot like having a release for
> code refactoring -- (i.e., not much for a user to get excited about).
Actually, I disagree. The locationmap enables a whole range of
functionality that was not possible before. It is not just the ability
to improve our xmap structure. We can now retrieve content from multiple
sources. We no longer limit the client URL space to the document
structure defined within Forrest and we can now create multiple sites
structures from the same content sources.
I do see it as a fundamental improvement in functionality. It might be I
am the only one with these use cases, but I have proposed a number of
talks at ApacheCon that I could not have done without Locationmap. I
believe there is a wider use base or this functionality.
Ross
Ross
Re: Release early, release often(Re: Using Jira and branches for Project Management)
Posted by Tim Williams <wi...@gmail.com>.
On 8/16/05, Ross Gardler <rg...@apache.org> wrote:
> David Crossley wrote:
> > Ross Gardler wrote:
> >
> >>Diwaker Gupta wrote:
> >>
> >>
> >>>IMHO, we do not practice "release early, release often", often enough :)
> >
> > [ snip ]
> >
> >
> >>I think we are all in agreement with this. So lets plan a 0.8 milestone
> >>1 release. On one of the major features in 0.8 will be Locationmaps.
> >
> >
> > What is meant by a "milestone" release, and why not just call
> > it 0.8 final? Then get on with 0.9 which will be forrest:views.
> > I do not see the need for this M1 and M2 stuff.
>
> That is fine by me as long as it doesn't upset the forrest:views people.
> I don't want to give the impression that I'm proposing pushing
> forrest:views back.
>
> Mind you since locationmap was originally committed during the 0.5
> development cycle it's release is overdue a little more than
> forrest:views ;-)
>
> Are others OK with doing a 0.8 with the locationmap and doing a 0.9 with
> forrest:views?
I gather this is a departure from the suggestion the other day that a
release is cooked when 0 or few issues left in JIRA? I'm not sure
what features should qualify for a new release but locationmap seems
to be widely useful or visible so I'm not sure that it rates the
distinction of a "key feature" driving the release. I don't have a
problem with it, just think this is a lot like having a release for
code refactoring -- (i.e., not much for a user to get excited about).
--tim
Re: Release early, release often(Re: Using Jira and branches for
Project Management)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ross Gardler wrote:
>
>>Diwaker Gupta wrote:
>>
>>
>>>IMHO, we do not practice "release early, release often", often enough :)
>
> [ snip ]
>
>
>>I think we are all in agreement with this. So lets plan a 0.8 milestone
>>1 release. On one of the major features in 0.8 will be Locationmaps.
>
>
> What is meant by a "milestone" release, and why not just call
> it 0.8 final? Then get on with 0.9 which will be forrest:views.
> I do not see the need for this M1 and M2 stuff.
That is fine by me as long as it doesn't upset the forrest:views people.
I don't want to give the impression that I'm proposing pushing
forrest:views back.
Mind you since locationmap was originally committed during the 0.5
development cycle it's release is overdue a little more than
forrest:views ;-)
Are others OK with doing a 0.8 with the locationmap and doing a 0.9 with
forrest:views?
Ross
Ross
Re: Release early, release often(Re: Using Jira and branches for Project Management)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Diwaker Gupta wrote:
>
> >IMHO, we do not practice "release early, release often", often enough :)
[ snip ]
> I think we are all in agreement with this. So lets plan a 0.8 milestone
> 1 release. On one of the major features in 0.8 will be Locationmaps.
What is meant by a "milestone" release, and why not just call
it 0.8 final? Then get on with 0.9 which will be forrest:views.
I do not see the need for this M1 and M2 stuff.
-David
Re: Release early, release often(Re: Using Jira and branches for
Project Management)
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Diwaker Gupta wrote:
>
> ...
>
>> IMHO, we do not practice "release early, release often", often enough
>> :) This has been mentioned on the list before (see [1], [2]), however
>> I don't think it has actually seeped into our development just as yet.
>>
>> [1] http://article.gmane.org/gmane.text.xml.forrest.devel/14805/
>> [2] http://article.gmane.org/gmane.text.xml.forrest.devel/11665/
>>
>> Take a look at our release durations:
>> o 0.2 -> 0.3 : 2 months
>> o 0.3 -> 0.4 : 1 month
>> o 0.4 -> 0.5 : 7 months
>> o 0.5 -> 0.6 : 1 YEAR
>> o 0.6 -> 0.7 : 8 months
>> o 0.7 -> 0.8 : 2 months and counting...
>>
>> I just think that releasing as soon as we have some set of self
>> contained features in is a good idea. It gives confidence to the users
>> that all is well -- I mean what the end user usually sees are "releases".
>
>
>
> I think we are all in agreement with this. So lets plan a 0.8 milestone
> 1 release. On one of the major features in 0.8 will be Locationmaps.
> These are working now and Tim just enabled locationmap mounting which
> allows us to use them within Forrest itself. We also have the new seed
> system which is pretty significant (although Thorsten needs to resolve
> the vote he called). I propose the following tasks for the 0.8M1 release:
>
> - Provide a Forrest locationmap to simplify the existing forrest sitemaps.
>
> - Provide better documentation for the locationmap
> - locationmap in seed
>
> - Finalise and document the new seed system
>
> - Solve the performance issues that have resulted form the Cocoon upgrade.
>
> Lets be careful about adding more stuff into this early release, that
> will only serve to delay the release too much.
>
> ----
>
> We can then start looking at 0.8M2 which should focus on forrest:views.
> Thosten already spent some time prioritising stuff we discussed at
> ApacheCon so we are well on our way to identifying the reqruiements for
> 0.8M2
>
> ----
>
> I'll start setting up Jira with these goals and assign sub tasks as per
> our discussion on using Jira (unless there are objections of course,
> I'll track this thread to keep things in line in Jira).
I best clarify this, I mean link issues appropriately, I do *not* mean I
intend to assign tasks to people - I hope that was obvious ;-)
Ross
Release early, release often(Re: Using Jira and branches for Project
Management)
Posted by Ross Gardler <rg...@apache.org>.
Diwaker Gupta wrote:
...
> IMHO, we do not practice "release early, release often", often enough :) This
> has been mentioned on the list before (see [1], [2]), however I don't think
> it has actually seeped into our development just as yet.
>
> [1] http://article.gmane.org/gmane.text.xml.forrest.devel/14805/
> [2] http://article.gmane.org/gmane.text.xml.forrest.devel/11665/
>
> Take a look at our release durations:
> o 0.2 -> 0.3 : 2 months
> o 0.3 -> 0.4 : 1 month
> o 0.4 -> 0.5 : 7 months
> o 0.5 -> 0.6 : 1 YEAR
> o 0.6 -> 0.7 : 8 months
> o 0.7 -> 0.8 : 2 months and counting...
>
> I just think that releasing as soon as we have some set of self contained
> features in is a good idea. It gives confidence to the users that all is well
> -- I mean what the end user usually sees are "releases".
I think we are all in agreement with this. So lets plan a 0.8 milestone
1 release. On one of the major features in 0.8 will be Locationmaps.
These are working now and Tim just enabled locationmap mounting which
allows us to use them within Forrest itself. We also have the new seed
system which is pretty significant (although Thorsten needs to resolve
the vote he called). I propose the following tasks for the 0.8M1 release:
- Provide a Forrest locationmap to simplify the existing forrest sitemaps.
- Provide better documentation for the locationmap
- locationmap in seed
- Finalise and document the new seed system
- Solve the performance issues that have resulted form the Cocoon upgrade.
Lets be careful about adding more stuff into this early release, that
will only serve to delay the release too much.
----
We can then start looking at 0.8M2 which should focus on forrest:views.
Thosten already spent some time prioritising stuff we discussed at
ApacheCon so we are well on our way to identifying the reqruiements for
0.8M2
----
I'll start setting up Jira with these goals and assign sub tasks as per
our discussion on using Jira (unless there are objections of course,
I'll track this thread to keep things in line in Jira). It would be
really nice if we had some documentation come out of that thread in time
for a 0.8M1 release as well.
Ross
Re: Using Jira and branches for Project Management
Posted by Diwaker Gupta <di...@apache.org>.
Thanks for a wonderful roundup of issues, Ross.
On Saturday 13 August 2005 4:00 am, Ross Gardler 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.
I agree. Even the mailing list is overwhelming these days, let alone JIRA.
> 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?
I think voting on issues is a good idea. It will give us a feel of what users
and developers want and can be a good starting point for a roadmap document.
<off-topic>
IMHO, we do not practice "release early, release often", often enough :) This
has been mentioned on the list before (see [1], [2]), however I don't think
it has actually seeped into our development just as yet.
[1] http://article.gmane.org/gmane.text.xml.forrest.devel/14805/
[2] http://article.gmane.org/gmane.text.xml.forrest.devel/11665/
Take a look at our release durations:
o 0.2 -> 0.3 : 2 months
o 0.3 -> 0.4 : 1 month
o 0.4 -> 0.5 : 7 months
o 0.5 -> 0.6 : 1 YEAR
o 0.6 -> 0.7 : 8 months
o 0.7 -> 0.8 : 2 months and counting...
I just think that releasing as soon as we have some set of self contained
features in is a good idea. It gives confidence to the users that all is well
-- I mean what the end user usually sees are "releases".
Talking about users, what do people think of doing a survey of Forrest users.
During the time that I've hung around the lists, I've noticed that often
times people start in the user-list, then slowly migrate to the dev-list and
some eventually end up as devs, which is just *great*.
However, I do think that we need to put in some more efforts to publicize
Forrest, make it more visible. Having an overlap between users and dev is not
only good, but IMHO necessary, but we still need to expand our user base.
</off-topic>
Diwaker
--
Web/Blog/Gallery: http://floatingsun.net