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] So what happens in a public review?

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


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 

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