OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] office-comment -> JIRA migration

On 05/06/09 06:20, robert_weir@us.ibm.com wrote:
> "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 05/05/2009 
> 11:41:00 PM:
>> 2. Wow, so we are up to 1500 this way.  For something pretty amusing, go 
> to
>> the end of the No Component list (it is the 8th page of all of them) and
>> notice a sorting aberration in JIRA.  OFFICE-2 comes after OFFICE-1499.
>> Heh.  Hmm, when I resort by the key that doesn't happen.  Not sure it is 
> me
>> or JIRA's default view.  Will keep watching.
> We have far fewer than that.  For example there are around 300 that are 
> just me responded to comments on the list.  Once we eliminate those, and 
> other comments on commnets, as well as the defects that were already 
> addressed in the ODF 1.0 public review, the ISO/IEC 26300 review and the 
> ODF 1.0 Errata 01 comments, I think we'll be down to 500 or so.

The pure number of comments actually says nothing. It is the number of 
e-mails on the comment mailing list. As Rob pointed out, this includes 
responses from TC members, discussions, off-topic mails, maybe even 
spam. But even if Rob has consolidated that, the number of open issues 
does not say a lot, because it does not differ between tasks that are 
open because they have not been reviewed by the TC, or tasks that are 
open because they are candidates for an errata.

>> 3. I see that I can make sub-tasks of issues I didn't originate (such as
>> OFFICE-1497) and I can comment, but I can't do anything about Components 
> and
>> Effected Versions.  I think a sub-task will let me though.  So I have 
> put my
>> recommendation at
>> <http://lists.oasis-open.org/archives/office/200904/msg00084.html> into 
> a
>> sub-task.  But I will do it on Alex Brown's OFFICE-1493 and then see if 
> I
>> can close OFFICE-1497.  This is not necessarily the best way to handle 
> this,
>> but it seems to be the only way those other than the officers can 
> provide
>> additional information on these.
> Ughhh,  Probably best to just add the info as a comment for now, or ask 
> Michael or I to change components, etc.  You can set components and 
> versions when you create an issue initially, right?  But creating subtasks 
> just to change the component, and then deleting the patent tasks sounds 
> like trouble, especially when we use subtasks for a legitimate purpose. 
> For example, when you delete the parent, what happens to the children?

Agreed. I further would recommend that we do not add any new tasks 
(unless they are imported from the comment list) before we have agreed 
how we actually use JIRA in practice.

> Or, if you want to be Maestro di Commenti, we could vote to approve you as 
> such and then maybe Mary would give you the fuller edit rights.
>> 4. In retrospect, it looks like I should have made 3 subtasks, one each 
> for
>> ODF 1.0, ODF 1.1, and 1.2, so they could be closed separately.  Bummer.
>> (What I ended up with instead is OFFICE-1501.)
>> Thoughts?
> I assume you are using "close" loosely.  The workflow should be:
> 1)"Create issue"
> 2)"Open issue", meaning that the TC has decided to accept the issue 
> something it will address.  It would be "Close issue" if the TC decided 
> not to do anything, that the comment was incorrect, invalid, superseded, 
> etc.
> 3)"Resolve issue", meaning the TC has determined the technical resolution 
> to the issue
> 4) "Apply issue resolution", meaning the Editor has updated the text of 
> the standard according to the resolution.

This workflow sounds reasonable.
> You can assign multiple target versions for the issue when you create the 
> issue.  This can be updated when the issue is opened, resolved and 
> applied.  So I don't think we need to create subtasks for that, unless we 
> have something complicated, like a defect that requires a different 
> technical resolution in different versions of ODF. 

Agreed. The result is that tasks remain open as long as they are a 
candidate for an errata. That's not a problem.

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]