Proposal: adopt the Kubernetes GitHub/Community management workflow


Ry Jones
 

Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger


Baohua Yang
 

Prefer the more-automatic way!


On Thu, May 30, 2019 at 7:13 AM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Best wishes!

Baohua Yang


Casey Kuhlman
 

As a contributor to both I can say that the Kubernetes system feels (a) baked, (b) friendly (or at least less human in a bad way), and (c) cohesive across repos and projects; whereas Hyperledger feels... less so.
____________________________________

Casey Kuhlman, Monax
CEO
Email: casey@... 
Phone (US): +1-423-523-9531(UK): +44-75-073-96359
____________________________________


On Thu, May 30, 2019 at 5:09 AM Baohua Yang <yangbaohua@...> wrote:
Prefer the more-automatic way!

On Thu, May 30, 2019 at 7:13 AM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Best wishes!

Baohua Yang


Ry Jones
 

On Thu, May 30, 2019 at 4:57 AM Casey Kuhlman via Lists.Hyperledger.Org <casey=monax.io@...> wrote:
As a contributor to both I can say that the Kubernetes system feels (a) baked, (b) friendly (or at least less human in a bad way), and (c) cohesive across repos and projects; whereas Hyperledger feels... less so.

Completely agreed. We're where we are, I want to fix it, help?
--
Ry Jones
Community Architect, Hyperledger


Shawn Amundson
 

I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

There are a couple things there I really like (if I'm understanding it correctly):

1. By default, everyone in the org having read access to all repos. That would be awesome.
2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

There are other good things in there too.

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

-Shawn

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger


Ry Jones
 

1. Nobody ever asked for that; I thought it came for free. I added all repos to the "Hyperledger Contributors" group (which should be everyone) as "read". You should see this reflected; I checked a few repos before and after, and it looks how I expect. If you do not see this, let me know.
2. Yes
3. My concern is, honestly, booting everyone that doesn't have 2FA enabled, which is a lot of contributors. I've been tempted to click the button, but I haven't. I suspect the answer is "yes" but we'll need somewhere to host it (GCE or AWS, probably, for production; I'm sure I have a machine that can run minikube that I can dedicate to the cause

before I started spending a lot of time on it, I wanted to see if we could reach consensus.


On Thu, May 30, 2019 at 12:32 PM Shawn Amundson <amundson@...> wrote:
I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

There are a couple things there I really like (if I'm understanding it correctly):

1. By default, everyone in the org having read access to all repos. That would be awesome.
2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

There are other good things in there too.

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

-Shawn

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Ry Jones
Community Architect, Hyperledger


Christopher Ferris <chrisfer@...>
 

I’d insist on all ppl with write and admin access to have 2FA. I would also make STRONG recommendation for others to do so as well. I too have been tempted to push the button, but that would only end in a flooded inbox with hate mail;-)

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris

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

1. Nobody ever asked for that; I thought it came for free. I added all repos to the "Hyperledger Contributors" group (which should be everyone) as "read". You should see this reflected; I checked a few repos before and after, and it looks how I expect. If you do not see this, let me know.
2. Yes
3. My concern is, honestly, booting everyone that doesn't have 2FA enabled, which is a lot of contributors. I've been tempted to click the button, but I haven't. I suspect the answer is "yes" but we'll need somewhere to host it (GCE or AWS, probably, for production; I'm sure I have a machine that can run minikube that I can dedicate to the cause

before I started spending a lot of time on it, I wanted to see if we could reach consensus.

On Thu, May 30, 2019 at 12:32 PM Shawn Amundson <amundson@...> wrote:
I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

There are a couple things there I really like (if I'm understanding it correctly):

1. By default, everyone in the org having read access to all repos. That would be awesome.
2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

There are other good things in there too.

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

-Shawn

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:
Much of this would not apply - we don't have a CLA, for instance. However:
https://github.com/kubernetes/community/tree/master/github-management
would make on-boarding new users more programmatic. Also:
Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.
Ry
--
Ry Jones
Community Architect, Hyperledger



--
Ry Jones
Community Architect, Hyperledger


hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Isn’t 2FA standard these days for this kind of thing?  Is there anything we can do to push contributors to set it up?  I’d have pushed the button…

 

From: tsc@... [mailto:tsc@...] On Behalf Of Christopher Ferris
Sent: Thursday, May 30, 2019 1:22 PM
To: Ry Jones <rjones@...>
Cc: Shawn Amundson <amundson@...>; TSC <tsc@...>
Subject: Re: [Hyperledger TSC] Proposal: adopt the Kubernetes GitHub/Community management workflow

 

I’d insist on all ppl with write and admin access to have 2FA. I would also make STRONG recommendation for others to do so as well. I too have been tempted to push the button, but that would only end in a flooded inbox with hate mail;-)

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris


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

1. Nobody ever asked for that; I thought it came for free. I added all repos to the "Hyperledger Contributors" group (which should be everyone) as "read". You should see this reflected; I checked a few repos before and after, and it looks how I expect. If you do not see this, let me know.

2. Yes

3. My concern is, honestly, booting everyone that doesn't have 2FA enabled, which is a lot of contributors. I've been tempted to click the button, but I haven't. I suspect the answer is "yes" but we'll need somewhere to host it (GCE or AWS, probably, for production; I'm sure I have a machine that can run minikube that I can dedicate to the cause

 

before I started spending a lot of time on it, I wanted to see if we could reach consensus.

 

On Thu, May 30, 2019 at 12:32 PM Shawn Amundson <amundson@...> wrote:

I'm not sure I fully grok everything there, given the amount of kubernetes-specific stuff (staging vs. non-staging repos, etc.).

 

There are a couple things there I really like (if I'm understanding it correctly):

 

1. By default, everyone in the org having read access to all repos. That would be awesome.

2. For our repos w/MAINTAINERS.md files, we should be able to derive write access programatically (into the tool's format), then apply it programatically. That would be awesome.

 

There are other good things in there too.

 

Would it be possible to pilot this on a few repos so we could gain a better understanding of it, or will this be a heavy lift to try it out?

 

-Shawn

 

On Wed, May 29, 2019 at 6:13 PM Ry Jones <rjones@...> wrote:

Much of this would not apply - we don't have a CLA, for instance. However:

https://github.com/kubernetes/community/tree/master/github-management

would make on-boarding new users more programmatic. Also:

Having this would allow committer promotion and removal automagically, instead of by the manual, error-prone process we have today.

 

I would prefer to keep this discussion on this mailing list, and go to the TSC call once a decision is made on if/how to implement it.

Ry

--

Ry Jones

Community Architect, Hyperledger



--

Ry Jones

Community Architect, Hyperledger

 


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


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


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




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