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

[Andrig Miller]

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 at redhat.com>
> To: jboss-as7-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev