Right, I'm totally in line with the "Send it when it's ready" - but I'm concerned about the last minute changes -> force to a vote approach.
It has the downside of changing what is, today, effectively 14 days review - since review can start during the discussion phase, ideally feedback can be provided in the first 7, and voting doesn't end until 7 days after - into a 7 day review, as there may have been last minute changes introduced. That's why I see that flexibility as being a bit undesirable; in the best case, it allows unintentional harm and, to some extent, this change would encourage that pattern. I guess I'm curious - are there cases where having to restart the 7 day discussion clock would be undesirable? The only situation I could think of was time-sensitive changes, but I think we both agree that those are a symptom of a bigger problem and not the thing to optimize for. Another positive benefit of the 'mandatory' 7 day review is that it allows for actionable feedback to be provided by our Interested Parties and Associate Members. That is, their feedback can inform further changes and corrections (with a clock restart), whereas without a forced clock restart, there's no way to incorporate that feedback short of a 'no' vote. Mandatory minimum time to review (final) text is fairly common in a number of organizations - both SDOs and legislative - and doesn't seem as if it would be too onerous. On Tue, Dec 5, 2017 at 3:26 PM, Tim Hollebeek <[email protected]> wrote: > I’m actually extremely supportive of this line of reasoning. That’s why > this ballot actually LENGTHENS the discussion period for all ballots. I > agree that “fix it later” is horrible, and that it is better to take up to > 30 days to get it right (I’d even support lengthening that number if people > want to do so). It’s the arbitrariness of “voting starts immediately after > seven days, regardless of where the discussion has gone” that drives those > bad decisions. I want to fix the perverse incentive that puts us in those > bad situations. > > > > -Tim > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Tuesday, December 5, 2017 1:19 PM > *To:* Tim Hollebeek <[email protected]> > *Cc:* CA/Browser Forum Public Discussion List <[email protected]> > > *Subject:* Re: [cabfpub] Pre-ballot: Ballot discussion ends when > discussion ends, and not before > > > > There have been more cases of bugs being introduced through changes than > there have been of typographical errors. There's also been the repeated > suggestion to "let it pass, and fix it afterwards" - which has also shown > to be a regular poison pill for discussion and deferring solving real > problems. > > > > To the extent the Forum provides a valuable venue to deconflict > requirements between various browser programs, it would seem avoiding > conflicts and forced 'no votes', particularly from browsers, would be > better. Otherwise, I can easily see the Baseline Requirements being less > valuable as input into Browser requirements or the accepted audit criteria > if unnecessary or controversial changes are rushed in. > > > > I can understand the argument against would be that such changes could > delay much needed fixes that are time sensitive. But we've also seen those > 'much needed' fixes themselves are the result of inadequate review and last > minute changes, which yet again argues for a thoughtful deliberation as to > what will become the common requirement. > > > > On Tue, Dec 5, 2017 at 3:10 PM, Tim Hollebeek <[email protected]> > wrote: > > Thanks for the two editorial comments; they are helpful and I will include > them. > > > > My position remains the same as it was in the previous thread: if you > believe you need more time to understand the ballot, you are free to vote > no. But people don’t need seven days to analyze an effective date that was > accidentally omitted. There have been other similar cases over the last > few years. > > > > I intentionally left gaining consensus up to the proposer, and they may do > so by any means they feel is appropriate. This may include waiting seven > days after making complex changes, to give people time to analyze them. > > > > -Tim > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Tuesday, December 5, 2017 1:03 PM > *To:* Tim Hollebeek <[email protected]>; CA/Browser Forum Public > Discussion List <[email protected]> > *Subject:* Re: [cabfpub] Pre-ballot: Ballot discussion ends when > discussion ends, and not before > > > > > > > > On Tue, Dec 5, 2017 at 2:41 PM, Tim Hollebeek via Public < > [email protected]> wrote: > > > > Now that I have a bit more time, I’d like to propose a ballot that we > discussed with Gerv after the recent CAA voting snafu. The current bylaws > require the proposer to predict in advance how long the discussion period > will be. We’ve had a few cases where we’ve had to choose between > withdrawing a ballot and starting over (with a week delay …) and going > forward with an imperfect ballot. We should have the time and flexibility > to get ballot right, even if a flaw is noticed late in the discussion > period. I included Gerv’s proposal to sunset abandoned ballots. > > > > While I was modifying the voting rules, I decided to make it clear that > the ballot can be modified in response to concerns identified during the > discussion period. We’ve always operated that way, so I thought I’d make > it clear in the bylaws. > > > > The change is in github here: > > > > https://github.com/cabforum/documents/compare/master... > timfromdigicert:patch-1 > > > > -(c) A representative of any Member can call for a proposed ballot to be > published for discussion and comment by the membership. Any proposed ballot > needs two endorsements by other Members in order to proceed. The discussion > period then shall take place for at least seven but no more than 14 > calendar days before votes are cast. The proposer of the ballot will > designate the length of the discussion period, and each ballot shall > clearly state the start and end dates and times (including time zone) for > both the discussion period and the voting period. > > +(c) A representative of any Member can call for a proposed ballot to be > published for discussion and comment by the membership. Any proposed ballot > needs two endorsements by other Members in order to proceed. The discussion > period then shall take place for at least seven calendar days. After seven > days, wheneverr the proposer feels the ballot is ready for voting, he shall > repost the ballot, incorporating any changes based on feedback from the > discussion period. However, if 30 days elapse from the beginning of the > discussion period without voting having started, the ballot will be > considered withdrawn. The ballot shall clearly state the start and end > dates and times (including time zone) for the voting period. > > > > Comments? Endorsers? > > > > There's a typo -> wheneverr should be whenever > > There's some unnecessary gendered language, "he shall repost" -> "The > proposer shall repost" > > > > That said, I'm uncomfortable with the idea of last minute changes to > trigger the vote. As captured during the previous discussion, it may make > more sense to have changes restart discussion to allow adequate review - > especially of the implications of the change. I think the Ballot 190 > discussions captured a number of ways in which the attempts to solve the > problem kept introducing new problems, especially if the proposer may be > misunderstanding the concerns. > > > > I think the end state should be "Members have at least 7 days to review > the final ballot and submit feedback" > > > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
