Re: Commenting on PRs

Hi Pierre-Antoine,

> On 17. Jan 2025, at 19:25, Pierre-Antoine Champin <pierre-antoine@champin.net> wrote:
> 
> 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.

Good to hear, but it sure felt that way. 

> On the contrary, it encourages you to let the PR be merged, and *then* make a subsequent PR to address your concerns

It is always harder to change something that has already been merged.

> if you consider that they are worth the WG's time.

I sure do.

> (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.

Of course we are, but IMO we are not that much in a hurry that my first comment on the document, before the first merge, without any deadline given, and while the editors are still waiting for comments from other WG members, should be met with constraints like "strong vs minor" and "time permitting". 

In fact nobody clearly knows where we are w.r.t. time, so I suggest we try to keep the ticking clock in mind, but also try not too let that ticking get louder than the actual conversation.

> > - 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’m not blaming anybody, and I’m also not playing people aginst each other, and you shouldn’t accuse me of that. In fact turning my question if I’m treated like everybody else into a question if I’m blaming people or playing them against each other is irritating.

> I guess this was written with those specific intentions, but it still comes out as aggressive (at least to me).

I guess you missed a "not" in that sentence. Instead of sensing anyhing you might concentrate on the facts: Niklas is waiting for Enrico’s comments but not for mine. Mine will be subject to dsiambiguation between "strong" and "minor" concerns, and are put under a "time permitting" constraint. I think it is understandable that all those caveats might make me worried if my concerns are considered with the scrutiny they deserve. I’m not playing people against each other, but you must excuse if I have questions if I'm treated as equal. 

> > 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.

I asked why it wasn’t merged already, and the answer was that Enrico’s comment is waited for. So it is a big deal, or at least a big deal w.r.t. him, but not w.r.t. me?

> > 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.

And what is "ready to merge"? This goes in circles. Niklas and you are the editors of this document. I’ve stated my concerns about the PR. Reacting on Niklas I’ve voiced my concerns of how my concerns wrt the PR are met. I suggested that you address them right away (and I just now posted a comment reflecting my current state of thinking after the discussion we had so far). You should proceed as you think is right. But don’t accuse me of aggressivness or read some "playing people aginst each other" between the lines when I clearly and comprehensibly voice my concerns. 

> 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.

That is a strange reading, and also a strange dichotomy. Of course I want my concerns being taken into account. If merging was done often and early I would not have any problem here. But there is a discrepance with how you describe merging and with how it seems to be handled in practice. On the one hand you ask me to act as if merging was something that happens early and often, on the other hand you do in fact handle it as if it it was something very special ("no more changes because poeple appoved already", "still waiting for XXX to comment") and you use that handling as argument for not incorporating (or rejecting) my concerns now. That clearly leaves a gap, a gap in which I fear my concerns to disappear.

> 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.

I’m well aware of the constraints that reality imposes on us, and of how consensus is achieved. I don’t think I’m overly enarmoured with my own concerns and I do disambiguate between what I think are strong or minor concerns. I do also know about the need and what it takes to compromise. Those of course are very subjective assessments, and maybe a bit too self-flattering.

The fact however that you don’t acknowledge and presumably can’t see how my concerns about process came to be, but instead see aggressiveness and the need to point out time constraints, still makes me think that you don’t understand my position. I hope I made myself somewhat clearer, but I don’t want us to continue this conversation. I suggest we leave it at this and continue with the actual work, as good as we can. I’m not telling you how to do your work as an editor, but maybe the discrepancy I outlined above between how you describe the role of merging and my perception of how it is actually handled will be of use to you.


Best,
Thomas


> 
>   pa
>

Received on Monday, 20 January 2025 13:45:06 UTC