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..
51 Comments
Arnaud J Le Hors
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.
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.
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.
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.
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.
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.
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).
Hart Montgomery
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.
Arnaud J Le Hors
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?
Hart Montgomery
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.
Vipin Bharathan
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...
Mic Bowman
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?
Hart Montgomery
I agree, and I would love to hear what the Fabric maintainers have to say about this.
Dan Middleton
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.
Hart Montgomery
"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.
Binh Nguyen
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.
Shawn Amundson
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."
Shawn Amundson
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.
Shawn Amundson
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.
Shawn Amundson
Suggest resolution 6.4 be removed given resolution 6.1.
Hart Montgomery
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.
Brian Behlendorf
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.
Hart Montgomery
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?
Brian Behlendorf
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.
Hart Montgomery
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.
Brian Behlendorf
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.
Hart Montgomery
Thanks for this reply. It has helped me to understand your philosophy on projects.
Dan Middleton
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.)
Hart Montgomery
I really want to be a fly on the wall when you propose HL Mini Muffins to the marketing committee.
Arnaud J Le Hors
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?
) 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.
Hart Montgomery
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.
Brian Behlendorf
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.
Hart Montgomery
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?
Brian Behlendorf
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.
Hart Montgomery
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.
Brian Behlendorf
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.
Hart Montgomery
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.
Vipin Bharathan
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.
Arnaud J Le Hors
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.
Hart Montgomery
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.
Brian Behlendorf
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.
Hart Montgomery
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?
Hart Montgomery
I am also laughing that we are having this discussion while sitting about 10 meters away from each other...
Christopher Ferris
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.
Dan Middleton
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.
Hart Montgomery
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.
Binh Nguyen
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.
Arnaud J Le Hors
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.
Arnaud J Le Hors
Based on Hart's input I've put 6.2 back in.
Troy Ronda
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.
Arnaud J Le Hors
The proposal read "rescinded from the top level nomination", not merely "rescinded".
Given that all the concerned projects are related to Fabric I added a sentence stating they will be considered as being part of Fabric.
Brian Behlendorf
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.
Arnaud J Le Hors
That's indeed the intent.
Christopher Ferris
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.
Brian Behlendorf
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.
Brian Behlendorf
(oops, meant as a reply to Chris's comment just above)
Christopher Ferris
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.