Page tree
Skip to end of metadata
Go to start of metadata

This is a list of considerations TSC members apply to inbound project contributions.


(Arun) Goal: 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 incubation under the Hyperledger. Ideas should start in Hyperledger Labs.

  • (Hart):  I'm fine with projects not necessarily be conceptually implemented (in full, anyway) and in use, as long as there is a community in place that convinces me that this will happen in the not too distant future.  If we have these guidelines, we also have to define "conceptually implemented" and "in use."  Does "in use" count production use cases, PoCs, running in the background on my backup work Linux box, or what exactly?  What does "conceptually implemented" mean?

Codebase

  • (Danno) Code should exist as open source software in some form
    • Some projects come up from labs (e.g., Cactus, Ursa)
    • Some projects have stand alone governance prior to joining (Besu ... others?)
  • DCO sign off exists in the code repository 
    • If not 100% ready, the code is capable of becoming compliant upon entry (i.e. squash commit)
  • (Arun) Answer the checklist (TODO: come up with a checklist) for a new project's proposal in terms of license/copyright, DCO requirements, file structure/repo requirement (should comply to this requirement within 6 months of incubation), CI/CD requirement, release process (will be incubation exit criteria).

Maintainers

  • (Danno) The project should have multiple maintainers
    • These maintainers need not be from different companies
      • However, having maintainers from different companies is seen as a positive sign (Hart)
    • Proposals with only one maintainer have been rejected by prior TSCs.
  • (Arun) Come up with a plan to promote contributors into maintainers. Get this plan published as part of project proposal.
  • (Arun) The project either has demonstrable examples of POC/production uses publicly available or has backing of more than one organization/individuals (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 or at least 35% of the codebase contributions).

Sponsors

  • Sponsors are advocates for the project. There should be more than one sponsor, and they should be from different organizations. They may or may not be committing resources to the project.

Legal

  • (Tracy) Trademark concerns – project names should not be trademarked by a contributing company or if it is, then the trademark will need to be handed over to Hyperledger.
    • (Hart) Haven't we often formally named projects after approval?  I think we should just require marketing approval for a name.  This should solve the trademarking issue, as well as a number of other things (technical people pick bad names if left to their own devices!).
  • (Danno) Codebase should be Apache 2 licensable, without encumbrances
    • Non-Apache 2 licensed code is possible, but requires Governing board approval (Section 12 subsection d of the Hyperledger Charter)
    • Special examination should be given to copyleft and non-licensed code.
    • Required patent licensing issues have prevented projects from entering incubation.
    • GPL licensing issues have prevented projects from entering incubation.
    • (Hart):  isn't this required explicitly?  I think this is non-negotiable.  We can also move this under legal.
  • If code does not already have copyright, the code should be modified to include copyright as per Copyright and License Policy prior to being brought into Hyperledger

Overlap with Existing Projects

  • (Tracy) The TSC has mentioned that they are not interested in bringing in additional distributed ledger projects. There should be a distinct advantage for a new distributed ledger project. This will be similar for other type of projects. In general, if a project is similar to an existing project, there should be a distinct advantage that the project brings over and beyond the existing project and that this cannot be contributed directly to the existing project.
    • (Hart) I think it should be the case that a new project should bring something to the table that current projects don't.  But I think this language might be a little too strong.
  • (Tracy) Based on the HIP template, dependent project's maintainers must sign off on the proposal before it is considered by the TSC.
    • (Danno) What is a dependent project? What is the difference between a dependent project and one used as a library vs. an optional integration?  What if multiple projects are integrated, can one block admission?
  • (Arun) 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.

Charter

  • (Arun) The project at the time of proposal must meet Hyperledger's charter as defined and amended on time to time. (Leaving it out on purpose, this is expected and implicit).
  • (Arun) 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.
    • (Hart) This seems like rules for the TSC rather than guidelines for the project.  Can we rephrase this so it tells the submitters what to expect rather than sets rules for the TSC?
    • (Arun) Right, makes sense.

Proposal Process

Recommendations

  • (Arun) Make relevant documentations, design discussions available in public. Keep them in review before bringing for discussion in TSC meeting.
    • (Hart) I think this is a big one.  We shouldn't even consider proposals where these things are not yet public, and should tell submitters to come back when they are.
  • (Arun) Publish the project's scope in advance. Call for public review comments on project's scope.
    • Optionally, make use of Hyperledger channels to invite more participation. Make use of Hyperledger mailing lists to invite and call for participation.
    • There can be special consideration, for example projects that are incubated from labs have been in the public domain, Hyperledger community is familiar with them.
  • No labels

12 Comments

    1. For Hyperledger, we may want to consider also distinguishing between labs and incubation since this question has come up multiple times over the past couple of months.

      1. In my mind labs corresponds to the sandbox. It has very low standards for admission and isn't subject to due diligence.  Incubation is the lowest level I would expect a project to be put into production where you don't have a maintainer/contributor on the team.

        I also feel that projects going to incubation should have a trajectory to active. I would think twice about voting to admit a project into incubation that will never progress to active for whatever reason.

  1. Regarding:

    • (Arun) Update checlist items for tools/website/writing blogs/marketing etc. (TODO: come up with a checklist). This becomes important as the community and number of projects grow.

    We have the following checklist for new projects: New Project Checklist - Community Architects - Hyperledger Confluence

    1. Ack, let me remove TODO part of the comment. Instead insert a clause that this checklist shall be completed once the TSC has accepted the project.

      1. As I said last week, I don't think we should have open references like that. Instead we should include whatever list we want to have in this very document.

  2. Regarding

    • (Arun) 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.

    I would not necessarily want blogs, articles, or social media promotion for projects that have not yet been accepted by the TSC. Hyperledger Labs are slightly different.

    1. Public review period and call for comments on the proposal will help us. First in terms of getting the proposal vetted through multiple eyes, gives the confidence on project's charter, shows the importance, identify potential risks, each of which is a great input for TSC. Second in terms of inviting collaboration. Blog posts or an article is to invite and encourage people to review all proposed projects as opposed to promoting an individual project.

      I agree that for a project incubating from labs, this step can be optional. These projects have been in public domain, specifically under Hyperledger GitHub, familiar to Hyperledger community and we have more insights on them.

      1. My concern was whether using Hyperledger blog or Hyperledger‘a social media accounts for proposals might imply some sort of endorsement. I think sending an email to the TSC list is good for getting people to take a look.

        1. Agree, sounds good, as long as there is an option to invite participation.

  3. Should we have a "Community" section as well?  While we want to clearly delineate the requirements from those for active status (or whatever badging system we decide to replace it with), it might make sense to make some suggestions about community.  Maybe I'm totally wrong here, but at least to me it seems like the TSC is clearly more likely to accept a project that has contributors/maintainers with lots of experience in the open source community (particularly those with HL experience) than a project whose contributors are totally new to open-source, all other things equal.  Should we formalize this?  Can we recommend steps in the document for contributors/maintainers that don't have open-source experience.  Apache has a "champion" role that, among other things, helps people newer to the community.  Maybe we don't want to formalize this like they've done, but maybe we can still encourage people to reach out for help?

  4. Regarding

    (Hart): I'm fine with projects not necessarily be conceptually implemented (in full, anyway) and in use, as long as there is a community in place that convinces me that this will happen in the not too distant future. If we have these guidelines, we also have to define "conceptually implemented" and "in use." Does "in use" count production use cases, PoCs, running in the background on my backup work Linux box, or what exactly? What does "conceptually implemented" mean?

    With "conceptual implementation" and "in use" - the intent is to approve a project - having strong reason to be placed in Hyperledger. We can define guidelines around how to showcase a strong reason. One such way is by demonstrating it in production use, another could be by showing the community demand (that there is no alternative to this project).