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

PROPOSED 

Blocking
Outcome
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 but will continue here.

Formal Proposal(s)

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Reviewed By


2 Comments

  1. Answering to the comment on Re: Summary & RFC

    1. 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.
    2. 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?
  2. If a project changes its mission or charter, that information should be reflected/updated wherever the project is described in detail.