OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings! 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. 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. 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. 3) An issue is not "resolved" until the TC approves the solution proffered by the assignee. 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. BTW, TC approval for #3 should be on the agenda and notice given that it is about to be voted on by the TC. 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. 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

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 >

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

Hi, On 19.01.2011 02:46, robert_weir@us.ibm.com wrote: OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com type= cite > 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. +1 OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com type= cite > 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. +1 OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com type= cite > 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. +1 OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com type= cite > 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. +1 OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com type= cite > 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. Right. I think what is important is to know for TC members is that it may become more difficult to get something into ODF if we are getting closer to an OASIS standard. It is therefore worth to care about the proposal one is interest in rather early than late. OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com type= cite > 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. I think the process we used in the TC for the work on comments did work sufficient well. It included the voting option you mention above, but also the option to set issues on a needs discussion status. A difficulty when working mostly with JIRA could be that it is difficult to notice changes to the issues one is interested in. JIAR sometimes does not send out notifications at all, and even reading through the notifications that are send out needs a lot of time. But we may solve this issues by opening issues only when work on an issue starts, and by having frequent working drafts that include resolved issues. When an issue is applied, we may set it to applied immediately, as we did in the past. We when have the following options to find issues: Status New - no one is working on the issue. No need to review it. Status Open - Someone is working on the issue. If I like to participate in its resolution, then I should track the issue. Status Resolved - Resolved issue. All TC members should review these issues frequently and cast their votes. Status Applied - The issue is available in a working draft. We may further agree that we use change tracking to mark the changes between working drafts (not CDs). This would provide the option to review changes to the specification without having to care about JIRA. But ideally we receive feedback for issues before they are applied. So, I still would encourage TC members to use JIRA. Michael OF9DF1E3E1.FF901FF4-ON8525781D.0005CA77-8525781D.00095C03@lotus.com type= cite > -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 --------------------------------------------------------------------- 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 -- Michael Brauer Oracle Office Development Phone: +49 40 23646 500 Oracle Office Global Business Unit ORACLE Deutschland B.V. & Co. KG Nagelsweg 55 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Oracle is committed to developing practices and products that help protect the environment