OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]

[Tim Hudson]

The votes on the PR are precisely that - to vote to proceed with the PR via
the normal review process - and that means looking at the varying
viewpoints.
If we reached a consensus that overall we didn't think the PR made sense
then we wouldn't form a vote of that form.

What you are voting for is that what the PR holds is what makes sense to
proceed with - subject to the normal review process - i.e. this isn't a
push-the-PR-in-right-now vote - it is a "proceed" vote.

A PR has a discussion in the PR comments, and generally an associated
issue, and always (as it is a PR) the suggested code change.
That is what is being voted on - to proceed with the PR - via the normal
review process.

As otherwise the PR remains blocked on an OTC decision - and the OTC
decision is to not continue to block the PR (blocked on an OTC decision).

Repeating again - the PR itself is what is being voted about - not a set of
different unstated viewpoints - it is what is in the PR - fix this problem
- and generally there is nothing critical seen in the code approach - but
our normal review processes still apply to handle it. Which means the PR
simply needs the two approvals.

The majority of the time in the OTC discussions we are actually looking at
the PR details in terms of the code changes - we aren't reviewing it as
such (although that does sometimes happen on the call) - we are looking at
the PR code changes providing the additional detail to help in the decision
making.

There are very few PRs which describe what is going to change in a useful
form independent of the code changes - they don't usually state things like
what is going to be changed - they are focused on what is wrong and the PR
is going to fix it - there isn't usually anything meaningful about what is
going to be changed in order to fix what is wrong.

A PR doesn't hold a range of code fixes to choose between - it holds a
discussion (comments) and a specific code fix - and perhaps that specific
code fix is the result of a sequence of code fixes that have evolved
through the discussion.

So the precise viewpoint you are voting for in those PRs is to proceed to
include that PR in the work for the current release while continuing to use
our normal review and approval processes - that is the vote text - and it
makes the intent of the vote.

Where there is a view that we should not take a particular approach
represented in a PR and should take an alternate approach then we don't
form a vote that way - we actually allocate someone to produce an alternate
PR. Often we leave the initial PR and alternate PR open until such time as
we can compare the approaches in concrete form and then we can make a
decision - but that would be accepting one PR over another PR. We have had
"competing" PRs regularly - and we then vote on the alternatives - where it
is clear what the alternatives are. A single PR vote is about that PR.

Tim.


On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx <kurt at roeckx.be> wrote:

> On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote:
> >
> > This isn't about the OTC meeting itself - this is about the details of
> the
> > topic actually being captured within the PR.
> > You need to actually look at the PR to form a view. And we do add to the
> > PRs during the discussion if things come up and we review the PR details.
> > So the vote isn't about an OTC discussion - the vote is precisely about
> the
> > PR itself.
> >
> > One of the things we have explicitly discussed on multiple calls is that
> in
> > order to be informed of the details, you need to consult the PR which
> has a
> > record of the discussion and often viewpoints that offer rather different
> > positions on a topic - and those viewpoints are what should be being
> > considered.
>
> I am happy to read the issue/PR to see the different view points.
> But different viewpoints is exactly the problem, which of those am
> I voting for?
>
> During a meeting, there probably was a consensus about what you're
> actually voting for, but that information is lost.
>
> In general, I want a vote to be about what is going to change, the
> how isn't important most of the time.
>
>
> Kurt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20210804/c7773659/attachment.html>