Re: Proposal for TSC RFCs?
For reference, this is something I did in the past when I chaired the W3C RDF Data Shapes WG and this info was extremely valuable. You can see what it looked like on the following page. Each resolution is listed with a pointer to the relevant minutes.
Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM
From: "hmontgomery@..." <hmontgomery@...>
To: Brian Behlendorf <bbehlendorf@...>, "tsc@..." <tsc@...>
Date: 06/12/2019 08:57 AM
Subject: [EXTERNAL] Re: [Hyperledger TSC] Proposal for TSC RFCs?
Sent by: tsc@...
You bring up good points. I don’t think it’s necessary that such a decision/workflow tracker use git, or other heavyweight systems. I obviously cannot speak for Shawn but I am pretty sure he didn’t mean that we needed to use git for this, either—just the essence of the rust RFC system. But, as you point out, it would be nice if we had a single, searchable place for TSC-implemented policies and rules. As Shawn points out, it would also be nice if we had a formal way to capture some of the decisions the TSC has made over the years.
Several times the TSC has had to remake decisions, or go back and think “did we formally say this? Does rule X extend to Y?” We have even “forgotten” about entire projects, as I alluded to in the subproject discussion. So I think that a little bit of (very lightweight) formalism around this might go a long way into saving the TSC time in the long run and making it easier for people to know what rules and procedures they need to follow.
On Behalf Of Brian Behlendorf
Sent: Tuesday, June 11, 2019 9:48 PM
Subject: Re: [Hyperledger TSC] Proposal for TSC RFCs?
The minutes and recordings of the TSC meetings are the formal recording of decisions made and should be considered canonical. Since Jan 24th of this year, those notes are taken & stored on the Wiki:
Previously, minutes were taken either as emails to the TSC list or as pages on Google Docs, and then posted along with recordings on a similar page, but on our older wiki:
It would be Really Cool if volunteers emerged to do two things:
1) Faithfully copy over the hypertext from the old Wiki's archive page to the current one
2) Migrate all the minutes stored on Google Docs to wiki pages.
Doing both will make it easier to search across the minutes, ensure they don't get modified without visibility, etc. Any takers? This is on the long long backlog for HL's small staffed community architecture team, but seems like an easy thing we could ask for help with.
New project proposals are formally tracked:
However, it's clearly not kept up to date well enough, and that's another example of history that has not been ported over to the new Wiki. Any volunteers to help clean that up? It's annoying enough to me in its current state and the air temperature is still too warm to fall asleep so I may get to it myself tonight. But if someone feels up for it, feel free to tag in.
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.
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.
On 6/11/19 3:22 PM, hmontgomery@...wrote:
I think this is a great idea. We have forgotten and/or reinvented so many things over the years, and good documentation would help us keep track of policy, as well as help newcomers unused to the TSC workflow.
I don’t know what the exact best way for this to happen is—as Shawn mentions, all of the projects that used the Rust template have tweaked it, sometimes substantially. But I think something like this would help us from making mistakes related to lack of information on previous TSC decisions. I’d support such a task force.
On Behalf Of Shawn Amundson
Sent: Tuesday, June 11, 2019 1:48 PM
To: hyperledger-tsc <hyperledger-tsc@...>
Subject: [Hyperledger TSC] Proposal for TSC RFCs?
a project maintainer and part of the Hyperledger community, it is difficult
to track what past decisions (especially related to policy) have been made
by the TSC. The quality of proposals going to the TSC also seem to vary
quite a bit, as does the amount of discussion about them.
In several of the projects, we have adopted an RFC process based on the one used for Rust (why invent a new one, if there is already a great one) - https://github.com/rust-lang/rfcs. Each project has adjusted it to its own needs.
Proposals like those coming out of the lifecycle and CI/CD discussions could be captured in this manner. Something like - https://github.com/rust-lang/rfcs/blob/master/0000-template.md. It's a really nice format, with sections to capture drawbacks, rationale, and alternatives -- which leads to a more informed decision.
Would the TSC be open to adopting something like this?
If so, could we form a task force to put together a solid proposal for it? (Yes, I'm volunteering.)
Executive Director, Hyperledger