Chair and Vice Chairs for Projects


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.

Discussion?

Thank you,
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Dan O'Prey <dan@...>
 

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.

Discussion?

Thank you,
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


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.


Shawn Amundson
 

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.

-Shawn


On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.

Discussion?

Thank you,
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org

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.


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.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- 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.
 
-Shawn
 
On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.
 
Discussion?
 
Thank you,
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org

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.

 

 

 


Vipin Bharathan
 

Hello all,

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)

Best,
Vipin
  


On Tue, Jun 18, 2019 at 10:10 AM Christopher Ferris <chrisfer@...> wrote:
+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.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 
----- 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.
 
-Shawn
 
On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.
 
Discussion?
 
Thank you,
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org

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.

 

 

 


Mic Bowman
 

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.

--mic


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.

-Shawn

On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.

Discussion?

Thank you,
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org

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.


Dave Huseby <dhuseby@...>
 

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.

Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


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.

--mic


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.

-Shawn

On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.

Discussion?

Thank you,
Silona

--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org

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.


hmontgomery@us.fujitsu.com <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 “point-of-contact.md” 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.

 

Thanks,

Hart

 

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.

 

Cheers!

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

 

 

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.

 

--mic

 

 

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.

 

-Shawn

 

On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.

 

Discussion?

 

Thank you,

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


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.


Brian Behlendorf
 

I think "point of contact" is fine.  I'll take the blame for the word "Chair" - as we were discussing some of the issues Silona mentioned in her original email (and which we could have gone into more detail about - again I'll take the blame as I believed it was urgent to get the TSC talking about this) I noted that our WGs and SIGs have Chairs, so we thought it would be simpler if we used the same term for someone who would perform roughly the same function.  Also, I have a tendency to borrow and steal from the Apache community structure whenever possible, and this is not unlike the "PMC Chair" that each project there has.

To compound it, we used the term "project manager", which in common parlance suggests a Gantt-chart-weilding, time-boxing slave driver who manages releases and punishes the lazy.  :)  Clearly that's not what was intended here.  A "Chair" on the WG or SIG or even here on the TSC is really there to remind the community of its processes, policies, and commitments to the rest of the Hyperledger organization.  The Community Architecture team Silona leads is so often on the hook for the grunt work of implementing things that make this community cohere, so it was out of a desire for simplicity that this proposal is made.  And her jerk of a boss, me, asks her and her team to constantly be thinking about "scale", so that our fixed headcount doesn't become an unfair limiter on the ability for the TSC to approve a worthy new project, and to avoid feeling like we have to do ourselves what we could turn to motivated volunteers in the community to do.

In that light, to review the short list of proposed responsibilities:

*    Writing and giving Quarterly Updates to the TSC, and attending TSC calls, especially when presenting the Update.

Clearly, as Hart suggested, this could be delegated - making sure someone writes this is the key thing to oversee, not to write it themselves.  And a good Chair & Vice Chair would rotate it around anyways.

*    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

As the volume of such communications has grown, there's hesitancy to distract the full developer community for each request for speakers for an event, or help looking into DCO conformance issues, or understanding something sensitive regarding individuals on a team, or other things that could trigger more noise than necessary.  We will tend to overshare rather than undershare; still, it's nice to know that if we need to reach out to Hyperledger Foobar, the context switch cost can be mitigated by having one or two individuals for her team to go to first.  Might also be helpful between projects.

*    Keeping the list of active maintainers current.

As Chris suggests, maybe there is already a process for this within a project, and a systematic way to maintain that e.g. MAINTAINERS.md.  Great.  This is just to ensure there's a human backstop to a process that could vary widely project to project, or if the TSC decides to standardize those actions more across projects, to implement that standard.

A proper Chair, of any of our units of community, would be wise to view themselves as servants of the community they are attached to, and not as top-down lord.  I think we took that for granted in the proposal.  So long as those three obligations seem right, POC seems fine.

Let's discuss more tomorrow on the TSC call,

Brian






On 6/18/19 10:40 AM, hmontgomery@... wrote:

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 “point-of-contact.md” 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.

 

Thanks,

Hart

 

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.

 

Cheers!

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

 

 

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.

 

--mic

 

 

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.

 

-Shawn

 

On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.

 

Discussion?

 

Thank you,

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


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.


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Christopher Ferris <chrisfer@...>
 

Point of contact (POC seems an overloaded, if not charged, acronym):
While I can appreciate the intent here (thanks, Brian for the elaboration), it is less clear that a single point of contact, even with a back-up, would work better than simply sending a note to either the list of maintainers, or even more simply to the project's mailing list. When the response is <crickets> that might be a sign of deeper problems. As I noted, being the contact for security is different than the contact for marketing or even for the TSC or CA team.
 
As to the responsibilities,
*    Writing and giving Quarterly Updates to the TSC, and attending TSC calls, especially when presenting the Update.
 
Preparing and presenting the quarterly updates:
Aside from the fact that everyone is juggling lots of things, and sometimes an update might slip (I know I have been guilty at least a couple times and begged for an additional week), if there's <crickets> then again, maybe a sign of deeper problems. As I think Vipin suggested, maybe the updates are too frequent. It might well be time to revisit the project update frequency and maybe if there are no issues, semi-annually might be sufficient? Certainly, that reduces the need to chase teams for their update.
 
Attending the TSC calls:
We don't mandate this, but by assigning a contact and suggesting the set of roles as above, now we seem to be drifting in that direction. I think we should ask ourselves why people that are engaged in the projects, and in a maintainer role, aren't attending. Maybe because the substance of the calls is not thought to be important/relevant to their work? They have a conflict?
 
Again, we might want to be a bit more reflective and ask ourselves (TSC) why that might be. Or, we might even ask the project contributors/maintainers (I know, what a concept!) before we mandate that someone attend calls (TSC, WG, or otherwise).
 
Maintainers policy:
Up until now, we have largely relegated the management and policies of a project to the project's maintainers.
Our charter does provide the following:

vii. establishing community norms, workflows or policies for releases;

We could, and maybe we should, establish a consistent policy for, at a minimum, how projects reflect to the broader community, who are the maintainers of that project (or repository) and provide their contact information (e.g. require a MAINTAINERS.md at the root of a project repo).
 
We might consider adopting a consistent policy for how maintainers are chosen (aside from the initial set designated in the draft project proposal), though it isn't clear that we need to address an identified problem with that, and before we did so, we would want to somehow get input from the various projects.
 
I'd be supportive of a proposal to have a consistent (and required) means of communicating the set of maintainers. I would also be supportive of a maintainers mailing list (per project and for all of Hyperledger) that could be automatically derived from a MAINTAINERS.md (e.g.).
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- Original message -----
From: "Brian Behlendorf" <bbehlendorf@...>
Sent by: tsc@...
To: tsc@...
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] Chair and Vice Chairs for Projects
Date: Tue, Jun 18, 2019 7:06 PM
 
I think "point of contact" is fine.  I'll take the blame for the word "Chair" - as we were discussing some of the issues Silona mentioned in her original email (and which we could have gone into more detail about - again I'll take the blame as I believed it was urgent to get the TSC talking about this) I noted that our WGs and SIGs have Chairs, so we thought it would be simpler if we used the same term for someone who would perform roughly the same function.  Also, I have a tendency to borrow and steal from the Apache community structure whenever possible, and this is not unlike the "PMC Chair" that each project there has.
 
To compound it, we used the term "project manager", which in common parlance suggests a Gantt-chart-weilding, time-boxing slave driver who manages releases and punishes the lazy.  :)  Clearly that's not what was intended here.  A "Chair" on the WG or SIG or even here on the TSC is really there to remind the community of its processes, policies, and commitments to the rest of the Hyperledger organization.  The Community Architecture team Silona leads is so often on the hook for the grunt work of implementing things that make this community cohere, so it was out of a desire for simplicity that this proposal is made.  And her jerk of a boss, me, asks her and her team to constantly be thinking about "scale", so that our fixed headcount doesn't become an unfair limiter on the ability for the TSC to approve a worthy new project, and to avoid feeling like we have to do ourselves what we could turn to motivated volunteers in the community to do.
 
In that light, to review the short list of proposed responsibilities:
 
*    Writing and giving Quarterly Updates to the TSC, and attending TSC calls, especially when presenting the Update.
 
Clearly, as Hart suggested, this could be delegated - making sure someone writes this is the key thing to oversee, not to write it themselves.  And a good Chair & Vice Chair would rotate it around anyways.
 
*    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
 
As the volume of such communications has grown, there's hesitancy to distract the full developer community for each request for speakers for an event, or help looking into DCO conformance issues, or understanding something sensitive regarding individuals on a team, or other things that could trigger more noise than necessary.  We will tend to overshare rather than undershare; still, it's nice to know that if we need to reach out to Hyperledger Foobar, the context switch cost can be mitigated by having one or two individuals for her team to go to first.  Might also be helpful between projects.
 
*    Keeping the list of active maintainers current.
 
As Chris suggests, maybe there is already a process for this within a project, and a systematic way to maintain that e.g. MAINTAINERS.md.  Great.  This is just to ensure there's a human backstop to a process that could vary widely project to project, or if the TSC decides to standardize those actions more across projects, to implement that standard.
 
A proper Chair, of any of our units of community, would be wise to view themselves as servants of the community they are attached to, and not as top-down lord.  I think we took that for granted in the proposal.  So long as those three obligations seem right, POC seems fine.
 
Let's discuss more tomorrow on the TSC call,
 
Brian
 
 
 
 
 
 
On 6/18/19 10:40 AM, hmontgomery@... wrote:

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 “point-of-contact.md” 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.

 

Thanks,

Hart

 

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.

 

Cheers!

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...

 

 

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.

 

--mic

 

 

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.

 

-Shawn

 

On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.

 

Discussion?

 

Thank you,

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


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.

 

 

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf
 


Silona Bonewald <sbonewald@...>
 

On Tue, Jun 18, 2019 at 4:06 PM Brian Behlendorf <bbehlendorf@...> wrote:
I think "point of contact" is fine.  I'll take the blame for the word "Chair" - as we were discussing some of the issues Silona mentioned in her original email (and which we could have gone into more detail about - again I'll take the blame as I believed it was urgent to get the TSC talking about this) I noted that our WGs and SIGs have Chairs, so we thought it would be simpler if we used the same term for someone who would perform roughly the same function.  Also, I have a tendency to borrow and steal from the Apache community structure whenever possible, and this is not unlike the "PMC Chair" that each project there has.

To compound it, we used the term "project manager", which in common parlance suggests a Gantt-chart-weilding, time-boxing slave driver who manages releases and punishes the lazy.  :)  Clearly that's not what was intended here.  A "Chair" on the WG or SIG or even here on the TSC is really there to remind the community of its processes, policies, and commitments to the rest of the Hyperledger organization.  The Community Architecture team Silona leads is so often on the hook for the grunt work of implementing things that make this community cohere, so it was out of a desire for simplicity that this proposal is made.  And her jerk of a boss, me, asks her and her team to constantly be thinking about "scale", so that our fixed headcount doesn't become an unfair limiter on the ability for the TSC to approve a worthy new project, and to avoid feeling like we have to do ourselves what we could turn to motivated volunteers in the community to do.

In that light, to review the short list of proposed responsibilities:

*    Writing and giving Quarterly Updates to the TSC, and attending TSC calls, especially when presenting the Update.

Clearly, as Hart suggested, this could be delegated - making sure someone writes this is the key thing to oversee, not to write it themselves.  And a good Chair & Vice Chair would rotate it around anyways.

*    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

As the volume of such communications has grown, there's hesitancy to distract the full developer community for each request for speakers for an event, or help looking into DCO conformance issues, or understanding something sensitive regarding individuals on a team, or other things that could trigger more noise than necessary.  We will tend to overshare rather than undershare; still, it's nice to know that if we need to reach out to Hyperledger Foobar, the context switch cost can be mitigated by having one or two individuals for her team to go to first.  Might also be helpful between projects.

*    Keeping the list of active maintainers current.

As Chris suggests, maybe there is already a process for this within a project, and a systematic way to maintain that e.g. MAINTAINERS.md.  Great.  This is just to ensure there's a human backstop to a process that could vary widely project to project, or if the TSC decides to standardize those actions more across projects, to implement that standard.

A proper Chair, of any of our units of community, would be wise to view themselves as servants of the community they are attached to, and not as top-down lord.  I think we took that for granted in the proposal.  So long as those three obligations seem right, POC seems fine.

Let's discuss more tomorrow on the TSC call,

Brian






On 6/18/19 10:40 AM, hmontgomery@... wrote:

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 “point-of-contact.md” 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.

 

Thanks,

Hart

 

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.

 

Cheers!

---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

 

 

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.

 

--mic

 

 

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.

 

-Shawn

 

On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> 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.

 

Discussion?

 

Thank you,

Silona


--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


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.


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Arnaud Le Hors
 

> 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.

While I agree with the sentiment regarding the proposal, having served as chair of standards working groups multiple times, I must say that I don't see chairs as having the type of power that is implied here. If anything I see chairs as people willing to make an effort to represent the whole group and being constrained to a level of neutrality that is not expected of others. Quite the opposite of a king of any sorts.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Shawn Amundson" <amundson@...>
To:        "Dan O'Prey" <dan@...>
Cc:        Silona Bonewald <sbonewald@...>, Hyperledger List <tsc@...>
Date:        06/18/2019 01:47 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Chair and Vice Chairs for Projects
Sent by:        tsc@...




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.

-Shawn


On Tue, Jun 18, 2019 at 1:57 AM Dan O'Prey via Lists.Hyperledger.Org<dan=digitalasset.com@...> 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.

Discussion?

Thank you,
Silona

--

Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


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.