<div dir="ltr"><div>Apologies for not having double-checked that the endorsement in principle carried over to the draft ballot. I think historically, ballot authors have sent direct messages to confirm endorsers were on-board as proposed and have double-checked everything.</div><div><br></div><div>Although I was listed as endorser, this wasn't something I'd had a chance to review / was not even aware changes had been made since we reviewed and endorsed, and it's something we plan to vote NO on, for two reasons:</div><div><br></div><div>1) The way this ballot updates the effect dates implies a normative requirement, but this is explicitly something we've called out as non-normative (because the Chair is allowed to update)</div><div>2) By placing this requirement here, this also in our bylaws *prevents* the Chair from assigning a new version or making edits, meaning this would be a "second" 1.7.3. That would not be good.<br></div><div><br></div><div>I realize this approach to effective date was added late (compared to the original text), which is what lead to both of these problems. It's entirely understandable how, so I hope it doesn't seem like I'm trying to point fingers, but trying to capture the context.</div><div><br></div><div>To answer Aaron's questions directly, below<br></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="color:rgb(0,0,0)">1) For ballot authors, where are standards/requirements like this documented? As someone relatively new to this community, the structure of this ballot seemed reasonable to me: there are not currently any other ballots in the pipeline which will be effective prior to the chosen date of July 1, so simply noting "this document has changed, and that change will go into effect on July 1" seems sufficient. How do we clearly document ballot best practices and style guides?</span></blockquote><div><br></div><div>Normally this is captured during the drafting and discussion period. I think the fact that we've had a number of ballots in the discussion period, some being kept alive even though their authors have made clear they do not expect to make progress, and others because they've been holding back, have made it harder to follow the active discussions on these. As time goes on, some of the context slips, and bugs like this crack in.</div><div><br></div><div>While we've talked about a style guide for presentation, the style guide for normative requirements here might be premature, judging by the challenges we've faced in the past. However, historically, we've explicitly added the effective date stated where the requirement is, and then cleaned up that language as part of the spring/fall cleanup ballots once that date has passed. For example, 4.9.10, 7.1.4.1, 7.1.6.4, and 7.2.2 of the BRs 1.7.3 all show examples of the approach for expressing such requirements, and then usually that specific sentence is subsequently removed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2) For the community, why was this issue not raised during the discussion period? The discussion period should not simply be a week-long waiting period, with folks only reading the actual redline once voting begins. How do we incentivize active review and discussion at the appropriate point in the process?<br></blockquote><div><br></div><div>Welcome to the CA/B Forum, where this has _always_ been a problem :)<br></div><div><br></div><div>Ideally, folks would participate and discuss prior to the discussion period. However, as we've seen for years, these discussions can go on indefinitely without resolution, as folks continue to bring up the same points and they're addressed the same way, but then forgotten before the next F2F. This is, for example, why CAA took so long - we just kept going in circles on the same talking points.</div><div><br></div><div>It would, ideally, be caught during the discussion period, but folks' priorities for reviews change, or they may not be aware that there are subtle differences from what was discussed vs what is actually proposed in the discussion period. Sometimes, in the rush to get a ballot out, minor tweaks are made that folks don't fully appreciate the implications of (e.g. as in this case), and aren't caught until voting. The same can be said for root program updates, since sometimes, a root program update spans months, has many fragmented discussions going on in parallel, and can be hard to find all the relevant changes being proposed and their interactions.</div><div><br></div><div>That said, having a ballot fail for reasons like this is not a big deal, and has happened in the past, and just delays things by two weeks (one week to finish voting, one week to start a new discussion period), while often leading to improvements.</div></div></div>