Page History

https://www.eclipse.org/projects/handbook/

Apache Foundation

Linux Foundation

Member Project Launch Process

Principles

Transparency

Openness

Vendor-Neutrality

Process

Repository Proposal

• Description
• Source Code
• Keep private until agreed

Community Review

• TST 
• DEG (if 
• Parent Group

Creation Review

• IP Review
• Security Review

Creation

Openness

COVESA provides the same opportunities for project and repository creation to all COVESA Members.  There are no rules to exclude any potential Member Contributors from proposing projects or repositories.  

Transparency

Projects and their associated work product, discussions, meetings, plans, and repositories are open, public and easily accessible.

Ecosystem

Repositories must belong to a group or project.  Projects must belong to Expert Groups or Birds of a Feather groups.  See COVESA Organization Structure for detail.

Collaboration

Collaboration between multiple organizations is critical to the success of COVESA.  Repositories are intended to be collaborative with multiple contributors from multiple organizations. 

Process

The process of repository creation is intended to be lightweight and be aligned with its associated group/project.  Hence, communication is key. 

Repository Proposal

• Repository proposals
  • must be made to the Project Leads, related Group Chairs and Community Director.  If relevant and necessary, they should include the Technical Steering Team.
  • must clearly state the repository's purpose and intended use.
  • must clearly state the relationship to projects/groups

ACTION ITEM:  Need a repository proposal template.

Community Review

Review is done by the related Expert Group or Birds of a Feather Group and the Project in a timely fashion (< 2 weeks).  Group Chairs and Project Leads with Community Director coordinate the review.

• Parent Group
• Data Expert Group (if relevant)
• Technical Steering Team (if relevant)
• Community Director

Creation Review

Once the repository proposal has been reviewed and agreed by the relevant parties, the repository can be created and populated.

• In order to avoid confusion or concern, repositories may remain private until agreed by Contributors, Leads, and Chairs.
• Repositories must meets the minimum repository requirements (below) and follow open source best practices
• Repositories must pass an IP review - ongoing
• Repositories must pass a Security review - ongoingPrivate until ready

Requirements and Best Practices

Structure

• ReadmeContain clear project description
• Parent Group or Project
• Type
  • Origin 
  • Member Submission
  • COVESA 
• group/project clearly stated
• License follows COVESA public policy for Open Source LicensingLicense
• Maintainers/Committers
  • Who Clearly identify maintainers/committers and associated organization
  • Organization Label/Identification
• Status 
  • Incubating
  • Mature
  • Archived/Historic
  • Transition and Lifecycle
    • Criteria?
• Way of Working
• Releases
CI/CD
• Phase - See Project Phases below
  • Incubating 
  • Mature
  • Archived
• Clearly defined way of working
• Release process if applies

Image Added

Source (Google Slides) for above flowchart

Project Phases

Projects and associated repositories will be in one of four phases: Proposal, Incubation, Mature, or Archived.

Proposal Phase

Project is being proposed to COVESA.  Project has not started in COVESA.

Creation Review

A project may move to incubation with Creation Review described above.

Incubation Phase

Project is establishing itself in COVESA working toward solid working code, stable APIs, establishing a  community, multi-organization contributions, meeting milestones and release and establishing open source practices.

Maturity Review

A project may request a Maturity review to transition the Mature Phase when it can provide documentation that it has solid working code, stable APIs, establishing a  community, multi-organization contributions, meeting milestones and release and establishing open source practices. 

Mature Phase

Project has established good open source practices, has regular predictable releases, multi-organization contributors, supports developers, adopters and users.

Archive Review

Projects will be actively reviewed every quarter.  Projects with no recent contributions, no active maintainers, no meetings, vulnerabilities that have not been addressed and no other signs of activity will be marked as Status: Pending Archive. An issue titled Pending Archive asking for a response from maintainers or for new maintainers will be posted.  If no answer within 6 months the project status will be changed Status: Archived.

Archived Phase

Project has reached its logical conclusion, is not being contributed to or used