toggle quoted messageShow quoted text
Fully support the sentiments expressed by Shawn and Chris.
However, in practical terms, we do need someone (anyone) reporting to TSC or the community. When we do not have a "point of contact", this engagement may not happen as people could say, this is not my job and I dont want to do this.
This is the conundrum, we have to reconcile decentralization with what it means to be part of the community, that is Hyperledger itself.
One of the ways we can ease this conflict is by demanding little; i.e. do not ask for elaborate reports with multiple sections and complex criteria.
The second way is for project activity to self-generate health and other reports using tools or utilities.
"Low touch" reporting in other words...this is what we should be working towards, simplicity and transparency. Of course easier said than done. One of the innovations that seem to work is having tsc members read, acknowledge and ask questions about the reports before hand (for example)
On Tue, Jun 18, 2019 at 10:10 AM Christopher Ferris <chrisfer@...
+100 for what Shawn said
"The CA team is seeing that larger projects that have many diverse repos and having Maintainers be responsible doesn't scale. There is often confusion on who to speak with." - doesn't scale for whom?
Fabric has a defined process (in the contribution guide) for selecting maintainers and keeping the list up to date. It may be that the sprawl of sub-projects is, or can be, confusing. However, looking across the Fabric repos (many are what we would call sub-projects such as fabric-sdk-go, fabric-sdk-py) they all seem to have a MAINTAINERS.md, though I did not look deep enough to determine if they shared or had a defined process. Frankly, a simple shout out in chat or an email to the mailing list should easily resolve any confusion.
It isn't at all clear to me why we want to impose a top-down management structure to a collaborative set of projects.
As for marketing, I really feel as if the community of developers collaborating on development of a project, working towards a release, should have a voice. However, I disagree that we should necessarily channel that through a single individual. If MC wants to run a campaign, then it should reach out through the mailing list and cross-post. This way, all of the voices can be heard.
Finally, as for getting the communities and maintainers involved in a project more engaged in various other aspects of Hyperledger (MC, TSC, WGs etc), I'm all for it. I just don't believe that this is how you accomplish that objective.
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
----- Original message -----
From: "Shawn Amundson" <amundson@...>
Sent by: tsc@...
To: "Dan O'Prey" <dan@...>
Cc: Silona Bonewald <sbonewald@...>, Hyperledger List <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] Chair and Vice Chairs for Projects
Date: Tue, Jun 18, 2019 7:49 AM
It would be better to call these "points of contact", as to not confuse it with a decision-making capability. Within some of the projects, we have a team of long-term maintainers for decision making, but no 'king of the project' position, intentionally. The points of contact should probably not have a primary if there are only two.
The maintainers lists, similarly, are governed by specific rules within the project. We are currently in the process of updating these for Sawtooth and it will require a fair bit of maintainer voting.
For the TSC updates, we've been trying to rotate that around the community a bit so that it's not always the same person representing the project.
For the MC, I think the TSC should appoint maintainers to the MC to participate as advisors directly, with the intent of wide project coverage.
Unofficial +1, this would be very helpful from the marketing side too
On Tue, Jun 18, 2019, 06:14 Silona Bonewald <sbonewald@...
I would like all projects to either elect or have the TSC nominate Chairs and Vice Chairs. The Chairs would serve more of a project manager role within the project's community.
The CA team is seeing that larger projects that have many diverse repos and having Maintainers be responsible doesn't scale. There is often confusion on who to speak with.
The CA team believes we need this type of role to help us scale to support more projects for the community.
The Chair's responsibilities would be:
- Writing and giving Quarterly Updates to the TSC, and attending TSC calls, especially when presenting the Update.
- Be the primary interface with the Hyperledger staff in regards to informing the project participants and contributors about ongoing Hyperledger activities, commitments, and cross-project initiatives
- Keeping the list of active maintainers current.
We would like Vice Chairs to be available for when Chairs are not available esp on the larger projects.
We can scale this out gradually and not require every project to do this at first but we would like a deadline perhaps in 3 months time? We would also like this to be a part of the project proposal process at the beginning.
This would require a vote of the TSC.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.