Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Next »

Volunteers:

Links to Related Material

Discussion Topics/Issues (draft)

Issue 1: When do we know that a project is "done"? What are the end-of-life criteria?

Proposed/Draft Resolution 1.1:

When a project, whether in Incubation or Active status, has not had any activities for over 6 months, it will be put on notice (via email to the project list) that it is on the path of being moved to "End of Life" (EOL) status out. After an additional 6 months have passed, if no activity has taken place, pending TSC approval, the project will effectively be moved to EOL. Software releases and quarterly TSC reports will be considered as signs of "activities".

Proposed/Draft Resolution 1.2:

Project Maintainers may submit to the TSC a request for moving their project to EOL. Pending TSC approval, a notification will be sent out to the project mailing list that the project is being placed on the path to EOL. After 6 months have passed, if no one has objected, pending TSC approval, the project will effectively be moved to EOL.

Issue 2: What are the criteria for a "First Major Release"? How does Dave's proposed Project Readiness fit in? FWIW, I created this set of criteria for the Fabric 1.0 release.

Proposed/Draft Resolution 2:

<insert here any criteria from Dave's Project Readiness proposal that do not pertain to what would be considered for graduating to "Active" status, which is handled separately.>

Issue 3: What criteria/steps/policies must releases after the First Major Release adhere to?

Proposed/Draft Resolution 3:

TBD

Issue 4: Under what circumstances can (or what are the criteria for) a project (to) be moved back to Incubation? to a lab?

Proposed/Draft Resolution 4:

Until projects are moved to EOL they can stay in Incubation or Active status for an unlimited amount of time.

Issue 5: Should all projects be required to start as a lab prior to being proposed for Incubation?

Proposed/Draft Resolution 5:

No. Projects can either start as a lab or be proposed to the TSC as a project entering Incubation. The TSC however may choose to direct a proposed project to a lab instead.

Issue 6: Should we have subprojects (and fewer toplevel projects)?

Proposed/Draft Resolution 6.1:

No. Existing projects already have various forms of subprojects which are left under the governance of each project. There is no need for the TSC to get into that micromanagement of the projects and subprojects. Of course, if any conflict were to rise between a project and one or more of its subprojects the issue can be brought up to the TSC for arbitration.

Proposed/Draft Related Resolution 6.2:

Existing projects that in practice are not being managed as "top level projects" should be officially rescinded from the top level nomination for house keeping purposes.

Proposed/Draft Related Resolution 6.3:

Projects that are dependent of one of the other projects should be folded under that project. This means Composer becomes Fabric Composer, Explorer becomes Fabric Explorer etc.

Issue 7: How/when does a project get officially names? (Early → easier to set up repository, Later → marketing committee can be involved, see mailing list for discussion)

Proposed/Draft Resolution 7:

Option 1: Ask the marketing committee to pre-approve a list of names that are catchy and not descriptive.

Option 2: Two phases for naming, the proposal comes with a temporary "code name" (e.g. a geographical location) that can be used for the repository with low risk of trademark violation. On approval, the marketing committee works with the proposers to create a long term name and does all checks. The repository name can be edited.

Issue 8: How do we deal with a new project coming in that is already a shipping product for a company?

  • Assuming it would need to pass Dave's proposed Project Readiness
  • It could be a bad look for a company to donate shipping code and then have it wallow in incubation
  • does it come in at the current shipping version ?

Proposed/Draft Resolution 8:

TBD

Comments

Hart:

I'd like our project lifecycle to satisfy three basic requirements:

  1. Make it easy for people to contribute high quality code that meets our mandate.  In other words, if something has technical merit and infrastructure behind it, the path to contribution should be easy.
  2. Make it easy for newcomers to understand the structure of Hyperledger, and how to get involved quickly.  This goes hand-in-hand with making it easy for the marketing folks to do their job and avoid confusion from outsiders on Hyperledger.
  3. Make technical governance relatively easy.  We don't want to bog down the TSC or other people who are responsible for things with meaningless governance rules.

Some comments on these points:

  1. I think that #1 has been less than optimal recently.  We've had a couple of recent projects where most of the discussion has been "should it be an independent project or a repo of another project."  I suggested subprojects as a potential compromise for future cases like this, but there are many other possible ways to handle this kind of issue (maybe a project taxonomy, for instance).
  2. On #2, the proliferation of projects has confused outsiders.  I can't count the number of times I've been asked how to build "an Ursa blockchain."  While I am definitely in favor of project proliferation, we need a way to control the message to the outside.  What we have right now is really confusing for newbies.
  3. As for #3, I think I (and a lot of others) were frustrated a bit by some of the recent project discussions.  We need to make things clear-cut.  While there will always be corner cases that require judgment calls, these should ideally be as few as possible.  This goes along with my points on #1.

What do you all think?


Bobbi:

To speak to point # 2, In order to reduce confusion for newcomers, consistent Marketing and learning materials that convey the Hyperledger projects accurately and that are designed to control the message.


  • No labels