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

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

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

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

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

Ah, I didn't mean to ignore: On 6/6/19 6:48 AM, Shawn Amundson wrote: They're not listed publicly, but they are representatives from our Premier Members, and their

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

> HLshouldn'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 commercialservice. says the guy whojust wrote: >

https://wiki.hyperledger.org/display/HYP/2019+06+06+TSC+Minutes Cheers! --- David Huseby Security Maven, Hyperledger The Linux Foundation +1-206-234-2392 dhuseby@...

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

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

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

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. -- Ry Jones Community

I strongly believewe need to give everyone a fair warning but I don't think we need to waitfor several months to pull the trigger either. I'd say a month at most. This is independentlyof the fact that

Hi Ry, I share Shawn'suncertainty expressed earlier about what exactly from the Kubernetes managementworkflow you are proposing we adopt. Is it primarily the automagic managementof the repos? Could

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

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

Correct. This is an org-level setting. 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

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

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