|
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 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:
|
|
|
|
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 -----
|
|
|
|
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@...>
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 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
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. Ry
|
|
|
|
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:
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
-- 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
toggle quoted messageShow quoted text
> 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
|
|
|
|
2019-06-06 TSC meeting minutes are done
Dave Huseby <dhuseby@...>
Cheers!
|
|
|
|
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
|
|
|
|
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,
|
|
|
|
Re: Proposal to the TSC: enable 2FA requirement across all orgs
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.
|
|
|
|
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.
toggle quoted messageShow quoted text
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 Correct. This is an org-level setting. The
quickest/best approach then is likely some sort of survey of 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,
toggle quoted messageShow quoted text
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:
|
|
|
|
Re: Proposal: adopt the Kubernetes GitHub/Community management workflow
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 --
|
|
|
|
Re: Proposal to the TSC: enable 2FA requirement across all orgs
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 Correct. This is an org-level setting. The quickest/best approach then is likely some sort of survey of 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
|
|
|
|
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.
toggle quoted messageShow quoted text
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 --
Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf
|
|
|