Re: Thoughts on using JIRA more effectively
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 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 release and then pretty much dump most everything into it. What ends up happening is that we end up with more JIRAs than we have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done. At first I thought this was bad, but the existence of a 1.x version means that you can still keep the vision of the major release going without making it hard to do minor releases. Seems like a good idea to me. I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves. Probably a bit too far. The process here is going to depend on when you branch the release, so: *) pre-branch - general conversation about the important things in this release (and are thus assigned to 1.2 etc), people fixing things randomly and throwing in (and as they resolve they move to 1.2 - there should be no resolveds in 1.x). *) post-branch - nothing should move to 1.2 without lots of discussion. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. New issues are unversioned. Component leads look at the issue and then assign them to 1.x, wishlist, 2.x, verification required, wontfix (resolving) et al. I am concerned that having Component leads is against the ASF way. The last thing we want is for the community to feel there is a hierarchy and opening up the opportunity for people to claim they are the leader of component/team X. Everyone should be a peer. I agree with the idea that we are peers but I think people have natural areas of expertise that fall out. (Well, apart from Jencks who seems to be able to do anything :-) In general though I might change something related to a bug or a performance problem but know that if its Tx related I'll call on Jencks, or Console related give Aaron a heads up. I don't think having people that are knowledgable in a given area as a main contact is an issue. However, they also need to look at the needs of the project and help mentor folks as well. I agree that people have natural areas of expertise. I am just wary of seeing people marketed as the Leader of component/team X by their employers or in articles/books (and they have the JIRA screen to back it up without an explanation of what it really means). What if two people consider themselves experts in a component, AFAIK, JIRA can only have one lead for a component? Will one get upset at the other being chosen as the Lead? How is a lead selected and what is the length of their term. In a perfect world I wouldn't see any problems with this, but I can see some potential issues here. What do others think? John Maybe have a weekly report of unassigned issues so the release manager can nudge people. I always have an urge to have IRC triage sessions with decisions reported back to the mail list, interesting to hear what Ken thinks on that. The IRC triage sessions are a good idea - with the importance on results being posted on the dev list. Hopefully Jason will be able to get the IRC logs posted to the dev list, so no-one misses out on the detail. 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? If a JIRA is not marked as in-progress then people should be encouraged to ask the assignee whether they can take it off their hands. I am also wondering whether we should have Geronimo Bug Guidelines page (e.g. like http://db.apache.org/derby/DerbyBugGuidelines.html ) on the website off the JIRA link that discusses JIRA usage and may help prevent JIRA being used as a place to ask questions, with the link to JIRA on that page. Excellent idea John. I'd like to coalesce the thinking in this thread and put something like that together. Are you volunteering :) I would be happy to put together a page similar to Derby's for review, I'll created GERONIMO-2080 and assigned to myself. John I would define leads for each component and delegate to them as release manager to give me a status
Re: Thoughts on using JIRA more effectively
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 release and then pretty much dump most everything into it. What ends up happening is that we end up with more JIRAs than we have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done. At first I thought this was bad, but the existence of a 1.x version means that you can still keep the vision of the major release going without making it hard to do minor releases. Seems like a good idea to me. I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves. Probably a bit too far. The process here is going to depend on when you branch the release, so: *) pre-branch - general conversation about the important things in this release (and are thus assigned to 1.2 etc), people fixing things randomly and throwing in (and as they resolve they move to 1.2 - there should be no resolveds in 1.x). *) post-branch - nothing should move to 1.2 without lots of discussion. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. New issues are unversioned. Component leads look at the issue and then assign them to 1.x, wishlist, 2.x, verification required, wontfix (resolving) et al. Maybe have a weekly report of unassigned issues so the release manager can nudge people. I always have an urge to have IRC triage sessions with decisions reported back to the mail list, interesting to hear what Ken thinks on that. 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? I would define leads for each component and delegate to them as release manager to give me a status of where things are - however I would make the default assignee be unassigned to encourage community. Hen
Re: Thoughts on using JIRA more effectively
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 user community. Maybe a few weeks before a release an announcement could get sent to the user list inviting people to vote. Paul 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. 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 have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done. I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. 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? Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour I'm using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of 1.1. For those things we can work on in 1.2 they'll get moved there. This will make releasing a whole lot easier from a goat herding perspective. I am not an Administrator and don't play one on TV but this elephant has been in our living room too long :) Matt
Re: Thoughts on using JIRA more effectively
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 page and add project portlet for Geronimo, and probably a few project statistic portlets (like "Raised In Versions (non-archived))").I pinged infrastructure about possibly upgrading JIRA, the newer version has some good features that will help us. I'm also going to ask them if we can get the Toolkit plugin installed and configured, as this has some really helpful additions (like one that will color older outstanding issues different, and another that will show all of the folks that participated in the issue).--jasonOn Jun 2, 2006, at 9:52 AM, Matt Hogstrom 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.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 have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done.I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves.For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc.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?Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour I'm using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of 1.1. For those things we can work on in 1.2 they'll get moved there.This will make releasing a whole lot easier from a goat herding perspective.I am not an Administrator and don't play one on TV but this elephant has been in our living room too long :)Matt
Re: Thoughts on using JIRA more effectively
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 report new issues unassigned and then whoever wants to work on it assigns it to hirself. I think it always worked pretty well with some exceptions, and there were some talks about re-assigning when someone stepped on and meant to work on an issue that had already been assigned. I understand that it's much harder to newcomers to re-assign than just assign an issue, so I like your idea to *not* assign an issue upfront. Just leave it until someone finds to be able to tackle it. Matt Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Thoughts on using JIRA more effectively
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, another non-committer had been working on it and got their patch in does not sound very appealing to me. 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 happen. Thoughts? Jacek Laskowski wrote: 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 report new issues unassigned and then whoever wants to work on it assigns it to hirself. I think it always worked pretty well with some exceptions, and there were some talks about re-assigning when someone stepped on and meant to work on an issue that had already been assigned. I understand that it's much harder to newcomers to re-assign than just assign an issue, so I like your idea to *not* assign an issue upfront. Just leave it until someone finds to be able to tackle it. Matt Jacek
Re: Thoughts on using JIRA more effectively
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 happen. Thoughts? There're several non-committers with assigned issues to them so it's worked pretty well so for. Of course, there's some risk that a non-committer would leave an issue assigned without being able to spend some time working on it, but it hasn't happened yet. We trust our community and haven't introduced any procedures to work it out other than helping out and assiging the issue to one of us committers with a note it's worked on and after a period of a sustained contribution the non-committer is included in geronimo-noncommitters group to be able to assign issues to hirself. Just say hello and let us know you're looking into an issue and we'll take greater care to not re-assign it to us, committers. Comment the issue you're at that it's already occupied, too. Just for the record. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Thoughts on using JIRA more effectively
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 should be looked at, but not in the current release - features that people have asked for but are not possible in the near term - a screen showing issues with attached patches, perhaps by priority, perhaps by component I don't like a large bucket of issues with no version assigned. It's my feeling that this bucket quickly gets out of control and no one looks at those issues (in part, due to it's size, and in part, because they're not on anyone's radar). If I *do* look at such an issue, I want to put it somewhere, to indicate that it's been reviewed, and when I think it ought to be looked at. I'd definitely be in favor of allocating some time in the immediate post-1.1 time frame for reviewing and fixing the numerous bugs relating to NPEs or terrible error messages if deployment plans are slightly incorrect. It would be great to clean all those out so we could then focus on more important issues for 1.2, etc. Thanks, Aaron 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. 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 have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done. I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. 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? Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour I'm using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of 1.1. For those things we can work on in 1.2 they'll get moved there. This will make releasing a whole lot easier from a goat herding perspective. I am not an Administrator and don't play one on TV but this elephant has been in our living room too long :) Matt
Re: Thoughts on using JIRA more effectively
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. 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 have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done. At first I thought this was bad, but the existence of a 1.x version means that you can still keep the vision of the major release going without making it hard to do minor releases. Seems like a good idea to me. I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves. Probably a bit too far. The process here is going to depend on when you branch the release, so: *) pre-branch - general conversation about the important things in this release (and are thus assigned to 1.2 etc), people fixing things randomly and throwing in (and as they resolve they move to 1.2 - there should be no resolveds in 1.x). *) post-branch - nothing should move to 1.2 without lots of discussion. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. New issues are unversioned. Component leads look at the issue and then assign them to 1.x, wishlist, 2.x, verification required, wontfix (resolving) et al. I am concerned that having Component leads is against the ASF way. The last thing we want is for the community to feel there is a hierarchy and opening up the opportunity for people to claim they are the leader of component/team X. Everyone should be a peer. Maybe have a weekly report of unassigned issues so the release manager can nudge people. I always have an urge to have IRC triage sessions with decisions reported back to the mail list, interesting to hear what Ken thinks on that. The IRC triage sessions are a good idea - with the importance on results being posted on the dev list. Hopefully Jason will be able to get the IRC logs posted to the dev list, so no-one misses out on the detail. 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? If a JIRA is not marked as in-progress then people should be encouraged to ask the assignee whether they can take it off their hands. I am also wondering whether we should have Geronimo Bug Guidelines page (e.g. like http://db.apache.org/derby/DerbyBugGuidelines.html ) on the website off the JIRA link that discusses JIRA usage and may help prevent JIRA being used as a place to ask questions, with the link to JIRA on that page. I would define leads for each component and delegate to them as release manager to give me a status of where things are - however I would make the default assignee be unassigned to encourage community. I think we need more discussion on the pros and cons of having component leads. Hen
Re: Thoughts on using JIRA more effectively
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 I'd offer thoughts. 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 have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done. At first I thought this was bad, but the existence of a 1.x version means that you can still keep the vision of the major release going without making it hard to do minor releases. Seems like a good idea to me. I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves. Probably a bit too far. The process here is going to depend on when you branch the release, so: *) pre-branch - general conversation about the important things in this release (and are thus assigned to 1.2 etc), people fixing things randomly and throwing in (and as they resolve they move to 1.2 - there should be no resolveds in 1.x). *) post-branch - nothing should move to 1.2 without lots of discussion. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. New issues are unversioned. Component leads look at the issue and then assign them to 1.x, wishlist, 2.x, verification required, wontfix (resolving) et al. I am concerned that having Component leads is against the ASF way. The last thing we want is for the community to feel there is a hierarchy and opening up the opportunity for people to claim they are the leader of component/team X. Everyone should be a peer. I agree with the idea that we are peers but I think people have natural areas of expertise that fall out. (Well, apart from Jencks who seems to be able to do anything :-) In general though I might change something related to a bug or a performance problem but know that if its Tx related I'll call on Jencks, or Console related give Aaron a heads up. I don't think having people that are knowledgable in a given area as a main contact is an issue. However, they also need to look at the needs of the project and help mentor folks as well. Maybe have a weekly report of unassigned issues so the release manager can nudge people. I always have an urge to have IRC triage sessions with decisions reported back to the mail list, interesting to hear what Ken thinks on that. The IRC triage sessions are a good idea - with the importance on results being posted on the dev list. Hopefully Jason will be able to get the IRC logs posted to the dev list, so no-one misses out on the detail. 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? If a JIRA is not marked as in-progress then people should be encouraged to ask the assignee whether they can take it off their hands. I am also wondering whether we should have Geronimo Bug Guidelines page (e.g. like http://db.apache.org/derby/DerbyBugGuidelines.html ) on the website off the JIRA link that discusses JIRA usage and may help prevent JIRA being used as a place to ask questions, with the link to JIRA on that page. Excellent idea John. I'd like to coalesce the thinking in this thread and put something like that together. Are you volunteering :) I would define leads for each component and delegate to them as release manager to give me a status of where things are - however I would make the default assignee be unassigned to encourage community. I think we need more discussion on the pros and cons of having component leads. Hen
Re: Thoughts on using JIRA more effectively
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 tasks too, so thought I'd offer thoughts. 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 have time to complete and end up with over a hundred JIRAs than move from version to version. I don't think this solution works because one never knows what's really left in a release to complete before its golden. Our intentions are noble (let's fix all those bad bugs) but of course our time is a limited resource and we can't always get everything done. At first I thought this was bad, but the existence of a 1.x version means that you can still keep the vision of the major release going without making it hard to do minor releases. Seems like a good idea to me. I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned to a release if the person assigning it is going to fix it and they assign it to themselves. Probably a bit too far. The process here is going to depend on when you branch the release, so: *) pre-branch - general conversation about the important things in this release (and are thus assigned to 1.2 etc), people fixing things randomly and throwing in (and as they resolve they move to 1.2 - there should be no resolveds in 1.x). *) post-branch - nothing should move to 1.2 without lots of discussion. For new issues that are not being worked on they get put into another category like 1.x, wishlist, etc. New issues are unversioned. Component leads look at the issue and then assign them to 1.x, wishlist, 2.x, verification required, wontfix (resolving) et al. I am concerned that having Component leads is against the ASF way. The last thing we want is for the community to feel there is a hierarchy and opening up the opportunity for people to claim they are the leader of component/team X. Everyone should be a peer. I agree with the idea that we are peers but I think people have natural areas of expertise that fall out. (Well, apart from Jencks who seems to be able to do anything :-) In general though I might change something related to a bug or a performance problem but know that if its Tx related I'll call on Jencks, or Console related give Aaron a heads up. I don't think having people that are knowledgable in a given area as a main contact is an issue. However, they also need to look at the needs of the project and help mentor folks as well. I agree that people have natural areas of expertise. I am just wary of seeing people marketed as the Leader of component/team X by their employers or in articles/books (and they have the JIRA screen to back it up without an explanation of what it really means). What if two people consider themselves experts in a component, AFAIK, JIRA can only have one lead for a component? Will one get upset at the other being chosen as the Lead? How is a lead selected and what is the length of their term. In a perfect world I wouldn't see any problems with this, but I can see some potential issues here. What do others think? John Maybe have a weekly report of unassigned issues so the release manager can nudge people. I always have an urge to have IRC triage sessions with decisions reported back to the mail list, interesting to hear what Ken thinks on that. The IRC triage sessions are a good idea - with the importance on results being posted on the dev list. Hopefully Jason will be able to get the IRC logs posted to the dev list, so no-one misses out on the detail. 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? If a JIRA is not marked as in-progress then people should be encouraged to ask the assignee whether they can take it off their hands. I am also wondering whether we should have Geronimo Bug Guidelines page (e.g. like http://db.apache.org/derby/DerbyBugGuidelines.html ) on the website off the JIRA link that discusses JIRA usage and may help prevent JIRA being used as a place to ask questions, with the link to JIRA on that page. Excellent idea John. I'd like to coalesce the thinking in this thread and put something like that together. Are you volunteering :) I would be happy to put together a page similar to Derby's for review, I'll created GERONIMO-2080 and assigned to myself. John I would define leads for each component and delegate to them as release manager to give me a status of where things are - however I would make the default assignee be unassigned to encourage community. I think we need more discussion on
Re: Thoughts on using JIRA more effectively
- 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 ( http://confluence.atlassian.com/ display/JIRAEXT/JIRA+Label+Plugin ) installed we could add labels (aka tags) to issues to add this type of metadata to issues. - a screen showing issues with attached patches, perhaps by priority, perhaps by component You can do this now, create a saved filter and then use the filter portlet on your dashboard to view the issues that match. If we were actually using Confluence to render dynamic pages, then we could embed that same portlet into a page so that everyone can see the same data. W/o you need to login to JIRA and configure a filter and portlet... Maybe we could link to a few pages in cwiki directly... ? --jason
