Volunteers:

Links to Related Material

Resolved Topics/Issues

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

Issue 2: What are the criteria for a "First Major Release"? Agreed on 9/5/2019

Issue 3: What criteria/steps/policies must releases after the First Major Release adhere to? Agreed on 9/5/2019

Issue 4: Under what circumstances can a project be moved back to Incubation? to a lab? Agreed 7/25/2019

Issue 5: Should all projects be required to start as a lab prior to being proposed for Incubation? Agreed 7/25/201

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

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

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

N.A.

Discussion Topics/Issues that need more discussion

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


Proposal


 Incubation


 First Major Release


Major Release:
Maintenance 

Deprecated


End of Life


Issue 5

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

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.

Agreed  


Issue 4

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

Resolution 4:

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

Agreed

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 ?

Resolution 8:

All new projects proposed to the TSC are considered to be starting in Incubation status. However, the Incubation exit criteria do not depend on any actual amount of time having been spent in Incubation. Whenever a project meets the Incubation exit criteria it can move to Active status. So, if a project happens to meet the Incubation exit criteria at the time a HIP is submitted to the TSC, the proposer of the project may submit a request to move to Active status at the same time. The project may then effectively move through Incubation immediately at the time it is accepted as a HIP.

The same goes with the first major release.


Agreed


Issue 2

What are the criteria for a "First Major Release"?



Resolution 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.

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)

Resolution 7:

To start, a proposal should come 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 will work with the proposers to create a long term name and will do all the necessary checks. The repository name can be changed.

Agreed

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)?

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 were originally started via a HIP but that in practice are not being managed as "top level projects" will 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.

Proposed/Draft Related Resolution 6.4:

Subproject status and reporting should be reported through the top level project. For example, Fabric Explorer status would be included in the Fabric quarterly reports..



Issue 1
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. 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".

Agreed

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.

Agreed







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.


68 Comments

  1. Vipin Bharathan

    For the points raised, as well as Hart's suggestion. The taxonomy discussion we had is the key. 

    Keeping taxonomy very simple- Blockchains/DLTs; Utilities; Libraries; (Apps?); (Communities:  Domain specific (SIGs), cross-cutting(WGs), labs ); Governance: (TSC, MarComm, The board). Some variant of this can work.

    Once we have this we can slot a new project into one of these categories (the dominant theme of new project should be used), if we do not agree then create new category (only if absolutely necessary)

    It should not be necessary to mandate a certain path for adoption (i.e. pass through labs, or needs to be incubated etc.) For this to be effective for shipped products we need to objectively evaluate them in terms of technical maturity (maybe a swat team, maybe talk to the customers of their shipped products etc.) (I do not think the TSC has the time for this) and they can be welcomed as active right from the get go.

    We need to get this into the project proposal Template as well.

  2. Arnaud J Le Hors

    How does Dave's proposed Project Readiness fit in?
    I think there is some good stuff in Dave's proposal but it mixes maturity of the project - in terms of community and organization - and maturity of the software, which is something we've tried to keep separate. It may not be possible to keep them completely separated but I think it is worth still trying.

    1. David Huseby

      My goal with the readiness is to define precise criteria for when a project is ready to exit one stage and move to the next. It will probably help to divide the criteria into technical and community buckets. It also means that a project can move backwards and forwards in the lifecycle. I think the important thing here is to have written criteria. I would suggest that we keep them to a minimum and make a point to revise and update them every quarter or six months to make sure the TSC's thinking is always reflected in them.

      These criteria primarily serve as directions for community leaders in each project to tell them what they should be working on if their goal is to move to X status, for all values of X. So if communicating clearly and precisely is the primary goal.

  3. Baohua Yang

    I would say we make everything as simple as possible from the beginning, then let it evolve if there's strong requirements.

    Simple is the best ticket for attracting new developers and users.

  4. Mark Wagner

    Do we need to cover labs here as well ?

    I realize that there is a separate process, controls, etc,  but they are related to projects....

    1. Hart Montgomery

      Yes, if we are going to make them a part of the project lifecycle (which seems to be the intention).

    2. Arnaud J Le Hors

      Cover the labs in what way?

      1. Ry Jones

        if we're talking about moving projects to and from labs in a formal way, do we need more formality over there?

        1. Arnaud J Le Hors

          No, that's the whole point to move a project to a lab in my view. There is no restrictions (well, very little) on labs so it's a good place for projects that don't manage to graduate to Active to live in. No more pressure, no more expectations. They can just continue their own course there.

          1. Vipin Bharathan

            I am against moving something back into labs. If there is very little or no activity on an incubated project for a while (1 year or 6 months), move it to "deferred" state (IETF uses this terminology for documents), no reports, no tracking, no marketing on "deferred" projects- what is the cost of a deferred project? What is the effort needed to move from incubated to deferred? (these two questions will have to be answered). There has to be a way for this project then to kick back into incubated state or into "archived" state. What is the effort needed for this? Another question

            1. David Huseby

              I also agree with Vipin on this. I think any labs that stall out and stop making forward progress should be marked as "deferred" or "archived". We could do house cleaning once per year where we go through the labs and archive stalled labs.

              I think Arnaud is correct that nothing should go back to lab status. I think that is because it would make "labs" as a stage before incubation and I don't think of labs projects like that. I think of them as speculative/disruptive in nature. Labs are smallish projects focused on thinking outside of the box. If they grow into a full project that's great, but I've always thought of labs as a place to nurture "wouldn't it be cool?" kind of ideas.

              Take the Hyperledger Umbra Lab for instance. It is focused on developing the ability to run HL networks under lab-like simulation conditions so that controlled computer science experiments can be executed in a repeatable way. We had mentees working on it last summer and we've got a new mentee and at least one other contributor working on it this summer. Eventually, I think we'll succeed and it will be great. I have high hopes for some success this year. But it is important to realize that it isn't critical path for HL's mission but it would be really cool to have the capability. Even if it grew into a full blow utility/tools project, I don't ever see it moving back to lab status.

            2. Dan Middleton

              If a project has failed to progress through incubation, I think it is fine to move it to the end of the lifecycle, which is currently called End of Life. If there does remain some community around it, there's nothing stopping them from forking the old project and trying to restart fresh in a lab. Doing that automatically seems unnecessary.

          2. David Huseby

            I agree with Arnaud on this one. The Labs should be for things that are more than just a cool idea but less than a project that wants marketing and to be included as a separate logo on the greenhouse graphic. The requirement of having a sponsor is all of the formality I think we need. The sponsorship serves to gate keep the labs area from just being a "place to park code". I think labs should be smallish research/speculative projects that make sense as part of the Hyperledger portfolio. I know I'm not saying anything new but thought I'd say it out loud to gather any responses or disagreements.

    3. Mic Bowman

      Certainly some labs are intended as pre-cursors to full projects, but some labs are just about exploring/collaborating on smaller related code that others may find valuable. So clarifying the role of labs wrt projects is fine so long as we don't constrain other roles for labs.


      And this is yet another discussion that we've already had in the previous TSC meetings.

      1. Christopher Ferris

        All the more reason to have a well documented and searchable decision log. (wink)

  5. Hart Montgomery

    Lots of people (myself included) are writing pretty substantial content in the comments.  Can we move these to the body of the document so it is easier to follow the discussion?  Thanks!

    1. Ry Jones

      sure!

    2. Arnaud J Le Hors

      Yes, I have to say I'm not too happy with the way inline comments are handled. Is there a way to get them displayed by default? I have only been able to see them by clicking on the anchor/highlighted text they relate to which makes spotting new comments cumbersome.

      So unless I missed something I agree to moving to general comments. Let's try to have one thread per issue as much as possible. And, please, make sure to reference what you are commenting on. It's not always obvious.

  6. Arnaud J Le Hors

    Proposed/Draft Resolution 1:

    When a project has not had any new releases for over 6 months, it should be moved out of Active status into "End of Life" status, pending TSC approval.


    Ry Jones

    generally agree, not sure if EOL is the right status - maybe another status between Active and EOL?


    Mic Bowman

    who should be responsible to propose that a project be EOL'd? Given that the burden of managing quiescent projects falls on HL staff, I would suggest that they should propose EOL.


    Ry Jones

    Sure. The costs range from trivial (the waste of printing stickers and marketing collateral), to more substantial (spending face time in booths discussing EOL projects). Retiring projects would also help clean the greenhouse of clutter.


    Baohua Yang

    Suggest: 6 months for TSC warning, and 12 months for end-of-life.


    Arnaud J Le Hors

    Projects are on a schedule to report to the TSC. I think that gives us all we need to figure out when a project has reached the point where it should be changed status.

    1. Dan Middleton

      Another criteria to consider is if a project has not submitted its update to the TSC in 6 months.

      A more subjective criteria is whether over a 6 month period the project has not made progress against its charter. One measure of that progress could be releases. 

    2. Shawn Amundson

      Releases in isolation aren't a good metric, because actively developed projects could have a longer major release cycle, especially if they are making larger architectural changes. A few other ideas: a) Is the project used by other projects within HL?; b) Are users relying/using the project? (It would be bad form to prematurely shut down a project if it's being used - someone might step up if there is user activity). c) What are the opinions of the current/last maintainers? If they feel it's done, that's probably a strong indicator. d) can the project articulate where the project is headed? e) is there discussion in rocketchat or the mailing list that suggests there is a community?

    3. Shawn Amundson

      To Mic's question about who proposes EOL. This should probably be a couple people on the TSC, as the TSC represents the development community.

    4. Arnaud J Le Hors

      I have amended the proposed resolution to take into account all the comments received to date and added another one (request from Maintainers).

      1. Mark Wagner

        We should also provide public notice by placing something on the project (or WG) wiki page that it is EOL, or maybe that we are considering transitioning it to EOL. People could be using it but not on the mailing list.


        Should we measure forks / downloads ?

        btw - do we need to define what happens to EOL projects?

        Does the wiki page go away?

        I assume that the git repo goes read only, but thats an assumption.

  7. Arnaud J Le Hors

    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.>

    Arnaud J Le Hors

    It would actually seem reasonable that there is an overlap.

    1. Vipin Bharathan

      Let us not a create a draft that is dependent on another draft. According to me that (project readiness proposal) needs some serious rework mostly for prolixity. Also for a lot of soft and possibly irrelevant criteria for readiness.

    2. Arnaud J Le Hors

      I agree with the sentiment Vipin. For expediency I merely put a reference when I did this yesterday but "we" should simply incorporate whatever is relevant into this very document.

  8. Arnaud J Le Hors

    Proposed/Draft Resolution 4:

    When a project has not managed to graduate to Active status 2 years after having entered Incubation it should be moved to a lab, pending TSC approval.

    Baohua Yang

    Moving back is not a good idea; moving to lab sounds a better way.


    Arnaud J Le Hors

    Can you please elaborate why you don't think it's a good idea?


    Ry Jones

    Is the lab the parking lot of misfit projects? I'd rather have a parking lot within the Hyperledger org itself; one that looks like moving back to incubation


    Arnaud J Le Hors

    I suppose we could leave it to the TSC to decide whether to move the project back to Incubation or to a lab but I think it would be better to set a default even if we allowed for a different move. I favor a lab because there is zero expectation for labs to ever graduate.

    Now, of course, if the project has no activity at all then we should just move it to EOL. But I think that case is covered with the other proposed resolution.


    Ry Jones

    I guess my pushback here is selfish and operational. Moving something from one org to another incurs NRE - branch protections are lost, team members are lost, and the like. Github supports an "archived, read-only" state now, as well.


    Arnaud J Le Hors

    Ah ok. I appreciate the technical pain this might involve but I don't think this should be the driving factor. Rather this may simply mean we need to rethink how lab repos are managed. We might need to be creative.


    Vipin Bharathan

    The lab is a nursery. Let us keep it as such. Do not move it back into labs. The sentiment on this list seems like it is inclined that way (except for Arnaud). What is the cost of keeping the project in incubation?
    If there is a lot of work in the project, but they have not been able to graduate to active due to non-functional reasons (diversity etc.)  they should continue to be in incubation.
    If there is no activity then we should create a different status "inactive" or "somnolent" or some such thing. Relate this to cost, i.e. how can we preserve the resources and the history with the least amount of cost and how can we re-animate the project in case people showed up with interest in doing so.

    1. Shawn Amundson

      Projects should never move backwards in the lifecycle, because it would be hard for companies to rely upon projects if that is the case. It's not clear that pushing a project back to labs wouldn't be similar to declaring EOL.


      Also, labs should be about grooming projects to be proposed, and not a graveyard for older projects.

    2. Arnaud J Le Hors

      Given the lack of consensus on moving projects back in any way I have amended the proposed resolution to essentially leave projects where they are indefinitely.

  9. Arnaud J Le Hors

    Proposed/Draft Resolution 5:

    The normal path for projects is for all of them to first start as a lab prior to being proposed as a project. Requests for derogation can be made to the TSC.

    Mic Bowman

    Should there be an "entrance" criteria that is couched in terms like the release criteria? That is, does a project have "code" or can a project be just "good ideas"?


    Mark Wagner

    I think that this is too general. It works if someone comes in with an idea on something that people would like to try. 

    However, if an company is donating shipping code then we need to be able to have clear criteria for how to handle that. I would not expect newly donated code to have a wide diversity of companies, but it could have a lot of contributors. How is that handled?

    1. Vipin Bharathan

      There have been many projects that have had just a few contributors and have found wide adoption. For example the first Bitcoin code was just written by one guy. People found the idea compelling and started using it, of course many joined as core developers later. Usefulness is the most important criterion. We have to give time for an idea to blossom. If we apply our criteria to projects that took a while to take off- are we going to nip some very useful project in the bud?

    2. Arnaud J Le Hors

      Given the lack of consensus in forcing all projects to start as a lab I have amended the proposed resolution to specifically state that going through a lab is not required, which is the status quo.

  10. Arnaud J Le Hors

    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.

    Hart Montgomery

    I disagree that this is a clear-cut answer.  I think it depends on how many new projects we plan on adding in the future.  If we plan on keeping the number of projects small, no subprojects makes sense.  But if we plan on giving out projects like it's summer 2016, then maybe we need something like subprojects.

    Mic Bowman

    I'll bring up my question from the email... what provides the "back pressure" on accepting new projects? Can hyperledger handle 100 projects? 1000? if not, why not? if there is no back pressure then there is no point in trying to organize projects/subprojects (and we should let a 1000 flowers bloom).

    Arnaud J Le Hors

    This is indeed an interesting question. Vipin and I were wondering whether there isn't a limit merely due to financial limitations if nothing else.

    It's not like there is an unlimited budget to provide for the resources every project consumes.


    Hart Montgomery

    Shouldn't the fact that existing projects already have effective subprojects be an argument FOR subprojects rather than against it?


    Hart Montgomery

    I think Mic's comment really hits the issue well.  Sure, as of now, it seems like we don't need subprojects.  But there is clearly some number of projects that, if we reach it, we will need some form of project hierarchy to manage marketing and governance.  I don't know what this number is or how close we are to reaching it, though.


    Ry Jones

    One constraint is how much time in the booth do we have to explain these projects? The marketing cost of a dozen similar-but-not-identical projects is higher than one project. Look at the tension we have around "where exactly does my project fit in the greenhouse graphic" and multiply by whatever larger positive integer you like

    Hart Montgomery

    The idea is that subprojects would NOT be micromanaged by the TSC.  One of the main points of subprojects would be to reduce the governance burden on the TSC, so governance (except for extraordinary matters) would be left to the parent project in the hierarchy.


    Ry Jones

    I think the TSC has taken a very hands-off approach to sub-projects and lifecycles of those, which I agree with. I think one point of contention right now is that Cello, Composer, and BE should probably be subprojects of Fabric as they are not cross-chain.

    1. Vipin Bharathan

      In the beginning when everything was in Incubation, we needed to explain all projects. There can be a filter, active projects only or the newer projects can be explained from the booth. If we are successful we will have this problem anyway, i.e. a proliferation of projects. There is no metric of marginal costs (marketing, time spent by tsc etc.) I concur with Mic here, let many flowers bloom or at least try to bloom; having filters, categories etc. may reduce pressure on marketing at a booth. 

  11. Arnaud J Le Hors

    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.

    Mic Bowman

    How do you determine that a project is not being effectively managed? Could refer back to the project "EOL". 


    Arnaud J Le Hors

    Sorry for the confusion. I really meant "practically". As Hart pointed out we have some projects that were initially brought in as top level projects (through HIP and TSC approval) when in practice they are just not considered top level projects and are not even listed as such. I'm not actually completely sure what needs to be done but we should probably have a decision made to clean up the record.

  12. Arnaud J Le Hors

    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.

    Mark Wagner

    Agree in concept but we need to reword this. If Fabric becomes dependent on Ursa this wording would put Fabric under Ursa.

    If a project only works to support or enhance another project, then it should get folded under. So if Composer only works with Fabric then it should get folded under Fabric.

    Do we want to set a time on how long "supporting" projects get to prove they can support multiple other projects before they get folded under ?  Or does a proposal for a new project get folded under until it can demonstrate support for multiple other projects ?

    For example, if we were voting on Grid tomorrow, would it need to demonstrate it supports more than Sawtooth ?


    Hart Montgomery

    This would definitely need rewording.  Nice response Mark.


    Arnaud J Le Hors

    Good point Mark. Please, feel free to change the text to something that might work better.


    Mark Wagner

    Oh, so raise a good point, get an action item.....

    1. Dan Middleton

      I disagree with the draft resolution. Top level projects shouldn't be required to consume other projects. And likewise distinct communities can operate independent of larger projects. In the case that there's a direct overlap in contributors and dependencies, then it will be most appropriate for those modules to be in the same project.

      As far as resolving existing projects, if a project has a cross-project charter it must fulfill that or come back to the TSC with a revised charter proposal. Explorer, specifically, has a naming problem, which should be addressed in concert with its charter.

      1. Brian Behlendorf

        If approved, how long does a project have to fulfill that requirement to have cross-framework support?  Consider Grid and Transact.  Even with the best of intent, if there isn't anyone who shows up within some amount of time to those two projects to port them to other frameworks, do we require them to come back to the TSC to revise their charter to state that they are not to be cross-framework projects?  Such efforts could materialize later of course. 

        I think I'm for a proposal that says no proposed project charter may limit that project to just one framework.  Fortunately, Explorer's approved scope, as well as all the content around Explorer today, express no such limitation, and I've heard devs say they would welcome PRs and input that would lead to such support.  We've had a few people say they'd like to add such support, but AFAIK those didn't lead to pull requests for it.  Nonetheless, that doesn't mean that Explorer should be demoted to sub-project status, even now a few years after such work could have been done.  If it does, then the odds of that additional support materializing drop to nearly zero - and even if it does emerge, does that mean we re-propose Explorer as a new top-level project?   This seems like unnecessary churn that doesn't help us get closer to cross-framework integration.

        1. Hart Montgomery

          Unfortunately, for cross-project collaboration, I don't think it's reasonable to assume that people will "show[s] up within some amount of time" and get cross-project collaboration done.  To my knowledge, all (or almost all) of the cross-project work has required a reasonable amount of planning and quite a bit of work getting core stakeholders from various different projects to work together.

          In the past, we approved a bunch of projects that said they would attempt or look into cross-product collaboration (even the APIs, as I like to point out).  For whatever reason, these collaborations haven't happened.  So I think we should assume that, unless projects have a well-formulated plan for cross-project collaboration, it's not likely to happen.  If we require that "no proposed project charter may limit that project to just one framework," it seems like incoming projects might just write their project proposals to be as general as possible and then only work one one project (which has historically been the case).

          I'm not sure what the answer regarding explorer should be, but I'm guessing that it might best be folded under Fabric since Sawtooth (and I think Iroha, but I could be mistaken) have built their own blockchain viewers rather than work on Explorer.

          1. Hart Montgomery

            To add to this point, have we ever had a cross-project effort that was not spearheaded by multiple TSC members or top-level maintainers from at least two projects?  I could be wrong, but I can't think of any.

    2. Shawn Amundson

      I disagree with this resolution. We should not have sub projects managed by the TSC. Separate projects should not be allowed to use another project's name. So while in some respects perhaps "Hyperledger Explorer" is a name that suggests cross-framework support, requiring it to be "Fabric Explorer" may cause confusion for the framework project's brand.


      1. Hart Montgomery

        "We should not have sub projects managed by the TSC."

        Regardless of the merits (or lack thereof) of subprojects, I'm not sure anyone was proposing that subprojects be managed by the TSC.  If I'm correct in judging the opinions of others, I think the majority opinion was that they should be managed by the projects themselves, at least in some high-level way.  

        Sawtooth has already, in my opinion, probably the most formally defined sub-project structure in Hyperledger.  So any sub-project proposal would probably look a lot like what you all are already doing.  This confuses me as to why the Sawtooth folks are generally the most vocally anti-sub-project group in Hyperledger...

        In addition, I'm not sure Fabric Explorer would be such a bad name.  Have you been asked if Explorer works with Sawtooth?  I definitely have.  Clarifying what works with what is something that we need to be doing from a marketing perspective (which most of this boils down to).

  13. Arnaud J Le Hors

    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.

    Baohua Yang

    Agree with [Option 2]. The author can negotiate with the marketing team with a valid name, and then get approval by TSC.


    Arnaud J Le Hors

    I don't think [Option 1] is practical. At least in some cases projects first start as a lab. We clearly don't want to ask the marketing committee to name every lab being created. And even if we did, I expect they would quickly answer: no, thanks! (smile)


    Arnaud J Le Hors

    Even though [Option 2] involves a bit of a pain I think that's the most practical option.


    Hart Montgomery

    I'm more of a fan of giving the marketing committee "veto power," which I think is what this effectively amounts to.    


    Ry Jones

    We do this internally at LF. FD.IO was Project Rotterdam, IIRC.


    Vipin Bharathan

    There has been no major problems with names yet. There has to be a back and forth with the Marketing Community, the sponsors and others before the project is brought into the picture. Just the way it is happening now. Even sub-optimal names got through the process. This should be a collaborative effort, not just left to Marcomm.

    1. Arnaud J Le Hors

      Given that the issue was brought up by Brian/the LF team, I assume they did see some problems they are trying to mitigate. But in any case everyone who has spoken up so far seems to agree on Option 2. Unless I hear anybody disagree I think we can make that the proposed resolution.

    2. Shawn Amundson

      The preference should be to retain the name that the developers have given the project. Especially if it has existed in labs and the name is good, it would be beneficial to keep it.


      The MC's role should be to vet and provide due diligence around proposed names. It would be best if the MC could weigh in on these topics prior to the proposal, because doing it post-acceptance does two things: a) provides pressure to come up with the name quickly (days, not months); and b) delays a lot of other HL activities that occur upon acceptance of the project (basically anything that requires the name, including repos, etc.). The MC should have a checklist of things that they look into (trademark violation, problems with the name in some languages, etc.).

  14. Vipin Bharathan

    Should we condense all our thoughts on these subjects, there seem to be long trails of discussions.

    To restate:

    1. Should projects start from labs? - My thought is no- that would be too restrictive
    2. Should projects be knocked back into labs? No is my vote, just add a new state "deferred" for non-activity or low activity. "deferred" projects do not get marketing
    3. Sub projects- yes if the amount of work for marketing is high. Is there a limit to number of high level projects in HL?
    4. Taxonomy should be clear
    5. Labs & projects should be in two different compartments.
    6. Simplicity is key when doing project lifecycle as well as graduation or state change criteria. 
    7. Names: chosen by sponsors with collaboration with marcomm

    1. Arnaud J Le Hors

      I agree we need to move forward but I don't think combining all the different issues into one thread is the way to go. It's for sure going to derail.

      Instead, I think we should try to evolve the different proposals - independently to see if we can have convergence. And you guys don't have to wait for me to do it, you should feel free to make counter/new proposals as well.

      We probably need people to vote on proposals they are willing to support though, with a +1 for instance, so we can assess whether a given proposal can be considered accepted - remembering that all this is pending approval by TSC anyway.

      1. Brian Behlendorf

        I like Vipin's consensus mechanism.  (smile)  I think we're pretty close to consolidating it.  I think I agree with his positions, with just one comment:

        On point #3: I do not think we should set or consider a limit on "high level projects", which I've been calling (as Apache does) "Top Level Projects", or we could just call "Projects" if we can avoid overloading the term.  If we get better categories and eventually concede to not listing all projects in one greenhouse graphic, we can scale up. 


        1. Arnaud J Le Hors

          Brian, this (#3) touches on a question which you probably can answer: is there a limit - due to financial and resource limitations - we need to worry about? So far the TSC has been operating without taking such limits into consideration. Are you saying we can keep doing so and approve as many new (top level) projects as we want?

          1. Brian Behlendorf

            Yes.  At least, I do not want "can HL staff handle yet another TLP" as a factor in whether a project, on its own merits, should be accepted into HL.  If I need more resources I'll go to the Governing Board as I do on a regular basis, though we'd first look for other ways to handle more scale without compromising quality, or something like that.

  15. Hart Montgomery

    Who is currently deciding the marketing priorities, and how are they being decided?  It looks more and more to me like these priorities are the real issue behind a lot of the project lifecycle and taxonomy stuff.

    1. Brian Behlendorf

      I guess you could say at the end of the day I, as Exec Director, "decide the marketing priorities" in so far as I direct Meredith and our contractors where to focus their time and attention on the day to day tactical implementation.  Now we aggregate all sorts of input from all over the project, from the dev communities and TSC calls to the sponsoring members through the marketing committee and Governing Board, and even what we see out there.  I'd say we're 60% pro-active and 40% re-active to things that come in from reporters, new projects that appear out of nowhere, articles that need correcting, conference talk requests. etc.  If the TSC wants more visibility into this I'd be up for Meredith to present to the TSC some day on how it all works, and how we can best support and work with the dev community.  LMK if that's interesting.

      1. Hart Montgomery

        Thanks for the response, and for the suggestion.  I think it would be awesome if Meredith could present to the TSC and knock out all of the marketing stuff at once.  We could also discuss project naming in this conversation, which has historically been another big time sink.  

        1. Brian Behlendorf

          Would it be useful, just brainstorming here, to have a regular, perhaps monthly, separate public call for the TSC and any other interested parties, where we cover what the marketing team is doing each month to get feedback, ask for help or e.g. relay speaking opportunities, and make room for dev-driven marketing efforts?

          1. Hart Montgomery

            Absolutely!  I think a monthly "non-technical" call would probably be great.  We could go over logistical stuff, governing board decisions, marketing stuff, etc.  Many of the things that get people upset in the technical community have non-technical origins.  Explaining these might go a long way.

  16. Vipin Bharathan

     I have made suggestions in italics against each resolution. Main aim is to be succinct and consumable with ease.

    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:

    Can we just point to a doc (that is not yet ready but draft) which will be a form of the project readiness document.

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

    Proposed/Draft Resolution 3:

    Backward compatibility, adherence to SemVer. Clear upgrade directions. Justification for breaking changes. Release notes (this seems obvious, but what is obvious to me may not be obvious to all) 

    Proposed/Draft Related Resolution 6.4:

    Subproject status and reporting should be reported through the top level project. For example, Fabric Explorer status would be included in the Fabric quarterly reports..

    Seems onerous, could be a very valid subproject which is independent of main project, has to be transparent to maintainers of main project, the TSC and any others who may wish to use the project

    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:

    Embrace this project if it fulfills most of the important criteria, especially if has a user base and a reputation.

    1. Arnaud J Le Hors

      Proposed/Draft Resolution 8:

      Embrace this project if it fulfills most of the important criteria, especially if has a user base and a reputation.

      What does "embrace this project" actually translate to practically speaking?

      In my opinion, the most straightforward way to handle this kind of situation is to actually follow the standard lifecycle, starting with the project in Incubation. If the project happens to already fulfill the criteria to move forward to the next step there is nothing stopping it from doing so very quickly and if it doesn't (fulfill the criteria) then it shouldn't, independently of what any company might be doing with that code.

    2. Mark Wagner

      I had added 6.4

      If an effort is under a top level project then it makes sense to track it there. By the definitions proposed, it doesn't seem that there would be a valid subproject that is independent of a top level project.

  17. Arnaud J Le Hors

    The whole subprojects concept remains very controversial apparently so I'm not sure how to make progress on this front. Discussing sub issues seems rather futile unfortunately.

  18. Todd Little

    Perhaps this has been discussed and I just missed it, but are their any guidelines or requirements for a project to even be considered by Hyperledger?  For example if I propose a project to create a blogging platform, where is it documented that this is an acceptable project or not?  It's not a blockchain based blogging platform so I would assume it wouldn't be approved, however is this stated anywhere?

    1. Arnaud J Le Hors

      Yes, the charter defines the mission and this would clearly falls out of it. On that ground the TSC would reject it.

      See https://www.hyperledger.org/about/charter

      1. Todd Little

        That same mission statement says: "a. create an enterprise grade, open source distributed ledger framework and code base, upon which users can build and run robust, industry-specific applications, platforms and hardware systems to support business transactions."  So by a similar interpretation, does that mean HL is supposed to drive towards convergence as it doesn't say "create enterprise grade, open source distributed ledger frameworks and code bases" which is what it seems to be doing?

      2. Arnaud J Le Hors

        Good question. Those who have followed the TSC discussions know that this has actually been the subject of quite a bit of debate. It is undeniable that the charter as it stands does not match what is going on. I understand the Governing Board has been discussing updating the charter to better match the reality.

        1. Christopher Ferris

          That said, it is pretty clear that Hyperledger is all about creating enterprise-grade DLT/blockchain technology, not blogging platforms. It says so right on the main wiki page. As for the charter, about the only thing one might change is from the singular to the plural for "framework" and "code base". When the organization was founded, it was thought it would be about a single project. As the community evolved, more than one code base was proposed and approved for incubation.

          As you probably are aware, this is exactly what we have been discussing for some time. We recognize that there are multiple frameworks, and that that can cause (and has caused) some confusion. Many of us think we should be working towards a world in which there is a single framework into which various components and capabilities can be plugged in, to provide a suitably extensible solution framework for a variety of use cases. many believe that there should be many such frameworks.

          There is no magic bullet. What we all do agree on is that we should operate as a single community of communities collaborating across the landscape. The recent maintainers summit made that clear, and the collaborative spirit was clearly improved.

  19. Dan Anderson

    It was suggested I raise my comment in this discussion. The Hyperledger project states are very confusing. Officially, I believe, there is `Incubation`, `Active` and some sort of bit-rot state, `Retired` or something like that.

    However, there are additional undocumented states, `Hyperledger Labs` state, which seems to rank lower than `Incubation` and is not documented.

    Another undocumented state is `full-fledged`, which appears to lie after the `Hyperledger Labs` state, ranked higher than `Hyperledger Labs` state, and ranks the same? as `incubation` state.

    It's all very confusing and should be standardized in one place. Thanks.

    1. Vipin Bharathan

      The lifecycle doc is meant to cover all this. There is an existing lifecycle doc, as you say, it may need to be reworked for today's reality- we probably need to add material about the labs, just to make matters clear. Labs is essentially a playground, it is orthogonal to projects. It is not of a lower "rank". Naturally some labs will petition for Incubation; however they have to demonstrate all the pre-requisites for any other project to enter incubation. Some labs may never choose to leave the labs playground; however people who have played around in the labs may use the insights that they have gathered to put into a totally new project that they propose.

    2. Christopher Ferris

      It is. There is a Project Lifecycle document, prominent on the main wiki page (right below the list of projects) that clearly lays out the lifecycle stages. Hyperledger Labs is not one of those, nor is "some sort of bit-rot state".

      As Mic Bowman noted above, there are some projects that begin as a Hyperledger Lab but then, after gaining some traction and interest by the community, choose to be considered for incubation. It is possible that the distinction between a Hyperledger Lab and a project that falls under the Project Lifecycle and has been approved by the TSC for incubation, may have been referred to as "fully fledged", but that is mere colloquialism.

      If you have specific proposed clarifications to the Project Lifecycle doc, please do raise them. If you have specific suggestions as to how we might better organize the wiki, to make the information you seek easier to find, we are also all ears.

      It would help if we could avoid the snark in the conversations, though.