Re: [office] Tracking issues

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 07:00:44 PM:

> 
> Just a couple of thoughts to follow up on the discussion about tracking
> issues for ODF-Next.
> 
> I think it was Oliver who suggested that we could use due dates and
> assignments to track the processing of issues in JIRA.
> 
> Since assignee is pretty much all over the place, for various reasons, I
> would suggest the following:
> 
> 1) As of our next TC call, let's agree that we blank the assignee field
> for all ODF-Next issues.
>

This is easy to do.
 
> 2) Let us further agree that when issues are "approved" for inclusion,
> at that point, an assignee is given the issue and entered in JIRA, along
> with a due date.
>

OK.

 
> If we really want to track things, I would suggest putting the TC
> meeting date of the assignment in the JIRA entry for that issue.
>

We are not able to modify the creation date for the issue.  But we could 
add a comment saying when a proposal was accepted, and that comment would 
be automatically dated.
 
> 3) An issue is not "resolved" until the TC approves the solution
> proffered by the assignee. 
>

But by "approval" I'd suggest that this could take different forms 
depending on how far advanced we are in the process.  For example, 
initially we might want to accept all proposals unless there is an 
objection.  That might work for CSD01.  But we might change the bias so by 
the time we have our final CSD no changes are accepted unless discussed 
and approved by the TC.  That encourages stability as the work progresses. 


 
> Thinking that Rob's opportunity to object to features he doesn't like
> occurs at #2, which is prior to a lot of effort being spent. 
>

I can object at any point, as can any other TC member.  But I think we'd 
all want to hear concerns earlier rather than later, so anything we can do 
to encourage that helps us all.

 
> BTW, TC approval for #3 should be on the agenda and notice given that it
> is about to be voted on by the TC. 
> 

As above, it might be treated as an exception process initially.  It 
should not be necessary to explicitly vote on every proposal from the 
start.  I think this will depend on the number of proposals we're dealing 
with.

> What does the foregoing *not* capture or that could be captured better
> by some other mechanism? 
> 
> Apologies for the early focus on process but I would like to get those
> issues out of the way so that we will have a clear status on issues and
> a process for dealing with them. 
>

How long do TC members need before having a proposal ready for review 
until they are able to approve or object to it?  Is one week sufficient? I 
think the Apache style voting we did in JIRA, with +1/-1, etc., worked 
well.  We need something that scales, and having items come up for 
discussion/resolution in TC meetings does not scale.  Heck, it barely 
scaled in the Formula SC.  So I think we need a method of processing 
proposals that encourages development of consensus via JIRA in almost all 
cases.  It should be very rare that we need to have a formal 
discussion/vote on a call. 

-Rob


 
> Particularly if we are talking about a new draft every 6 months. (which
> I think is a very good idea)
> 
> Hope everyone is having a great day!
> 
> Patrick
> -- 
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
> 
> Another Word For It (blog): http://tm.durusau.net
> Homepage: http://www.durusau.net
> Twitter: patrickDurusau
> Newcomb Number: 1
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>