Page tree
Skip to end of metadata
Go to start of metadata

Approved Resolution 6.1 (TSC 11/07/2019):

No. Existing projects already have governance mechanisms in place to handle multiple components within the project. There is no need for the TSC to get into that micromanagement of the projects and its components. Projects may decide to manage component development as subprojects but no formal definition of subproject is intended by the TSC.

When a project sends to the TSC its quarterly report, it needs to include anything relevant from all related efforts.

From a decision process perspective, it is expected that all maintainers have a maintainer vote and maintainers need to work out between themselves who maintains which pieces and how they resolve conflict. Projects should document how decisions are made and by whom.

Of course, if any conflict were to rise between maintainers within a project that can not be resolved by the project's own governance, the issue can be brought up to the TSC for arbitration.

Approved Related Resolution 6.2 (TSC 11/07/2019):

For house keeping purposes, existing projects that were originally started via a HIP but in practice are not being managed as "top level projects" are officially rescinded from the top level nomination and rolled over into their related project. Specifically, this concerns the following projects which will then be considered to be part of Fabric:

2017-02-28 - New Project: Fabric Go SDK Proposal - approved 2017-03-17

2016-08-09 - New Project: Fabric Python SDK Proposal - approved 2016-09-08

2016-06-02 - New Project: Chaintool Proposal - approved 2016-06-16

2016-05-24 - New Project: Java Chaincode support for Hyperledger Fabric Proposal - approved 2016-05-26

2016-05-03 - New Project: Exerciser for the Hyperledger Fabric v0.2 Proposal - approved 2016-05-12

Source: Proposals through 2018

Approved Related Resolution 6.5 (TSC 11/07/2019):

A new project proposal that is a feature unique to an existing project will be guided to that existing community to see about joining it. If discussion with the existing project community leads to not joining it then the proposal will be reviewed on its own merits as an independent project.

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

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


  • No labels

51 Comments

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


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


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



  1. I'll reiterate and condense some of my earlier comments:  if we are going to have a lot of projects and want to give people ownership, we probably need subprojects.  If this is the case, subproject management should be done by the projects in a way that essentially already happens today in big projects like Fabric or Sawtooth–and not getting the TSC involved much.

    1. As you point out big projects already have subprojects so we don't need to change anything to make that happen. The question is what else do we need if anything?

      1. The issue is not when a subproject forms organically from a big project, it's when some people come along and want to add something to a big project while maintaining some sense of ownership .  When this discussion came up two years ago, many people suggested that a sense of ownership was important.  If we think that this is not the case, maybe we can just tell people to merge their coding efforts with big projects.

  2. Agree with all these resolutions except 6.4 - reporting can be done on an as needed basis. Otherwise you make maintainers of top-level projects responsible for chasing down sub-projects that they do not really control. Health measures for sub-projects can be automatically garnered through tools. If the health is slipping, the project should be set to deferred or EOL.

    Also 6.3 is the result of 6.2... 

  3. The Justitia proposal provides a very good concrete example for framing the subprojects discussion. In reading the proposal, it is clear that the project augments Fabric functionality. I would say that it is a clear example of a "subproject" in that sense. What steps would we propose for that (sub)project to receive approval for a repository? Should that be the responsibility of the Fabric maintainers?

    1. I agree, and I would love to hear what the Fabric maintainers have to say about this. 

      1. The resolution ended up being that Fabric absorbed the proposal.

        Had the fabric community rejected the content, then we would have created a separate project. That project would not have been a sub project because that would have forced the fabric community to adopt something they disagreed with.

        1. "Had the fabric community rejected the content, then we would have created a separate project."

          Is everyone else this comfortable adding new projects?  From what others have commented, I'm not sure this is the general consensus.

          1. Based on 6.1, I would say no. If a subproject is rejected by the project's community, it must mean that majority of the users of the project wouldn't use the subproject that's why they didn't accept the subproject to begin with. I don't see any reason to allow creating a separate project for the subproject.

  4. Suggest rewording Resolution 6.1 to:

    "No. Existing projects already have governance mechanisms in place to handle multiple components within the project. There is no need for the TSC to get into that micromanagement of the projects and its components. Projects may decide to manage component development as subprojects but no formal definition of subproject is intended by the TSC. Of course, if any conflict were to rise between maintainers within a project that can not be resolved by the project's own governance, the issue can be brought up to the TSC for arbitration."



  5. Disagree with resolution 6.3, as the practical result is that the TSC would mandate that projects add and maintain specific components. This should rather be a discussion between the projects to agree to merge.

  6. Brian commented: "If approved, how long does a project have to fulfill that requirement to have cross-framework support? Consider Grid and Transact."


    I think there is a big difference related to the types of projects. Explorer is an application, and applications/tools should probably have a multi-framework requirement. When applications or tools ask frameworks for support, they are asking for resources to work on their project instead of the framework project–they don't help develop the framework, it's just more work. On the other hand, libraries like Transact and Ursa intend to offer a capability to make it easier for frameworks to accomplish their goals. Thus, it should be a non-goal for Transact or Ursa as a library to provide cross-framework support. However, it is a goal to get libraries like Transact and Ursa to be adopted across framework projects and serve as a shared resource. And adoption may take a while, because it can be a non-trivial amount of work involved at the framework level.

  7. Suggest resolution 6.4 be removed given resolution 6.1.

  8. Can we get discussion going on the following point:

    What should the status of Explorer be?

    I think this would help flesh out people's opinions here.

    1. Speaking personally as someone with a lot of history in this space but not as a TSC member so ignore at will.

      Explorer should remain a top-level project so long as its developers go above and beyond to support anyone showing up with contributions that support other frameworks at Hyperledger.  "Above and beyond" subject to interpretation of course but I'd think of it as being willing to make major architectural changes, and doing some of the legwork to implement such a change, in order to provide enough footholds for other devs to implement support for other frameworks, and also of course helping those new contributors up the curve to becoming maintainers.

      Requiring them to add support for additional frameworks they aren't familiar with and don't have their own needs to support seems to be reaching too deeply into dictating functionality to a project, something we've never done before.  And if we do, which ones are required?  All of them?

      Requiring a new project coming in to already have support for all HL frameworks also seems unreasonable, at least before we have common APIs that all frameworks support.  Then the surface area may be small enough to argue it should be a requirement, or at least a major factor in acceptance criteria.

      1. Thanks for the response!  Let's continue this constructive example then.

        Sawtooth has a "Sawtooth Explorer" that is functional (and nice!).  Suppose the Sawtooth devs wanted to integrate/merge this into Explorer.  How much work would constitute going "above and beyond" by the Explorer team to make this happen?  How much should they have to do, and how much should the Sawtooth devs have to do?


        1. Yep, excellent question again.  I don't think any of us who aren't Explorer developers can say precisely what that looks like.  However, I think most of us have had experiences on other projects where there's a distinction between building support for a specific feature by one external client, versus a generalized approach that meets a wider set of needs. The Explorer developers should be expected to go "above and beyond" in working with the support-for-Sawtooth-motivated-devs in a deep conversation about how to meet those needs generically, to define that API or whatever, and then at least part of the work to implement that; but part of it can also be reasonably asked for by the support-for-Sawtooth-motivated devs.  (I use that awkward phrase to indicate it doesn't have to be Sawtooth maintainers or even current contributors to Sawtooth - it could be new people entirely).  I think we can then expect the Sawtooth-motivated-devs to do all of the work from that generalized interface to Sawtooth specifics, with tight support from the other devs when they have questions or hit snags. 

          Mainly, we want to avoid the anti-pattern of "we're here to add Sawtooth support - we have some questions" "No, go away, we will only commit to Fabric".  I've never heard the Explorer devs say that, it's not in their scope or charter, and I'd kick them to sub-project (or even out of HL entirely) if they did.

          1. Thanks again for continuing the discussion.  What you say in your last line above sounds very different to me than "above and beyond."  That being said, I don't think anyone in Hyperledger is actively opposed to people coming on and adding interoperability functionality to their code.  However, it seems that basically no one is willing to do it themselves.

            If Sawtooth Explorer maintainers said they would be open to supporting other projects if other developers came and did the interoperability work for them, would you support them if they tried to become an independent project?

            Sorry if my tone is negative here, and thanks for reading.

            1. If the Sawtooth Explorer maintainers said such a thing as part of their proposal to become a top-level project, that would satisfy the requirement.  We could have competing Explorers, though the second one should probably pick a unique name.  Though first I'd really encourage them to find a way to combine efforts with the pre-existing Explorer project.  Why would they not?  It seems even acceptable for the "Explorer" project to have two codebases, one for Fabric and one for Sawtooth, that they intend to eventually merge, opportunistically, as makes sense. 

              1. Thanks for this reply.  It has helped me to understand your philosophy on projects.

                1. Explorer is a unique situation so I don't know how much we want to dwell on it. The origins are pretty close to the origin of Hyperledger before we had a broader sense of the portfolio and naming implications. Priorities from the original sponsors have also changed over time.

                  (And for the record it's not like there haven't been efforts to get sawtooth features into explorer. Time has been spent at multiple hackfests with well intended collaboration across both teams, however neither team has been able to prioritize a sustained effort.)

                  That said, the main problem with explorer is the name. If it was called HL Mushroom, it wouldn't be a point of confusion whether or not it represented an explorer project for the entirety of Hyperledger. 

                  Next point, when a project takes on a charter, the maintainers are signing up to deliver that either through their own efforts or successfully recruiting new contributors/maintainers.

                  Today we would not charter a project that was say Hyperledger Database meant to be the database layer to all hyperledger projects and then expect that all the other project maintainers were going to spend time on it.

                  If we're going to do anything to HL Explorer out of this, and I don't think we should, it would be to rename the project to something abstract like HL Mini Muffins or HL Donut Holes or HL Brownies. (I think maybe I need to go eat something.)

                  1. I really want to be a fly on the wall when you propose HL Mini Muffins to the marketing committee.

    2. I don't think we should single out Explorer. To me it is an interesting example to consider but either we adopt a general policy to keep framework specific projects as subprojects or we don't.

      So far we've clearly been functioning under the assumption that projects that could be framework independent should be handled as top level projects, even if they don't (yet) support multiple frameworks.

      I think this makes things very confusing so, as I said before, I would be in favor of changing that approach and keep projects as subprojects of the framework (btw, should I say DLT? (wink)) they depend on/support until they support any others.

      But so far it seems like I've been the minority opinion on that.

      One thing we must remember is that this is open source and people work on what they want. We cannot force anyone to work on something they have no interest in. So we cannot require that people developing Explorer also supports other frameworks for instance. That just doesn't make sense.

      1. I agree that we need a general policy, but we also need to make sure that it works in practice.  "Exploring" how a general policy would apply to Explorer seems to be a useful exercise for this.

        I also agree with your other points, and think I am in the minority on most of those too.  

        "One thing we must remember is that this is open source and people work on what they want. We cannot force anyone to work on something they have no interest in. So we cannot require that people developing Explorer also supports other frameworks for instance. That just doesn't make sense."  '

        Yep!  We have, as a group, historically massively overestimated how much cross-project collaboration and integration will happen organically.

        1. And my main concern, back to Arnaud's point, is that if a project starts as a subproject of one framework, even if the devs are completely open to supporting others, and willing to go "above and beyond", other frameworks will ignore them and not be motivated to try, because then you're helping "the competition".  So what's already hard technically would become hard both technically and socially.

          1. Has this historically happened?  Was this an issue at Apache?  It's not something I was really considering as a concern, but I could definitely be wrong here.

            Here's my thinking:  suppose you have an interoperability project and a currently existing project has some code that performs roughly the same functionality.  At least to me, the critical thing to achieve seems to be reaching a point where a project will have to spend more work updating their own code to get to the same functionality/efficiency/security as your code than to update/build APIs to your code.  If this isn't achieved, the currently existing project won't switch, but if it is, there is a good chance, even if you are "hosted" by another framework.

            Does this make sense?

            1. On your first question: I have meant to write a longer piece on this, but haven't had the time this past week or two, but yes, this has been a serious issue in the past.

              In the early days of Apache, just as it was expanding beyond httpd, there was a project called Jakarta founded in 1999.  The anticipation was that there was about to be a lot of code related to Java standards about to be open sourced by Sun and others, just as Tomcat was.  So to encourage that community to teach each other, Jakarta was established as an umbrella project within the Apache hierarchy.  A similar umbrella was set up for XML, for a wide range of XML-parsing and processing engines about to come out.

              This was a bad call.  Governance in a growing community is tough enough - to introduce two layers of governance (Jakarta's PMC over these internal projects; then Apache's board over the Jakarta PMC) was so complicated no one could set or follow processes to everyone's satisfaction.  Authority over when new projects could be accepted was complicated; projects came in which were written in Java, and might incidentially implement Java standards, but not want to be limited to Jakarta. And the Apache board's oversight role clashed with Jakarta leadership, and average devs felt like they were too distant from the board.  In 2005, the Jakarta shell was abandoned, and all its "subprojects" promoted to regular Top Level Projects over time, with Jakarta being disbanded in 2011.  That represented 12 years of drama and angst which could have been streamlined had those projects come in through the standard process.  Some were swept into a "Apache Commons" project that still has a library-like atmosphere.

              The main wisdom that came out of that exercise was that at the ASF, project boundaries are much less about a technical product and much more about a bonded set of individuals and the chartered scope that brings them focus.  The Project Management Committee - the PMC, essentially our "maintainers" on each project - are officially recognized corporate officers of the ASF and are responsible for whatever goes on within their project, led by a "VP" for each project.  The VP and the PMC are responsible for following the policies and practices of the ASF, reporting quarterly to the board, etc, and when it's time to roll up a project, they do that too.  They don't get to say "BobX wrote that code, but he's not around anymore, sorry" when a copyright violation or security hole is reported - they have to fix it, or stop distributing the code.  That sense of responsibility acts as a natural limiter, in a way, for the amount of code and its fragmentation within a given project.  Umbrella projects had too much distance and too little discipline to fulfill these obligations.

              So this is my primary concern about "subprojects" - if these are pieces of the whole, such as fabric-ca, and if it's code written by the same general pool of maintainers and regular contributors, or even if these are 3 or 4 separate but highly complementary pieces, so long as the maintainers and devs feel a sense of responsibility for the whole, and help move the whole of the code forward, then it's up to them what they do, and that's just one "project" from the point of view of the TSC and everyone else.  Two levels of governance and oversight is just asking for dropped balls, confusion, and general complexity.


              1. Thanks for this great reply.  This is really interesting, and I suspect others will appreciate this as well.  I certainly don't have nearly as much experience as you in open source software, so it's always good to hear these facts of wisdom.

            2. And to answer your second question and proposition - yes, there's a calculus to it, complicated by the fact that developers (except for the truly great developers, who are generally very lazy and very humble) will tend to know and trust their code much more than someone else's, even if objectively they are of the same value.  One tends to also diminish one's own efforts on one's passion project.  All we can do to address this is encourage further componentization, so the hill to climb to understand and trust someone else's code gets smaller; and greater cross-project presentations, so that people at Fabric understand the merits/demerits of their BFT consensus algorithm, or devs at Indy understand Sawtooth's consensus API, or the like.  It never works when it is forced top-down, and would likely shut down innovation if it became a gating factor for code on the way into a project.

              1. Thanks again for indulging me.  I guess the question is:  how can we foster componetization without a top-down approach?  Your comments here make total sense to me.


  9. This discussion has helped my thinking. Thanks to Brian and Hart Montgomery

    From the discussion, it is evident:

    a. Sub-projects, even if they are dependent can exist separately (meaning worked on and released) and should not be put under the control of other maintainers. For example, I can create a project dependent on Linux without asking Linux maintainers or reporting to them.  No one can prevent me from creating a public repository with a license that I support and may attract more developers. The question is where can this project be housed?

    b. Should they be top level: gets back to what resources are used-real estate on the front page, marketing resources, other LF resources. If resource use cannot be sustained, can they be encouraged to be in labs, especially new projects like Justitia. The real question to be answered is What is wrong with proliferation of projects? As asked by Mic Bowman earlier.

    So 6.1 is leave existing sub-projects alone- 6.2 through 6.4 are related since 6.2 relentlessly marches on into 6.3 and 6.4.

    Simplicity should be the aim, unintended consequences similar to what Brian Behlendorf  mentions should be avoided if possible. This can only come through a light touch, Baohua Yang had suggested this. Over specification is to be avoided.



    1. My motivation to make "dependent" (I realize this is an inadequate name) projects subprojects was not about control but clarity. Clarity with regard to the goal of the (sub)project so that the developers aren't subjected to pressure from other projects a la "but when are you going to support xxx?" and clarity with regard to what is possible. I find it annoying to have to explain all the time that Explorer only supports Fabric and Sawtooth has its own explorer for example.

      When it comes to control, being a subproject doesn't necessarily mean being put under the control of "other maintainers". For Fabric at least we have different lists of maintainers for different repos and if a subproject lives in its own repo (which would be my expectation, at least by default) it can have its own list of maintainers.

      1. This comment summarizes things really well. 

        Clarity with regards to outsiders is important–as Arnaud points out, it should be clear to people looking at Hyperledger that, say, Explorer doesn't work with Sawtooth.  

        1. It may be better to get that clarity from a proper technical diagram of the different software products from the different projects than to overload or constrain our community management processes and tools to such a thing. You don't want Explorer's initial or current state of "not working with Sawtooth" from being misunderstood hard-locked-in destiny or TSC edict.

          1. Sure, this makes sense.  Do you have an idea of how we can get this messaging across to people who aren't super-familiar with Hyperledger?

            1. I am also laughing that we are having this discussion while sitting about 10 meters away from each other...

  10. I think of a "sub-project" as Arnaud does above... as a convention to clarify intentionality. eg. we had fabric-sdk-go proposed and approved for incubation. It is kept fairly current, and I have requested a few times that it be formally become part of the fabric release, but the maintainers have not taken that next step. The project is definitely fabric-specific, and that is unlikely to change, unless there is some consolidation of all SDKs.

    Explorer was proposed with intentionality of being multi-dlt capable, but the initial scope of the project was fabric. Whether the maintainers make efforts to add support for other dlts is purely their prerogative. Open source is about scratching an itch. If you want something done, roll up your sleeves and dig in. That Explorer has not expanded is unfortunate. However, it is unclear to me that the project contributors and maintainers would get in the way of someone willing to add additional support as long as it didn't disrupt.

    Now, do I think that before the TSC incubates a sub-project that it should be proposed to the maintainers of the top-level to which it is intended to support as a new feature? yes, I absolutely think that this is the correct course. Having sub-projects that are not aligned on releases can also create confusion. Hence, maybe sub-projects that are not initially accepted as a new feature proposal should start as a lab, and when mature and integrated with a current release, then rather than become a sub-project, maybe they should instead be proposed to be incorporated into the top-level release process.

  11. I'm going to assert that the consensus view here is that we adopt 6.1 and that obviates 6.3 and 6.4.

    6.2 is probably also obviated. I think the main goal is to cleanup something from the early days, but I say let sleeping dogs lie. 

    As new proposals come in we should be clear on charter and objectives. A proposal that is a feature unique to an existing project should be guided to that existing community to see about joining it. If the existing project community declines then the proposal should be reviewed on its own merits as an independent project.

    1. The subproject discussion got started because people were becoming critical of new project submissions.  The criticism was rooted in worry about having too many projects and the effects that this could have on HL as a whole.  The goal of subprojects was to have a consistent way to place new code submissions into HL that wasn't seemingly dependent on whether TSC members had coffee before the meeting or not (i.e, not have to go through the "full" project submission process).

      If we decide to not have subprojects, can we get a clearer criteria for proposing projects to HL?  Ideally a third party should be able to look at the proposal, read the criteria, and then decide whether or not the project is likely to be admitted to HL or not.  Right now that is far from the case.

      6.2 seems fine to me.  Technically Fabric-Java-SDK is still a project, and the TSC could ask for a report!  No official action has been taken.

  12. I don't agree with 6.3. Both Explorer and Composer intend to support multiple blockchain platforms, evidenced through the project design and code (framework); however, the "last mile" only supports Fabric. Both projects don't prevent rather more than welcome supporting other platforms. Development resource for these higher level tool projects are quite limited and the learning curve to add a platform is steep. But I think we rather have potential ability available rather than not. Perhaps we should enforce a new top level project, like Explorer and Composer, at the on-set to have commitment from multiple platforms, and that should be an incubator exit criterion. Explorer and Composer are still in Incubation, so TSC can enforce/add such a criterion on exit.

  13. I don't think there is enough support for 6.2, 6.3, and 6.4 to warrant keeping these alive, so I have now marked them abandoned.

    While we continue to be divided on the idea of having formal subprojects the majority seems to be against. So, I move to bring proposal 6.1 to the TSC for approval and leave it to the TSC to decide.

    I also added the new proposal 6.5 based on Dan's above comment which actually captures what we have been doing as of late.

  14. Based on Hart's input I've put 6.2 back in.

  15. On 6.2:

    I assume the intention is that these projects automatically roll-over into subprojects?

    (or said another way, I would assume that this resolution is not about "officially rescinded"ing these projects.)

    Do I have the correct assumption?

    The resolution should be more explicit about what happens to these projects as creating a limbo state would not be a good outcome.

    1. The proposal read "rescinded from the top level nomination", not merely "rescinded". (smile)

      Given that all the concerned projects are related to Fabric I added a sentence stating they will be considered as being part of Fabric.

  16. The way I read both 6.1 and 6.2, as I assume these are separate recommendations and entirely compatible, is that we do away with any formal notion of a "subproject", as least so far as project governance and the TSC is concerned.  E.g., Fabric and all its "subprojects" are really just a part of the Fabric community, with one maintainer pool, who happen to issue a series of different software products.  It means when Fabric sends to the TSC its quarterly report, it needs to include anything relevant from those other efforts.  It means when a Fabric subproject starts to spiral, it is the Fabric maintainers who collectively take action, rather than finger-pointing or saying "no one owns that".  

    This might sound scary, but I think this is preferable to a hierarchy of projects, adding too many layers between people writing code and the TSC is not good.  It also avoids any abandonment of oversight.  And it encourages people working on one piece to get familiar with the other pieces. 


    1. That's indeed the intent.

  17. Based on the discussion today, and the suggestion made by Nathan that: "We expect from a decision process perspective all maintainers have a maintainer vote and they need to work out between themselves who maintains which pieces and how they resolve conflict", I think that we should make this point clearly as a function of resolution of this issue. I would suggest that a "top-level" project needs to define its process in writing as to how decisions are made and by whom. For instance, we have had a role in Fabric of a "release manager" in addition to maintainers. The release managers decided what gets in a release and when it is soup, etc. We have also had some repositories with specific maintainers that are not maintainers of other repos. This might be confusing to some, and it is sort of unwritten lore as to how all this works. Explicitly stating those roles, and identifying who holds them and what decisions that they can make seems a reasonable improvement.

  18. That makes sense, as long as it is kept fresh, as people come and go and you don't want specific people to be attached to specific portions of code in a way that feels locked-in or conveys exclusivity.  It should also avoid creating a way to duck responsibility.  If a major issue is discovered in a certain body of code, and all the "specific maintainers" of that code are not around or responsive, it's still the responsibility of the full set of maintainers to respond & fix.

    1. (oops, meant as a reply to Chris's comment just above)

    2. Yes, agree to a point, and to be clear, I am not suggesting that a boy of code have a single maintainer. In fact, that would be an anti-pattern. I was thinking, though, that if there's documentation, for instance, that that might have some of the content editors as maintainers, not just code jockeys; or if there's an SDK in a particular language, that you'd have some maintainers competent in that language who might not be maintainers for other parts of the code base, eg.