Date: Thu, 28 Mar 2024 21:19:22 +0000 (UTC)
Message-ID: <1355462937.11301.1711660762834@aws-us-west-2-hyp-confluence-1.web.codeaurora.org>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_11300_1215761975.1711660762834"
------=_Part_11300_1215761975.1711660762834
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
This document provides information to help people who are considering br=
inging their projects to Hyperledger for incubation. Specifically, it will =
outline items that the TSC will take into consideration when evaluating the=
project, as well as, some best practices that have been followed by other =
projects prior to the project proposal being submitted to the TSC. Our hope=
is that this document will smooth the entry process for new projects being=
proposed. The project proposal =
process and the template for project proposals=
are outlined outside of this document. The goal of incubation within H=
yperledger is to provide a space for projects that have high potential to g=
row in the community. Ideas should start in Hyperledger Labs.=
p>
Considerations
When considering projects that are proposed for incubation to Hyperledge=
r, the TSC will consider the following items: codebase, maintainers, commun=
ity, sponsors, legal, and overlap with existing projects. The below items a=
re not hard and fast rules for projects being accepted. The considerations =
are a guide to project proposers. If you meet most of the considerations, y=
ou are most likely to be accepted. If you do not meet any of the considerat=
ions, you are most likely to not be accepted.
Codebase
- Code should exist as open source software in some form. Previous accept=
ed projects have come up through labs (e.g., Cactus, Ursa); while othe=
rs previously had stand alone governance prior to joining (e.g., Besu)=
.
- DCO sign off should exists in the code repository. If not 100% rea=
dy, the code must be capable of becoming compliant upon entry (i.e. squash =
commit).
Maintainers
- The project should have multiple maintainers. These maintainers ne=
ed not be from different companies; however, having maintainers from d=
ifferent companies is seen as a positive sign. Proposals with only one maintainer have been rejected by pr=
ior TSCs.
- The project should have demonstrable examples of POC/production uses pu=
blicly available.
- The project should have the backing of more than one organization/indiv=
iduals (i.e., the project proposers should be able to demonstrate significa=
nt, long term contribution in codebase).
- TSC more likely to accept projects that have contributors familiar with=
open source practices. Participating in existing projects or starting in H=
yperledger Labs is a great place to grow this experience.
- Sponsors are advocates for the project. There should be more than one s=
ponsor, and they should be from different organizations. They may or may no=
t be committing resources to the project.
Legal
- Trademark concerns =E2=80=93 project names should not be trademark=
ed by a contributing company or if it is, then the trademark will need to b=
e handed over to Hyperledger. Project names must be approved by the Hyperle=
dger marketing committee
- Projects do not require a name prior to being submitted.
- Codebase should be Apache 2 licensable, without encumbrances
- Non-Apache 2 licensed code is possible, but requires Governing board ap=
proval (Section 12 subsection d of the Hyperledger=
Charter)
- Special examination should be given to copyleft and non-licensed code.<=
/li>
- Required patent licensing issues have prevented projects from entering =
incubation.
- GPL licensing issues have prevented projects from entering incubation.<=
/li>
- 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.
Overla=
p with Existing Projects
- The TSC has mentioned that they are not interested in bringing in addit=
ional distributed ledger projects. There should be a distinct advantage for=
a new distributed ledger project. This will be similar for other type of p=
rojects. 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 existi=
ng project.
- New projects should bring something to the table that current projects =
do not.
Best Practices
The following best practices have been identified by previous proposals.=
- Discuss the new project proposal within the community prior to submitti=
ng to the TSC for consideration. You might do this through existing chat ch=
annels, mailing lists, or direct communication with members of the communit=
y.
- Make sure that any links provided in the proposal are publicly availabl=
e.
- If you need an introduction into the Hyperledger Community, the Learnings Material Development Working Group will p=
rovide a good introduction.
Information below this line is the original discussion.
This is a list of considerations TSC members apply to inbound project co=
ntributions.
(Arun) Goal: Provide space under Hyperledger for a=
project that has high potential to grow in the community. The project s=
hall 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 fut=
ure. If we have these guidelines, we also have to define "conceptuall=
y implemented" and "in use." Does "in use" count production use cases=
, PoCs, running in the background on my backup work Linux box, or what exac=
tly? 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 ... ot=
hers?)
- 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 checkli=
st (TODO: come up with a checklist) for a new project's proposal in terms o=
f license/copyright, DCO requirements, file structure/repo requirement (sho=
uld comply to this requirement within 6 months of incubation), CI/CD requir=
ement, 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 posit=
ive sign (Hart)
- Proposals with only one maintainer have been rejected by prior TSCs.
(Arun) Come up with a plan to promote contributors into maintai=
ners. Get this plan published as part of project proposal.
- (Arun) The project either has demonstrable examples of POC/product=
ion uses publicly available or has backing of more than one organization/in=
dividuals (should be able to demonstrate significant contribution in codeba=
se, should also be able to demonstrate that this engagement is long term ~e=
x: 3 months long or at least 35% of the codebase contributions).
- Sponsors are advocates for the project. There should be more than one s=
ponsor, and they should be from different organizations. They may or may no=
t be committing resources to the project.
Legal
- (Tracy) Trademark concerns =E2=80=93 project names should not be t=
rademarked by a contributing company or if it is, then the trademark will n=
eed 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 sho=
uld solve the trademarking issue, as well as a number of other things (tech=
nical 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 ap=
proval (Section 12 subsection d of the Hyperledger=
Charter)
- Special examination should be given to copyleft and non-licensed code.<=
/li>
- Required patent licensing issues have prevented projects from entering =
incubation.
- GPL licensing issues have prevented projects from entering incubation.<=
/li>
(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
Over=
lap 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 advan=
tage for a new distributed ledger project. This will be similar for other t=
ype 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 bey=
ond the existing project and that this cannot be contributed directly to th=
e existing project.
- (Hart) I think it should be the case that a new project should bring so=
mething to the table that current projects don't. But I think this la=
nguage 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?&=
nbsp; What if multiple projects are integrated, can one block admission?
- (Arun) h=
ttps://hyperledger.github.io/hyperledger-hip/ lists that a new pro=
ject proposal must be floated in mailing list such as TSC's before submitti=
ng a HIP.
Charter
(Arun) The project at the time of proposal must meet Hyperledge=
r's charter as defined and amended on time to time. (Leaving it out on purp=
ose, 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 T=
SC makes a decision. Project proposal can bring the topic back to TSC if th=
ere are no action items pending and all questions are answered with documen=
ts 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=
h1>
Recommendations
- (Arun) Make relevant documentations, design discussions available in pu=
blic. Keep them in review before bringing for discussion in TSC meeting.
- (Hart) I think this is a big one. We shouldn't even consider prop=
osals 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 rev=
iew comments on project's scope.
Optionally, make use of Hyperledger channels to invite more par=
ticipation. Make use of Hyperledger mailing lists to invite and call fo=
r participation.
- There can be special consideration, for example projects that are incub=
ated from labs have been in the public domain, Hyperledger community is fam=
iliar with them.
------=_Part_11300_1215761975.1711660762834--