Date   

Re: Hyperledger project naming guidelines - draft for discussion

Shawn Amundson
 

On Thu, Jun 6, 2019 at 4:24 PM Arnaud Le Hors <lehors@...> wrote:
> HL shouldn't dictate via TSC policy a requirement to sign up for survey monkey. There are a lot of ways to do it
> without mandating a particular commercial service.

says the guy who just wrote:

> you should add something like "Google your potential project name with the terms 'Open Source'" to see if it is already taken"

 ;-)

And... this is why we have peer review. :) Totally agree, it should be written in a way that describes the intent and not the tool.

-Shawn
 


Re: Hyperledger project naming guidelines - draft for discussion

Shawn Amundson
 

Agree.

Additionally, having the MC or other HL staff attempt to identify potential problems with specific names and conveying that to the project team would be the really helpful thing here. Some names having bad connotations in other languages is a great example of something that the projects might not have the resources to identify independently.

-Shawn


On Fri, Jun 7, 2019 at 10:06 AM Christopher B Ferris <chrisfer@...> wrote:
As I also commented on the call, I agree that the guidelines as written don't really address the concerns.
I also agree that the guidance to use descriptive names is also more likely to result in problems especially when we have multiple similar projects (AS WE HAVE TODAY).
 
Short, catchy, names that are memorable and unique are what we should be advocating.
 
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: "Middleton, Dan" <dan.middleton@...>
Sent by: tsc@...
To: Brian Behlendorf <bbehlendorf@...>, Shawn Amundson <amundson@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
Date: Fri, Jun 7, 2019 9:46 AM
 

Per my verbal comments in the TSC meeting, I do not think these guidelines will prevent the kind of problems we’ve had in the past.

For example, there’s nothing here that makes clear a name like “blockchain” is impermissible.

 

Regarding the notion of descriptive names, I’m unclear whether that is guidance to adopt that for new names or simply another option to fully abstract names like Ursa.

 

I would appreciate if the Marketing Committee could revise these guidelines with these points in mind and the others described in this thread. There may have been other verbal feedback from the TSC meeting which is not yet captured in this thread.

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Brian Behlendorf <bbehlendorf@...>
Date: Friday, June 7, 2019 at 12:46 AM
To: Shawn Amundson <amundson@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion

 

Ah, I didn't mean to ignore:

 

On 6/6/19 6:48 AM, Shawn Amundson wrote:

Who are the current members of the MC?

They're not listed publicly, but they are representatives from our Premier Members, and their calls & discussion list are open to PR contacts at all General Members.  It's defined in Section 5 of the Hyperledger Charter.  Led by Dan O'Prey from Digital Asset and Alissa Worley from Accenture.  It's how we coordinate with members on getting our collective word out about the projects and activities at HL.   They don't have any perogative or control over what goes on in the technical side of Hyperledger, but we thought they might be helpful in thinking about naming guidelines.

Brian

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

 

 


Request for Comment - Contributor Community Needs

Middleton, Dan <dan.middleton@...>
 

To: TSC members, Project Maintainers, Community Contributors

 

The Hyperledger Board will be discussing 2020 priorities in July. I would like to make sure that we incorporate feedback from the contributor community into that planning.

I have created a table on the wiki where you can insert requests and rationale.

 

https://wiki.hyperledger.org/display/HYP/RFC+-+2020+Contributor+Support

 

Please use the wiki for comment rather than this email thread.

 

Thanks,

Dan Middleton

Hyperledger TSC Chair


Re: Hyperledger project naming guidelines - draft for discussion

Christopher Ferris <chrisfer@...>
 

As I also commented on the call, I agree that the guidelines as written don't really address the concerns.
I also agree that the guidance to use descriptive names is also more likely to result in problems especially when we have multiple similar projects (AS WE HAVE TODAY).
 
Short, catchy, names that are memorable and unique are what we should be advocating.
 
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: "Middleton, Dan" <dan.middleton@...>
Sent by: tsc@...
To: Brian Behlendorf <bbehlendorf@...>, Shawn Amundson <amundson@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
Date: Fri, Jun 7, 2019 9:46 AM
 

Per my verbal comments in the TSC meeting, I do not think these guidelines will prevent the kind of problems we’ve had in the past.

For example, there’s nothing here that makes clear a name like “blockchain” is impermissible.

 

Regarding the notion of descriptive names, I’m unclear whether that is guidance to adopt that for new names or simply another option to fully abstract names like Ursa.

 

I would appreciate if the Marketing Committee could revise these guidelines with these points in mind and the others described in this thread. There may have been other verbal feedback from the TSC meeting which is not yet captured in this thread.

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Brian Behlendorf <bbehlendorf@...>
Date: Friday, June 7, 2019 at 12:46 AM
To: Shawn Amundson <amundson@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion

 

Ah, I didn't mean to ignore:

 

On 6/6/19 6:48 AM, Shawn Amundson wrote:

Who are the current members of the MC?

They're not listed publicly, but they are representatives from our Premier Members, and their calls & discussion list are open to PR contacts at all General Members.  It's defined in Section 5 of the Hyperledger Charter.  Led by Dan O'Prey from Digital Asset and Alissa Worley from Accenture.  It's how we coordinate with members on getting our collective word out about the projects and activities at HL.   They don't have any perogative or control over what goes on in the technical side of Hyperledger, but we thought they might be helpful in thinking about naming guidelines.

Brian

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

 

 


Re: Hyperledger project naming guidelines - draft for discussion

Middleton, Dan <dan.middleton@...>
 

Per my verbal comments in the TSC meeting, I do not think these guidelines will prevent the kind of problems we’ve had in the past.

For example, there’s nothing here that makes clear a name like “blockchain” is impermissible.

 

Regarding the notion of descriptive names, I’m unclear whether that is guidance to adopt that for new names or simply another option to fully abstract names like Ursa.

 

I would appreciate if the Marketing Committee could revise these guidelines with these points in mind and the others described in this thread. There may have been other verbal feedback from the TSC meeting which is not yet captured in this thread.

 

Thanks,

Dan

 

From: <tsc@...> on behalf of Brian Behlendorf <bbehlendorf@...>
Date: Friday, June 7, 2019 at 12:46 AM
To: Shawn Amundson <amundson@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion

 

Ah, I didn't mean to ignore:

 

On 6/6/19 6:48 AM, Shawn Amundson wrote:

Who are the current members of the MC?

They're not listed publicly, but they are representatives from our Premier Members, and their calls & discussion list are open to PR contacts at all General Members.  It's defined in Section 5 of the Hyperledger Charter.  Led by Dan O'Prey from Digital Asset and Alissa Worley from Accenture.  It's how we coordinate with members on getting our collective word out about the projects and activities at HL.   They don't have any perogative or control over what goes on in the technical side of Hyperledger, but we thought they might be helpful in thinking about naming guidelines.

Brian

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


CTA: Enable two factor auth on GitHub

Ry Jones
 

Hi all,
The Hyperledger GitHub orgs (Hyperledger, Hyperledger Labs) will have two factor auth enabled  in the very near future. Doing so will remove people without 2FA from the orgs.

Please enable two factor auth for your GitHub account[0] to prevent being removed.


Re: Hyperledger project naming guidelines - draft for discussion

Brian Behlendorf
 

Ah, I didn't mean to ignore:

On 6/6/19 6:48 AM, Shawn Amundson wrote:
Who are the current members of the MC?

They're not listed publicly, but they are representatives from our Premier Members, and their calls & discussion list are open to PR contacts at all General Members.  It's defined in Section 5 of the Hyperledger Charter.  Led by Dan O'Prey from Digital Asset and Alissa Worley from Accenture.  It's how we coordinate with members on getting our collective word out about the projects and activities at HL.   They don't have any perogative or control over what goes on in the technical side of Hyperledger, but we thought they might be helpful in thinking about naming guidelines.

Brian

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


Re: Hyperledger project naming guidelines - draft for discussion

Brian Behlendorf
 

Thanks Shawn for your comments.  Look for changes that reflect them soon.

Arnaud, the existence of an "Apache Aries" wasn't really a big deal, there were other concerns around names of projects this year I'd rather not resurface now.  Coming up with a clearer set of best practices and a process seemed to be what people we talked to felt would be the most constructive way to avoid churn and angst in the future. 

Brian

On 6/6/19 2:24 PM, Arnaud Le Hors wrote:
> HL shouldn't dictate via TSC policy a requirement to sign up for survey monkey. There are a lot of ways to do it
> without mandating a particular commercial service.

says the guy who just wrote:

> you should add something like "Google your potential project name with the terms 'Open Source'" to see if it is already taken"

 ;-)

Joke aside, I actually agree with Shawn and thought the same when I saw it. I think we ought to be neutral on this sort of thing and only mention possible tools as examples to help those who may not know any.

The whole Aries situation is totally news to me and rather baffling. Biran, is that what actually motivated this whole thing to start with?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Shawn Amundson" <amundson@...>
To:        Brian Behlendorf <bbehlendorf@...>
Cc:        "tsc@..." <tsc@...>
Date:        06/06/2019 03:50 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
Sent by:        tsc@...




Brian,

A good start! If these are meant to be policies,they should probably be written up with more explanation and guidance.  Maybe the prose could include references to external sources that provide more in-depth discussion of the topics being covered. T

The implication of your email is that teams have not been doing the very basic things listed, and I think the opposite is probably true -- that teams have put a lot of time and effort into the names. Still, these are good things to have clearly articulated.

In the "New Project Naming Process", you should add something like "Google your potential project name with the terms 'Open Source'" to see if it is already taken". This seems in-line with the rest of the items listed, and is a better approach than the tools mentioned. This would have helped identify Apache Aries as a conflict with Hyperledger Aries (or maybe it was known already, but some of us found it surprising).

In the "New Project Branding Considerations", we should have something in there the logo not overlapping with existing projects. It seems very odd that Aries and Ursa share a theme, and that Hyperledger Aries and Apache Aries essentially have the same logo (a ram).

During the logo discussions, there is a form that we help fill out - that could probably be included in one of these documents as a way to help make some of the list items more concrete. (Ali has the doc - the questions seem pretty well thought out.)

In the "New Project Naming Process" - HL shouldn't dictate via TSC policy a requirement to sign up for survey monkey. There are a lot of ways to do it without mandating a particular commercial service.

Who are the current members of the MC?

-Shawn

On Thu, Jun 6, 2019 at 12:57 AM Brian Behlendorf <bbehlendorf@...> wrote:

We have seen a small handful of projects join Hyperledger in recent
months, and it's likely we'll see a similar number if not more apply
through the rest of this year.  Naming has at times been an issue for
submissions.  While it's important that the developers behind a proposal
set the name for their project, the Hyperledger Marketing Committee and
some of the LF staff put together a set of guidelines and
recommendations for new project names and a process for the proposers,
TSC, and HL/MC to use to arrive at a name.

The result is two new draft articles for your review in the Community
Tools section of the Wiki.

The first is a step-by-step process found under the how-to articles:

https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863190

The second provides our branding considerations, common pitfalls to
avoid, and questions to help guide the evaluation process, found under
"Best Practices":

https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863192

We are open to taking your comments on tomorrow's TSC call, and ideally
we can iterate it based on feedback and get the TSC's approval at an
upcoming call. We are asking the same of the Marketing Committee on our
monthly call this upcoming Tuesday, with the goal of closing in on
approvals in the next two weeks.

Thanks!

Brian


--
Brian Behlendorf
Executive Director, Hyperledger

bbehlendorf@...
Twitter: @brianbehlendorf








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


Re: Hyperledger project naming guidelines - draft for discussion

Arnaud Le Hors
 

> HL shouldn't dictate via TSC policy a requirement to sign up for survey monkey. There are a lot of ways to do it
> without mandating a particular commercial service.

says the guy who just wrote:

> you should add something like "Google your potential project name with the terms 'Open Source'" to see if it is already taken"

 ;-)

Joke aside, I actually agree with Shawn and thought the same when I saw it. I think we ought to be neutral on this sort of thing and only mention possible tools as examples to help those who may not know any.

The whole Aries situation is totally news to me and rather baffling. Biran, is that what actually motivated this whole thing to start with?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Shawn Amundson" <amundson@...>
To:        Brian Behlendorf <bbehlendorf@...>
Cc:        "tsc@..." <tsc@...>
Date:        06/06/2019 03:50 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
Sent by:        tsc@...




Brian,

A good start! If these are meant to be policies,they should probably be written up with more explanation and guidance.  Maybe the prose could include references to external sources that provide more in-depth discussion of the topics being covered. T

The implication of your email is that teams have not been doing the very basic things listed, and I think the opposite is probably true -- that teams have put a lot of time and effort into the names. Still, these are good things to have clearly articulated.

In the "New Project Naming Process", you should add something like "Google your potential project name with the terms 'Open Source'" to see if it is already taken". This seems in-line with the rest of the items listed, and is a better approach than the tools mentioned. This would have helped identify Apache Aries as a conflict with Hyperledger Aries (or maybe it was known already, but some of us found it surprising).

In the "New Project Branding Considerations", we should have something in there the logo not overlapping with existing projects. It seems very odd that Aries and Ursa share a theme, and that Hyperledger Aries and Apache Aries essentially have the same logo (a ram).

During the logo discussions, there is a form that we help fill out - that could probably be included in one of these documents as a way to help make some of the list items more concrete. (Ali has the doc - the questions seem pretty well thought out.)

In the "New Project Naming Process" - HL shouldn't dictate via TSC policy a requirement to sign up for survey monkey. There are a lot of ways to do it without mandating a particular commercial service.

Who are the current members of the MC?

-Shawn


On Thu, Jun 6, 2019 at 12:57 AM Brian Behlendorf <bbehlendorf@...> wrote:

We have seen a small handful of projects join Hyperledger in recent
months, and it's likely we'll see a similar number if not more apply
through the rest of this year.  Naming has at times been an issue for
submissions.  While it's important that the developers behind a proposal
set the name for their project, the Hyperledger Marketing Committee and
some of the LF staff put together a set of guidelines and
recommendations for new project names and a process for the proposers,
TSC, and HL/MC to use to arrive at a name.

The result is two new draft articles for your review in the Community
Tools section of the Wiki.

The first is a step-by-step process found under the how-to articles:

https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863190

The second provides our branding considerations, common pitfalls to
avoid, and questions to help guide the evaluation process, found under
"Best Practices":

https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863192

We are open to taking your comments on tomorrow's TSC call, and ideally
we can iterate it based on feedback and get the TSC's approval at an
upcoming call. We are asking the same of the Marketing Committee on our
monthly call this upcoming Tuesday, with the goal of closing in on
approvals in the next two weeks.

Thanks!

Brian


--
Brian Behlendorf
Executive Director, Hyperledger

bbehlendorf@...
Twitter: @brianbehlendorf








2019-06-06 TSC meeting minutes are done

Dave Huseby <dhuseby@...>
 


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


Re: Hyperledger project naming guidelines - draft for discussion

Shawn Amundson
 

Brian,

A good start! If these are meant to be policies,they should probably be written up with more explanation and guidance.  Maybe the prose could include references to external sources that provide more in-depth discussion of the topics being covered. T

The implication of your email is that teams have not been doing the very basic things listed, and I think the opposite is probably true -- that teams have put a lot of time and effort into the names. Still, these are good things to have clearly articulated.

In the "New Project Naming Process", you should add something like "Google your potential project name with the terms 'Open Source'" to see if it is already taken". This seems in-line with the rest of the items listed, and is a better approach than the tools mentioned. This would have helped identify Apache Aries as a conflict with Hyperledger Aries (or maybe it was known already, but some of us found it surprising).

In the "New Project Branding Considerations", we should have something in there the logo not overlapping with existing projects. It seems very odd that Aries and Ursa share a theme, and that Hyperledger Aries and Apache Aries essentially have the same logo (a ram).

During the logo discussions, there is a form that we help fill out - that could probably be included in one of these documents as a way to help make some of the list items more concrete. (Ali has the doc - the questions seem pretty well thought out.)

In the "New Project Naming Process" - HL shouldn't dictate via TSC policy a requirement to sign up for survey monkey. There are a lot of ways to do it without mandating a particular commercial service.

Who are the current members of the MC?

-Shawn


On Thu, Jun 6, 2019 at 12:57 AM Brian Behlendorf <bbehlendorf@...> wrote:
We have seen a small handful of projects join Hyperledger in recent
months, and it's likely we'll see a similar number if not more apply
through the rest of this year.  Naming has at times been an issue for
submissions.  While it's important that the developers behind a proposal
set the name for their project, the Hyperledger Marketing Committee and
some of the LF staff put together a set of guidelines and
recommendations for new project names and a process for the proposers,
TSC, and HL/MC to use to arrive at a name.

The result is two new draft articles for your review in the Community
Tools section of the Wiki.

The first is a step-by-step process found under the how-to articles:
https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863190

The second provides our branding considerations, common pitfalls to
avoid, and questions to help guide the evaluation process, found under
"Best Practices":
https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863192

We are open to taking your comments on tomorrow's TSC call, and ideally
we can iterate it based on feedback and get the TSC's approval at an
upcoming call. We are asking the same of the Marketing Committee on our
monthly call this upcoming Tuesday, with the goal of closing in on
approvals in the next two weeks.

Thanks!

Brian


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





Hyperledger project naming guidelines - draft for discussion

Brian Behlendorf
 

We have seen a small handful of projects join Hyperledger in recent months, and it's likely we'll see a similar number if not more apply through the rest of this year.  Naming has at times been an issue for submissions.  While it's important that the developers behind a proposal set the name for their project, the Hyperledger Marketing Committee and some of the LF staff put together a set of guidelines and recommendations for new project names and a process for the proposers, TSC, and HL/MC to use to arrive at a name.

The result is two new draft articles for your review in the Community Tools section of the Wiki.

The first is a step-by-step process found under the how-to articles: https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863190

The second provides our branding considerations, common pitfalls to avoid, and questions to help guide the evaluation process, found under "Best Practices": https://wiki.hyperledger.org/pages/viewpage.action?pageId=13863192

We are open to taking your comments on tomorrow's TSC call, and ideally we can iterate it based on feedback and get the TSC's approval at an upcoming call. We are asking the same of the Marketing Committee on our monthly call this upcoming Tuesday, with the goal of closing in on approvals in the next two weeks.

Thanks!

Brian


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


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Shawn Amundson
 

I'm willing to help with this, in particular working on the section on how we manage repo admins. Here's a first cut:

github Repository Admin Privileges
----------------------------------

Github "repo admin" permissions will be delegated to a limited number of
maintainers if the project maintainers desire. However, project maintainers
must adhere to the following:

- Act in a responsible and collaborative manner.
- Do not intentionally violate any policy which has been approved by the TSC.
  For example, if the TSC approved a policy which explicitly stated that GitHub
  issues or the GitHub wiki should not be enabled, then they must not be
  enabled.
- Specifically, make sure the DCO policy is not subverted. It is the project
  maintainer's responsibility to help enforce the DCO policy that commits
  have the proper sign-offs.

The Hyperledger community architects will maintain a single page on the wiki
which lists all of the relevant policies which have been adopted by the TSC
for reference by the project maintainers.

Project maintainers will be granted this permission if the following is true:

- For projects with formal governance rules, those rules should be used to
  designate individuals to have this permission.  For other projects, agreement
  amongst the project maintainers (as defined by who has writer permission on
  the repository) can be used to designate individuals.  Projects are not
  required to designate anyone.
- The individual must be active within Hyperledger for a minimum of a year
  prior to being designated.
- The individual must demonstrate a working knowledge of the related
  Hyperledger policies. This may involve training or mentorship by the
  Hyperledger community architects or other maintainers.

A project may designate a maximum of three individuals at a time.


On Tue, Jun 4, 2019 at 9:14 AM Arnaud Le Hors <lehors@...> wrote:
Hi Ry,

I share Shawn's uncertainty expressed earlier about what exactly from the Kubernetes management workflow you are proposing we adopt. Is it primarily the automagic management of the repos?

Could you please put on the wiki an actual proposal that we could read and vote on? I'm sorry for the extra work but I just don't see how we can fully understand what's proposed otherwise. Hopefully, it's just a matter of copy/pasting the right sections from the kubernetes pages.

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Shawn Amundson" <amundson@...>
To:        Ry Jones <rjones@...>
Cc:        TSC <tsc@...>
Date:        06/04/2019 03:42 AM
Subject:        Re: [Hyperledger TSC] Proposal: adopt the Kubernetes GitHub/Community management workflow
Sent by:        tsc@...





Regardless of whether we use prow, we still need repo admin role for a select few project maintainers.

The "Maintainer (beta)" role looks geared toward teams using github wiki and issues/projects -- not terribly interesting for HL.

-Shawn

On Mon, Jun 3, 2019 at 2:22 PM Ry Jones <rjones@...> wrote:
I have some interesting news: the Hyperledger orgs are in a couple of betas for GitHub,
one of which gives us a slightly broader set of user roles. The Maintain role, in particular,
looks helpful.

Many of the tasks in the Admin role would be handled by the proposed use of k8s/prow.

Ry
--
Ry Jones
Community Architect, Hyperledger
Chat@rjones




Re: Proposal to the TSC: enable 2FA requirement across all orgs

Ry Jones
 

I did an audit of the main org. Slightly over half of our 400 members are not using two factor authentication.

There is no easy way to tie those members to activity in the org.

On Tue, Jun 4, 2019 at 07:15 Arnaud Le Hors <lehors@...> wrote:
I strongly believe we need to give everyone a fair warning but I don't think we need to wait for several months to pull the trigger either. I'd say a month at most.

This is independently of the fact that 2FA isn't without its own pitfalls...
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Ry Jones" <rjones@...>
To:        Brian Behlendorf <bbehlendorf@...>
Cc:        Andrew Grimberg <agrimberg@...>, TSC <tsc@...>
Date:        06/03/2019 07:21 PM
Subject:        Re: [Hyperledger TSC] Proposal to the TSC: enable 2FA requirement across all orgs
Sent by:        tsc@...




On Mon, Jun 3, 2019 at 10:00 AM Brian Behlendorf <bbehlendorf@...> wrote:

Thanks Andy.  I'm also guessing it's not possible to require 2FA across
only some GH repos within a given org.



Correct. This is an org-level setting.

The quickest/best approach then is likely some sort of survey of
committers (as measured by commits to any repo over the last say 3
months) asking each to confirm they're using 2FA.  Then those who
haven't yet confirmed can be followed up with to make sure there's no
technical barrier keeping them from moving.  After some window of time
(say a month), given no technical barriers, it's enabled for all repos
and orgs.



This is a broader discussion we should have around marketing. In the beginning, anyone
that asked to be a member of the org was invited. Very few members are active. If/when
we move to automated management of repos, there will be a series of policy decisions
to make, distinct from 2FA.

Ry
--
Ry Jones
Community Architect, Hyperledger
Chat@rjones



--
Ry Jones
Community Architect, Hyperledger


Re: Proposal to the TSC: enable 2FA requirement across all orgs

Arnaud Le Hors
 

I strongly believe we need to give everyone a fair warning but I don't think we need to wait for several months to pull the trigger either. I'd say a month at most.

This is independently of the fact that 2FA isn't without its own pitfalls...
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Ry Jones" <rjones@...>
To:        Brian Behlendorf <bbehlendorf@...>
Cc:        Andrew Grimberg <agrimberg@...>, TSC <tsc@...>
Date:        06/03/2019 07:21 PM
Subject:        Re: [Hyperledger TSC] Proposal to the TSC: enable 2FA requirement across all orgs
Sent by:        tsc@...




On Mon, Jun 3, 2019 at 10:00 AM Brian Behlendorf <bbehlendorf@...> wrote:

Thanks Andy.  I'm also guessing it's not possible to require 2FA across
only some GH repos within a given org.



Correct. This is an org-level setting.

The quickest/best approach then is likely some sort of survey of
committers (as measured by commits to any repo over the last say 3
months) asking each to confirm they're using 2FA.  Then those who
haven't yet confirmed can be followed up with to make sure there's no
technical barrier keeping them from moving.  After some window of time
(say a month), given no technical barriers, it's enabled for all repos
and orgs.



This is a broader discussion we should have around marketing. In the beginning, anyone
that asked to be a member of the org was invited. Very few members are active. If/when
we move to automated management of repos, there will be a series of policy decisions
to make, distinct from 2FA.

Ry
--
Ry Jones
Community Architect, Hyperledger
Chat@rjones




Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Arnaud Le Hors
 

Hi Ry,

I share Shawn's uncertainty expressed earlier about what exactly from the Kubernetes management workflow you are proposing we adopt. Is it primarily the automagic management of the repos?

Could you please put on the wiki an actual proposal that we could read and vote on? I'm sorry for the extra work but I just don't see how we can fully understand what's proposed otherwise. Hopefully, it's just a matter of copy/pasting the right sections from the kubernetes pages.

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Shawn Amundson" <amundson@...>
To:        Ry Jones <rjones@...>
Cc:        TSC <tsc@...>
Date:        06/04/2019 03:42 AM
Subject:        Re: [Hyperledger TSC] Proposal: adopt the Kubernetes GitHub/Community management workflow
Sent by:        tsc@...





Regardless of whether we use prow, we still need repo admin role for a select few project maintainers.

The "Maintainer (beta)" role looks geared toward teams using github wiki and issues/projects -- not terribly interesting for HL.

-Shawn


On Mon, Jun 3, 2019 at 2:22 PM Ry Jones <rjones@...> wrote:
I have some interesting news: the Hyperledger orgs are in a couple of betas for GitHub,
one of which gives us a slightly broader set of user roles. The Maintain role, in particular,
looks helpful.

Many of the tasks in the Admin role would be handled by the proposed use of k8s/prow.

Ry
--
Ry Jones
Community Architect, Hyperledger
Chat@rjones




Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Shawn Amundson
 


Regardless of whether we use prow, we still need repo admin role for a select few project maintainers.

The "Maintainer (beta)" role looks geared toward teams using github wiki and issues/projects -- not terribly interesting for HL.

-Shawn

On Mon, Jun 3, 2019 at 2:22 PM Ry Jones <rjones@...> wrote:
I have some interesting news: the Hyperledger orgs are in a couple of betas for GitHub,
one of which gives us a slightly broader set of user roles. The Maintain role, in particular,
looks helpful.

Many of the tasks in the Admin role would be handled by the proposed use of k8s/prow.

Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal: adopt the Kubernetes GitHub/Community management workflow

Ry Jones
 

I have some interesting news: the Hyperledger orgs are in a couple of betas for GitHub,
one of which gives us a slightly broader set of user roles. The Maintain role, in particular,
looks helpful.

Many of the tasks in the Admin role would be handled by the proposed use of k8s/prow.

Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal to the TSC: enable 2FA requirement across all orgs

Ry Jones
 

On Mon, Jun 3, 2019 at 10:00 AM Brian Behlendorf <bbehlendorf@...> wrote:
Thanks Andy.  I'm also guessing it's not possible to require 2FA across
only some GH repos within a given org.

Correct. This is an org-level setting.

The quickest/best approach then is likely some sort of survey of
committers (as measured by commits to any repo over the last say 3
months) asking each to confirm they're using 2FA.  Then those who
haven't yet confirmed can be followed up with to make sure there's no
technical barrier keeping them from moving.  After some window of time
(say a month), given no technical barriers, it's enabled for all repos
and orgs.

This is a broader discussion we should have around marketing. In the beginning, anyone
that asked to be a member of the org was invited. Very few members are active. If/when
we move to automated management of repos, there will be a series of policy decisions
to make, distinct from 2FA.

Ry
--
Ry Jones
Community Architect, Hyperledger


Re: Proposal to the TSC: enable 2FA requirement across all orgs

Brian Behlendorf
 

Thanks Andy.  I'm also guessing it's not possible to require 2FA across only some GH repos within a given org.

The quickest/best approach then is likely some sort of survey of committers (as measured by commits to any repo over the last say 3 months) asking each to confirm they're using 2FA.  Then those who haven't yet confirmed can be followed up with to make sure there's no technical barrier keeping them from moving.  After some window of time (say a month), given no technical barriers, it's enabled for all repos and orgs.

It is probably worth a vote on the TSC on the policy question: should 2FA be a requirement for commits? If yes, then we can figure out a rollout strategy that best balances notice and grace with expediency.

Brian

On 6/3/19 8:26 AM, Andrew Grimberg wrote:
No, that's not actually possible. You can verify if a change comes in
with a GPG signature on it, but not if a particular account is using 2FA
for access to the GitHub UI. Those are two distinctly different things.

As an aside, we currently have a change under review [0] against lftools
that will allow someone with admin rights on a GH org to get an "audit"
of the org including who does and does not have 2FA enabled.

-Andy-

[0] https://gerrit.linuxfoundation.org/infra/c/releng/lftools/+/15264

On 5/30/19 3:41 PM, Brian Behlendorf wrote:
Can we tell which commits come in without 2FA?

Brian

On 5/30/19 2:02 PM, Christopher Ferris wrote:
You should give a warning. You can add all github ids to a team and @
the team. Maybe give a few days to remediate. I approve subject to
advance warning and update to contributors guides.

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@... <mailto:chrisfer@...>
twitter: @christo4ferris
blog: https://developer.ibm.com/code/author/chrisfer/
IBM Open Source white
paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402 <tel:+1%20508%20667%200402>

On May 30, 2019, at 4:54 PM, Ry Jones <rjones@...
<mailto:rjones@...>> wrote:

In light of recent discussions on this mailing list,
<https://lists.hyperledger.org/g/tsc/message/2295> I ask the TSC to
vote by email on enabling 2FA for the Hyperledger and Hyperledger
Labs orgs.

We will lose many members that are committers. It will cause turbulence.
Ry
--
Ry Jones
Community Architect, Hyperledger
Chat <https://www.youtube.com/watch?v=EEc4JRyaAoA>: @rjones
<https://chat.hyperledger.org/direct/rjones>
--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf

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