Re: Chair and Vice Chairs for Projects <hmontgomery@...>

I think this is the right idea.  We can even generalize this system and have a project “point of contact for X” where X could be security, quarterly reporting, press releases, etc. 


Most (or all) of the projects already have effective project management, so I think there would be quite a bit of resistance (as some have already indicated) to mandating a new type of project governance.  But having a top-level “” that functions as a list of contacts for a project for various different things might be a nice thing to have.   I wouldn’t be opposed if the TSC mandated to the projects, “give us at least two emails for security concerns, give us at least two more for marketing,” etc.  Such an approach might solve the problems that Silona is looking to fix while also not disrupting the current governance structure.


Thoughts?  Thanks for your time.





From: tsc@... [mailto:tsc@...] On Behalf Of Dave Huseby
Sent: Tuesday, June 18, 2019 9:10 AM
To: Mic Bowman <cmickeyb@...>
Cc: Shawn Amundson <amundson@...>; Dan O'Prey <dan@...>; Silona Bonewald <sbonewald@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Chair and Vice Chairs for Projects


I want to point out that for the last two years, I have maintained a list of "security volunteers" that are "points of contact" in each project that are also on the security@... mailing list.  I try to keep at least two people on each team so that there is a backup person if the primary person isn't around. The design is to keep all projects in the loop on confidential security bug reports and to have people who can coordinate the fix for security bugs on an urgent basis if needed. It has worked well so far but I would like to tighten it up a bit and have more regular check-ins with people to make sure that each team has somebody.


I like Silona's proposal because I think it functions the same way as the security volunteers but for other community related needs like the TSC updates and coordinating other community upkeep. I don't really care what title we use so long as the duties are clearly written down. I want to add the security volunteers to this effort with the hope that it will all coalesce around a directory somewhere on the wiki that let's everybody quickly figure out who to talk to.



David Huseby
Security Maven, Hyperledger
The Linux Foundation



On Tue, Jun 18, 2019 at 8:56 AM Mic Bowman <cmickeyb@...> wrote:

Agreed that the name "chair" implies more than what is actually intended. "Point of contact" seems more appropriate.


Regarding the rotating TSC updates... i think there is a difference between who actually handles the TSC update & who ensures that *someone* handles the TSC update. While this doesn't seem to be an issue with the larger, active projects, I can imagine that it is more of an issue with some of the less active projects.





On Tue, Jun 18, 2019 at 4:47 AM Shawn Amundson <amundson@...> wrote:

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.




On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <> wrote:

Unofficial +1, this would be very helpful from the marketing side too


On Tue, Jun 18, 2019, 06:14 Silona Bonewald <sbonewald@...> wrote:

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.




Thank you,



Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220

The Linux Foundation

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 If you are not the intended recipient, please delete this message.

Join to automatically receive all group messages.