<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
Dear Members,<br>
<br>
Following-up on an issue that came up during the <a
href="https://lists.cabforum.org/pipermail/servercert-wg/2024-January/004133.html">discussion</a>
of a ballot in the server certificate WG, I created
<a class="moz-txt-link-freetext" href="https://github.com/cabforum/forum/issues/42">https://github.com/cabforum/forum/issues/42</a> and hope to discuss at
the next F2F, but we could start earlier using the mailing list.<br>
<br>
IMO every code management system MUST have a process to address
"conflicts" that may be caused when two independent processes try to
update the same part of a document. The current language in the
Bylaws do not <b>require </b>the proposer to describe what the
outcome of the ballot should be if a previous ballot passes or
fails. It leaves this at the discretion of the proposer of the
subsequent ballot.<br>
<br>
Do others see this as a risk that needs to be addressed firmly in
the Bylaws, changing the "may" into a "shall"? <br>
<br>
In practice, the proposer of a subsequent ballot would need to
include two versions of the language of the conflicting section:<br>
<ol>
<li> the language of the section if both ballots A+B pass</li>
<li>the language of the section of ballot A fails and ballot B
passes</li>
</ol>
<p>It doesn't seem too much of a burden to me and the benefits are
obvious (removal of the risk of creating an unstable end state of
the conflicting section).</p>
<p>Happy to hear other opinions.</p>
<p>Dimitris.<br>
</p>
</body>
</html>