gRFC discussion: PR vs mailing list

[Christopher Warrington (CHRISTOPHER)]

I've noticed that much of the valuable discussion in gRFCs [1] these days is
happening via GitHub's PR interface.

The proposal process currently says:

> For at least a period of 10 business days (the minimum comment period), it
> is expected that the OWNER will respond to the comments and make updates
> to the RFC as new commits to the PR. Through the process, the discussion
> needs to be kept to the designated thread in the mailing list in order to
> avoid splintering conversations. The OWNER is encouraged to solicit as
> much feedback on the proposal as possible during this period. PR comments
> should belimited (sic, PR to fix [2]) to formatting and vocabulary.

Note in particular:

> the discussion needs to be kept to the designated thread in the mailing
> list

Practice and documentation have diverged. :-)

Should we

1. update the documented process to reflect the what people are doing today,
2. as a community work to change our collective behavior and redirect
comments on GitHub back to the mailing list thread (perhaps with help
from automation),
3. figure out some sort of in between (e.g., reflect comments/message back and forth),
4. start a proposal to come up with a different process that doesn't invite
such bifurcation, or
5. something else?

I'm intentionally not linking to any examples, as I don't want to imply that
anyone is doing anything wrong. I'm trying to bring this up as an
observation that what we say we do and what we end up doing are different as
a way to figure out how to bring them back in sync with each other so that
new contributors know what to expect.

[1]: https://github.com/grpc/proposal
[2]: https://github.com/grpc/proposal/pull/176

--
Christopher Warrington
Microsoft Corp.

[Eric Anderson]

On Fri, Apr 10, 2020 at 3:32 PM 'Christopher Warrington (CHRISTOPHER)' via grpc.io <grp...@googlegroups.com> wrote:

I've noticed that much of the valuable discussion in gRFCs [1] these days is
happening via GitHub's PR interface.

Oh, yeah... This has probably always been happening, though. I have seen some detailed review/discussion on grpc-io, but it seems like it has been fairly limited (in number of gRFCs) and has diminished over time.

The risk of "splintering conversations" is probably not that big; it seems people have done a reasonable job of @-ing people into GitHub threads. (The opposite of CCing into group threads is also good, but I think it has been mostly a one-way street "toward GitHub".) Since few discussions have involved more than 4 people, it has been easy to shift to practicalities.

I think it would be pretty easy to say "discussion can happen either location" and we just accept the complexities. Could probably just say "if a conversation moves it should be cross-linked when it moves," which is possible in both directions. I sort of feel people have been taking "The OWNER is encouraged to solicit as much feedback on the proposal as possible" seriously and will try to make sure people aren't left-behind in a discussion (which also means keeping discussion on a platform that works for its participants).

I think the biggest risk is when people are following along but haven't spoken up; the owner may not realize they are interested if things change dramatically. The cross-linking helps here, but I do think there will be times someone will be left behind. "Everything on the mailing list" has a lot of nice properties, but it also seems counter to how people naturally work. So I think tweaking/optimizing the process that people are actually doing is more likely to be more inclusive.

This is all based on the assumption that "things have mostly been working." If that's not true I'd be happy to get behind seriously trying to enforce the existing process and see if we can't form some new habits.

I'm intentionally not linking to any examples, as I don't want to imply that
anyone is doing anything wrong.

I think this is widespread enough and that the team doesn't skew legalistic, so I think it is probably safe to bring in specific examples if needed. But because it is so widespread we probably don't need to. We should just be clear we're trying to understand what is happening and improve the process and not throwing the rulebook in someone's face.