OASIS Open Document Format for Office Applications (OpenDocument) TC

OK.  OK.  OK.  I messed that one up and sent this note to the 
office-comment list, instead of the office list.  I am slapping my own 
wrists for commenting on the public comment list.

-Rob


The last public review we had on this TC was January 2007 I believe, with 
the review of ODF 1.1.  So we have many TC members who have not been 
through the process before.  And we also have new tools, like JIRA, that 
we did not have in the last round.  So it is worth reviewing the 
requirements and how we might apply them in this case.

OASIS TC Process 3.2 covers the public review (
http://www.oasis-open.org/committees/process.php#publicReview).

Highlights are:

1) All public (non TC member) comments must come through the 
office-comment list.   This preserves the IP pedigree of our work, since 
submissions via the comment list happen under the Feedback License (
http://www.oasis-open.org/who/ipr/feedback_license.pdf).  So if you hear a 

comment via email, or on Twitter or a blog or discussion forum elsewhere, 
please ask the author to submit the comment formally via the 
office-comment list.  Instructions are here: 
http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=office

2) Also note that according to TC Process 2.8, "The purpose of the TC?s 
public comment facility is to receive comments from the public and is not 
for public discussion" and "Comments to the TC made by Members of the TC 
must be made via the TC general email list, and comments made by non-TC 
members, including from the public, must be made via the TC?s comment 
facility. Comments shall not be accepted via any other means."  So 
comments on the public review draft from TC members are made via the usual 

means (TC's mailing list, bringing up in a meeting, or preferably entered 
directly into JIRA) and not via the comment list. 

When you enter the issue in JIRA, classify the component as "Packaging". 
We can then track the public review comments as those that were assigned 
packaging between November 13th and January 12th.

3) The TC must acknowledge the receipt of each public comment.  This 
occurs automatically, since we use an email reflector list.  Each person 
who submits a comment will immediately receive a copy of the comment back 
to them via email.  That is the acknowledgement. 

4) We need to track all comments received.  This will be done in JIRA. I 
have automation that will automatically transfer comments into JIRA from 
the office-comment list.  This works best when we observe the prohibition 
against discussion on the comment list.  Otherwise we will end up with 
extraneous comments in JIRA.

5) Sometime after the end of the review period (60 days) we need to 
publish the disposition of each comment.  Typically, we propose 
dispositions on the list, or directly in JIRA, and then vote to approve 
the dispositions in a meeting.  The dispositions are then published in the 

meeting minutes and that satisfies the requirement to publish 
dispositions.   However, if there are more than a handful of comments we 
could also just minute that the comments are disposed as per their 
resolutions in JIRA, and then give their OFFICE-X numbers.  Since all JIRA 

resolutions get echoed to the mailing list, this should meet the 
requirements as well.

6) We cannot make changes to the public review draft while the review is 
underway.  However, that does not prevent us from making changes in a new 
numbered revision of the standard to address public comments as they are 
received.  In fact this is a wise use of time.

7) We can have several cycles of public review to the extent we continue 
to make substantive changes to the text. 

We can discuss this more on Monday's call if anyone has questions, 
comments or concerns.

Regards,

-Rob

Oh good. I was going to comment but then saw you sent it to the wrong list. Will comment now :)  See inline.

Mary 

On Nov 15, 2009, at 7:30 PM, robert_weir@us.ibm.com wrote:

> OK.  OK.  OK.  I messed that one up and sent this note to the 
> office-comment list, instead of the office list.  I am slapping my own 
> wrists for commenting on the public comment list.
> 
> -Rob
> 
> 
> The last public review we had on this TC was January 2007 I believe, with 
> the review of ODF 1.1.  So we have many TC members who have not been 
> through the process before.  And we also have new tools, like JIRA, that 
> we did not have in the last round.  So it is worth reviewing the 
> requirements and how we might apply them in this case.
> 
> OASIS TC Process 3.2 covers the public review (
> http://www.oasis-open.org/committees/process.php#publicReview).
> 
> Highlights are:
> 
> 1) All public (non TC member) comments must come through the 
> office-comment list.   This preserves the IP pedigree of our work, since 
> submissions via the comment list happen under the Feedback License (
> http://www.oasis-open.org/who/ipr/feedback_license.pdf).  So if you hear a 
> 
> comment via email, or on Twitter or a blog or discussion forum elsewhere, 
> please ask the author to submit the comment formally via the 
> office-comment list.  Instructions are here: 
> http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=office
> 
> 2) Also note that according to TC Process 2.8, "The purpose of the TC?s 
> public comment facility is to receive comments from the public and is not 
> for public discussion" and "Comments to the TC made by Members of the TC 
> must be made via the TC general email list, and comments made by non-TC 
> members, including from the public, must be made via the TC?s comment 
> facility. Comments shall not be accepted via any other means."  So 
> comments on the public review draft from TC members are made via the usual 
> 
> means (TC's mailing list, bringing up in a meeting, or preferably entered 
> directly into JIRA) and not via the comment list. 
[note: posting issues to JIRA rather than the TC email list is okay because JIRA is set to send an email back to the list with the issue. Otherwise you'd have to post the issue to the TC list as well as create it in JIRA.]
> 
> When you enter the issue in JIRA, classify the component as "Packaging". 
> We can then track the public review comments as those that were assigned 
> packaging between November 13th and January 12th.
> 
> 3) The TC must acknowledge the receipt of each public comment.  This 
> occurs automatically, since we use an email reflector list.  Each person 
> who submits a comment will immediately receive a copy of the comment back 
> to them via email.  That is the acknowledgement. 
[actually no - the language is as follows: "The TC must acknowledge the receipt of each comment, track the comments received, and publish to its primary e-mail list the disposition of each comment at the end of the review period."
Depending on various settings, a sender may or may not receive a copy of a message they posted. But the acknowledgement of receipt isn't meant to imply that you send something directly back to the submitter, but that the comment is noted in a log of some sort along with its resolution.]
> 
> 4) We need to track all comments received.  This will be done in JIRA. I 
> have automation that will automatically transfer comments into JIRA from 
> the office-comment list.  This works best when we observe the prohibition 
> against discussion on the comment list.  Otherwise we will end up with 
> extraneous comments in JIRA.
> 
> 5) Sometime after the end of the review period (60 days) we need to 
> publish the disposition of each comment.  Typically, we propose 
> dispositions on the list, or directly in JIRA, and then vote to approve 
> the dispositions in a meeting.  The dispositions are then published in the 
> 
> meeting minutes and that satisfies the requirement to publish 
> dispositions.   However, if there are more than a handful of comments we 
> could also just minute that the comments are disposed as per their 
> resolutions in JIRA, and then give their OFFICE-X numbers.  Since all JIRA 
> 
> resolutions get echoed to the mailing list, this should meet the 
> requirements as well.
[actually, no, it doesn't. A comment resolution log must be prepared and posted ("at the end of the review period"). I'm guessing you can just export this from JIRA and that in JIRA there's a link to the original comment posted to the comment list for traceability?]
> 
> 6) We cannot make changes to the public review draft while the review is 
> underway.  However, that does not prevent us from making changes in a new 
> numbered revision of the standard to address public comments as they are 
> received.  In fact this is a wise use of time.
> 
> 7) We can have several cycles of public review to the extent we continue 
> to make substantive changes to the text. 
> 
> We can discuss this more on Monday's call if anyone has questions, 
> comments or concerns.
> 
> 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 
> 

Hi Mary,

On 11/16/09 01:55, Mary McRae wrote:

>> 3) The TC must acknowledge the receipt of each public comment.  This 
>> occurs automatically, since we use an email reflector list.  Each person 
>> who submits a comment will immediately receive a copy of the comment back 
>> to them via email.  That is the acknowledgement. 
> [actually no - the language is as follows: "The TC must acknowledge the receipt of each comment, track the comments received, and publish to its primary e-mail list the disposition of each comment at the end of the review period."
> Depending on various settings, a sender may or may not receive a copy of a message they posted. But the acknowledgement of receipt isn't meant to imply that you send something directly back to the submitter, but that the comment is noted in a log of some sort along with its resolution.]
>> 4) We need to track all comments received.  This will be done in JIRA. I 
>> have automation that will automatically transfer comments into JIRA from 
>> the office-comment list.  This works best when we observe the prohibition 
>> against discussion on the comment list.  Otherwise we will end up with 
>> extraneous comments in JIRA.
>>
>> 5) Sometime after the end of the review period (60 days) we need to 
>> publish the disposition of each comment.  Typically, we propose 
>> dispositions on the list, or directly in JIRA, and then vote to approve 
>> the dispositions in a meeting.  The dispositions are then published in the 
>>
>> meeting minutes and that satisfies the requirement to publish 
>> dispositions.   However, if there are more than a handful of comments we 
>> could also just minute that the comments are disposed as per their 
>> resolutions in JIRA, and then give their OFFICE-X numbers.  Since all JIRA 
>>
>> resolutions get echoed to the mailing list, this should meet the 
>> requirements as well.
> [actually, no, it doesn't. A comment resolution log must be prepared and posted ("at the end of the review period"). I'm guessing you can just export this from JIRA and that in JIRA there's a link to the original comment posted to the comment list for traceability?]

If we export that resolution log from JIRA and post that to the comment 
list, are we then meeting the requirement to acknowledge the receipt  of 
each comment (as discussed in item 3 above)?

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

Hi Michael,

  You don't post it to the comment list; you post it to the TC list. (Remember, the email archives, as well as every other resource associated with a TC, is always publicly viewable.) Assuming that the export would contain a link to the original email, the name of the person submitting the comment, a description of the comment, and a description of its resolution, then you would satisfy the requirement.

Mary 


On Nov 16, 2009, at 3:39 AM, Michael Brauer - Sun Germany - ham02 - Hamburg wrote:

> Hi Mary,
> 
> On 11/16/09 01:55, Mary McRae wrote:
> 
>>> 3) The TC must acknowledge the receipt of each public comment.  This occurs automatically, since we use an email reflector list.  Each person who submits a comment will immediately receive a copy of the comment back to them via email.  That is the acknowledgement. 
>> [actually no - the language is as follows: "The TC must acknowledge the receipt of each comment, track the comments received, and publish to its primary e-mail list the disposition of each comment at the end of the review period."
>> Depending on various settings, a sender may or may not receive a copy of a message they posted. But the acknowledgement of receipt isn't meant to imply that you send something directly back to the submitter, but that the comment is noted in a log of some sort along with its resolution.]
>>> 4) We need to track all comments received.  This will be done in JIRA. I have automation that will automatically transfer comments into JIRA from the office-comment list.  This works best when we observe the prohibition against discussion on the comment list.  Otherwise we will end up with extraneous comments in JIRA.
>>> 
>>> 5) Sometime after the end of the review period (60 days) we need to publish the disposition of each comment.  Typically, we propose dispositions on the list, or directly in JIRA, and then vote to approve the dispositions in a meeting.  The dispositions are then published in the 
>>> meeting minutes and that satisfies the requirement to publish dispositions.   However, if there are more than a handful of comments we could also just minute that the comments are disposed as per their resolutions in JIRA, and then give their OFFICE-X numbers.  Since all JIRA 
>>> resolutions get echoed to the mailing list, this should meet the requirements as well.
>> [actually, no, it doesn't. A comment resolution log must be prepared and posted ("at the end of the review period"). I'm guessing you can just export this from JIRA and that in JIRA there's a link to the original comment posted to the comment list for traceability?]
> 
> If we export that resolution log from JIRA and post that to the comment list, are we then meeting the requirement to acknowledge the receipt  of each comment (as discussed in item 3 above)?
> 
> 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