Status

RESOLVED 

Blocking
OutcomePR Merged
Minutes LinkSee Incubation entry considerations

Overview of Proposal

The criteria used to decide whether to approve or not a project proposal is currently not documented anywhere. This proposal is about addressing this gap by developing a document to be used as a reference for what is to be considered when evaluating a project proposal, similar to the Incubation exit criteria.

Formal Proposal(s)

Add project incubation entry considerations · Pull Request #13 hyperledger/tsc

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Reviewed By


9 Comments

  1. Hart Montgomery

    Even if we don't have total agreement on a formal criteria, I think it would be good if we could put together a document of recommendations in the form of "plusses" and "minuses."  TSC members might not agree on the importance of all of these, and each project being proposed for incubation would likely not have all of the "plusses," but hopefully we could come up with a criteria such that a proposal that had most of the "plusses" and few of the "minuses" would be overwhelmingly likely to be accepted, and the converse would also hold true.  This would let proposers make informed decisions about whether to submit a proposal or wait.

    In the same vein, some guidelines suggesting whether a contribution would be more appropriate for labs or incubation would also be a good thing.

    1. Hart Montgomery

      These could be "living" documents as well, and updated whenever the TSC decided to clarify.

  2. Hart Montgomery

    Some criteria proposed so far:

    • I proposed that projects should have contributors/maintainers from two independent entities.  So far, we have never accepted a project that has not met this requirement (see Tracy's comment), and this ensures that companies submitting code have made steps towards open governance.
    • Danno proposed that projects should be open-sourced in some form for a time before being accepted into incubation.  
    • Angelo proposed that projects that propose new protocols should have appropriate backing in the form of academic publications.

    I probably missed some things, so please feel free to add/comment (or fix what I've written above if you are Danno or Angelo).

    1. Tracy Kuhrt

      Related to the point of contributors/maintainers from two independent entities not being accepted into incubation

      • I proposed that projects should have contributors/maintainers from two independent entities.  So far, we have never accepted a project that has not met this requirement, and this ensures that companies submitting code have made steps towards open governance.

      We have accepted three projects with a single organization: Burrow, Composer, Cello. Since we have as part of the exit incubation criteria the need for maintainers from more than one companies, I would not stop a project from coming in with only a single organization if they have some history of doing open source development.

      1. Hart Montgomery

        You are right!  I confused the sponsors and contributors for those projects.  Thanks for the correction.

  3. Danno Ferrin

    I don't know about "a long time" but they should be open source for some time. Projects outside of the first year have either come up through labs or have been existing open source projects with their own governance. I don't know if we should designate a magic number but I don't think it needs to be a long time.

  4. Danno Ferrin

    As for contributors. Maintainers from one company can be fine, but I would want to see non company contributions.

    I do think we should have a standard that there be multiple maintainers, three ideally as a minimum. They can all be from the same company. Solang was rejected from incubation because if this.

  5. Arun S M

    Collecting relevant information floating around on this topic from HIP:

    1. https://hyperledger.github.io/hyperledger-hip/ lists that a new project proposal must be floated in mailing list such as TSC's before submitting a HIP.
    2. It is still important to define the word sponsor in the proposal document.

  6. Arun S M

    Few thoughts on this topic:

    • The goal should be to provide space under Hyperledger for a project that has high potential to grow in the community. The project shall be conceptually implemented and in use. Otherwise Hyperledger Labs is the place to grow up before incubating under Hyperledger.

    Quorum requirements and minimum expectations:

    1. As far as the requirement of maintainers/contributors from multiple organizations, my opinion is that we can be relaxed on this requirement. Allow newer projects to grow and gain community through Hyperledger.
    2. The project either has demonstrable examples of POC/production uses or has backing of more than one organization (should be able to demonstrate significant contribution in codebase, should also be able to demonstrate that this engagement is long term ~ex: 3 months long, at least 35% of the codebase contributions).

    Open source contribution/governance:

    1. The project at the time of proposal must meet Hyperledger's charter as defined and amended on time to time.
    2. Make existing source code and relevant documentations, design discussions available in public. Keep them in review before bringing for discussion in TSC meeting.
    3. TSC may decide to go through in depth and understand the project, ask for special sessions. There is no fixed timeline as to when TSC makes a decision. Project proposal can bring the topic back to TSC if there are no action items pending and all questions are answered with documents to demonstrate the completion.
    4. Come up with a plan to promote contributors into maintainers. Get this plan reviewed in TSC.
    5. Publish the project's charter in advance through Hyperledger channels (maybe a blog, an article, social media promotion). Call for public review comments on project's charter.
    6. TODO: Create a checklist for a new project's proposal in terms of license/copyright, DCO requirements, file structure/repo requirement, CI/CD requirement, release process. Project must adhere to this checklist. This is must as we are talking about bringing in an existing project into Hyperledger.
    7. TODO: Create a checklist of items for sharing relevant information about the new project with the larger community. This could be requirements to update tools/website/writing blogs/marketing etc.

    Failing to all or some of these requirement, a project maybe sent to Hyperledger Labs for observation. The project can propose back to TSC in 2 months after it is sent for observation. Note that these observations will be considered in addition to above points in such a case.

    For those projects which are graduating from Hyperledger Labs, there can be concession on points such as requirement of public review of projects' charter. It is good to do, but is an optional.