...

1. Each initial blueprint is encouraged to take on at least two Committers from different companies
2. Complete all templates outlined in this document
3. A lab with exact configuration required by the blueprint to connect with Akraino CI and demonstrate CD. User should demonstrate either an existing lab or the funding and commitment to build the needed configuration.
4. Blueprint is aligned with the Akriano Edge Stack Charter
5. Blueprint code that will be developed and used with Akraino repository should use only Open Source software components either from upstream or Akriano projects.
6. For new blueprints submission, the submitter should review existing blueprints and ensure it      is it is not a duplicate blueprint and explain how the submission differs . The functional fit of an existing blueprint for a use case does not prevent an additional blueprint being submitted.

...

...

 3.3.2.2.2.2 Template 2 - Blueprint family template

Below is a sample Blueprint family template. The full template will be maintained on the Akraino Wiki.

...

 3.3.2.2.2.3 Template 3 - Blueprint species template

Below is a sample Blueprint template defining an Akriano species. The full template will be maintained on the Akraino Wiki.

...

The life cycle of a project is depicted in the following diagram: 

...

The Chair and Co-Chair work together to share the responsibilities of chairing the TSC.

4.3.1.1 Responsibilities

The primary responsibility of the TSC Chair and Co-Chair are to represent the technical community in communications with the LF Akraino Edge Stack Fund of The Linux Foundation and to be responsible for:

...

The decision to close the coordination area is created by a TSC decision (according to the TSC voting rules).  Once a coordination area is updated, the coordination area will be removed from the Akraino Wiki.

4.4  TSC Operations

4.4.1   TSC Decision Making Process

...

There are no limits to the number of terms an individual can serve.

4.4.3   TSC Election Mechanics

...

• Defining Akraino’s release vehicles (such as a Coordinated Release) that align with the Project’s,mission,
• Fostering cross-project collaboration,
• Serving as Akraino’s primary technical liaison body with other consortiums and groups,
• developing an architecture,
• setting simultaneous release dates,
• defining release quality standards,
• defining technical best practices and community norms (including the establishment and maintenance of a Development Process),
• monitoring technical progress,
• mediating technical conflicts between Committers and PTLs,
• organizing inter-project collaboration,
• coordinating technical community engagement with the end-user community.

4.6  TSC Subcommittees

The TSC, at its discretion, may establish subcommittees to assist the TSC with its responsibilities and provide expert guidance in technical subject areas (e.g., architecture or security).

...

It is expected that subcommittee membership shall be open to all Akraino Contributors; however, subcommittees [or TSC] may impose restrictions such as the number of participants from a single company [organization]. While the desire may be to keep its size and scope limited, each subcommittee shall be open to the Akraino membership.  

4.6.1.2   Subcommittee Chair / Vice Chair

...

Members of the sub-committee who want to run for Chair for the subcommittee self nominate

4.6.3.2     Update of a TSC subcommittee

...

As a guideline, a subcommittee is most appropriate when the task to be addressed involves a relatively stable group of people with a high level of intersection of common involvement.  A coordinator is more appropriate when there is a more dynamic group of people and issues may change frequently. A coordinator is also more appropriate for smaller efforts or topics requiring infrequent meetings. 

Glossary

...