<div dir="auto"><div>You cannot meaningfully vote on the PR without reviewing it. It is that simple. There is zero point in providing details beyond that as the PR is the details. The subject of the PR doesn't remove the need to read the details to form a view.<div dir="auto"><br></div><div dir="auto">The commentary on the PR and the code itself is what needs to be reviewed in order to form a view point - and that journey needs to be gone through if you want to offer a meaningful opinion on a PR.</div><div dir="auto"><br></div><div dir="auto">Any attempt to make a decision based on any form of summary of a PR is completely missing the point of participation in the review process - you might as well toss a coin to form your vote if you aren't going to look at the actual details. </div><div dir="auto"><br></div><div dir="auto">Reviewing the code changes and the comments is what is necessary for that purpose and the PR itself is where we want any additional comments to be made.</div><div dir="auto"><br></div><div dir="auto">Remember that this context is where and OTC member has placed a hold on a PR for a discussion and decision to be made and there is no clear consensus in the OTC meeting on the path forward or any OTC member wants a formal decision made for whatever reason. There is always a discussion prior to the vote being called.</div><div dir="auto"><br></div><div dir="auto">A substantial portion of the PRs result in one or more OTC member acknowledging that the didn't realise the PR meant what it means from having seen its title or summary description - and actually having to read the full commentary *and* the code to understand the context was absolutely necessary. </div><div dir="auto"><br></div><div dir="auto">Remember that someone has gone to the effort generally of raising and issue and the creating a proposed solution in a PR and multiple people have looked at it and provided feedback and one or more of them decided that we need a decision made for some reason (and those reasons widely vary). To make an informed decision reasonably requires reviewing all that information to form a view. </div><div dir="auto"><br></div><div dir="auto">There is no short cut to reading the PR itself and the vote text reflects that reality. </div><div dir="auto"><br></div><div dir="auto">In our OTC meetings we review the issues and review the PRs and we do that by going through the details - not by working off the title of the issue or PR.</div><div dir="auto"><br></div><div dir="auto">If you want to only comment on PRs off a summary list then go to GitHub and use its summary views to get that.</div><div dir="auto"><br></div><div dir="auto">We could perhaps even add another label with OTC vote pending which might get close to what you want in a single GitHub view. </div><div dir="auto"><br></div><div dir="auto">It won't avoid the need to actually read the details to be able to form a view prior to voting. <br><div dir="auto"><br></div><div dir="auto">Tim.</div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 29 Aug 2021, 22:35 Kurt Roeckx, <<a href="mailto:kurt@roeckx.be">kurt@roeckx.be</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I currently fail to see why you can't describe in words what you<br>
intend to fix. The PR itself has a subject, so have the commits.<br>
<br>
One of the reasons we have this vote is public is so that people<br>
reading this list can comment on it. Just some number doesn't tell<br>
them anything without having to go and look it up and spend time<br>
trying to understand. A simple summary of what we intend to vote<br>
on will help them understand if they want to look at this or not.<br>
<br>
If you feel that it should not be part of the vote text, can we at<br>
least have some introduction text?<br>
<br>
For instance PR 16203 was about adding the TLS 1.3 KDF. I can see<br>
several vote text for that:<br>
- Add the TLS 1.3 KDF to the provider in 3.0.<br>
- Add the TLS 1.3 KDF to the provider, and use it in the ssl library<br>
  in 3.0 so that TLS 1.3 can be used in FIPS mode.<br>
- Add support for using TLS 1.3 in FIPS mode in 3.0<br>
<br>
Most of our votes are not about how it's implemented, but really<br>
a general direction. As you say yourself, it's about proceeding in<br>
that direction. I don't see why you can't describe that direction<br>
with words.<br>
<br>
Some of the PR and issues we vote on have different view<br>
points based on the comments. Am I voting on the last comment<br>
made in the PR or issue? With a PR you can argue it's not the<br>
comments but the code, but what happens in case the PR is changed<br>
before I can vote? We have also voted on issue, were several<br>
things were mentioned in the issue, some things I agree we should<br>
do, others I don't.<br>
<br>
<br>
Kurt<br>
<br>
On Wed, Aug 04, 2021 at 08:25:59AM +1000, Tim Hudson wrote:<br>
> The votes on the PR are precisely that - to vote to proceed with the PR via<br>
> the normal review process - and that means looking at the varying<br>
> viewpoints.<br>
> If we reached a consensus that overall we didn't think the PR made sense<br>
> then we wouldn't form a vote of that form.<br>
> <br>
> What you are voting for is that what the PR holds is what makes sense to<br>
> proceed with - subject to the normal review process - i.e. this isn't a<br>
> push-the-PR-in-right-now vote - it is a "proceed" vote.<br>
> <br>
> A PR has a discussion in the PR comments, and generally an associated<br>
> issue, and always (as it is a PR) the suggested code change.<br>
> That is what is being voted on - to proceed with the PR - via the normal<br>
> review process.<br>
> <br>
> As otherwise the PR remains blocked on an OTC decision - and the OTC<br>
> decision is to not continue to block the PR (blocked on an OTC decision).<br>
> <br>
> Repeating again - the PR itself is what is being voted about - not a set of<br>
> different unstated viewpoints - it is what is in the PR - fix this problem<br>
> - and generally there is nothing critical seen in the code approach - but<br>
> our normal review processes still apply to handle it. Which means the PR<br>
> simply needs the two approvals.<br>
> <br>
> The majority of the time in the OTC discussions we are actually looking at<br>
> the PR details in terms of the code changes - we aren't reviewing it as<br>
> such (although that does sometimes happen on the call) - we are looking at<br>
> the PR code changes providing the additional detail to help in the decision<br>
> making.<br>
> <br>
> There are very few PRs which describe what is going to change in a useful<br>
> form independent of the code changes - they don't usually state things like<br>
> what is going to be changed - they are focused on what is wrong and the PR<br>
> is going to fix it - there isn't usually anything meaningful about what is<br>
> going to be changed in order to fix what is wrong.<br>
> <br>
> A PR doesn't hold a range of code fixes to choose between - it holds a<br>
> discussion (comments) and a specific code fix - and perhaps that specific<br>
> code fix is the result of a sequence of code fixes that have evolved<br>
> through the discussion.<br>
> <br>
> So the precise viewpoint you are voting for in those PRs is to proceed to<br>
> include that PR in the work for the current release while continuing to use<br>
> our normal review and approval processes - that is the vote text - and it<br>
> makes the intent of the vote.<br>
> <br>
> Where there is a view that we should not take a particular approach<br>
> represented in a PR and should take an alternate approach then we don't<br>
> form a vote that way - we actually allocate someone to produce an alternate<br>
> PR. Often we leave the initial PR and alternate PR open until such time as<br>
> we can compare the approaches in concrete form and then we can make a<br>
> decision - but that would be accepting one PR over another PR. We have had<br>
> "competing" PRs regularly - and we then vote on the alternatives - where it<br>
> is clear what the alternatives are. A single PR vote is about that PR.<br>
<br>
> On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx <<a href="mailto:kurt@roeckx.be" target="_blank" rel="noreferrer">kurt@roeckx.be</a>> wrote:<br>
> <br>
> > On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote:<br>
> > ><br>
> > > This isn't about the OTC meeting itself - this is about the details of<br>
> > the<br>
> > > topic actually being captured within the PR.<br>
> > > You need to actually look at the PR to form a view. And we do add to the<br>
> > > PRs during the discussion if things come up and we review the PR details.<br>
> > > So the vote isn't about an OTC discussion - the vote is precisely about<br>
> > the<br>
> > > PR itself.<br>
> > ><br>
> > > One of the things we have explicitly discussed on multiple calls is that<br>
> > in<br>
> > > order to be informed of the details, you need to consult the PR which<br>
> > has a<br>
> > > record of the discussion and often viewpoints that offer rather different<br>
> > > positions on a topic - and those viewpoints are what should be being<br>
> > > considered.<br>
> ><br>
> > I am happy to read the issue/PR to see the different view points.<br>
> > But different viewpoints is exactly the problem, which of those am<br>
> > I voting for?<br>
> ><br>
> > During a meeting, there probably was a consensus about what you're<br>
> > actually voting for, but that information is lost.<br>
> ><br>
> > In general, I want a vote to be about what is going to change, the<br>
> > how isn't important most of the time.<br>
> ><br>
> ><br>
> > Kurt<br>
> ><br>
> ><br>
</blockquote></div></div></div>