Hi Everyone,

Sorry to spam you all again, but I wanted to address some more issues and concerns about our processes.  Most of this is in light of our discussion over email and in the TSC meeting last week. I have two main points I’d like to address:  centralizing our governing documents, and fixing some stuff around the LFID usage (which relates to DCO, TSC voting, and community metrics.  I’ll address these in sequence.

Governening Documents:

It’s been brought up repeatedly that our governing documents are hard to find, don’t mesh well together, and in some cases are contradictory.  New people or projects looking to find the proper way to do something are often left confused.  As I pointed out in my long email last week, even major things like the criteria for a 1.0 release are not consistent across all of our documents.  In many cases, they are not in a place that’s easy to find or locate, either.  It would be great if we could address these problems—if it’s hard for Hyperledger dinosaurs to find and make sense out of these things, then it’s absolute terror for newbies.

So, with this in mind, I’d like to propose the following:  we merge all of our governing documents into a single “Hyperledger TSC Constitution.”  We use numbering and lettering for different “articles” of the said constitution, like the style of the Hyperledger charter (https://www.hyperledger.org/about/charter, in case you are curious).  This will require some work to put everything in place and number and itemize everything, but I think it will be well worth it in the long run.  We would also require future changes to adhere to this indexed style.

Keeping our rules in this form would have many benefits.  Everything would be in one place, so it would be easy to find (obviously we could break down things into different documents if we wanted to do so, but the indexing would be consistent through different documents and all documents would need to be stored in a common repo).  It would be easy to keep track of changes and new rules, and we would have less chance of having duplicate/inconsistent rules (like for the active status exit criteria and the 1.0 release).  When we wanted to refer people to rules, it would be of the form “see rule 3.b.ii” rather than “spend 15 minutes fruitlessly searching for a document on the wiki.”

Does this make sense?  I view this as a no-brainer and something we should absolutely do.  Maybe there is a better way to lay things out, but having a centralized, indexed, and ordered set of rules makes a ton of sense.

LFID Usage:

In light of the DCO discussion at this week’s TSC meeting, I think it makes sense to discuss how we handle identity at Hyperledger.  I’d like to make a constructive suggestion, which I encourage people to take apart.  I’m not confident what I’m proposing is the best way to do things, but I’d love to spur some more discussion on this.

An idea:  suppose we make the LFID the root of all activity at Hyperledger.  When you sign up for an LFID, you list all of your relevant information (i.e. company) and sign whatever legal documents you need with respect to say, DCO.  For legal purposes, we probably need real names (which we don’t ever make public).  We also require people to list their github ID.

When people contribute code (which can happen under github), we run a check to make sure that their github ID is associated with a LFID in good standing (i.e. DCO stuff is OK).  This probably can just be handled by only giving permissions to people with LFIDs, although I don’t know what the best solution is here—I’m not a github wizard like some people on this list are.  While this adds an extra onerous step for contribution (you need an LFID and to answer/sign some stuff), I’m not sure we’ll be able to avoid something like this once we get new DCO requirements.  I would be surprised if we can continue to do DCO without some real-world tie to people.

The advantages of this would seem substantial:

1.       We would have infrastructure in place to handle whatever requirements we needed to handle DCO stuff.  From my (mostly uneducated on this topic) point of view, it looks like we’re going to have to do something like this anyway if we get new requirements for handling DCO stuff (which also seems likely).  I cannot say for certain on this either, but it might also make it possible that we don’t have to sign individual github commits if this is the case, which would be nice.

2.       Having a tie between contributor and LFID (with proper information on the people behind the LFIDs) would enable easy collection of contributor statistics, which we could then publish.  This would seem to benefit the collective community quite a bit.  If people are worried about privacy, we could torture the LF staff and require them to publish differentially private community statistics (which would be a funny measure of community support—if your community can’t be differentially privatized effectively, an individual is too dominant!).

3.       We could handle TSC elections by LFID.  While it wouldn’t totally prevent election fraud (someone could still have their whole company sign up), it would stop people from spamming anonymous github IDs and raise the bar for shenanigans a little bit.  It would presumably also make elections easier to manage for the LF staff.

4.       We would still allow people to remain externally anonymous.  The only public-facing thing would be the github ID, which could be pseudonymized if people wanted.  This would give people the ability to avoid unwanted spam and comments (although, it wouldn’t protect you from emails like this!).

Again, this second section is a lot of speculation on my part.  I’d be curious to hear if people thing this is right, wrong, crazy, or have better suggestions.

If you’re here, thank you for suffering through yet another long email.  I’d love to hear suggestions and criticism, so please feel free to speak up.  Thanks a lot for your time, and I hope that everyone is having a wonderful weekend.

Thanks,

Hart