Public notifications

[John Haug]

(From today's call: Here's the thread for discussion on the question of making public notifications of potentially disruptive changes we're considering to the standard.)

I'm fairly certain we have consensus that we don't want to make breaking changes and cause problems for any known implementations.  That said, there may still be benefit to alerting IS 29500 implementers of potential future changes and obtaining feedback on what is being used and how.

The main benefit is risk reduction by having the opportunity to learn of implementers relying on functionality we may change.  We are fortunate to have a number of implementers as members of WG 4 and/or Ecma TC 45, but there are some who implemented IS 29500:2008 and have since disappeared from the standard maintenance work.  Certainly there are others we aren't aware of.  If the feedback mechanism is moderated, we can obtain this information without spiraling into free-for-all chaos that potentially circumvents JTC 1 design processes.  Whether this sufficiently mitigates the risk is dependent on publishing the right type of info and getting enough of the right eyes on it.

I see two core questions for WG 4:

*         Do we want to do this?

*         If so, how do we want to do this?

I think this is worth pursuing and my proposal and discussion is below.

I think this topic was a worthwhile little tangent to today's agenda and I'm curious to hear others' thoughts.

John


=Location=
The simple and obvious answer seems to be to post the content on the WG 4 website.

=Content=
We could publish anything from a brief statement to a change-tracked diff document.  Given that we'll continue working on the topic, I think the right answer is to make broad statements about what will change and how, without getting into all the fluctuating details.  We want to know whether the plan of record affects anyone negatively, not necessarily how they would design it if they were king.  Essentially, executive summary material - current plan is to change A to do B, remove C and add D.  This also means we don't have to update the doc constantly.

One thing we can do here that is never reflected in the official CORs and AMDs is to discuss rationale, to whatever depth we feel is appropriate.  We need to keep what we publish brief for busy readers, so a short statement of our motivation behind the changes and why we chose the proposed solutions seems right.

=Feedback=
One option that should be easy to manage is to solicit feedback to the "WG4 Project Editor" Windows Live account.  We use that SkyDrive for DRs and it should have an associated Hotmail address.  I don't have login access to verify that, but we could Rex can verify.  The burden here would be on Rex to forward any mail on to the WG 4 list.  This is the closest we have to a WG 4 e-mail address that I know of.

Another is to use a WG 4 member's e-mail address, but that's dependent on one's continued membership.  And I doubt anyone wants to own this or use their personal or work account for it. :)

Another is a public list, Wiki or forum.  I think this adds unnecessary setup and management burden, plus leads to free-for-all chaos.

=Visibility=
This exercise is pointless if implementers don't see it.  What options do we have to advertise this?  Members' individual blogs/Twitter/etc., liaison reports (with requests for members to pass on to their partners, etc.), official minutes submitted to SC 34, other?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20111130/3b0ff3d3/attachment.htm>