Summary & RFC

Owned by Arun .S.M.
Last updated: Nov 19, 2020
3 min read

Much spoken about the topic rollover of projects tied to a single other project. It appears to be an extension to the topic of a project's lifecycle (depends how we see it). Like there exists option for amendments in the constitution, my approach would be to look into the opens/concerns and then fix them in place. Please feel free to pitch in as this list covers a variety of topics from different points in time.

Project lifecycle task force has defined different stages a project can be in (Ref: Project Lifecycle Task Force). Also, amount of time a project can be in Incubation or Active is forever (Ref: Unlimited Incubation period). Here's the list of stages that a project can be in

  1. Lab (not part of the formal stages list - https://github.com/hyperledger/tsc/blob/gh-pages/project-lifecycle.md)
  2. Proposal
  3. Incubation
  4. Active
  5. Promoted Release
  6. Inactive (not part of the formal stages list - https://github.com/hyperledger/tsc/blob/gh-pages/project-lifecycle.md)
  7. Deprecated
  8. EOL


Opens:

  1. As per the decision log a similar proposal was abandoned earlier Issue 6: Should we have subprojects (and fewer toplevel projects). This talks about a top level project having dependent on single other project (different wordings maybe?). Reason for abandoning it is unclear.
  2. [Quote from the Rollover of projects tied to a single other project] "Sharing the benefits of being a top level project such as security audits, communication services and ambiguous dependency between projects". This appears to be a major factor in considering the proposal. It is unclear what is the effort/cost of doing these activities. Because security audits are done either way, irrespective of a project is a top level project or sub-project of another top level project. As far as the other activities/facilities refer to the proposals section.


Proposals:

  1. Proposal 1: Brian's email captures four proposals in the email thread. It's pivoted around a specific project. But we can take the ideas and generalize them as possible proposals.
  2. Proposal 2: Possibly consider a different approach for the projects that are already a top level project in Hyperledger (reasons are listed as sub-bullet points). Follow this if the case requires, special TSC may be required.
    1. There is a possibility that the maintainers still adhere to their original project charter. But a subset of volunteers have backed out.
  3. Proposal 3: A top level project will not be penalized for the case of a sponsoring/volunteer organization/individual back-out
    1. If the reason is amount of effort required and the headcount
      1. Hyperledger can come up with a list of open contribution proposals and put it out for the larger community. Maybe there are other organizations willing to spend these additional efforts and get things done.
      2. Hyperledger sponsored internships are another way to evaluate these efforts.
    2. If the reason is obvious business decisions
      1. Capture this decision information against the project (Open: decide upon best way to capture this information). Note: There is no change to a new organization/individual joining the efforts. Anybody is free to join/join back anytime.
    3. If the reason for back-out is technical
      1. Bring up the points up for discussion to the TSC. TSC can be a technical consultant to help out.
      2. Document these reasons for not involving in a project.
  4. Proposal 4: No interest in the developer community outside the single other project
    1. Periodically checking whether the project meets the charter.
      1. Promoted releases will go through their agreed upon project charter as in https://github.com/hyperledger/tsc/blob/gh-pages/criteria-for-promoted-release.md. Extend this condition for all the following major releases.
    2. This should not occur if everything was done right.
      1. Opens:
        1. Come up with a way to measure this (the measure of interest of the community outside Hyperledger) metric.
        2. Come up with a mechanism to measure the original charter goals. One possible solution is to assign measurable goals to an organization/individual from the project proposal charter. Measure the progress in quarterly report.
    3. Extend and introduce a new project stage. A project that will be merged with another project will be put on notice (through Github/documentation/blog/email communication) for about 6 months in this stage before merging with the other top level project.
    4. Inactivity from the original contributors/maintainers as well. Read more about the proposal at Inactive Projects.
  5. Proposal 5: Extend the proposal Project maturity metrics to include facilities a top level project can get based on the badges they earn. Solving one of the major concern that few of these projects are earning more than required benefits from the Hyperledger.


Ending note, it is commendable to see these many proposals go in, also it is a great idea of the previous TSC members on documenting each of the decision process. Most of the answers we want are a keyword search away in the confluence. I strongly believe in diversity. Strength lies in how diverse the community is (smile). Let's embrace all the ideas and follow the one that works for the most.