Re: [jboss-as7-dev] IMPORTANT New JIRA Policy & Massive JBAS JIRA Reorg/Cleanup

One question. Has there been anything done to the JIRA's that originate with EAP? I'm a little afraid that we might close those, when we shouldn't. We don't want a repeat of what happened with EAP 5, where a bunch of EAP 4.x related JIRA's never were fixed in AS 5.0, and we ended up having to fix a large number of bugs again after EAP 5 shipped, which in the case of more than a few customers was a complete embarrassment. Andy ----- Original Message ----- > From: "Jason T. Greene"<jason.greene(a)redhat.com> > To: jboss-as7-dev(a)lists.jboss.org > Sent: Tuesday, March 22, 2011 3:17:36 PM > Subject: [jboss-as7-dev] IMPORTANT New JIRA Policy& Massive JBAS JIRA Reorg/Cleanup > Hi Everyone, > > I'm sure many of you will agree that the JBAS jira has had a very poor > signal to noise ratio for awhile now. his has been a problem since > important issues often go unnoticed, and it's extremely time consuming > to do any kind of release or organization. > > Our release model is such that we only focus on one major release at a > time. Once that happens it typically becomes part of the enterprise > product line which has it's own JIRA project (JBPAPP). Since we have a > very new architecture with 7, there isn't much value in keeping around > hundreds of stale issues which may not be relevant any more. > > So, I have /closed all issues that were not assigned to an as7 > release/ > as out of date. > > I have also renamed all components that are no longer relevant to be > prefixed with z - Legacy (to sort at the bottom). > > From now on JIRA should accurately reflect our 7 timeline and work > queue. > > > I am asking for everyone's help though in keeping this manageable by > doing the following: > > 1. When creating an issue that you intend to assign to yourself, pick > a > fix-for release version that you can commit to achieving. Please be > realistic in making this choice, as very few of our issues do not get > rescheduled. > > 2. If you can not commit to a point in the schedule, but you just want > to log the issue to be worked on, then leave it unassigned and set the > fix-for to be "Open to Community". I am hoping this will be an easy > place to point people that want to jump in. > > 3. If you have an issue you know you cant work on, but think it is > timeline sensitive, then leave it unassigned and let me know about it. > We will figure out a way to resource it. > > 4. If you validate that a bug is valid then please schedule it or > leave > a note so that when I go through them I can find a place for it. > > 5. If you are a component lead you will probably get auto-assigned. > The > intention is that you will either take on the issue, delegate it to > someone else, verify it and unassign, or in the worst case just > unassign. > > Also note that I may close issues that are continually not resolved > when > scheduled, so if you really care about the issue please schedule it > reliably. > > If we do this right, we should start to see that each release has a > manageable number of issues on it, and that everyone has a reasonable > number assigned to them. > > If you have any questions or any other ideas on how we can get a more > accurate reflection of our work in JIRA, then let me know. > > Thanks! > > -- > Jason T. Greene > JBoss, a division of Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev