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 35 Next »

Volunteers:

Links to Related Material

Discussion Topics/Issues with proposed resolutions that don't seem controversial

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

Issue 4: Under what circumstances can a project be moved back to Incubation? to a lab?

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

Issue 7: How/when does a project get officially names?

Discussion Topics/Issues that need more discussion

Issue 2: What are the criteria for a "First Major Release"?

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

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

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


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