Commenting on PRs

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