What if a top level project does not meet its charter goal?
Status | RESOLVED |
Blocking | |
Outcome | Addressed with the publication of the guide on how to raise an issue with the TSC |
Minutes Link |
Overview of Proposal
The typical situation is that a project is launched on the premise that it will support several DLT platforms but end up only supporting one. In this case a rollover was considered but got little support and was seen as too narrowly focused. The question is more broadly about how a project that has deviated from its original intended goal should be dealt with. It would seem sensible to at least recognize the deviation somehow - possibly with a charter revision.
Initial discussion on this topic can be found on the Summary & RFC page.
Formal Proposal(s)
Add a page providing information on how to raise an issue with the TSC so that this kind of issue can be addressed.
See https://github.com/hyperledger/tsc/pull/15
Action Items
Reviewed By
Comments
If a project changes its mission or charter, that information should be reflected/updated wherever the project is described in detail.
Observations/comments/feedbacks heard so far:
A project which is incubated has adhered to best practices put together by the TSC.
The project's maintainers and contributors have choice to make decisions on the architecture and the future roadmap.
The quarterly report submitted to the TSC shall suffice to know if there is any violation on Hyperledger's charter. Note that the project's charter is defined and managed by respective maintainers/contributors.
Reflect/update the information where applicable ~ documentation, communication channels ~ maintainers' mode of communication.
Establish a mechanism for raising concerns over a project, TSC can mediate the discussion between them (plaintiff ) and the maintainers. Hope this never happens.
Answering to the comment on Re: Summary & RFC
I am not a big fan of TSC considering the merit "that a project is proposed to support DLTs 1,2,3". This criteria is subjective, it is critical if the project's scope is interoperability, and is a good for most other cases. To keep the space open for innovation, we could have flexibility. If we find out that the end user has difficulty in understanding then greenhouse representation can improve. The use of a particular DLT is a choice that user makes based on the project's maturity and the badging criteria.
On the comment "Will we tell the project that they cannot change their charter? If so, will the project say okay, but still do what they want? Will we remove the project from the Hyperledger greenhouse?": Hopefully we won't have any project doing that. TSC wouldn't agree for the new charter if there is a serious concern with the project that it is not adhering to. Should we bring this into as a new badge?