[Servercert-wg] Document Versioning

[Ryan Sleevi]

On Sun, Aug 18, 2019 at 4:39 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 17/8/2019 9:21 μ.μ., Ryan Sleevi wrote:
>
>
> On Sat, Aug 17, 2019 at 3:46 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>> Until today, the Chair or Vice-Chair was assigning numbers to documents.
>> If you want us to have a consistent numbering scheme with major and minor
>> numbers, you could propose such a scheme in a Bylaws update. We could also
>> add it in the topics for discussion in an upcoming governance subcommittee.
>>
>> This is more of an administrative issue and should be disconnected from
>> the ballot language.
>>
>
> Hi Dimitris,
>
> I forked this thread so as to hopefully disconnect.
>
>
> +1
>
> As you no doubt recall, given that it's come up with numerous F2F and
> phone conversations, we don't really have a process in place to allow the
> Chair and Vice-Chair to make modifications to Ballots as they're adopted.
> The inclusion of informative revision history, within our documents, also
> means that we can't simply take the document as-is and allow the chair to
> ascribe a version to it.
>
>
> I disagree. Looking back, this has always been the case with the Final
> Maintenance Guidelines. The Chair assigned a version number and updated the
> informative revision history. In some cases, the Chair also updated the
> "relevant dates" table when the ballot proposer forgot to include this. All
> Members accepted this procedure and so far no objections have been raised.
>

Would it be useful to dig up the minutes that contradict this summary?


> Despite this, you can see I tried to explicitly make it clear in the
> Ballot what the Chair or Vice-Chair could change, in order to ensure that
> these changes were captured by Ballot.
>
>
> I noticed that, it looks good. We could also ballot a procedure to support
> what you wrote in SC22 so we don't have to repeat this in every ballot.
>

Yes, that's definitely a solution. I'd love to find something even
better/easier, so we can formalize the informal process in a way that does
not create any concerns or risks. Hopefully that should be uncontroversial.
However, in the absence of such formalization, I've tried to work within
the rules we have written down.


> With that said, and although I do not object to your proposed scheme
> (changing the BRs to 1.8 instead of 1.6.6 and the EV Guidelines to 1.8
> instead of 1.7.1), I disagree with this being proposed in the ballot
> without prior discussion. It creates a disconnect to the existing
> versioning. The CABF has been using a consistent numbering scheme since
> version 1.4.2 in the EVG and 1.3.0 in the BRs. Suddenly both documents will
> "jump" to 1.8. What if another member proposes a ballot updating the
> documents to another arbitrary number like "100"?
>

The discussion period of the Ballot is 2 weeks. I'm not sure if you're
suggesting there should be a pre-ballot discussion period, and perhaps even
a pre-pre-ballot discussion period, in addition to a Ballot discussion
period, and to what extent language should be expected to be finalized at
each step. As several members have noted on the past phone calls, the best
way to get feedback is to put the actual, final text out there, as a
Ballot, so that feedback is gathered during the discussion period.


> I agree that we could potentially change our Bylaws or the process for
> Ballots within the respective CWGs, since it functionally ties to the Final
> Guideline / Final Maintenance Guidelines of the CWGs, to allow the Chair or
> Vice-Chair additional flexibility here. As I've stated in the past, I'm
> supportive of viewing those two respective sections in our documents
> (version history and effective dates) as informative, non-normative
> sections - i.e. having no binding weight on members - and thus supportive
> of allowing flexibility to edit. I also support that flexibility for
> versions.
>
> However, as we don't have that flexibility now, I thought it best to play
> it safe.
>
>
> As we are getting closer to moving the "canonical versions" on GitHub
> (that requires change to the Bylaws), I'm sure this flexibility will be
> covered one way or the other.
> However, when we have an established practice for years with no objections
> or problems, this automatically becomes kind of a norm. I think it is safe
> to continue with the existing precedent until we can discuss separately and
> get consensus on a versioning scheme.
>

That's certainly an option! And that's why it's important to formalize some
of our processes. Luckily, as this is a Ballot, and not an ad-hoc decision
by a member to reinterpret a portion of our Bylaws, we have the opportunity
to discuss and vote on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190819/3df6055a/attachment-0001.html>