Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] New Model for IEEE Standards Maintenance



Adrian-

It certainly is true that folks make misteaks. I believe that is an argument for my method. I also believe that this is mostly about managing the expectations of the working group as to will do the work and when. It SHOULD be the burden of the amending Task Group to prove to and convince the larger Working Group that: 1) A change to the base standard is needed to accommodate their amendment.
    2) That the change they propose will do no harm.
It is at the point that they are trying to make their case that you want everybody else to keep their eyes on them and the new text.

The time to have the system EXPECT to do the work is during the amendment development process. I assert that if the explicit expectation is that the revision process is to clean up the mess that the amendment makes, then folks will fall to the occasion and make the job worse at revision time. In particular, it should be emphasized to the comment resolution group that one of their major responsibilities is to not break the standard.

My experience in an engineering situation is that problem never get easier or cheaper to fix by putting them off.

When you set expectations that merge problems will be handled later by the revision process you set yourself up for:
    1) Having fewer eyes look at it when the time comes
(Sponsor companies want to pay for new standards, not maintaining last years already approved project) 2) Setting up a situation that generates interpretation and maintenance requests.

All of this is not to say that there should be no technical diligence when it comes down to the editorial merge. Rather, I argue that most of the work should be able to be done and should be done by the editing staff. They (of course) absolutely should have a core technical expert on their speed-dial while they are doing it. This is (almost) the court of last resort. Therefore the system should not be set up to load the work in there.

Best regards,

    Geoff

On 4/2/11 11:17 PM, Stephens, Adrian P wrote:

Hello Geoff,

What I'm saying is that those people who created the amendment did so with all due diligence, the IEEE-SA

professional editing staff did their work with all due diligence, and yet, when I come to roll in that amendment,

I discover that mistakes have been made, and a strict interpretation of the editing instructions is not

possible.

This is my experience with 802.11, where I'm currently rolling in a 400-page amendment # 8.

It may be that this should not be the case. Perhaps we should pay our volunteers more, and insist that they

are intimately familiar with all ~2200 pages of the existing standard before being allowed to contribute any

material to it. I would like to see the changes to the IEEE-SA rules that would achieve this ;0)

We're all human, and humans make mistakes. Saying "it should not be" doesn't change this. Our systems

(i.e. balloting and resolution by committee) reduce, but do not eliminate, the probability of errors in

published amendments.

Best Regards,

Adrian P STEPHENS

Tel: +44 1954 204 609 (office)
Tel: +44 792 008 4900 (mobile)
Skype: adrian_stephens

----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

*From:* Geoff Thompson [mailto:thompson@ieee.org]
*Sent:* Saturday, February 05, 2011 12:57 AM
*To:* Stephens, Adrian P
*Cc:* James P. K. Gilb; Grow, Bob; tony@JEFFREE.CO.UK; STDS-802-SEC@LISTSERV.IEEE.ORG
*Subject:* Re: [802SEC] New Model for IEEE Standards Maintenance

Adrian-

I'm afraid that I have to take an opposing view on this.
My experience has been that the time to present these changes to existing text is at the time when the amendment is initially put up for approval. That is the point in time when the most eyes examine the draft and that is exactly what is needed for this sort of exercise.

Kicking this portion of the problem down the road to be resolved at revision time only sets things up for a number of problems: 1) inconsistencies/conflicts will produce WG overhead in errata and requests for interpretation if it isn't done right the first time 2) Editing for revisions is work that is more difficult to get funded than editing for a new project with the carrot of new products 3) Close scrutiny in voting for revisions is work that is more difficult to get accomplished than the equivalent effort for a new project with the carrot of new products.

It is a challenge to handle multiple edits to the same area when more than one project is in Sponsor Ballot but I believe there are extensions to editing tools that can display this and that the proper text reconciliation work should be done as early as possible when the task groups are still at the height of their participation.

Amendments are supposed to have clean enough editng instructions that generating an edition is an exercise that only takes expertise in operating editing tools. No expertise in the subject matter should be required. No ambiguities should be encountered. Those should have been seen and resolved during project balloting.

Having standing conflict in a published standard is at worst bait for a lawsuit.

Best regards,
    Geoff

On 2/2/11 10:32 PM, Stephens, Adrian P wrote:

Hello James,
I think I'd go further than that. IMHO, any complex amendment
is likely to contain errors that make a strict interpretation of its
editing instructions impossible.  (e.g. I'm just about to roll in a
400-page amendment #8.)
When a revision is active, the editor can highlight these inconsistencies/conflicts
either to the group responsible for making changes,  or to the balloters by comments
in the draft revision.
I'm not sure how this should be treated in the case of an Edition.
If the editor is aware of a conflict,  should he highlight this,  or silently
ignore it?
This is separate from the question of whether the editor correctly interpreted
the instructions in the amendment.
Best Regards, Adrian P STEPHENS Tel: +44 1954 204 609 (office)
Tel: +44 792 008 4900 (mobile)
Skype: adrian_stephens
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-----Original Message-----
From:owner-stds-802-sec@ieee.org  <mailto:owner-stds-802-sec@ieee.org>  [mailto:owner-stds-802-sec@ieee.org] On Behalf Of James P. K. Gilb
Sent: Thursday, February 03, 2011 12:54 AM
To: Grow, Bob
Cc:tony@JEFFREE.CO.UK  <mailto:tony@JEFFREE.CO.UK>;STDS-802-SEC@LISTSERV.IEEE.ORG  <mailto:STDS-802-SEC@LISTSERV.IEEE.ORG>
Subject: Re: [802SEC] New Model for IEEE Standards Maintenance
All The only issue I have with editions is that they should still have some
technical review to make sure that no mistakes were made.
Although we try hard, when you have 3 amendments modifying the same
location in a base standard, it may take some technical expertise to
make sure everything came out right.
It could be as simple as the Sponsor assigning a group of reviewers to
assist the editors.  Then it could be a simple approval by the Sponsor
that based on the opinion of the reviewers, the edition is OK for
publication.
James Gilb On 02/02/2011 09:01 AM, Grow, Bob wrote:
    Tony:

    I have been working with publication staff on publishing all amendments, corrigenda and errata as editions.  Publication staff has been generally favorable to this, the only identified negative is product pricing (why do I have to pay for all 3500 pages of 802.3 when I already have it and only want the new 50 pages).

    If you or others are interested, I can provide details on what I've proposed.  I'm certainly willing to accept support, and constructive criticism as well for any IEEE-SA participants.

    Your proposal to do editions at least every three mitigates the pricing issue because a revision presents the same situation.

    --Bob

    -----Original Message-----

    From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-SEC@ieee.org] On Behalf Of Tony Jeffree

    Sent: Wednesday, February 02, 2011 4:03 AM

    To:STDS-802-SEC@LISTSERV.IEEE.ORG  <mailto:STDS-802-SEC@LISTSERV.IEEE.ORG>

    Subject: [802SEC] New Model for IEEE Standards Maintenance

    Reflecting on this new model, I have a couple of observations.

    As I said on the conference call, I don't believe that the changes as

    outlined are of any great benefit (or dis-benefit for that matter) to 802,

    which seems to be a wasted opportunity when I believe that a simple change

    COULD be made that would actually be of benefit.

    I have never understood the point of the 3-year revision rule - apparently

    it is OK to have a gozillion amendments approved in years 1-3 after a

    revision, and all is OK for those 3 years, but suddenly at the end of year

    3, it is not-OK anymore. That makes no sense to me whatever, and will make

    even less sense once the revision cycle moves to 10 years.

    What would make far more sense to me would be to lose the 3-year revision

    rule, and instead, impose a requirement to produce an Edition when there are

    N amendments (where N probably equals 3) that haven't previously been

    incorporated into a revision or an edition. That would materially improve my

    situation in 802.1, as it would remove an arbitrary requirement to revise

    after 3 years when an editorial roll-up would be entirely sufficient to the

    needs both of the readership and the WG. Producing editions on a regular

    basis is in any case something that I try to do with 802.1Q already.

    Regards,

    Tony

    ----------

    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.