Unfortunately in many large RFC discussions repetition means visibility.
Anyway, as someone in the "explicit over implicit" camp I sometimes just give a thumbs-down instead of a comment because I don't want to derail the discussion with another rehash of "is explicit really explicit". In that way the thumbs-down works as a signal of disagreement without stepping into the line of fire.
If I see a well-put comment that I agree with, I'll give it an upvote, but Github discussions make it very easy for those to be overlooked. In my experience the key to getting heard in RFC discussions is repetition, volume and code. Short explanatory comments have a harder time coming through, and a couple of thumbs-down on the top post at least signal that there's some disagreement.
While this argument could be made for down votes vs upvotes on the same post (I would disagree but it's more subtle), a vote on a comment laying out one specific concern conveys more information than a vote on the RFC as a whole, because the comment is more specific. Compare "I disagree with this RFC as a whole" with "I agree that the proposed syntax is inconsistent with this part of the language".
I'd just say "suboptimal," since it works fine as long as there aren't too many comments. But anything that goes towards discussing bikeshed colors or language principles can get quickly out of hand.
Unfortunately, that makes information just less discoverable. There's a couple changes I dislike and would like to follow, but it's really hard to know where all the discussion is happening once it starts spanning multiple issues.
I believe Github is just unsuited for those kinds of discussions. Anything with real threading would work better in my opinion. Maybe even just have weekly RFC discussion posts on reddit would help. It would also help to make RFCs more visible to the community, which I'd also love to see more of.
That's another point, currently RFCs aren't as widely visible as they could be. I only find them via TWIR. They aren't even posted here on the internals board. If they become more widely communicated, the discussion volume will increase.
I agree, it's very frustrating. Plus while it seems intuitive that "be more detailed and put in some code examples" would be helpful, it often leads to tangents that derail the non-threaded discussion. Like discussions of alternatives for specific examples instead of a focus on the demonstrated underlying point.
The good news is that harsh, emotional language will also get your comment more visibility, but that doesn't happen too often because in general the participants want fruitful discussions. Any time I've seen this (or it happened to me) was due to frustration with the limitations of the discussion format.
Yeah, I'm not gonna stop with that. Or rather, I'm just less involved in RFCs in general now because of the frustration of being ignored. But when it's really important to me I'm gonna do what works for things to be seen.
Otherwise, without thumbs-down and strategical commenting I don't think I'd have much of a voice at all.
And, please believe me, it is very frustrating to me.
The review functionality would also seem more suitable for discussions about parts of the RFC, rather than discussing the idea of the RFC as a whole.
Discussing an RFC as a whole is often not fruitful. If you take issue with the motivation, review the motivation, if you take issue with technical aspects, review the reference, if you have an alternative in mind, review the alternatives section, etc.
As a fallback, could a bot remove the toplevel comments perhaps and post a āuse the review discussion featureā message higher up? Should probably let the core team post on the top level to allow for posting related things and such.
I think this is a bad idea - people could lose their messages which may be long.
This is a good idea, rfcbot could do this. I don't think we need a technical solution here, just a matter of encouraging reviews and general etiquette.
How about a reply from a bot to every non-core commenter to move the comment then?
Iād very much like to avoid the situation where the visible top comments are all in favor of the change and all disagreement is pushed somewhere else.
I think this would create chaos and the bot would then have to remove its own comment upon the commenter removing theirs - otherwise, we'd end up with a bunch of bot comments. I think a comment at the top from rfcbot thanking the RFC author for the RFC and discouraging downvotes and encouraging reviews and upvotes on reviews is best.
PS: very few RFCs are actually the responsibility of T-core.. most are T-lang or T-libs.
So, what would be the procedure when people donāt follow that, but the main discussion happens in the top-level?
I donāt think such a post would have a big effect in the high-volume discussions without someone to keep pushing it towards the review functionality.
The good thing about reviews is that they are tied to some specific RFC text, so they are much more local. With reviews, some concerns can be raised, resolved, and then folded (which GitHub will do automatically) once the concern has been resolved. That way, it is easier to see what issues are outstanding and what issues are resolved.
I agree that we shouldn't force discussions to reviews, but it should be the recommended way imo.
We don't need a procedure. We can and should trust in people doing the right thing (whatever we decide the right thing to be).
I should clarify: I don't think this will happen out of malice, I think it will happen because someone will make a short top level comment like they're used to from Github discussions (e.g. "Please don't forget use-case X" or "Could this have relation to issue Y") and then the rest will flow from there.
But I'm happy to join discussions wherever they end up happening.
For sure. However, since the rfcbot's comment will always be the first comment on an RFC, it will stay very visible and most people will read it at least once (once they've seen that particular message they will have internalized it).