Fabric had a set of release criteria for 1.0 documented here: 

https://wiki.hyperledger.org/display/fabric/Release+Exit+Criteria

These aren't Hyperledger criteria, these were what the maintainers came up with as a measure of 

maturity suitable for what we felt to be a 1.0 GA release.

I agree we are in a difficult position having already allowed Iroha to graduate to Active status.
While the full discussion is omitted, when we reviewed the request to graduate to Active status, we did

have a discussion of the diversity of contributors. If memory serves, there was a desire to continue to drive diversity

of contributor, and that resulted in DaveH visiting with the team to help them become more integrated

with the broader community. At the time, there were a few individual contributors that had fixed bugs etc,

yet if I look at the most recent 6 months, the contributions are almost exclusively from Soramitsu.

Here we are with a request to go to 1.0, and while the code may be robust, the diversity of contributing

organizations is actually much worse than it was reported at the request to graduate.

So, while I am in agreement that 1.0 should be a measure of maturity of the code, I really think that we need to reconsider how we evaluate requests to graduate. I also think that all of our projects need to double down on growing diversity of contributors and maintainers.

Chris

On Fri, Mar 15, 2019 at 10:58 AM Arnaud Le Hors <lehors@...> wrote:

I essentially agree with Dave. I think we found ourselves in an odd situation with Iroha in Active status without a diverse community of contributors but, pending resolution of the CDO issue, apparently ready for a 1.0 release.

I can't say that I know where Dave's criteria for a 1.0 release come from. While we have a fairly precise definition of what it takes for a project to move out of Incubation into Active status [1] I don't think we have anything similar for a 1.0 release, do we?

The key thing here is that the status of a project is meant to be representative of how the project operates, whether it has a good methodology, test suites, etc, independently of the maturity of the software being developed. One key criteria for moving out of incubation is to have a diversity of contributors. In Iroha's request to move out of incubation [2] it was stated that this was the case but that no longer seems to be true.

It's important to remember that we have agreed that in some cases we might allow for a project to have a 1.0 release (aka First Major Release) while still being in Incubation. [3]

On the face of today's situation, it would seem that the right thing to do is indeed to move the project back into Incubation - even though that's not a transition we had anticipated in the Project Lifecycle [4] - and allow for the release of Iroha 1.0.

[1] https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria
[2] https://docs.google.com/document/d/1Vi_Ii0omj8lqjt-tdwIiEQPSku8V5DEku2aS5lr1Vo0/edit#
[3] https://wiki.hyperledger.org/display/HYP/Project+Lifecycle#ProjectLifecycle-first_major_release
[4] https://wiki.hyperledger.org/display/HYP/Project+Lifecycle
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Dave Huseby" <dhuseby@...>
To:        "hmontgomery@..." <hmontgomery@...>
Cc:        Vipin Bharathan <vipinsun@...>, Hyperledger List <tsc@...>
Date:        03/15/2019 05:18 AM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...

---

Here's my 2p on this:

I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.

The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.

By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.

I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.

If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.

I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.

Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...


On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,

 

Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?

 

Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.

 

Thanks,

Hart

 

From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent: Thursday, March 14, 2019 9:04 AM
Cc: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 

Hi all,

 

As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?

 

Another interesting statistic would be increase in contributor diversity SINCE 1.0.

Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.

 

Please put this on next week's agenda.

 

Regards,

Vipin

 

Also added as comment on the Agenda.