Issue 6: Should we have subprojects (and fewer toplevel projects)?
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..
Comments
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.
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?
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.
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...
Jun 14, 2019
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.
Jun 14, 2019
Jun 14, 2019
Jun 14, 2019
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.
Jun 19, 2019
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.
Jun 20, 2019
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.
Jun 20, 2019
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.
Jun 20, 2019
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.
Jun 20, 2019
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).
Jun 20, 2019