- Updated the taxonomy for clarity and precision. Projects
will now be classified as frameworks, components,
templates and tools instead of just
frameworks and tools. We made a guess as to where each
project would like to be, realizing the boundaries can be
fuzzy. If you feel they should be grouped differently
let's discuss that, but we can accommodate some movement
within the layout.
- We placed in some blank generic logos to accommodate
anticipated expansion. When we publish this formally we
will remove the generic logos; it's merely intended to
show where we'd expand.
- Illustrate a broader view of the various ways to participate in the greenhouse by including a sort of foundation floor in this greenhouse to include Labs, as well as a community section including WGs, SIGs, Meetups and HGF. If this results in a graphic that's too tall or busy for, say, a slide in a presentation slide deck, this section can be moved to its own slide, which is why we show it with and without. It's anticipated that we'd make each of the individual components here look better before final push, perhaps by coming up with logos for each or at least different colors.
- Emphasize the frameworks, as they are likely the first
projects we want people new to HL to know about, and they
pull together many of the other pieces as components. We
still need better taglines for each framework but those
can be improved over time.
- We removed the taglines for the other projects for
visual simplicity; perhaps on the website when showing
this graphic we can have a roll-over that shows more depth
on each project before shooting you over to the project's
particular home page.
- Remove the greyed out other LF projects and "Community Stewardship and Technical, Legal, Marketing, Organizational Infrastructure" copy to avoid this looking like a sea of small print as the greenhouse grows.
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf
I agree with Dan here.
Also, I am not a marketing person, so take this cum grano salis, but we probably spend too much time on naming as a technical community. I’m not sure naming guidelines will be that useful either (as Brian points out as well)—I think the best approach is to require new projects to consult with or get sign-off from the marketing committee on their names. This can be an interactive process that varies based on the needs of each project.
Does this make sense?
Thanks,
Hart
Sent: Monday, June 10, 2019 6:10 AM
To: Shawn Amundson <amundson@...>; Brian Behlendorf <bbehlendorf@...>
Cc: Hyperledger List <tsc@...>; Meredith Bennett <mbennett@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
I’d prefer to only engage marketing resources etc. after a project has been formally approved by the TSC.
--Dan
From: <tsc@...> on behalf of Shawn Amundson <amundson@...>
Date: Saturday, June 8, 2019 at 12:04 PM
To: Brian Behlendorf <bbehlendorf@...>
Cc: Hyperledger List <tsc@...>, Meredith Bennett <mbennett@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
We should probably fold the timing question into the lifecycle discussion, because it may depend on some of the other topics like whether everything goes through labs first.
-Shawn
On Fri, Jun 7, 2019 at 4:32 PM Brian Behlendorf <bbehlendorf@...> wrote:
Thanks all, all these comments (and those expressed during the TSC call, and those expressed in side channels elsewhere) will get back to Meredith, who'll be working on an update.
To a few points:
* These were created as a way to formalize an existing informal process, whose informality was cited as the main reason why debates over names felt arbitrary and unfair, and when feedback was given why it was sometimes dismissed. Creating these guidelines and process won't necessarily resolve debates over names, but hopefully give us a chance to channel those discussions more productively and have process that feels optimally fair.
* Naming discussions necessarily involve a tremendous amount of subjectivity, aesthetics that will differ person to person, language and cultural differences, etc. There is no algorithm that will give us a binary result as to whether a name should be allowed or not. So instead we give guidelines, and it might be OK if those guidelines end up possibly conflicting when evaluated individually. It also means we should not worry about whether names would have had to change if we'd used this process before now. Bygones.
And a few open questions:
* It seems like the primary bone of contention is around whether those names should be descriptive ("The name should give people some understanding of what the technology does and/or how people can use it.") or not. Most current HL project names aren't related at all to what the software does. Fitting something adequate into 8 characters, without being misleading, can be tough. Still, it can help people looking over the landscape better if the terms have something to connect them to the rest, functionally. Would anyone like to argue in favor of this requirement, or offer a rephrasing?
* Finally it seems like people want more detail as it relates to timing, and when a name should be locked in. The timeline was written without regard to events like when a project is proposed or approved. In my opinion, it makes sense to consider a name potentially changeable after a project is first publicly proposed, but then locked in once it's voted upon by the TSC, so that we can proceed ASAP to setting up associated resources and getting an announcement made. Thoughts? If it makes sense to others we can modify the process to specifically align with the project proposal/acceptance process, perhaps even merge the two.
Brian
On 6/7/19 12:20 PM, Shawn Amundson wrote:
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: @christo4ferrisIBM 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
--Brian BehlendorfExecutive Director, Hyperledgerbbehlendorf@...Twitter: @brianbehlendorf
No second call until further notice
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community
All are welcome.-
Agenda: https://wiki.hyperledger.org/display/IWG/2019-06-12
- Luca Boldrin (Is Blockchain necessary to implement SSI?)- Preliminary slides
- Ajay Jadhav India consent layer
- Work on the Identity WG paper
Meeting minutes:
We are taking the minutes on the wiki now. ( https://wiki.hyperledger.org/display/IWG/2019-06-12+Notes ) Please edit collaboratively or send updates by email.
You need a LF ID to login to edit.
You do not need a LFID to read passively.
All are welcome. You do not have to be a member of Hyperledger to be on the call!
zoom details
iPhone one-tap :
US: +16465588656,,4034983298# or +16699006833,,4034983298#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
Meeting ID: 403 498 3298
International numbers available: https://zoom.us/u/bAaJoyznpThis is an open call.
Please reach out if you have questions, attend the call, participate to collaborate!
I’d prefer to only engage marketing resources etc. after a project has been formally approved by the TSC.
--Dan
From: <tsc@...> on behalf of Shawn Amundson <amundson@...>
Date: Saturday, June 8, 2019 at 12:04 PM
To: Brian Behlendorf <bbehlendorf@...>
Cc: Hyperledger List <tsc@...>, Meredith Bennett <mbennett@...>
Subject: Re: [Hyperledger TSC] Hyperledger project naming guidelines - draft for discussion
We should probably fold the timing question into the lifecycle discussion, because it may depend on some of the other topics like whether everything goes through labs first.
-Shawn
Thanks all, all these comments (and those expressed during the TSC call, and those expressed in side channels elsewhere) will get back to Meredith, who'll be working on an update.
To a few points:
* These were created as a way to formalize an existing informal process, whose informality was cited as the main reason why debates over names felt arbitrary and unfair, and when feedback was given why it was sometimes dismissed. Creating these guidelines and process won't necessarily resolve debates over names, but hopefully give us a chance to channel those discussions more productively and have process that feels optimally fair.
* Naming discussions necessarily involve a tremendous amount of subjectivity, aesthetics that will differ person to person, language and cultural differences, etc. There is no algorithm that will give us a binary result as to whether a name should be allowed or not. So instead we give guidelines, and it might be OK if those guidelines end up possibly conflicting when evaluated individually. It also means we should not worry about whether names would have had to change if we'd used this process before now. Bygones.
And a few open questions:
* It seems like the primary bone of contention is around whether those names should be descriptive ("The name should give people some understanding of what the technology does and/or how people can use it.") or not. Most current HL project names aren't related at all to what the software does. Fitting something adequate into 8 characters, without being misleading, can be tough. Still, it can help people looking over the landscape better if the terms have something to connect them to the rest, functionally. Would anyone like to argue in favor of this requirement, or offer a rephrasing?
* Finally it seems like people want more detail as it relates to timing, and when a name should be locked in. The timeline was written without regard to events like when a project is proposed or approved. In my opinion, it makes sense to consider a name potentially changeable after a project is first publicly proposed, but then locked in once it's voted upon by the TSC, so that we can proceed ASAP to setting up associated resources and getting an announcement made. Thoughts? If it makes sense to others we can modify the process to specifically align with the project proposal/acceptance process, perhaps even merge the two.
Brian
On 6/7/19 12:20 PM, Shawn Amundson wrote:
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: @christo4ferrisIBM 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
--Brian BehlendorfExecutive Director, Hyperledgerbbehlendorf@...Twitter: @brianbehlendorf
Thanks all, all these comments (and those expressed during the TSC call, and those expressed in side channels elsewhere) will get back to Meredith, who'll be working on an update.
To a few points:
* These were created as a way to formalize an existing informal process, whose informality was cited as the main reason why debates over names felt arbitrary and unfair, and when feedback was given why it was sometimes dismissed. Creating these guidelines and process won't necessarily resolve debates over names, but hopefully give us a chance to channel those discussions more productively and have process that feels optimally fair.
* Naming discussions necessarily involve a tremendous amount of subjectivity, aesthetics that will differ person to person, language and cultural differences, etc. There is no algorithm that will give us a binary result as to whether a name should be allowed or not. So instead we give guidelines, and it might be OK if those guidelines end up possibly conflicting when evaluated individually. It also means we should not worry about whether names would have had to change if we'd used this process before now. Bygones.
And a few open questions:
* It seems like the primary bone of contention is around whether those names should be descriptive ("The name should give people some understanding of what the technology does and/or how people can use it.") or not. Most current HL project names aren't related at all to what the software does. Fitting something adequate into 8 characters, without being misleading, can be tough. Still, it can help people looking over the landscape better if the terms have something to connect them to the rest, functionally. Would anyone like to argue in favor of this requirement, or offer a rephrasing?
* Finally it seems like people want more detail as it relates to timing, and when a name should be locked in. The timeline was written without regard to events like when a project is proposed or approved. In my opinion, it makes sense to consider a name potentially changeable after a project is first publicly proposed, but then locked in once it's voted upon by the TSC, so that we can proceed ASAP to setting up associated resources and getting an announcement made. Thoughts? If it makes sense to others we can modify the process to specifically align with the project proposal/acceptance process, perhaps even merge the two.
Brian
On 6/7/19 12:20 PM, Shawn Amundson wrote:
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: @christo4ferrisIBM 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 BehlendorfExecutive Director, HyperledgerTwitter: @brianbehlendorf
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf
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: @christo4ferrisIBM 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 BehlendorfExecutive Director, HyperledgerTwitter: @brianbehlendorf
-- Brian Behlendorf Executive Director, Hyperledger bbehlendorf@... Twitter: @brianbehlendorf
> 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"
;-)
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: @christo4ferrisIBM 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 BehlendorfExecutive Director, HyperledgerTwitter: @brianbehlendorf
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
Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
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 BehlendorfExecutive Director, HyperledgerTwitter: @brianbehlendorf
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:
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
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
> 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
> 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
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
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
----------------------------------
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.
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
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