Re: [802SEC] Proposal for Editions
As some may recall, I have been advocating publishing all amendments and corrigenda as consolidations (editions) for some time. In my proposals, I have recommended that WGs be allowed to decide if an amendment/corrigendum is balloted as a redline or as change instructions (as is currently done).
Publishing of redlines I agree is a valuable product and something that IEEE-SA is now selectively offereing. Since these can be done as diffs, I don't think it is a significant workload for editorial staff, and probably less than the work of publishing a change instruction amendment and then later having to merge the amendment for a revision.
Personally, for 802 I think a bundle of redline and clean versions would be an appropriate product to serve the needs of implementers.
I agree balloting as redlines also is often valuable. A speed increase or new PHY type for 802.3 is not likely to show as much benefit from a redline ballot as would energy efficient Ethernet which is much better reviewed in context (as you point out for much 802.1 work). In a very large document though, a complete redline is difficult to find scattered changes, so only supplying changed clauses or a changed clause list might be necessary for a redline ballot.
The only point where I find using consolidated redlines problematic is when amendment projects are very parallel (e.g., in ballot at the same time).
--Bob
-----Original Message-----
From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-SEC@ieee.org] On Behalf Of Tony Jeffree
Sent: Wednesday, October 05, 2011 7:33 AM
To: STDS-802-SEC@LISTSERV.IEEE.ORG
Subject: Re: [802SEC] Proposal for Editions
I would agree with that too.
Regards,
Tony
On 5 October 2011 15:18, Geoff Thompson <thompson@ieee.org> wrote:
> All-
>
> I would focus on a specific aspect of this.
> When a standard has a non-trivial number of approved parts it is extremely
> difficult for voters to evaluate additional drafts.
> Having to consider a large number of documents when voting on drafts is a
> significant disservice to our balloting reviewers.
> So, again, just having consolidations a base text for revisions doesn't
> deal with the critical issue in 802.
>
> Regards,
> Geoff
>
>
> On 510//11 5:44 AM, Tony Jeffree wrote:
>
>> I should have added to this...in WGs where a number of amendments to a
>> single base standard are being processed simultaneously, as has been the
>> case in 802.1 for some while, the availability of an up-to-date
>> consolidation of all published material considerably aids the development
>> of
>> further amendments. So for me, focusing the generation of consolidations
>> solely on the need for base text for a revision only deals with half (or
>> maybe much less) of the problem.
>>
>> Regards,
>> Tony
>>
>>
>> On 5 October 2011 11:27, Tony Jeffree<tony@jeffree.co.uk> wrote:
>>
>>
>>
>>> Bob -
>>>
>>> I agree with much of what you have said here. However, given feedback
>>> received from implementers in 802.1, I don't believe that *just*
>>> publishing
>>> amendments/corrigenda as consolidations serves our readership either. The
>>> complexity of our standards, and the sometimes intricate way that an
>>> amendment inserts itself into the base, means that for the implementer to
>>> have a clear picture of what an amendment does to the base document,
>>> he/she
>>> needs to see the deltas; in order to have a clear picture of what the
>>> final
>>> end result is, he/she needs to see the consolidation.
>>>
>>> So I believe that publishing amendments/corrigenda as deltas to the base
>>> standard is necessary IN ADDITION TO publishing the consolidation, and
>>> preferably publishing the consolidation at the same time or soon after.
>>> We
>>> are currently processing several amendments to Q that are following this
>>> model; I am hoping that we will be able to publish a consolidation very
>>> soon
>>> after we are done with the individual amendments. I know that this
>>> creates
>>> an additional load on the editing staff, but on the other hand, it
>>> actually
>>> delivers what the implementers need.
>>>
>>> Regards,
>>> Tony
>>>
>>>
>>>
>>> On 27 September 2011 16:28, Grow, Bob<bob.grow@intel.com> wrote:
>>>
>>>
>>>
>>>> Paul:
>>>>
>>>> While a reasonable IEEE-SA wide policy, it does little to help the most
>>>> active 802 standards.
>>>>
>>>> 1. We have already learned that we have to create consolidations in
>>>> some
>>>> WGs simply to manage the continuing amendment of the standard. (This
>>>> policy
>>>> will not change that. If this were a rule rather than a pubs policy,
>>>> then
>>>> we would be in violation of the statement that a consolidation shall
>>>> only be
>>>> prepared for a revision. But if it is read only referring to pubs staff
>>>> then there isn't an issue, only no help to our needs.)
>>>>
>>>> 2. Four months is a significant problem. In my 802.3 experience it has
>>>> been difficult to find a period of 1 year in which to do a revision.
>>>> The 3
>>>> year, 3 amendment rule has to be satisfied and some of our standards
>>>> will
>>>> have a half dozen or more approved amendments/corrigenda and a few new
>>>> amendment projects in process when we try to slot a revision into the
>>>> flow
>>>> of new projects. While we can typically give a 4 month heads-up for
>>>> when we
>>>> plan a revision, it will typically be triggered when the last amendment
>>>> to
>>>> be included in the revision is approved. (No new amendments are
>>>> expected to
>>>> complete within a year or so.) At that point, the latest amendment
>>>> needs to
>>>> be prepared for publication and then consolidated into the revision
>>>> draft,
>>>> then maintenance changes need to be consolidated into the draft in
>>>> preparation to go to WG ballot. Either volunteers have to merge the
>>>> approved draft into the staff prepared revision draft (with publication
>>>> changes possibly being missed),!
>>>> or we have to find a longer gap into which the revision can be slotted,
>>>> or staff has to be willing to accelerate the consolidation of a
>>>> virtually
>>>> complete amdnement/corrigenda.
>>>>
>>>> Fortunately, publication staff has been willing to work with us in
>>>> recognition of these needs, but the policy certainly doesn't specify
>>>> what we
>>>> need.
>>>>
>>>> On the other hand, if all amendments and corrigenda were published as
>>>> consolidations (editions) pubs staff would not have to handle the
>>>> amendment/corrigenda twice (publish and then consolidate), our balloters
>>>> and
>>>> users of the standard would not be faced with trying to make sense of a
>>>> standard composed of a big set of documents with stacked changes and
>>>> order
>>>> specific changes, and we would be making fewer errors by consistently
>>>> having
>>>> a solid single base standard (not a base standard with separately
>>>> published
>>>> amendments and corrigenda that are part of the standard).
>>>>
>>>> --Bob
>>>>
>>>> -----Original Message-----
>>>> From: ***** IEEE 802 Executive Committee List ***** [mailto:
>>>> STDS-802-SEC@ieee.org] On Behalf Of Paul Nikolich
>>>> Sent: Tuesday, September 27, 2011 6:48 AM
>>>> To: STDS-802-SEC@LISTSERV.IEEE.ORG
>>>> Subject: [802SEC] Proposal for Editions
>>>>
>>>> Dear EC members,
>>>>
>>>> Attached is a proposal from the SA regarding a guideline for
>>>> consolidations (also known as editions or roll-ups). I've reviewed it
>>>> and
>>>> it looks like a reasonable process. The one gap I would like filled is
>>>> the
>>>> time for the SA to respond to a WG Chair 'request for consolidation' be
>>>> defined (one week, perhaps).
>>>>
>>>> Please review the guideline and provide feedback to the EC reflector and
>>>> Karen McCabe. Thank you.
>>>>
>>>> Regards,
>>>>
>>>> --Paul
>>>>
>>>> ----------
>>>> This email is sent from the 802 Executive Committee email reflector.
>>>> This
>>>> list is maintained by Listserv.
>>>>
>>>> ----------
>>>> This email is sent from the 802 Executive Committee email reflector.
>>>> This
>>>> list is maintained by Listserv.
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ----------
>> This email is sent from the 802 Executive Committee email reflector. This
>> list is maintained by Listserv.
>>
>>
>>
>
> ----------
> This email is sent from the 802 Executive Committee email reflector. This
> list is maintained by Listserv.
>
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.