How to participate in open source discussions and RFCs
GitHub Discussions, RFC process, staying on-topic, signal vs noise contributions, +1 reactions vs substantive comments, disagreeing constructively, RFC decision lifecycle
Discussions Are Not Forums
Open source project discussions and RFCs are working documents -- not general discussion threads. Every comment should add new information, a concrete use case, or a specific technical concern.
Signal vs Noise
High-signal contribution: I tried approach X and it breaks when Y because Z -- here is a minimal case. Low-signal contribution: I agree with this or Would love to see this. Use the thumbs-up reaction instead of writing agreement comments -- they add noise to long threads without adding value.
How to Disagree Constructively
Disagree with arguments, not people. This approach has a race condition when two clients write simultaneously is constructive. This is badly designed is not. Propose an alternative: An alternative that avoids the race condition is X -- here is a sketch.
Understanding RFC Decisions
When an RFC is rejected, the core team documents the reason. These rejection reasons are valuable -- they tell you why a seemingly good idea does not fit the project. Read them. They encode architectural decisions that affect every future contribution you make.
If you want to move an RFC forward, offer to implement it. Saying you can take this on if the approach is approved is the single most effective comment in a stalled RFC discussion.