OASIS Open Document Format for Office Applications (OpenDocument) TC

To get an understanding what the work flow in JIRA for these issues
could be now, I've started to add the comments and proposed resolution
that I have forwarded as documents previously to the items. I have
entered the proposed resolutions into the "proposal" field. To be able
to differ between those item where we have a proposed resolution and
those where we have none, I've set the status of those items where we
have a proposed resolution to "Resolved". This is the 3rd status in the
chain "New" -> "Open" -> "Resolved" -> "Applied" -> "Closed".

My proposal how we proceed is:

Whoever has time and and interest may comment on an item, and may
provide a resolution. This resolution is recorded in the "proposal"
field. If a proposal for a resolution does exist, the proposer of the
resolution sets the status of the issue to "resolved".

Patrick (or myself if an issue affects the schema) takes the issues
whose status is "resolved" and applies the proposed resolution to the
specification text. He then sets the status to "Applied".

The changes to the specification still will be recorded. We continue to
have a week for TC internal reviews of drafts before we vote on them in
a TC meeting, or we conduct electronic ballots for committee drafts, 
that run at least a week anyway, so that there is the same time 
available for a review.

TC members therefore have the choice to either watch the items in JIRA,
or to just review the changes in the next draft. The approval of a
resolution takes place with the approval of a committee draft. This
means that nothing that we do in JIRA implies any kind of approval by
the TC, and that it is not required to watch the changes in JIRA to
figure out what changes are made in a draft.

When a draft has been approved as committee draft, all issues applied to
that draft are closed (unless someone has objected to a particular
resolution).

I have created two new filters:

"Open 1.2 Editorial Notes" lists those items whose title starts with
"Editorial Notes" and that are open. This filter may be used to find all
issues for which no resolution does exist yet.

"Resolved, unapplied 1.2 Editorial Notes" lists those items for which a
resolution has been proposed, and whose status is "resolved". This
filter is useful if you want to review proposed resolution, but also
useful for Patrick to find the items that may be ready to be applied to 
the specification.

Best regards

Michael





On 05/28/09 20:05, robert_weir@us.ibm.com wrote:
> You probably want to delete all of those 260+ notifications from JIRA. 
> These was a one-time port of Patrick's remaining editor notes. They've 
> been entered, opened, and assigned to Patrick.  This will make it easier 
> to track these items going forward.
> 
> Regards,
> 
> -Rob
> 
> 
> ---------------------------------------------------------------------
> 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, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

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

This sounds good.  I'd suggest two other possibilities:

1) We probably need a way to suggest that a particular item requires 
discussion by the TC, because it is a large change or controversial.  JIRA 
doesn't have  a workflow state that corresponds to this.  So, I think we 
need to rely on TC members (including Patrick) to nominate items for TC 
meeting agendas, that they think require additional discussion.  Maybe 
they also add a comment to the JIRA issue, something we can search for 
like "Hold for Discussion".  This would indicate that we do not trigger 
the "Apply" state change until discussed.  Of course, the vast majority of 
issues are editorial or minor and will require no in depth discussion, and 
would make it into the proposed CD for review and approval at that time.

2) It is possible that some of the editor notes are found to be invalid, 
or should be deferred for the next version of ODF.  So it is possible that 
some comments might not go to the create->open->resolve->apply->close 
states, but might go directly create->close, or create->assign to 
ODF-Next.  These will probably be rare.

-Rob

Michael.Brauer@Sun.COM wrote on 05/29/2009 07:47:11 AM:
> 
> [office] JIRA Work Flow Proposal, was Re: [office] All done
> 
> Sent by:
> 
> Michael.Brauer@Sun.COM
> 
> To get an understanding what the work flow in JIRA for these issues
> could be now, I've started to add the comments and proposed resolution
> that I have forwarded as documents previously to the items. I have
> entered the proposed resolutions into the "proposal" field. To be able
> to differ between those item where we have a proposed resolution and
> those where we have none, I've set the status of those items where we
> have a proposed resolution to "Resolved". This is the 3rd status in the
> chain "New" -> "Open" -> "Resolved" -> "Applied" -> "Closed".
> 
> My proposal how we proceed is:
> 
> Whoever has time and and interest may comment on an item, and may
> provide a resolution. This resolution is recorded in the "proposal"
> field. If a proposal for a resolution does exist, the proposer of the
> resolution sets the status of the issue to "resolved".
> 
> Patrick (or myself if an issue affects the schema) takes the issues
> whose status is "resolved" and applies the proposed resolution to the
> specification text. He then sets the status to "Applied".
> 
> The changes to the specification still will be recorded. We continue to
> have a week for TC internal reviews of drafts before we vote on them in
> a TC meeting, or we conduct electronic ballots for committee drafts, 
> that run at least a week anyway, so that there is the same time 
> available for a review.
> 
> TC members therefore have the choice to either watch the items in JIRA,
> or to just review the changes in the next draft. The approval of a
> resolution takes place with the approval of a committee draft. This
> means that nothing that we do in JIRA implies any kind of approval by
> the TC, and that it is not required to watch the changes in JIRA to
> figure out what changes are made in a draft.
> 
> When a draft has been approved as committee draft, all issues applied to
> that draft are closed (unless someone has objected to a particular
> resolution).
> 
> I have created two new filters:
> 
> "Open 1.2 Editorial Notes" lists those items whose title starts with
> "Editorial Notes" and that are open. This filter may be used to find all
> issues for which no resolution does exist yet.
> 
> "Resolved, unapplied 1.2 Editorial Notes" lists those items for which a
> resolution has been proposed, and whose status is "resolved". This
> filter is useful if you want to review proposed resolution, but also
> useful for Patrick to find the items that may be ready to be applied to 
> the specification.
> 
> Best regards
> 
> Michael
> 
> 
> 
> 
> 
> On 05/28/09 20:05, robert_weir@us.ibm.com wrote:
> > You probably want to delete all of those 260+ notifications from JIRA. 

> > These was a one-time port of Patrick's remaining editor notes. They've 

> > been entered, opened, and assigned to Patrick.  This will make it 
easier 
> > to track these items going forward.
> > 
> > Regards,
> > 
> > -Rob
> > 
> > 
> > ---------------------------------------------------------------------
> > 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, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
> 
> 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
> 
> 
> 
> ---------------------------------------------------------------------
> 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,

robert_weir@us.ibm.com wrote:
> This sounds good.  I'd suggest two other possibilities:
>
> 1) We probably need a way to suggest that a particular item requires 
> discussion by the TC, because it is a large change or controversial.  JIRA 
> doesn't have  a workflow state that corresponds to this.  So, I think we 
> need to rely on TC members (including Patrick) to nominate items for TC 
> meeting agendas, that they think require additional discussion.  Maybe 
> they also add a comment to the JIRA issue, something we can search for 
> like "Hold for Discussion".  This would indicate that we do not trigger 
> the "Apply" state change until discussed.  Of course, the vast majority of 
> issues are editorial or minor and will require no in depth discussion, and 
> would make it into the proposed CD for review and approval at that time.
>
>   
Yes, but with the caveat that even issues that need discussion may not 
need to wait for time on a TC call. To the extent possible (it isn't 
always) I would like to see the TC list used for discussion and 
resolution of issues.
> 2) It is possible that some of the editor notes are found to be invalid, 
> or should be deferred for the next version of ODF.  So it is possible that 
> some comments might not go to the create->open->resolve->apply->close 
> states, but might go directly create->close, or create->assign to 
> ODF-Next.  These will probably be rare.
>
>   
Well, not just editorial notes (although that is what we are discussing) 
but other comments as well could go into an "assign to ODF-Next" status.

Hope you are looking forward to a great weekend!

Patrick
> -Rob
>
> Michael.Brauer@Sun.COM wrote on 05/29/2009 07:47:11 AM:
>   
>> [office] JIRA Work Flow Proposal, was Re: [office] All done
>>
>> Sent by:
>>
>> Michael.Brauer@Sun.COM
>>
>> To get an understanding what the work flow in JIRA for these issues
>> could be now, I've started to add the comments and proposed resolution
>> that I have forwarded as documents previously to the items. I have
>> entered the proposed resolutions into the "proposal" field. To be able
>> to differ between those item where we have a proposed resolution and
>> those where we have none, I've set the status of those items where we
>> have a proposed resolution to "Resolved". This is the 3rd status in the
>> chain "New" -> "Open" -> "Resolved" -> "Applied" -> "Closed".
>>
>> My proposal how we proceed is:
>>
>> Whoever has time and and interest may comment on an item, and may
>> provide a resolution. This resolution is recorded in the "proposal"
>> field. If a proposal for a resolution does exist, the proposer of the
>> resolution sets the status of the issue to "resolved".
>>
>> Patrick (or myself if an issue affects the schema) takes the issues
>> whose status is "resolved" and applies the proposed resolution to the
>> specification text. He then sets the status to "Applied".
>>
>> The changes to the specification still will be recorded. We continue to
>> have a week for TC internal reviews of drafts before we vote on them in
>> a TC meeting, or we conduct electronic ballots for committee drafts, 
>> that run at least a week anyway, so that there is the same time 
>> available for a review.
>>
>> TC members therefore have the choice to either watch the items in JIRA,
>> or to just review the changes in the next draft. The approval of a
>> resolution takes place with the approval of a committee draft. This
>> means that nothing that we do in JIRA implies any kind of approval by
>> the TC, and that it is not required to watch the changes in JIRA to
>> figure out what changes are made in a draft.
>>
>> When a draft has been approved as committee draft, all issues applied to
>> that draft are closed (unless someone has objected to a particular
>> resolution).
>>
>> I have created two new filters:
>>
>> "Open 1.2 Editorial Notes" lists those items whose title starts with
>> "Editorial Notes" and that are open. This filter may be used to find all
>> issues for which no resolution does exist yet.
>>
>> "Resolved, unapplied 1.2 Editorial Notes" lists those items for which a
>> resolution has been proposed, and whose status is "resolved". This
>> filter is useful if you want to review proposed resolution, but also
>> useful for Patrick to find the items that may be ready to be applied to 
>> the specification.
>>
>> Best regards
>>
>> Michael
>>
>>
>>
>>
>>
>> On 05/28/09 20:05, robert_weir@us.ibm.com wrote:
>>     
>>> You probably want to delete all of those 260+ notifications from JIRA. 
>>>       
>
>   
>>> These was a one-time port of Patrick's remaining editor notes. They've 
>>>       
>
>   
>>> been entered, opened, and assigned to Patrick.  This will make it 
>>>       
> easier 
>   
>>> to track these items going forward.
>>>
>>> Regards,
>>>
>>> -Rob
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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, Technical Architect Software Engineering
>> StarOffice/OpenOffice.org
>> Sun Microsystems GmbH             Nagelsweg 55
>> D-20097 Hamburg, Germany          michael.brauer@sun.com
>> http://sun.com/staroffice         +49 40 23646 500
>> http://blogs.sun.com/GullFOSS
>>
>> 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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 
>
>
>   

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

Michael,

The proposed flow looks good to me but I have a fairly practical question:

If I mark a comment as "applied," I would expect users to think if they 
look at the current working draft, the comment *has been* applied. That 
is that the current working draft is in synch with the status as 
reflected in JIRA.

Would anyone object to my simply updating the status of comments in JIRA 
and then posting a working draft later the same day? Such that any 
comment marked "applied" will be reflected in a draft dated for the same 
day?

Granted in my working copy I may be updating comments, particularly 
those that apply to several areas over a period of days but I will only 
update the status in JIRA on one day and post that draft later the same day.

Does anyone have a better suggestion?

Hope everyone is either enjoying now or looking forward to a great weekend!

Patrick


Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> To get an understanding what the work flow in JIRA for these issues
> could be now, I've started to add the comments and proposed resolution
> that I have forwarded as documents previously to the items. I have
> entered the proposed resolutions into the "proposal" field. To be able
> to differ between those item where we have a proposed resolution and
> those where we have none, I've set the status of those items where we
> have a proposed resolution to "Resolved". This is the 3rd status in the
> chain "New" -> "Open" -> "Resolved" -> "Applied" -> "Closed".
>
> My proposal how we proceed is:
>
> Whoever has time and and interest may comment on an item, and may
> provide a resolution. This resolution is recorded in the "proposal"
> field. If a proposal for a resolution does exist, the proposer of the
> resolution sets the status of the issue to "resolved".
>
> Patrick (or myself if an issue affects the schema) takes the issues
> whose status is "resolved" and applies the proposed resolution to the
> specification text. He then sets the status to "Applied".
>
> The changes to the specification still will be recorded. We continue to
> have a week for TC internal reviews of drafts before we vote on them in
> a TC meeting, or we conduct electronic ballots for committee drafts, 
> that run at least a week anyway, so that there is the same time 
> available for a review.
>
> TC members therefore have the choice to either watch the items in JIRA,
> or to just review the changes in the next draft. The approval of a
> resolution takes place with the approval of a committee draft. This
> means that nothing that we do in JIRA implies any kind of approval by
> the TC, and that it is not required to watch the changes in JIRA to
> figure out what changes are made in a draft.
>
> When a draft has been approved as committee draft, all issues applied to
> that draft are closed (unless someone has objected to a particular
> resolution).
>
> I have created two new filters:
>
> "Open 1.2 Editorial Notes" lists those items whose title starts with
> "Editorial Notes" and that are open. This filter may be used to find all
> issues for which no resolution does exist yet.
>
> "Resolved, unapplied 1.2 Editorial Notes" lists those items for which a
> resolution has been proposed, and whose status is "resolved". This
> filter is useful if you want to review proposed resolution, but also
> useful for Patrick to find the items that may be ready to be applied 
> to the specification.
>
> Best regards
>
> Michael
>
>
>
>
>
> On 05/28/09 20:05, robert_weir@us.ibm.com wrote:
>> You probably want to delete all of those 260+ notifications from 
>> JIRA. These was a one-time port of Patrick's remaining editor notes. 
>> They've been entered, opened, and assigned to Patrick.  This will 
>> make it easier to track these items going forward.
>>
>> Regards,
>>
>> -Rob
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>

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

Patrick Durusau 

On Friday 29 May 2009, robert_weir@us.ibm.com wrote:
> I'm thinking 'applied' means you or Michael has updated the text or schema 
> and it will appear in the next uploaded version of the text.  When the CD 
> is approved we can then mark the issue 'closed'. 

Yes. This is just like with software bugs. We mark bugs as "FIXED"
once the fix exists in the developer's version of the source code,
even if the fix has not been deployed to users yet. This is the same here.


-- 
David Faure, faure@kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

Hi all,

   If you need additional workflow steps just let me know - I can  
create a customized version for the ODF TC.

Mary

On May 29, 2009, at 10:50 AM, Patrick Durusau wrote:

> Michael,
>
> The proposed flow looks good to me but I have a fairly practical  
> question:
>
> If I mark a comment as "applied," I would expect users to think if  
> they look at the current working draft, the comment *has been*  
> applied. That is that the current working draft is in synch with the  
> status as reflected in JIRA.
>
> Would anyone object to my simply updating the status of comments in  
> JIRA and then posting a working draft later the same day? Such that  
> any comment marked "applied" will be reflected in a draft dated for  
> the same day?
>
> Granted in my working copy I may be updating comments, particularly  
> those that apply to several areas over a period of days but I will  
> only update the status in JIRA on one day and post that draft later  
> the same day.
>
> Does anyone have a better suggestion?
>
> Hope everyone is either enjoying now or looking forward to a great  
> weekend!
>
> Patrick
>
>
> Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
>> To get an understanding what the work flow in JIRA for these issues
>> could be now, I've started to add the comments and proposed  
>> resolution
>> that I have forwarded as documents previously to the items. I have
>> entered the proposed resolutions into the "proposal" field. To be  
>> able
>> to differ between those item where we have a proposed resolution and
>> those where we have none, I've set the status of those items where we
>> have a proposed resolution to "Resolved". This is the 3rd status in  
>> the
>> chain "New" -> "Open" -> "Resolved" -> "Applied" -> "Closed".
>>
>> My proposal how we proceed is:
>>
>> Whoever has time and and interest may comment on an item, and may
>> provide a resolution. This resolution is recorded in the "proposal"
>> field. If a proposal for a resolution does exist, the proposer of the
>> resolution sets the status of the issue to "resolved".
>>
>> Patrick (or myself if an issue affects the schema) takes the issues
>> whose status is "resolved" and applies the proposed resolution to the
>> specification text. He then sets the status to "Applied".
>>
>> The changes to the specification still will be recorded. We  
>> continue to
>> have a week for TC internal reviews of drafts before we vote on  
>> them in
>> a TC meeting, or we conduct electronic ballots for committee  
>> drafts, that run at least a week anyway, so that there is the same  
>> time available for a review.
>>
>> TC members therefore have the choice to either watch the items in  
>> JIRA,
>> or to just review the changes in the next draft. The approval of a
>> resolution takes place with the approval of a committee draft. This
>> means that nothing that we do in JIRA implies any kind of approval by
>> the TC, and that it is not required to watch the changes in JIRA to
>> figure out what changes are made in a draft.
>>
>> When a draft has been approved as committee draft, all issues  
>> applied to
>> that draft are closed (unless someone has objected to a particular
>> resolution).
>>
>> I have created two new filters:
>>
>> "Open 1.2 Editorial Notes" lists those items whose title starts with
>> "Editorial Notes" and that are open. This filter may be used to  
>> find all
>> issues for which no resolution does exist yet.
>>
>> "Resolved, unapplied 1.2 Editorial Notes" lists those items for  
>> which a
>> resolution has been proposed, and whose status is "resolved". This
>> filter is useful if you want to review proposed resolution, but also
>> useful for Patrick to find the items that may be ready to be  
>> applied to the specification.
>>
>> Best regards
>>
>> Michael
>>
>>
>>
>>
>>
>> On 05/28/09 20:05, robert_weir@us.ibm.com wrote:
>>> You probably want to delete all of those 260+ notifications from  
>>> JIRA. These was a one-time port of Patrick's remaining editor  
>>> notes. They've been entered, opened, and assigned to Patrick.   
>>> This will make it easier to track these items going forward.
>>>
>>> Regards,
>>>
>>> -Rob
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> -- 
> 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)
>
>
> ---------------------------------------------------------------------
> 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

On Fri, 2009-05-29 at 11:08 -0400, Mary McRae wrote:
> Hi all,
> 
>    If you need additional workflow steps just let me know - I can  
> create a customized version for the ODF TC.
> 

I think it would be good if we wouldn't use "Resolved" just because one
person posted a suggested solution. I think there should be a chance for
competing solutions.

So a proposal might need to sit for 48 hours before it becomes
applicable.
> 
-- 
Andreas J. Guelzow, PhD, FTICA
Coordinator, Mathematical & Computing Sciences
Concordia University College of Alberta

Andreas,

On 05/29/09 17:45, Andreas J. Guelzow wrote:
> On Fri, 2009-05-29 at 11:08 -0400, Mary McRae wrote:
>> Hi all,
>>
>>    If you need additional workflow steps just let me know - I can  
>> create a customized version for the ODF TC.
>>
> 
> I think it would be good if we wouldn't use "Resolved" just because one
> person posted a suggested solution. I think there should be a chance for
> competing solutions.
> 
> So a proposal might need to sit for 48 hours before it becomes
> applicable.

The approval of any resolution takes place with the approval of a draft 
as committee draft (or with the approval of a Committee Specification, 
because there may be multiple committee drafts, and a resolution my be 
revised). For that reason, it is possible to propose a competing 
solution even when an item has been applied. Sure, this may mean some 
more work for the TC editor. But I don't expect that this situation will 
happen frequently. And if it happens, I'm also not sure if a TC member 
that wishes to make a counter proposal really notices a proposal in 
question early enough to create a counter proposal within 48 hours.

On the other hand, tracking when proposals have been added to an JIRA 
item, and when the 48 hours have been passed is some overhead, and makes 
the process more complex. But the intention behind using JIRA is to 
simplify tracking of items and to make the tracking more transparent. 
The intention is not to create a JIRA based resolution approval process. 
  In so far, I would recommend that we use JIRA with as little 
additional process details as possible unless we really find that these 
are required while using JIRA in practice.

Best regards

Michael

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

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

Ohh... now you're asking for trouble.

-Rob


Mary McRae