Re: Hyperledger project naming guidelines - draft for discussion

Shawn Amundson

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.


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.


On 6/7/19 12:20 PM, Shawn Amundson wrote:

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.


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.

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Cognitive Applications
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper:
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.





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 Behlendorf
Executive Director, Hyperledger
Twitter: @brianbehlendorf



Brian Behlendorf
Executive Director, Hyperledger
Twitter: @brianbehlendorf

Join to automatically receive all group messages.