Proposed:

The text below is from the perspective of a single lab steward (Vipin Bharathan- we need to socialize this proposal to get a broader view and a consensus among stewards and all affected parties)

Sponsors as they function today do not protect against any governance harm, their engagement past the initial proposal is minimal, unless they are also maintainers/committers. The proposal is to remove the requirement for sponsors in the application and fill the gaps for governance with automation, repo-linting and periodic reviews. 

Introduction

Current practice is for sponsors to be involved just at the inception of the lab. Sponsor requirement has always been a box-ticking exercise. Lab Stewards have consistently read and commented on lab proposals to improve the quality of submission and sometimes challenge the purpose of the lab.

Sections on contributions, good first issues, timely reviews etc. apply across the Hyperledger universe and not justlabs. Let us have a comprehensive and concise doc on these practices for all Hyperledger code. 

Some of these are mechanistic, others are social- a community mentor can certainly help with the social angle, but the mechanistic angle (like the license-guidance in the Readme for contributions, what to expect for a turnaround etc.) can be filled by tools like the repolinter or more documentation. Sponsors do not have to be the vehicle for this.

If there are specific harms to Hyperledger that result from this state of affairs, they are no more than that of regular projects who are meant to be self-regulating with a modicum of automation thrown in. Also make these harms transparent, so that tools can be built to counter them and the create an exception process with human intervention.

Hyperledger Labs have been very active in 2020, with multiple new labs being born last year, correspondingly there has been archiving and un archiving of labs as well. This points to lots of code being contributed on a range of active projects. 

Hyperledger Labs have been a very important proving ground. For example for re-use of code and concepts between the SIGs, the eThaler project developed for the lab has seen the code for its token re-used on the Climate Action & accounting SIG. There are many other success stories.

Review the language in the labs charter on Sponsors.

Proposers need a Sponsor (i.e. a maintainer of one of the Hyperledger projects, a TSC member or a WG chair);

From the Process To Propose A New Lab

The sponsor(s) are responsible for reviewing the proposal. Sponsors do not have a responsibility beyond this; ongoing work like contributing code or reviews is not tied to their role as sponsors. In reviewing the proposal, the sponsor(s) make sure that the proposal is cogent, and novel (in conception, proposed execution, or interested community). To find sponsors a. the proposers can use their connections to existing projects and ask maintainers b. find working groups or projects with affinities to the proposed lab and pitch the project (good to have the template already filled out) in associated channels and or mailing lists. The WG chairs emails, the maintainers contacts etc. can be found on the wiki or github. Make personal appeals if you can.

Comment: This language was created to clarify the role of the Sponsor as well as to guide proposers in finding Sponsors, since we (the lab stewards) had several reports about the friction in finding Sponsors. 

Specific cases:

Not all labs follow Apache 

About the licensing issue in labs, two projects with no license file, 3 with CC-By-4.0 (which reportedly fits in with HL charter) and of course the one with MIT. All others (37) have Apache 2.0- Sponsors nor lab stewards are not setup to catch license conformance, especially if source is imported from other repos or license file is changed by lab maintainers., suggest adding this to periodic repolinter or to automation when creating the labs similar to the checks for DCO. Current practices include the creation of labs with prebuilt Apache license file.