AW: Commenting on PRs

Hi Pierre-Antoine, Thomas and all,

I also do not remember the meeting in which I mentioned the forms of consensus. But the pointer to the process document is really helpful. Also, the note on the flexibility we have to obtain consensus can help us to find new ways of moving faster forward.

Best,

Felix

Am 17.01.25, 19:26 schrieb "Pierre-Antoine Champin" <pierre-antoine@champin.net>:
Dear Thomas,

to continue the discussion that started in
https://github.com/w3c/rdf-primer/pull/16, but derailed into something
more general:

> > > > Strong concerns [can be addressed in more detailed follow-ups,
making it easier to review particulars. ]
> > >
> > > Why only "strong" concerns?
> >
> > Those can and should be addressed; minor concerns may, if there is
time (which I surely hope).
>
> I find that this limits my chance of participation. It seems to
suggest that I was too late with my eventually "not strong" concerns,

It does not suggest that your concerns are not strong, nor than it is
too late.
On the contrary, it encourages you to let the PR be merged, and *then*
make a subsequent PR to address your concerns if you consider that they
are worth the WG's time.

(again, when this was written, you had not yet expressly said that you
were OK to merge the PR, and rather given the opposite impression --
more about this below)

> but  - there was no date set until which comments had to be made, -
there is still a lot of time,

What is the basis for that latter claim?
The WG was supposed to finish in August. We have requested a new charter
which has not been accepted yet,
and if it gets accepted, we are supposed to be done with the deliverable
in one year.
So we are, generally, in a hurry.

> - work had stalled for weeks because of the holidays anyway, - no one
knows when @franconi will find the time etc. Also, what if @franconi has
only "not strong" concerns as well?

Blaming people nominally or playing them off against each other is not
an OK behavior.
I guess this was written with those specific intentions, but it still
comes out as aggressive (at least to me).

> I think you should be more flexible. Approvals right now IMO can only
ever refer to a current state and are to be understood as some kind of
strawpoll. The only approval that really counts is on the final version
before publishing.

To your latter sentence: exactly! So merging a PR should not be
considered a big deal. Other PRs can come after and undo what was
wrongly done in it... What matters is if the PR moves us in the right
direction, not whether it moves us to perfection.

> Granted, I'm not an expert on W3C process and if there is a document
somewhere that describes the expected required process in more detail
I'll gladly take a link.

There is no specific guidelines about how to manage github PRs (each
group can basically decide how they want to do that). But the general
understanding is that the thread in a PR is to discuss this PR itself,
and to stop when the PR is ready to merge. Furhter discussion can happen
in issues, or other PRs.

By continuing the discussion in the PR thread, you gave the impression
that you wanted to prevent its merging. It turns out that it was not
your intention, but that's how I (and, I suspect, others) have
interpreted it.


Finally, about the distinction of strong concerns vs. minor concerns, I
refer you to the definition of "Consensus" in the process document:
https://www.w3.org/policies/process/#Consensus

In a nutshell: consensus is not necessarily unanimity. We are not
looking for a solution that everyone likes, but a solution that most
people like, and those who don't can still live with. (A point that
Felix made some time ago in a WG meeting -- I'm too lazy to find the
corresponding minutes right now...).

When a decision gets significant traction in the group, those of us who
do not like it it need to decide how bad they dislike it. In particular,
we must balance this dislike to the cost to the group... Spending more
time discussing a given decision means less time to discuss others,
meaning that we may fail to include other good things in the spec, or
even fail to publish the spec at all...

I hope this helps.

  pa