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] Tracking issues


Rob,

>From below:


> 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. 

+1!

I don't really think we need votes in all cases but I do think we need a
process that has clearly defined go/no go points in the process.

If nothing else, it will help us track where we are with any given
issue.

I have no real investment in any particular methodology, but you brought
up the point that the TC needs to decide if it wishes to pursue an
issue. Or I suppose there is no sustained opposition to pursuit of an
issue. 

My real interest in having a somewhat orderly work flow that doesn't see
us trying to address/integrate a lot of issues late in the process. 

Having whatever process is scalable and amendable to the TC that
achieves that end works for me.

Hope you are having a great day!

Patrick

On Tue, 2011-01-18 at 20:46 -0500, robert_weir@us.ibm.com wrote:
> 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 
> > 
> 




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