Date   

Cancelled Event: Technical Steering Committee (TSC) - Thursday, 2 January 2020 #cal-cancelled

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Cancelled: Technical Steering Committee (TSC)

This event has been cancelled.

When:
Thursday, 2 January 2020
7:00am to 8:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.backup

Organizer: Technical Steering Committee (TSC)

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community.backup

Or iPhone one-tap :
US: +16699006833,,6223336701# or +16465588656,,6223336701#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
Meeting ID: 622-333-6701
International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs


Cancelled Event: Technical Steering Committee (TSC) - Thursday, 26 December 2019 #cal-cancelled

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Cancelled: Technical Steering Committee (TSC)

This event has been cancelled.

When:
Thursday, 26 December 2019
7:00am to 8:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.backup

Organizer: Technical Steering Committee (TSC)

Description:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community.backup

Or iPhone one-tap :
US: +16699006833,,6223336701# or +16465588656,,6223336701#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
Meeting ID: 622-333-6701
International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs


TSC Agenda for Dec 19, 2019

Arnaud Le Hors
 

Hi,

The agenda for this week's call is online. There are several quarterly reports that have been posted, please, make sure to review them before hand if possible.

Based on last week's discussion I will call for a vote on two issues highlighted as such in the agenda. I then want to spend some time discussing further the idea of "Promoted Release".

https://wiki.hyperledger.org/display/TSC/2019+12+19+TSC+Agenda

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


Upcoming Event: DCIWG Quarterly Report reminder - Thu, 12/12/2019 9:00am-10:00am #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: DCIWG Quarterly Report reminder

When: Thursday, 12 December 2019, 9:00am to 10:00am, (GMT-08:00) America/Los Angeles

View Event

Description: Reminder: Hyperledger DCIWG Quarterly Update Due #tsc-project-update

When: At the end of the month

View Event

Organizer: community-architects@hyperledger.org

Description: The Hyperledger DCIWG update to the TSC is due at the end of the month.  Please schedule a time to add a review on an upcoming TSC call and please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Re: TSC Agenda for Dec 12, 2019

mark wagner <mwagner@...>
 

I need to travel to a doctors appointment this morning so I fear I will not be on the TSC Call today.

-mark


On Wed, Dec 11, 2019 at 3:57 PM Arnaud Le Hors <lehors@...> wrote:
Hi,

The agenda for this week's call is online. There are several quarterly reports that are due and haven't been posted yet though.

https://wiki.hyperledger.org/display/TSC/2019+12+12+TSC+Agenda

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Re: Upcoming Event: Hyperledger Quilt Quarterly Update Due #tsc-project-update - Thu, 12/12/2019 #tsc-project-update #cal-reminder

David Fuelling
 

Hello TSC,

I have been traveling and will not have the Quilt status report ready this morning - hopefully it will be all right to present to the TSC next week.

Thanks for your understanding,

David Fuelling


On Thu, Dec 5, 2019 at 12:00 AM tsc@... Calendar <tsc@...> wrote:

Reminder: Hyperledger Quilt Quarterly Update Due #tsc-project-update

When: Thursday, 12 December 2019

View Event

Organizer: community-architects@...

Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Upcoming Event: Hyperledger Learning Materials Development WG Quarterly Update Due #tsc-wg-update - Thu, 12/19/2019 #tsc-wg-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Learning Materials Development WG Quarterly Update Due #tsc-wg-update

When: Thursday, 19 December 2019

View Event

Organizer: community-architects@...

Description: Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update.


Upcoming Event: Hyperledger Caliper Quarterly Update Due #tsc-project-update - Thu, 12/19/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Caliper Quarterly Update Due #tsc-project-update

When: Thursday, 19 December 2019

View Event

Organizer: community-architects@...

Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


TSC Agenda for Dec 12, 2019

Arnaud Le Hors
 

Hi,

The agenda for this week's call is online. There are several quarterly reports that are due and haven't been posted yet though.

https://wiki.hyperledger.org/display/TSC/2019+12+12+TSC+Agenda

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


IDWG call minutes/notes and recordings for Dec 11, 2019

Vipin Bharathan
 

Hi all,

Terrific attendance and great discussion on Digital Wallets with side excursions into ISO 307 etc.

Thanks to Darrell O'Donnell for the presentation and Kelly Cooper for notes.
I have added the audio and video recordings to the minutes.
Until next year.
Hopefully we will start the year off with a bang on Jan 8th with a talk by Kim Cameron.
We need ideas on the format and content of the IDWG in the new year.
Happy new year and a great solstice.


Thanks again,
Vipin


Besu Architecture Overview Presentation - Dec 11th 11 AM PST

Ram Jagadeesan (rjagadee)
 

Folks,

Danno Ferrin and Lucas Saldanha from Consensys will present an overview of the Besu architecture, 11 AM PST, Wed Dec 11th.

Please note that this is a one-off event not in our regular bi-weekly meeting slot.

Here is the proposed agenda:
* Ethereum Basics
- Networking & Gossip
- Block Production
- Consensus (briefly)
* Contract Execution
- EVM
- Account Storage Trie
- State Storage Trie
* Chain Reorgs for non-finalized consensus protocols
  • * EEA Privacy
    - Technical Specification
    - Restricted vs Unrestricted
    * Besu Private TXs
    - Orion/PMT/Privacy Precompile
    - Processing of Private TXs
    * Privacy Groups
    - What are they?
    - Benefits
    * Future work?
    - Handling reorgs
    - ...


Identity WG call tomorrow Dec 11, 2019 (12 noon EST, 17:00 UTC)

Vipin Bharathan
 

Hi all,

Make suggestions or comments on the wiki page or in a response to this email.

The main event is a talk by Darrell O'Connell on digital wallets. This will likely last 30 minutes with adequate time for questions and answers.

Call is on hyperledger zoom.

Please attend to learn about or teach us the latest in Digital Wallets.

Thanks,
Vipin


Re: Volume II--Administrivia

VIPIN BHARATHAN
 

Hart,
As usual you are very thorough.
This proposal gells with the IPR (Intellectual Property Rights) regime of W3C CG participation and is simple to implement.
Thanks

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: tsc@... <tsc@...> on behalf of hmontgomery@... via Lists.Hyperledger.Org <hmontgomery=us.fujitsu.com@...>
Sent: Saturday, December 7, 2019 4:54 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: [Hyperledger TSC] Volume II--Administrivia
 

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

 


Identy WG report on PDS/IdH/EDV call Dec 6, 2019

Vipin Bharathan
 

Hi all,

What does the subject line mean?

Let me try expanding it.
PDS= Personal Data Store
IdH=Identity Hub
EDV=Encrypted Data Vault

All relate to a similar concept- Data (and claims) about a subject stored in an adequately protected location; under distributed control (includes delegation) to be used in various contexts.

What this meeting was about?
Many bodies (standards or implementation or both) are working on parallel problems about PDS/idH/EDV. In order not to diverge too much and create conflicting and competing standards and implementation, these parties (DiF, W3C, Solid, Aries/Indy, other experts) are hammering out a consensus(that word again) about where to house the standardization and implementation efforts. About 60 people were involved in the calls.

What did they achieve so far?
  1.  The agreed to work together
  2.  They will house the calls in DiF, which will be open to the entire community (not just to paying members of DiF)
  3.  DiF will also house the reference implementation and test suites. Reference does not imply preferred.
  4.  Since this is about the data storage, all questions on the user-facing front end as well as schemas for storage and the communication between the various parties are out of scope. However, they will support already existing efforts in these areas.
  5. The IPR (Intellectual Property Rights)  starts with the agreement in W3C Community groups (that anyone can join), thus the openness. There are some questions to be answered about the IPR in DiF which is housed under a different IPR regime.
When I used the word hammering, I meant it almost literally. It is great to witness compromise; especially for those of us who are outside the windows looking in.

What is missing?
The IPR stuff- the ED of DiF (Rouven Heck) will see how the DiF IPR can be integrated to the W3C CG IPR and how everyone can work together. There are documents that can bootstrap the effort, implementation of certain components exist. All of these will feed into the effort.

Why is it relevant to the Identity WG and Blockchains?
Since this is about the idea of how data repositories on Identity are specified and implemented, this falls under IDWG. Blockchains enter in two ways- for peer to peer access to the truth about the repository; to be used as the identity solution for other use cases. Right now we are interested parties, not direct participants. Any individual or enterprise can join the new effort.

What is in the short term for us, the Identity WG?
We have worked closely with the Indy/Aries community; and hosted presentations on related topics; including the DiF/Aries paper on HUBS vs wallets.
This Wednesday (the 11th) we will have a presentation from Darrell O'Donnell on digital wallets. Which are the means with which interaction with the repository will happen.
We had presentations on the Digital Locker in India (which is similar to a personal wallet). This is already in production with a billion plus users. Control and governance of this is not as distributed as a democracy deserves; there are steps being taken to get more privacy and freedom from surveillance on this platform.

Comments and responses are welcome...
Thanks,
Vipin


Volume II--Administrivia

Hart Montgomery
 

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

 


Re: Incubation/Active Status

Silona Bonewald <sbonewald@...>
 

This is a wonderful writeup, Hart.  Thank you for sharing.

On Wed, Dec 4, 2019 at 4:11 PM hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

Sorry for the incoming long wall of text.  I wanted to comment on the incubation/active status debates so that hopefully we could clarify things, frustrate people less, and spend less time on what is essentially a rubber stamp in the future.  With that being said, here goes:

 

In light of all of the discussion we’ve had on the Besu proposal for active status, I wanted to dig down into the details of why people care so much about active status versus incubation.  We discussed this a little bit in the project lifecycle task force (https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria), but in light of all of the discussion at the last TSC meeting, I thought it might be a good idea to bring it up again.

 

My fundamental question is the following:  why do we care so much (or at all) about active/incubation status, and do we even need a distinction? 

 

The two documents that are relevant to the discussion are:

https://wiki.hyperledger.org/display/HYP/Project+Lifecycle

https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria

 

Let’s ignore for a moment that the exit criteria in these two documents are not exactly consistent (for instance, the project lifecycle document requires a “history of releases” like that of an active project, while the actual exit criteria document only would require a “developer preview”).  This is something that definitely needs to be cleaned up, but I’ll mostly go by the exit criteria document, since it is more recent.

 

The core overriding requirement for active status, as put by Chris first (I think), is that “the community and infrastructure necessary for a project to succeed are in place.”  This means that all people and things that a project will need to generate good quality, useful code are there.  With this in mind, let’s take a look at the core requirements from the exit criteria document:

 

1.       Legal (Apache 2.0, etc.)

2.       Community—the seemingly most discussed metric

3.       Sufficient test coverage

4.       Sufficient user documentation

5.       Alignment (i.e., the project still fits within Hyperledger)

6.       Infrastructure is set up

7.       CII Badge

 

We also require TSC approval for a project’s 1.0 release.  This hasn’t been migrated over to the official TSC documentation list (so, there’s even more inconsistency here in terms of what is written in the official TSC documentation).  But here (https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321784 ) is the document and here is a summary:

 

1.       Project has reached active status

2.       Release features meet the project’s charter

3.       Satisfies “internal project requirements”—mostly things like appropriate test coverage, bug handling, and documentation

4.       Satisfies “technical criteria”—CII badge, security audit, crypto code auditing, license scan, etc.

 

Obviously there is a lot of overlap between these two. 

 

In particular, of the active status criteria, #3 (test coverage), #4 (sufficient user documentation), and #7 (CII badge) are explicitly covered in the 1.0 release criteria.  In addition, #6 (infrastructure) and #1 (legal) are mentioned in both, although the requirements for 1.0 release seem a little bit more stringent (i.e. more infrastructure is required).

 

Let’s go back to the beginning of the project lifecycle and look at what is required for incubation status:

 

1.       Have a clear description

2.       Have a well-defined scope

3.       Identify committed development resources

4.       Identify initial maintainers

5.       Be vendor neutral

 

We have been implicitly requiring incoming code to be correctly licensed by incubation (rather than active status), so one easy move I think we could do is to formalize this requirement.  It’s not mentioned in either the project lifecycle document or the project proposal document.

 

“Well-defined scope” corresponds roughly to “Alignment” in the incubation exit criteria, and we ask the “context” question in the project lifecycle document, so I’d assume that any project that fails the #2 requirement “Alignment” for active status will probably not have made it to incubation in the first place, barring some sort of pivot (but this would, of course, fail the #2 requirement for 1.0 release (release meet’s the project’s charter).

 

So if we assume metrics #1 (legal) and #5 (alignment) are already a given due to the project getting into incubation in the first place, then the only thing active/incubation is really giving us that is unique from both the project proposal requirements and the 1.0 release criteria is the community metric. 

 

Perhaps not coincidentally, we have talked about the community metric the most for active status discussion, and it seems to be the bottleneck in most past, current, and planned proposals (i.e., people are waiting on proposing due to the community metric).  This metric is also perhaps the most subjective.  On the most recent TSC call, it seemed like everyone had a different interpretation of the community metric. 

 

The exact community metric requirements are:

·         The project must have an active and diverse set of contributing members representing various constituencies

·         The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)

·         Release plans are developed and executed in public by the community.

 

Out of these, the first two are very open to interpretation.  If one is so inclined, it’s easy to make the case that many (or, if you want to be argumentative, all) of the Hyperledger projects are highly dependent on a “single entity.”  Regardless of whether you agree with what I’m about to propose, I think it’s a relatively universal good idea that if we do keep the incubation exit criteria in its current form, we should provide more quantification here so that projects that want to apply for active status have a better idea of what they need to attain.

 

I’ve mostly stuck with established facts so far.  Now I’m going to veer off into what might be a controversial opinion.  I’m of the opinion that the only real criterion (and purpose) of the active status/incubation exit criteria checkpoint is the community status evaluation—everything else either follows from the project being approved for incubation in the first place or is present in the 1.0 release criteria. 

 

What does the general community get from incubation/active status?  A binary value that says whether the TSC thought the community support of a certain project was “good” or “not good” on some particular day.  In the grand scheme of things, this is not particularly useful information, since even the TSC can’t exactly agree on what “good” community support is.

 

On the other hand, there are several notable tools that would provide community metrics that could be very useful for outsiders.  Bitergia (https://blog.bitergia.com/) is an example that comes to mind.  If we had strong public metrics on code contributions and community support (distributions on contribution by company, contributor, geography, etc.) this active/incubation bit wouldn’t really be needed:  rather than have the TSC assess the status of a community, why not give people all of the appropriate information and let them judge for themselves?

 

We can argue that something like security or cryptography requires expert review:  it’s very hard for someone who isn’t an expert in these areas to decide whether or not something is secure, even given time to examine it.  But community support is not exactly something that requires an expert review—any average person with some knowledge of software development can make a pretty reasonable determination of community support if they are given enough facts.  Since this is something that is very subjective but also doesn’t require expert knowledge to analyze, it might be best to leave the TSC out of this.

 

So, while I don’t think this is feasible now since we don’t have the software in place to property handle contributor analytics, I think it might be worth considering in the long run to do the following:

 

1.       Move all of the requirements of the incubation exit criteria to either the 1.0 release or the project proposal.

2.       Get rid of the active/incubation status altogether.

3.       Collect and publish a large and useful amount of contributor statistics so outsiders can determine the level of community support for a project themselves.

 

What do people think about this?  Does this make sense?

 

I’d also like to point out that we currently require projects to achieve active status before releasing a 1.0 version.  If we keep active status as a milestone, I’d like to push back on this requirement.  At least in my opinion, we approved this assuming the bar for active status was much lower than it currently is today.  The bar for active status seems to be very high.  Something like Explorer may never get enough contributors to have active status under the current metrics—and this is OK, because it may not need a lot of contributors to build successful software--but that doesn’t mean it shouldn’t be able to release a 1.0 if the software is excellent.

 

Finally, regardless of what you think about this idea, we do need to clean up our documentation on this.  It’s not clear at all and is in some cases contradictory.  Putting all of the useful documentation in one place and adding some examples of when (and when not) projects are ready for milestones would be quite useful for projects and hopefully end a lot of the frustration involved in the project lifecycle process for both the projects and the TSC.

 

Please let me know what you all think about this (positive and negative).  If this gets a lot of responses, I’ll move it to a wiki so it can be further taken apart.

 

If you’ve made it this far, bless your heart and thanks for reading.

 

Thanks,

Hart

 



--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Re: Incubation/Active Status

Middleton, Dan <dan.middleton@...>
 

Hi Hart,

I think these topics are familiar to us and so it’s easy for us to dig into more details and more options.

That of course works against us moving the TSC agenda to technical topics.

What topics would those be? We need to give ourselves the priority and space to start building that agenda.

 

Thanks,

Dan

 

From: "Montgomery, Hart" <hmontgomery@...>
Date: Friday, December 6, 2019 at 3:25 AM
To: Dan Middleton <dan.middleton@...>, "tsc@..." <tsc@...>
Subject: RE: [Hyperledger TSC] Incubation/Active Status

 

Hi Dan,

 

I’m not sure I totally agree with all of these points.  Maybe you can convince me otherwise, but I’m not yet convinced.

 

I definitely agree that having a diverse contributor and maintainer base is a positive thing.  I don’t think anyone is denying that.  My points are that 1) no one can seem to agree on what the diversity threshold should be for active status and 2) would we really need a TSC determination if we could just publish contributor statistics?

 

As I pointed out in the “book” below (as Arnaud put it, anyway), I don’t think it requires an expert to determine community support levels if we provide good metrics.  It’s not a security analysis or something like that.   It’s apparent from the TSC discussion that some people are OK working with code from a project with a less diverse maintainer base than others are, and, in my opinion, that’s totally fine.  I’m happy to let them decide their thresholds. 

 

As for your second point, there might be small projects that produce perfectly good software that is production-ready, even though the community is small.  Why should these projects not be allowed to release a 1.0?  Some things are just small in scope.  Again, I think as long as people who want to use the software are informed in advance that it is heavily dependent on a small number of people (again, the community metrics), I don’t see why this would be a problem.  In my mind, a 1.0 should be about software quality.

 

As I interpret it, you want the active status requirement to function as something that forces people to reach out to the community for contributors.  Is this correct?

 

Thanks again for engaging and for reading, and please feel free to tell me why I speak nothing but heresy!

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Thursday, December 5, 2019 2:30 AM
To: Montgomery, Hart <hmontgomery@...>; tsc@...
Subject: Re: [Hyperledger TSC] Incubation/Active Status

 

I think the incubation / active status serves an important function. It demands of a project that it spends effort to get a diverse contributor/maintainer base and learns how to operate in a community.

That kind of diversity is important for a healthy and reliable project and inhibits single vendor control.

 

The requirement that a project fulfill this milestone before it’s first major release is directly in line with this. We do not want to advertise a project is production ready if it relies on an immature community under single vendor control.

 

My $0.02,

Dan

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, December 4, 2019 at 11:11 PM
To: "tsc@..." <tsc@...>
Subject: [Hyperledger TSC] Incubation/Active Status

 

Hi Everyone,

 

Sorry for the incoming long wall of text.  I wanted to comment on the incubation/active status debates so that hopefully we could clarify things, frustrate people less, and spend less time on what is essentially a rubber stamp in the future.  With that being said, here goes:

 

In light of all of the discussion we’ve had on the Besu proposal for active status, I wanted to dig down into the details of why people care so much about active status versus incubation.  We discussed this a little bit in the project lifecycle task force (https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria), but in light of all of the discussion at the last TSC meeting, I thought it might be a good idea to bring it up again.

 

My fundamental question is the following:  why do we care so much (or at all) about active/incubation status, and do we even need a distinction? 

 

The two documents that are relevant to the discussion are:

https://wiki.hyperledger.org/display/HYP/Project+Lifecycle

https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria

 

Let’s ignore for a moment that the exit criteria in these two documents are not exactly consistent (for instance, the project lifecycle document requires a “history of releases” like that of an active project, while the actual exit criteria document only would require a “developer preview”).  This is something that definitely needs to be cleaned up, but I’ll mostly go by the exit criteria document, since it is more recent.

 

The core overriding requirement for active status, as put by Chris first (I think), is that “the community and infrastructure necessary for a project to succeed are in place.”  This means that all people and things that a project will need to generate good quality, useful code are there.  With this in mind, let’s take a look at the core requirements from the exit criteria document:

 

  1. Legal (Apache 2.0, etc.)
  2. Community—the seemingly most discussed metric
  3. Sufficient test coverage
  4. Sufficient user documentation
  5. Alignment (i.e., the project still fits within Hyperledger)
  6. Infrastructure is set up
  7. CII Badge

 

We also require TSC approval for a project’s 1.0 release.  This hasn’t been migrated over to the official TSC documentation list (so, there’s even more inconsistency here in terms of what is written in the official TSC documentation).  But here (https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321784 ) is the document and here is a summary:

 

  1. Project has reached active status
  2. Release features meet the project’s charter
  3. Satisfies “internal project requirements”—mostly things like appropriate test coverage, bug handling, and documentation
  4. Satisfies “technical criteria”—CII badge, security audit, crypto code auditing, license scan, etc.

 

Obviously there is a lot of overlap between these two. 

 

In particular, of the active status criteria, #3 (test coverage), #4 (sufficient user documentation), and #7 (CII badge) are explicitly covered in the 1.0 release criteria.  In addition, #6 (infrastructure) and #1 (legal) are mentioned in both, although the requirements for 1.0 release seem a little bit more stringent (i.e. more infrastructure is required).

 

Let’s go back to the beginning of the project lifecycle and look at what is required for incubation status:

 

  1. Have a clear description
  2. Have a well-defined scope
  3. Identify committed development resources
  4. Identify initial maintainers
  5. Be vendor neutral

 

We have been implicitly requiring incoming code to be correctly licensed by incubation (rather than active status), so one easy move I think we could do is to formalize this requirement.  It’s not mentioned in either the project lifecycle document or the project proposal document.

 

“Well-defined scope” corresponds roughly to “Alignment” in the incubation exit criteria, and we ask the “context” question in the project lifecycle document, so I’d assume that any project that fails the #2 requirement “Alignment” for active status will probably not have made it to incubation in the first place, barring some sort of pivot (but this would, of course, fail the #2 requirement for 1.0 release (release meet’s the project’s charter).

 

So if we assume metrics #1 (legal) and #5 (alignment) are already a given due to the project getting into incubation in the first place, then the only thing active/incubation is really giving us that is unique from both the project proposal requirements and the 1.0 release criteria is the community metric. 

 

Perhaps not coincidentally, we have talked about the community metric the most for active status discussion, and it seems to be the bottleneck in most past, current, and planned proposals (i.e., people are waiting on proposing due to the community metric).  This metric is also perhaps the most subjective.  On the most recent TSC call, it seemed like everyone had a different interpretation of the community metric. 

 

The exact community metric requirements are:

  • The project must have an active and diverse set of contributing members representing various constituencies
  • The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)
  • Release plans are developed and executed in public by the community.

 

Out of these, the first two are very open to interpretation.  If one is so inclined, it’s easy to make the case that many (or, if you want to be argumentative, all) of the Hyperledger projects are highly dependent on a “single entity.”  Regardless of whether you agree with what I’m about to propose, I think it’s a relatively universal good idea that if we do keep the incubation exit criteria in its current form, we should provide more quantification here so that projects that want to apply for active status have a better idea of what they need to attain.

 

I’ve mostly stuck with established facts so far.  Now I’m going to veer off into what might be a controversial opinion.  I’m of the opinion that the only real criterion (and purpose) of the active status/incubation exit criteria checkpoint is the community status evaluation—everything else either follows from the project being approved for incubation in the first place or is present in the 1.0 release criteria. 

 

What does the general community get from incubation/active status?  A binary value that says whether the TSC thought the community support of a certain project was “good” or “not good” on some particular day.  In the grand scheme of things, this is not particularly useful information, since even the TSC can’t exactly agree on what “good” community support is.

 

On the other hand, there are several notable tools that would provide community metrics that could be very useful for outsiders.  Bitergia (https://blog.bitergia.com/) is an example that comes to mind.  If we had strong public metrics on code contributions and community support (distributions on contribution by company, contributor, geography, etc.) this active/incubation bit wouldn’t really be needed:  rather than have the TSC assess the status of a community, why not give people all of the appropriate information and let them judge for themselves?

 

We can argue that something like security or cryptography requires expert review:  it’s very hard for someone who isn’t an expert in these areas to decide whether or not something is secure, even given time to examine it.  But community support is not exactly something that requires an expert review—any average person with some knowledge of software development can make a pretty reasonable determination of community support if they are given enough facts.  Since this is something that is very subjective but also doesn’t require expert knowledge to analyze, it might be best to leave the TSC out of this.

 

So, while I don’t think this is feasible now since we don’t have the software in place to property handle contributor analytics, I think it might be worth considering in the long run to do the following:

 

  1. Move all of the requirements of the incubation exit criteria to either the 1.0 release or the project proposal.
  2. Get rid of the active/incubation status altogether.
  3. Collect and publish a large and useful amount of contributor statistics so outsiders can determine the level of community support for a project themselves.

 

What do people think about this?  Does this make sense?

 

I’d also like to point out that we currently require projects to achieve active status before releasing a 1.0 version.  If we keep active status as a milestone, I’d like to push back on this requirement.  At least in my opinion, we approved this assuming the bar for active status was much lower than it currently is today.  The bar for active status seems to be very high.  Something like Explorer may never get enough contributors to have active status under the current metrics—and this is OK, because it may not need a lot of contributors to build successful software--but that doesn’t mean it shouldn’t be able to release a 1.0 if the software is excellent.

 

Finally, regardless of what you think about this idea, we do need to clean up our documentation on this.  It’s not clear at all and is in some cases contradictory.  Putting all of the useful documentation in one place and adding some examples of when (and when not) projects are ready for milestones would be quite useful for projects and hopefully end a lot of the frustration involved in the project lifecycle process for both the projects and the TSC.

 

Please let me know what you all think about this (positive and negative).  If this gets a lot of responses, I’ll move it to a wiki so it can be further taken apart.

 

If you’ve made it this far, bless your heart and thanks for reading.

 

Thanks,

Hart

 


Re: Incubation/Active Status

Hart Montgomery
 

Hi Dan,

 

I’m not sure I totally agree with all of these points.  Maybe you can convince me otherwise, but I’m not yet convinced.

 

I definitely agree that having a diverse contributor and maintainer base is a positive thing.  I don’t think anyone is denying that.  My points are that 1) no one can seem to agree on what the diversity threshold should be for active status and 2) would we really need a TSC determination if we could just publish contributor statistics?

 

As I pointed out in the “book” below (as Arnaud put it, anyway), I don’t think it requires an expert to determine community support levels if we provide good metrics.  It’s not a security analysis or something like that.   It’s apparent from the TSC discussion that some people are OK working with code from a project with a less diverse maintainer base than others are, and, in my opinion, that’s totally fine.  I’m happy to let them decide their thresholds. 

 

As for your second point, there might be small projects that produce perfectly good software that is production-ready, even though the community is small.  Why should these projects not be allowed to release a 1.0?  Some things are just small in scope.  Again, I think as long as people who want to use the software are informed in advance that it is heavily dependent on a small number of people (again, the community metrics), I don’t see why this would be a problem.  In my mind, a 1.0 should be about software quality.

 

As I interpret it, you want the active status requirement to function as something that forces people to reach out to the community for contributors.  Is this correct?

 

Thanks again for engaging and for reading, and please feel free to tell me why I speak nothing but heresy!

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Middleton, Dan
Sent: Thursday, December 5, 2019 2:30 AM
To: Montgomery, Hart <hmontgomery@...>; tsc@...
Subject: Re: [Hyperledger TSC] Incubation/Active Status

 

I think the incubation / active status serves an important function. It demands of a project that it spends effort to get a diverse contributor/maintainer base and learns how to operate in a community.

That kind of diversity is important for a healthy and reliable project and inhibits single vendor control.

 

The requirement that a project fulfill this milestone before it’s first major release is directly in line with this. We do not want to advertise a project is production ready if it relies on an immature community under single vendor control.

 

My $0.02,

Dan

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, December 4, 2019 at 11:11 PM
To: "tsc@..." <tsc@...>
Subject: [Hyperledger TSC] Incubation/Active Status

 

Hi Everyone,

 

Sorry for the incoming long wall of text.  I wanted to comment on the incubation/active status debates so that hopefully we could clarify things, frustrate people less, and spend less time on what is essentially a rubber stamp in the future.  With that being said, here goes:

 

In light of all of the discussion we’ve had on the Besu proposal for active status, I wanted to dig down into the details of why people care so much about active status versus incubation.  We discussed this a little bit in the project lifecycle task force (https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria), but in light of all of the discussion at the last TSC meeting, I thought it might be a good idea to bring it up again.

 

My fundamental question is the following:  why do we care so much (or at all) about active/incubation status, and do we even need a distinction? 

 

The two documents that are relevant to the discussion are:

https://wiki.hyperledger.org/display/HYP/Project+Lifecycle

https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria

 

Let’s ignore for a moment that the exit criteria in these two documents are not exactly consistent (for instance, the project lifecycle document requires a “history of releases” like that of an active project, while the actual exit criteria document only would require a “developer preview”).  This is something that definitely needs to be cleaned up, but I’ll mostly go by the exit criteria document, since it is more recent.

 

The core overriding requirement for active status, as put by Chris first (I think), is that “the community and infrastructure necessary for a project to succeed are in place.”  This means that all people and things that a project will need to generate good quality, useful code are there.  With this in mind, let’s take a look at the core requirements from the exit criteria document:

 

  1. Legal (Apache 2.0, etc.)
  2. Community—the seemingly most discussed metric
  3. Sufficient test coverage
  4. Sufficient user documentation
  5. Alignment (i.e., the project still fits within Hyperledger)
  6. Infrastructure is set up
  7. CII Badge

 

We also require TSC approval for a project’s 1.0 release.  This hasn’t been migrated over to the official TSC documentation list (so, there’s even more inconsistency here in terms of what is written in the official TSC documentation).  But here (https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321784 ) is the document and here is a summary:

 

  1. Project has reached active status
  2. Release features meet the project’s charter
  3. Satisfies “internal project requirements”—mostly things like appropriate test coverage, bug handling, and documentation
  4. Satisfies “technical criteria”—CII badge, security audit, crypto code auditing, license scan, etc.

 

Obviously there is a lot of overlap between these two. 

 

In particular, of the active status criteria, #3 (test coverage), #4 (sufficient user documentation), and #7 (CII badge) are explicitly covered in the 1.0 release criteria.  In addition, #6 (infrastructure) and #1 (legal) are mentioned in both, although the requirements for 1.0 release seem a little bit more stringent (i.e. more infrastructure is required).

 

Let’s go back to the beginning of the project lifecycle and look at what is required for incubation status:

 

  1. Have a clear description
  2. Have a well-defined scope
  3. Identify committed development resources
  4. Identify initial maintainers
  5. Be vendor neutral

 

We have been implicitly requiring incoming code to be correctly licensed by incubation (rather than active status), so one easy move I think we could do is to formalize this requirement.  It’s not mentioned in either the project lifecycle document or the project proposal document.

 

“Well-defined scope” corresponds roughly to “Alignment” in the incubation exit criteria, and we ask the “context” question in the project lifecycle document, so I’d assume that any project that fails the #2 requirement “Alignment” for active status will probably not have made it to incubation in the first place, barring some sort of pivot (but this would, of course, fail the #2 requirement for 1.0 release (release meet’s the project’s charter).

 

So if we assume metrics #1 (legal) and #5 (alignment) are already a given due to the project getting into incubation in the first place, then the only thing active/incubation is really giving us that is unique from both the project proposal requirements and the 1.0 release criteria is the community metric. 

 

Perhaps not coincidentally, we have talked about the community metric the most for active status discussion, and it seems to be the bottleneck in most past, current, and planned proposals (i.e., people are waiting on proposing due to the community metric).  This metric is also perhaps the most subjective.  On the most recent TSC call, it seemed like everyone had a different interpretation of the community metric. 

 

The exact community metric requirements are:

  • The project must have an active and diverse set of contributing members representing various constituencies
  • The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)
  • Release plans are developed and executed in public by the community.

 

Out of these, the first two are very open to interpretation.  If one is so inclined, it’s easy to make the case that many (or, if you want to be argumentative, all) of the Hyperledger projects are highly dependent on a “single entity.”  Regardless of whether you agree with what I’m about to propose, I think it’s a relatively universal good idea that if we do keep the incubation exit criteria in its current form, we should provide more quantification here so that projects that want to apply for active status have a better idea of what they need to attain.

 

I’ve mostly stuck with established facts so far.  Now I’m going to veer off into what might be a controversial opinion.  I’m of the opinion that the only real criterion (and purpose) of the active status/incubation exit criteria checkpoint is the community status evaluation—everything else either follows from the project being approved for incubation in the first place or is present in the 1.0 release criteria. 

 

What does the general community get from incubation/active status?  A binary value that says whether the TSC thought the community support of a certain project was “good” or “not good” on some particular day.  In the grand scheme of things, this is not particularly useful information, since even the TSC can’t exactly agree on what “good” community support is.

 

On the other hand, there are several notable tools that would provide community metrics that could be very useful for outsiders.  Bitergia (https://blog.bitergia.com/) is an example that comes to mind.  If we had strong public metrics on code contributions and community support (distributions on contribution by company, contributor, geography, etc.) this active/incubation bit wouldn’t really be needed:  rather than have the TSC assess the status of a community, why not give people all of the appropriate information and let them judge for themselves?

 

We can argue that something like security or cryptography requires expert review:  it’s very hard for someone who isn’t an expert in these areas to decide whether or not something is secure, even given time to examine it.  But community support is not exactly something that requires an expert review—any average person with some knowledge of software development can make a pretty reasonable determination of community support if they are given enough facts.  Since this is something that is very subjective but also doesn’t require expert knowledge to analyze, it might be best to leave the TSC out of this.

 

So, while I don’t think this is feasible now since we don’t have the software in place to property handle contributor analytics, I think it might be worth considering in the long run to do the following:

 

  1. Move all of the requirements of the incubation exit criteria to either the 1.0 release or the project proposal.
  2. Get rid of the active/incubation status altogether.
  3. Collect and publish a large and useful amount of contributor statistics so outsiders can determine the level of community support for a project themselves.

 

What do people think about this?  Does this make sense?

 

I’d also like to point out that we currently require projects to achieve active status before releasing a 1.0 version.  If we keep active status as a milestone, I’d like to push back on this requirement.  At least in my opinion, we approved this assuming the bar for active status was much lower than it currently is today.  The bar for active status seems to be very high.  Something like Explorer may never get enough contributors to have active status under the current metrics—and this is OK, because it may not need a lot of contributors to build successful software--but that doesn’t mean it shouldn’t be able to release a 1.0 if the software is excellent.

 

Finally, regardless of what you think about this idea, we do need to clean up our documentation on this.  It’s not clear at all and is in some cases contradictory.  Putting all of the useful documentation in one place and adding some examples of when (and when not) projects are ready for milestones would be quite useful for projects and hopefully end a lot of the frustration involved in the project lifecycle process for both the projects and the TSC.

 

Please let me know what you all think about this (positive and negative).  If this gets a lot of responses, I’ll move it to a wiki so it can be further taken apart.

 

If you’ve made it this far, bless your heart and thanks for reading.

 

Thanks,

Hart

 


Minutes for 05 DEC 2019 meeting are published

Ry Jones
 


Re: Incubation/Active Status

Christopher Ferris <chris.ferris@...>
 

Great thread, thanks Hart for the thoughtful note, and the others for piling on.

"The core overriding requirement for active status, as put by Chris first (I think), is that “the community and infrastructure necessary for a project to succeed are in place.” "

Yeah, well, that little girl was me (couldn't resist).

Seriously, though, I do believe that to be the case. I'm not sure how we define objective criteria, because at the end of the day, it is a subjective concept. I also agree with Dan that the distinction serves a useful purpose. Groups such as Apache, Eclipse, CNCF and too many more to mention have incubation programs. Here's the Eclipse incubator graduation review criteria: https://www.eclipse.org/projects/dev_process/#6_3_2_Graduation_Review

6.3.2 Graduation Review

The purpose of the Graduation Review is to mark a Project’s change from the Incubation Phase to the Mature Phase.

The Graduation Review confirms that the Project is/has:

  • A working and demonstrable code base of sufficiently high quality.

  • Active and sufficiently diverse communities appropriate to the size of the graduating code base: Adopters, Developers, and users.

  • Operating fully in the open following the principles and purposes of Eclipse.

  • A credit to Eclipse and is functioning well within the larger Eclipse community.

A Graduation Review is generally combined with a progress or Release Review.

Look familiar?

So, while I agree we could tighten up our documented criteria, and we could and maybe should have Hyperledger publish some objective metrics for the community (I have been asking for this since I can't remember) the last line of the Eclipse criteria is kind of what we're looking for here. Has Besu met that bar? I don't know that I would quite say that, though I would say that the team is working hard towards this goal, and for that they deserve credit for the rapid progress that they have made. This is also the first time we have incubated a code base that was already mature and had somewhat of an active community around it. The challenge now is integrating those communities to the point that they feel like one and the same.

What I don't want to see (and I am sure others agree) is this discussion creating a speed bump to that integration. Hence, while the besu team have been very actively trying to integrate, I do think that those of us who have been with Hyperledger for what seems like forever, need to meet them half way, and I will be honest to say I haven't seen that happen, either.

Maybe what we need to do is have an early 2020 Contributor Summit (or whatever we want to call it) where we provide an opportunity to engage in a manner similar to the very effective Maintainer Summit in MSP.

Chris


On Thu, Dec 5, 2019 at 5:29 AM Middleton, Dan <dan.middleton@...> wrote:

I think the incubation / active status serves an important function. It demands of a project that it spends effort to get a diverse contributor/maintainer base and learns how to operate in a community.

That kind of diversity is important for a healthy and reliable project and inhibits single vendor control.

 

The requirement that a project fulfill this milestone before it’s first major release is directly in line with this. We do not want to advertise a project is production ready if it relies on an immature community under single vendor control.

 

My $0.02,

Dan

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, December 4, 2019 at 11:11 PM
To: "tsc@..." <tsc@...>
Subject: [Hyperledger TSC] Incubation/Active Status

 

Hi Everyone,

 

Sorry for the incoming long wall of text.  I wanted to comment on the incubation/active status debates so that hopefully we could clarify things, frustrate people less, and spend less time on what is essentially a rubber stamp in the future.  With that being said, here goes:

 

In light of all of the discussion we’ve had on the Besu proposal for active status, I wanted to dig down into the details of why people care so much about active status versus incubation.  We discussed this a little bit in the project lifecycle task force (https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria), but in light of all of the discussion at the last TSC meeting, I thought it might be a good idea to bring it up again.

 

My fundamental question is the following:  why do we care so much (or at all) about active/incubation status, and do we even need a distinction? 

 

The two documents that are relevant to the discussion are:

https://wiki.hyperledger.org/display/HYP/Project+Lifecycle

https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria

 

Let’s ignore for a moment that the exit criteria in these two documents are not exactly consistent (for instance, the project lifecycle document requires a “history of releases” like that of an active project, while the actual exit criteria document only would require a “developer preview”).  This is something that definitely needs to be cleaned up, but I’ll mostly go by the exit criteria document, since it is more recent.

 

The core overriding requirement for active status, as put by Chris first (I think), is that “the community and infrastructure necessary for a project to succeed are in place.”  This means that all people and things that a project will need to generate good quality, useful code are there.  With this in mind, let’s take a look at the core requirements from the exit criteria document:

 

  1. Legal (Apache 2.0, etc.)
  2. Community—the seemingly most discussed metric
  3. Sufficient test coverage
  4. Sufficient user documentation
  5. Alignment (i.e., the project still fits within Hyperledger)
  6. Infrastructure is set up
  7. CII Badge

 

We also require TSC approval for a project’s 1.0 release.  This hasn’t been migrated over to the official TSC documentation list (so, there’s even more inconsistency here in terms of what is written in the official TSC documentation).  But here (https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321784 ) is the document and here is a summary:

 

  1. Project has reached active status
  2. Release features meet the project’s charter
  3. Satisfies “internal project requirements”—mostly things like appropriate test coverage, bug handling, and documentation
  4. Satisfies “technical criteria”—CII badge, security audit, crypto code auditing, license scan, etc.

 

Obviously there is a lot of overlap between these two. 

 

In particular, of the active status criteria, #3 (test coverage), #4 (sufficient user documentation), and #7 (CII badge) are explicitly covered in the 1.0 release criteria.  In addition, #6 (infrastructure) and #1 (legal) are mentioned in both, although the requirements for 1.0 release seem a little bit more stringent (i.e. more infrastructure is required).

 

Let’s go back to the beginning of the project lifecycle and look at what is required for incubation status:

 

  1. Have a clear description
  2. Have a well-defined scope
  3. Identify committed development resources
  4. Identify initial maintainers
  5. Be vendor neutral

 

We have been implicitly requiring incoming code to be correctly licensed by incubation (rather than active status), so one easy move I think we could do is to formalize this requirement.  It’s not mentioned in either the project lifecycle document or the project proposal document.

 

“Well-defined scope” corresponds roughly to “Alignment” in the incubation exit criteria, and we ask the “context” question in the project lifecycle document, so I’d assume that any project that fails the #2 requirement “Alignment” for active status will probably not have made it to incubation in the first place, barring some sort of pivot (but this would, of course, fail the #2 requirement for 1.0 release (release meet’s the project’s charter).

 

So if we assume metrics #1 (legal) and #5 (alignment) are already a given due to the project getting into incubation in the first place, then the only thing active/incubation is really giving us that is unique from both the project proposal requirements and the 1.0 release criteria is the community metric. 

 

Perhaps not coincidentally, we have talked about the community metric the most for active status discussion, and it seems to be the bottleneck in most past, current, and planned proposals (i.e., people are waiting on proposing due to the community metric).  This metric is also perhaps the most subjective.  On the most recent TSC call, it seemed like everyone had a different interpretation of the community metric. 

 

The exact community metric requirements are:

  • The project must have an active and diverse set of contributing members representing various constituencies
  • The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)
  • Release plans are developed and executed in public by the community.

 

Out of these, the first two are very open to interpretation.  If one is so inclined, it’s easy to make the case that many (or, if you want to be argumentative, all) of the Hyperledger projects are highly dependent on a “single entity.”  Regardless of whether you agree with what I’m about to propose, I think it’s a relatively universal good idea that if we do keep the incubation exit criteria in its current form, we should provide more quantification here so that projects that want to apply for active status have a better idea of what they need to attain.

 

I’ve mostly stuck with established facts so far.  Now I’m going to veer off into what might be a controversial opinion.  I’m of the opinion that the only real criterion (and purpose) of the active status/incubation exit criteria checkpoint is the community status evaluation—everything else either follows from the project being approved for incubation in the first place or is present in the 1.0 release criteria. 

 

What does the general community get from incubation/active status?  A binary value that says whether the TSC thought the community support of a certain project was “good” or “not good” on some particular day.  In the grand scheme of things, this is not particularly useful information, since even the TSC can’t exactly agree on what “good” community support is.

 

On the other hand, there are several notable tools that would provide community metrics that could be very useful for outsiders.  Bitergia (https://blog.bitergia.com/) is an example that comes to mind.  If we had strong public metrics on code contributions and community support (distributions on contribution by company, contributor, geography, etc.) this active/incubation bit wouldn’t really be needed:  rather than have the TSC assess the status of a community, why not give people all of the appropriate information and let them judge for themselves?

 

We can argue that something like security or cryptography requires expert review:  it’s very hard for someone who isn’t an expert in these areas to decide whether or not something is secure, even given time to examine it.  But community support is not exactly something that requires an expert review—any average person with some knowledge of software development can make a pretty reasonable determination of community support if they are given enough facts.  Since this is something that is very subjective but also doesn’t require expert knowledge to analyze, it might be best to leave the TSC out of this.

 

So, while I don’t think this is feasible now since we don’t have the software in place to property handle contributor analytics, I think it might be worth considering in the long run to do the following:

 

  1. Move all of the requirements of the incubation exit criteria to either the 1.0 release or the project proposal.
  2. Get rid of the active/incubation status altogether.
  3. Collect and publish a large and useful amount of contributor statistics so outsiders can determine the level of community support for a project themselves.

 

What do people think about this?  Does this make sense?

 

I’d also like to point out that we currently require projects to achieve active status before releasing a 1.0 version.  If we keep active status as a milestone, I’d like to push back on this requirement.  At least in my opinion, we approved this assuming the bar for active status was much lower than it currently is today.  The bar for active status seems to be very high.  Something like Explorer may never get enough contributors to have active status under the current metrics—and this is OK, because it may not need a lot of contributors to build successful software--but that doesn’t mean it shouldn’t be able to release a 1.0 if the software is excellent.

 

Finally, regardless of what you think about this idea, we do need to clean up our documentation on this.  It’s not clear at all and is in some cases contradictory.  Putting all of the useful documentation in one place and adding some examples of when (and when not) projects are ready for milestones would be quite useful for projects and hopefully end a lot of the frustration involved in the project lifecycle process for both the projects and the TSC.

 

Please let me know what you all think about this (positive and negative).  If this gets a lot of responses, I’ll move it to a wiki so it can be further taken apart.

 

If you’ve made it this far, bless your heart and thanks for reading.

 

Thanks,

Hart

 

1061 - 1080 of 3847