[cabfpub] [EXTERNAL]Re: Ballot XXX: Update Discussion Period
Dimitris Zacharopoulos
jimmy at it.auth.gr
Mon Dec 11 16:37:16 UTC 2017
Perhaps I misunderstood Kirk's original intent so please correct me if
I'm wrong.
IMO the "editorial changes" proposal is independent to ballots being
discussed or voted on. The proposal is that at any time (_not during an
official ballot discussion or voting period_), if someone detects a typo
or an incorrect reference in a CA/B Forum document that fits the
definition of an "editorial change" (as noted in the W3C Process
Document provided by Virginia), that member may just send an e-mail to
the public list saying what the problem is and a recommended correction,
and that this is an "editorial change".
Examples that would probably qualify as "editorial changes" from past
cases:
1. "certificaet" to "certificate"
2. The name of the document "baseline requirements"
3. Incorrect references when the BRs were converted to RFC3647 format
Then, there are two possible routes:
1. If there is an objection made by a member, the change is no longer
considered "editorial" and it has to go through a separate ballot
process (changes proposed by a member, endorsed by two others,
discussed and voted on).
2. If there is no objection, it will be included in the text of an
upcoming ballot (whatever ballot that is), and this particular
change will be marked in the introduction section of the ballot as
"editorial change" or "errata", or whatever. It will be discussed
and voted along with the rest of the ballot language. Then, two
possible outcomes:
1. The ballot passes, and so are the "editorial changes"
2. The ballot fails, so the "editorial changes" will have to wait
for a next ballot
These "editorial changes" will always have to catch a "ballot train" in
order to be formally accepted. They can be introduced by any member when
there is no formal ballot discussion or voting period.
"Worst case scenario" I can think of:
1. The forum is discussing about a new ballot and the formal discussion
period starts at day X
2. A member introduces an "editorial change" _one day_ before day X.
3. The official discussion period for the new ballot begins, including
the text with the "editorial changes" at day X
4. Members have 7 days of official discussion to object to the
"editorial changes", in which case the ballot author and endorsers
will either remove these changes before the voting period begins or
let them be and risk the ballot failing.
I don't mind working on a separate ballot for this and let Gerv's ballot
go ahead. Would people support this? Do you see any other risks in this
process?
Dimitris.
On 10/12/2017 6:34 μμ, Ryan Sleevi wrote:
> Kirk, Dimitris,
>
> Could you explain how you imagine this process working? I think it's
> presently underspecified, highlighting Gerv's concerns.
>
> Here's just a small sample of realistic problems that would emerge:
> 1) At what point can such Editorial Changes be proposed? During
> discussion or during voting?
> 2) At what point are objections raised? What happens if votes were
> based on text that was Editorial, objections were raised that they're
> not Editorial, and in the retrospective analysis of the original
> language, the votes change?
>
> Working through a simple analysis of timelines and identifying at what
> point X can happen and at what point it can no longer happen would do
> a great service in identifying further deficiencies in the proposed
> language. I suspect that if we attempt to solve this problem, it will
> inevitably end up looking very similar to our voting procedures, since
> the design of those are to allow folks ample time to vote and to avoid
> confusion as to what is being voted on. Thus, I question the
> fundamental value.
>
> I appreciate the enthusiasm being applied for what members may see as
> 'simple' fixes, but as we know with substantive changes in process,
> these are hardly that.
>
> Further, I would encourage those proposing the "Editorial Language" to
> do so in a separate ballot. I think we'd be reasonably confident to
> say that this is not a problem being introduced by this Ballot,
> therefore, I would suggest we not attempt to solve it by attaching
> unnecessarily to this ballot.
>
> On Sat, Dec 9, 2017 at 7:44 PM, Kirk Hall via Public
> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>
> +1 – sounds good to me.
>
> Gerv – are you willing to make this change to your draft ballot?
>
> *From:*Dimitris Zacharopoulos [mailto:jimmy at it.auth.gr
> <mailto:jimmy at it.auth.gr>]
> *Sent:* Friday, December 8, 2017 3:24 PM
> *To:* Virginia Fournier <vfournier at apple.com
> <mailto:vfournier at apple.com>>; CA/Browser Forum Public Discussion
> List <public at cabforum.org <mailto:public at cabforum.org>>; Kirk Hall
> <Kirk.Hall at entrustdatacard.com
> <mailto:Kirk.Hall at entrustdatacard.com>>; Gervase Markham
> <gerv at mozilla.org <mailto:gerv at mozilla.org>>
>
>
> *Subject:* Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update
> Discussion Period
>
> Offering a previously stated suggestion.
>
> "Editorial changes" (the definitions 1 and 2 from W3C Process
> Document seem reasonable) must be proposed to the public list and
> clearly identified as such. If any voting member objects and
> considers such change as "not editorial", then the formal ballot
> process shall take place. if no objections are raised, then these
> editorial changes shall be applied along with changes approved via
> the next upcoming ballot.
>
> Does this make sense?
> Dimitris.
>
> On 8/12/2017 9:14 μμ, Virginia Fournier via Public wrote:
>
> Maybe we could state that “editorial” changes could be made
> without restarting the discussion period. “Editorial” could
> be defined something like 1 and 2 below (taken from the W3C
> Process Document):
>
>
> 6.2.5 Classes of Changes
>
> This document distinguishes the following 4 classes of changes
> to a specification. The first two classes of change are
> considered editorial changes, the latter two substantive changes.
>
> *1. No changes to text content***
>
> These changes include fixing broken links, style sheets or
> invalid markup.
>
> *2. Corrections that do not affect conformance***
>
> Changes that reasonable implementers would not interpret as
> changing architectural or interoperability requirements or
> their implementation. Changes which resolve ambiguities in the
> specification are considered to change (by clarification) the
> implementation requirements and do not fall into this class.
>
> Examples of changes in this class include correcting
> non-normative code examples where the code clearly conflicts
> with normative requirements, clarifying informative use cases
> or other non-normative text, fixing typos or grammatical
> errors where the change does not change implementation
> requirements. If there is any doubt or dissent as to whether
> requirements are changed, such changes do not fall into this
> class.
>
> *3. Corrections that do not add new features***
>
> These changes /may/ affect conformance to the specification. A
> change that affects conformance is one that:
>
> ·makes conforming data, processors, or other conforming agents
> become non-conforming according to the new version, or
>
> ·makes non-conforming data, processors, or other agents become
> conforming, or
>
> ·clears up an ambiguity or under-specified part of the
> specification in such a way that data, a processor, or an
> agent whose conformance was once unclear becomes clearly
> either conforming or non-conforming.
>
> *4. New features***
>
> Changes that add a new functionality, element, etc.
>
> Best regards,
>
> Virginia Fournier
> Senior Standards Counsel
> Apple Inc.
> ☏ 669-227-9595 <tel:%28669%29%20227-9595>
> ✉︎ vmf at apple.com <mailto:vmf at apple.com>
>
>
>
>
>
> On Dec 8, 2017, at 10:29 AM, Kirk Hall
> <Kirk.Hall at entrustdatacard.com
> <mailto:Kirk.Hall at entrustdatacard.com>> wrote:
>
> Gerv, this started as your ballot, so it's up to you - do you
> want to allow such minor edits without restarting the
> discussion period, or not?
>
> If yes, you need to put defining / permissive language in the
> ballot. I won't be comfortable if we have no written
> permission for edits, but then allow them informally later
> when ballots have errors - it needs to be in the ballot.
>
> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org]
> Sent: Friday, December 8, 2017 1:23 PM
> To: Kirk Hall <Kirk.Hall at entrustdatacard.com
> <mailto:Kirk.Hall at entrustdatacard.com>>; CA/Browser Forum
> Public Discussion List <public at cabforum.org
> <mailto:public at cabforum.org>>; Ryan Sleevi <sleevi at google.com
> <mailto:sleevi at google.com>>
> Cc: Virginia Fournier <vfournier at apple.com
> <mailto:vfournier at apple.com>>
> Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update
> Discussion Period
>
> On 08/12/17 18:17, Kirk Hall via Public wrote:
>
> Just putting the question to you in the abstract – do you
> think we
> should have to restart a seven day discussion just to
> correct an
> obvious typo?
>
>
> Let us say the answer to that question is "no". Then the
> obvious next question is: "how do you, the proponent of this
> idea, define 'obvious typo' in a way which does not open the
> door to substantive changes, or changes which people would
> argue about the substantiveness of, and without inventing Yet
> Another Voting/Polling Mechanism"?
>
> Gerv
>
>
>
>
> _______________________________________________
>
> Public mailing list
>
> Public at cabforum.org <mailto:Public at cabforum.org>
>
> https://cabforum.org/mailman/listinfo/public
> <https://cabforum.org/mailman/listinfo/public>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
> <https://cabforum.org/mailman/listinfo/public>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171211/c484e540/attachment-0003.html>
More information about the Public
mailing list