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

[Darran Lofthouse]

On 03/23/2011 02:41 AM, Andrig Miller wrote:
> 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.

I would have thought that of the ones still applicable would have been 
raised against the actual components integrated with JBoss AS rather 
than the core of AS itself.

> 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
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev