Point well taken as that certainly could bubble up as a problem if one person was elevated above
other in the group.
John Sisson wrote:
Matt Hogstrom wrote:
John Sisson wrote:
Henri Yandell wrote:
On 6/2/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Having done two releases I have some
Having done two releases I have some thoughts on how we are using JIRA. I imagine that there are a
number of thoughts on how we can manage JIRA.
Currently we create a release and then pretty much dump most everything into it. What ends up
happening is that we end up with more JIRAs than we
On 6/2/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Having done two releases I have some thoughts on how we are using JIRA. I
imagine that there are a
number of thoughts on how we can manage JIRA.
I tend to do release management tasks too, so thought I'd offer thoughts.
Currently we create a
Have we considered using the voting system built into JIRA to figure
out which JIRAs should really get attention? Sometimes when I have a
few spare cycles I'll go looking for JIRAs to fix and this additional
metric would help me choose. It would also give us an additional way
to listen to the
Can we mark some of the older M* builds are archived? That will help make the "Raised In Versions (non-archived))" portlet more useful.I'm curious... has everyone setup their JIRA home/dashboard to show more details specific to Geronimo... if not, I'd recommend creating a new "Geronimo" portal
On 6/2/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
I'm not sure how to handle assignment of JIRAs as they generally fall into
someone's area of
expertise but I think the fact their assigned to someone might scare someone
away from looking at it
. Thoughts?
What I wish to happen is to
So... an observation from a non-committer. If there's a JIRA that a
non-committer would like to fix, can that non-committer be assigned the
JIRA? I ask because the prospect of diving into something, spending
several hours on it, and submitting a patch only to find out that in the
meantime,
On 6/2/06, Bryan Noll [EMAIL PROTECTED] wrote:
I guess the downside to assigning JIRA's to non-committers is that who
knows whether the person asking to have the JIRA assigned to him/her is
someone who will actually resolve it, or someone who thinks that they
would like to and then it doesn't
Here's what I'd like:
- a prioritized list of stuff I plan to work on for a release (where
the priorities are priorities on my list, not necessarily
corresponding to severity of problem, etc.)
- a list of bugs that *someone* ought to look at for a release
- features (and more rarely, bugs) that
Henri Yandell wrote:
On 6/2/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Having done two releases I have some thoughts on how we are using
JIRA. I imagine that there are a
number of thoughts on how we can manage JIRA.
I tend to do release management tasks too, so thought I'd offer thoughts.
John Sisson wrote:
Henri Yandell wrote:
On 6/2/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Having done two releases I have some thoughts on how we are using
JIRA. I imagine that there are a
number of thoughts on how we can manage JIRA.
I tend to do release management tasks too, so thought
Matt Hogstrom wrote:
John Sisson wrote:
Henri Yandell wrote:
On 6/2/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Having done two releases I have some thoughts on how we are using
JIRA. I imagine that there are a
number of thoughts on how we can manage JIRA.
I tend to do release management
- a list of bugs that *someone* ought to look at for a release
- features (and more rarely, bugs) that should be looked at, but not
in the current release
- features that people have asked for but are not possible in the
near term
If we got the JIRA label plugin (
13 matches
Mail list logo
