Re: Proposal for TSC RFCs?

Shawn Amundson

On Tue, Jun 11, 2019 at 11:47 PM Brian Behlendorf <bbehlendorf@...> wrote:
Requiring a formal proposal template for all topics for TSC conversations, or those that would result in decisions, feels a bit process-heavy, as often small suggestions during a conversation become decisions made.  But for the larger concepts, such as new graphical takes on the greenhouse, I've been encouraging people to make these suggestions in longer form ahead of time, giving TSC members a chance to read & consider before discussing on the calls.  I'm also completely happy (as anyone who knows my antipathy for calls knows) to see issues opened, discussed, and decided completely outside of the calls.  Getting people to at least use the mailing list and Wiki for these proposals rather than Google Docs would be an improvement; seeing a page in the TSC space of outstanding issues (much like the "backlog" queue maintained in the current agenda) would as well.  But the calls are at least a place where the TSC can reach and formally record a consensus on an issue, even if that only takes 5 minutes to reflect the consensus arrived at over an email conversation.  So the minutes to those meetings should still be the canonical source of what was decided, even if the why and rationales are a bit more spread out.

I don't think a fairly light-weight process like the Rust RFC model is too much to ask for proposals that impact the projects, and in particular policies. It does set the bar substantially higher than it is currently, but that's kind of the point -- the bar is so low now that what we have are seemingly random wiki pages which don't make any effort to describe the "why" behind their content (and most, as far as I can tell, are not TSC approved).

Take for example project proposals. The project proposals are vastly better than most other content presented to the TSC. This is because there is a fairly great template for it and the teams take it seriously and spend a lot of effort and time trying to explain themselves. We should expand this to other decisions as well.

The TSC could determine when the RFC process needs to be used or not - I think what we would want to do in the task force is provide some guidance on it but ultimately leave it to individual TSC decisions.
While using Git to manage RFCs makes sense for code-level decisions, using Git/Github for TSC proposals and discussions feels like it might exclude quite a few people.  Needing to do a git clone to change text is a fair uplift from going to a wiki page and clicking edit - totally justified when you're all maintainers and already have git copies of your core projects' repos locally, but harder outside that context.  In both systems you get visibility into who's changed what.  In a wiki you get search for free (yes, one could grep locally...).  In either scenario you need gardeners, which feels like the most precious resource we have. 

This should certainly be part of what the task force answers. The collaborative peer review process is important, as is the ability to track changes and capture feedback. I think the best approach is to talk to a wide number of maintainers and other collaborators and get a feel for what is the most likely process to get us higher quality RFCs. Ideally the new process would enable more maintainer input than we have today.


Join to automatically receive all group messages.