Rob, Your key phrase is "There might be some workflow things we can define..." Until those are defined (and I agree with you, they shouldbe) then it's horses
for courses: people will use the tools at hand if it gets their particular job
done.

Cheers, Peter

From: robe...@us.ibm.com [mailto:robe...@us.ibm.com] Sent: Tuesday, 24 April, 2012 16:21 To: Chet Ensign Cc: cha...@lists.oasis-open.org; Jamie Clark; Scott McGrath; OASIS TAB Subject: Re: [chairs] Chairs: Requesting your feedback on comment resolution
logs

Chet Ensign <chet...@oasis-open.org<mailto:chet...@oasis-open.org>>
wrote on 04/24/2012 06:21:40 PM:

The liaison aspect is interesting. We've had a few rounds of defect reports
between ISO/IEC JTC1/SC34 and the ODF TC. On the JTC1 side they expect
documents. They have a form for reporting defects and expect a response in a
particular form as well, ultimately as draft corrigenda. So there is a formal
aspect to this, as well as the responsiveness/professional courtesy aspect you
noted before.

Another new data point, since your last note. I was recently at an ODF
conference in Brussels (an ODF Plugfest). I gave an update on the work of of
the ODF TC, and in the Q&A received some feedback on the public comment process:

1) There is an expectations that those who submit comments should get a timely
personal response. But not only for comments submitted during a public review
period. They expect it for all comments. This is reasonable, though the OASIS
process only makes it a requirement for public review comments.

2) Timely means days or weeks, not months.

3) There was the expectation that the comment list could be used to ask
questions and seek clarifications about the interpretation of the spec, and that
TC members would reply with an official response. But as you know, this is not
really possible. We generally turn "What does clause 1.2.3 mean?" into a defect
report "Clause 1.2.3 is ambiguous". But we don't issue interpretations.

4) The feedback I received might be particular to a mature standard like ODF.
If you are working on your first edition of a standard, then you may not get
comments until your first public review. But once you have 3 revisions of your
standard published, then comments flow in at a regular pace, regardless of your
current review status. And the comments are often from implementors, not spec
reviewers. If they are actively implementing the spec, then their code may be
waiting for your response. So a different situation, maybe different
expectations compared to CSD 01 of FooML 1.0.

In a sense, responding to comments becomes a maintenance activity, rather than a
public review activity.

There might be some workflow things we can define in JIRA to make comment
processing easier. For example, if responding to the comment submittor is
important, than maybe that should be be a stage in the workflow? Or a field
that can be set and filtered on?

If we can get JIRA to manage this well, then it has reasonable export to
spreadsheet capabilities.

More radical options, that would require some IT support:

1) Allow the public to register in JIRA and submit issues directly.

2) Allow public to "watch" issues in JIRA so they are notified when the status
changes.

In other words, the things that are good about JIRA for us are also good for
those submitting comments to us.

Regards,

-Rob