[Hyperledger Project TSC] Proposal Template Rough Draft
toggle quoted messageShow quoted text
As far as feedback I received I noted:
1. Put in a lifecycle section (incubator, testing, released etc.)
2.Scope and closure: what is the exact scope? How do we know the project is over (successfully or unsuccessfully or incomplete)? There were several views on this including the facts that the project can never be closed since it is continuously improving. I believe we can resolve this in combination, define status and put the project lifecycle as continuous improvement.
3.What defines a project? Your definition seems to be good.
As far as the links to other templates are concerned, the Apache system is a little too generic as it can house a wide variety of projects. However as suggested there, the project proposal template should be descriptive not normative. This allows for proposals that do not fit into the template as future proposals cannot be fully anticipated.
What are the next steps?
1. I will write this out in some more detail incorporating feedback
2. We will need to host this in a shared area after getting initial clearance from the tsc. This can be further refined as time passes and as experience teaches us.
To the general tsc list: Any more comments?
Date: Thu, 18 Feb 2016 13:17:58 -0600
From: Georg Link <linkgeorg@...>
Subject: Re: [Hyperledger Project TSC] Proposal Template Rough Draft
Content-Type: text/plain; charset="utf-8"
thank you for making the initial proposal.
I think you already received some good feedback during the TSC call.
For everyone who was not on the TSC call earlier. Here are examples from
other Collaborative Projects:
Further ideas might come from looking at Apache Incubator:
One question that I don't remember being addressed: who can be a technical
champion. Does it have to be a TSC member (similar to the apache incubator)
or can it be anyone?
Another topic brought up: what are "projects" within Hyperledger.
>From my understanding it is any initiative that furthers Hyperledger,
including new features, modules (maybe in different repositories), or
special interest sub-groups (QA-group ?). Basically anything that requires
resources and the community should decide collectively whether to go down a
certain path (commit to the proposed project).
- It might be helpful to include a "definition" to know for what to create
a project proposal.
On Thu, Feb 18, 2016 at 8:47 AM, vipin bharathan via hyperledger-tsc <
> Some thoughts on the proposal template which I had volunteered to help
> 1. The seeds of a new project proposal has to be vetted in a public
> forum like hyperledger-technical before creating a project proposal.
> 2. It needs a technical champion who believes in the project and who
> should be the technical lead on the project. The project champion can
> change in the middle of the project.
> 3. The proposal template for HyperLedger Improvement Proposal (HIP):
> - Author(s) name and contact details including email address, a short
> name for the project (less than 10 words).
> - Abstract (less than 50 word) description of the project.
> - The description and need for this project, substantiated by:
> - Technical details Effects on
> - Transactions- including confidentiality, signing, traceability,
> identity of participants, contracts (scripts)
> - Effects on User facing Clients that help with transaction
> formation (similar to Wallets in BTC)
> - Effects on the network, throughput, visibility to other
> participants, change in protocol if any, criteria for network participation
> - Block formation and ledger formation viz. Consensus algorithm,
> size overhead, effects on the throughput and rate
> - Cryptographic implications if any.
> - Backward compatibility (hard fork or updates by all network
> participants needed?)
> - Rough design and thought experiment (Gedanken Experiment) on the
> probable effects, if any
> - Address any possible objections and also support that came up
> during seed proposal from technical community on the lists.
> - Traceablity, testing criteria to gauge effects on installed base.
> - Any other technical details, including languages used, other
> technology needed and (preferably) public sources for additional tools and
> - References and defense of why this is needed, especially if the
> same ideas have been already addressed in any other project.
> - Rough gauge of effort and resources committed (coders and any
> other resources that are needed) and timeline if available.
> - Readability which means following certain conventions. The style
> itself could be controlled by Chicago Manual Of Style say, explanation of
> abbreviations, references, diagrams. A proposal editor appointed from by
> the tsc could help with this. As technical people we often do not think
> about this aspect. This is extremely important as the clear statement of
> the problem and its technical details are helpful to elicit a solution in
> the community and prompt volunteers. This can be helped by having a
> proposal builder software or a template itself.
> Any comments?
Michael Dolan <mdolan@...>
You may find this example helpful as well. Particularly the section on states of lifecycle in section 3.3.toggle quoted messageShow quoted text
VP of Strategic Programs
The Linux Foundation