- Proposal for TSC RFCs?
Re: Proposal for TSC RFCs?
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 email@example.com to automatically receive all group messages.