[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]