# Project Lifecycle We use [GitHub Custom Properties](https://docs.github.com/en/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization) to indentify a Project’s Classification within our Community. ## Custom Properties ### Flagship-Project This is a boolean. Where set to `true`, this indicates the Project has Flagship Status - i.e. it’s popular or something we want to highlight. ### Project-Status There are four options to choose from: 1. **Active** - the project is being actively maintained 2. **Archived** - the project is not being maintained 3. **Graduated** - the project has been superseded by official Sonatype Project The fourth option is to leave this field _unset_. This means the project’s status has not yet been assessed and confirmed. # 1 - Starting a New Project You can share your idea for a new Project by starting a [Discussion here](https://github.com/orgs/sonatype-nexus-community/discussions/new?category=project-proposal). [Organization Admins](https://contribute.sonatype.com/docs/community_roles/admin/) can execute the below procedure to create new Project within the Sonatype Open Source Community. ## New Project Proposal ### Prerequisites - Ensure you have defined a clear purpose for the new project - [Maintainers](https://contribute.sonatype.com/docs/community_roles/maintainer/) of the project must have previously contributed to another Sonatype Open Source Project #### Why? Having contributed previously means you’ll have signed our CLA and understand our Community workflows. ### Creating the Project - Create a new GitHub Repository in the [Sonatype Community GitHub Organization](https://github.com/organizations/sonatype-nexus-community/repositories/new) using the [Community Project Template](https://github.com/sonatype-nexus-community/community-project-template) as the template repository - See our [GitHub Repository Configuration Standards](https://contribute.sonatype.com/docs/standards/github-repository/) #### Heads up! This will cause a number of default files to be placed into your new repository. It will also automatically inherit a number of Organization defined files that you do not need to redefine in your project. ## External Project Contributions External contributors may propose an existing repository for migration into the Sonatype Open Source Community. Follow these steps to accept and onboard the repository: ### 1. Proposal Submission - The external contributor should initiate a [Project Proposal Discussion](https://github.com/orgs/sonatype-nexus-community/discussions/new?category=project-proposal). - Include the following details in the discussion: - Public Repository URL - A summary of the project’s purpose and goals - Any existing contributors who intend to transition as maintainers ### 2. Initial Review - Ensure the repository aligns with the Community’s goals and standards. - Confirm that the repository has an open-source license compatible with the [Sonatype Open Source Community licensing policy](https://contribute.sonatype.com/docs/standards/). - Assess the project’s activity level, community engagement, and quality of documentation. ### 3. Feedback Period - Allow a period for community members and Organization Admins to review and provide feedback on the proposal. - A thorough review must be performed by Sonatype’s legal team. - Address any concerns or required changes before proceeding. ### 4. Repository Transfer Once the proposal is approved, the repository must be transferred to the [Sonatype Community GitHub Organization](https://github.com/sonatype-nexus-community). The transfer process includes: - Coordinating with the repository owner to initiate the transfer. - Updating any necessary repository settings to align with [GitHub Repository Configuration Standards](https://contribute.sonatype.com/docs/standards/). ### 5. Assign Roles and Responsibilities - Ensure that proposed maintainers meet the [Maintainer Requirements](https://contribute.sonatype.com/docs/community_roles/maintainer/). - Assign the necessary roles and permissions to maintainers and contributors. - Update the repository’s [Code Owners](https://contribute.sonatype.com/docs/standards/repository-contents/#code-owners) and the respective GitHub Team. ### 6. Announce and Promote - Publicly announce the inclusion of the project in the Community through appropriate channels. - Update the [Community Project List](https://contribute.sonatype.com/projects/active/) to reflect the new addition. # 2 - Activating a Project Projects within our Community may occasionally transition between states, such as moving from an unset or archived status to active. This process ensures projects are thoughtfully evaluated and meet the standards required for active maintenance. ## Activating a Project To activate a project, follow these steps: ### 1. Review the Project Assess the project’s relevance, dependencies, and community interest. This includes: - Consider recent issues, pull requests, or community engagement - Review alignment with current Community goals, as applicable - Confirm the project’s compliance with Community [Project Standards](https://contribute.sonatype.com/docs/standards/) ### 2. Assign Maintainer(s) Ensure at least one [maintainer](https://contribute.sonatype.com/docs/community_roles/maintainer/) is identified to oversee the project and handle ongoing contributions. This step is crucial for maintaining quality and responsiveness. Maintainers MUST have previously contributed to another Sonatype Open Source Project. This ensures they are familiar with our Community workflows and have signed our CLA. Assigning the initial maintainers for a project requires unanimous approval of the [Community Admins](https://contribute.sonatype.com/docs/community_roles/admin/). #### Bring your friends Additional maintainers may be added at this stage OR a later date with unanimous approval from the existing maintainers and support from at least one Community Admin. ### 3. Update the Custom Property Modify the **Project-Status** property using [GitHub Custom Properties](https://docs.github.com/en/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization): - **Set to `Active`** to indicate the project is actively maintained. For projects previously archived: - First, unarchive the repository via the GitHub interface. ### 4. Communicate the Change - Announce the project’s activation in relevant Community channels. - Update any associated documentation to reflect its active status. ## Qualifying Projects For a list of projects currently archived or unset, use the following links: - [Unset Projects](https://github.com/orgs/sonatype-nexus-community/repositories?q=visibility%3Apublic+archived%3Afalse+no%3Aprops.Project-Status) - [Archived Projects](https://github.com/orgs/sonatype-nexus-community/repositories?q=visibility%3Apublic+archived%3Atrue) Activation is a deliberate process aimed at fostering robust and meaningful contributions. By ensuring thoughtful evaluation, we maintain the integrity and quality of our Community projects. # 3 - Graduation Process For some of our Community Projects, there comes a time where Sonatype officially supports the features or functions provided by a Community Project. In these situations we mark the Community Project as _Graduated_ by following the below process. ## Graduation Preparation ### Project Graduation Proposal For the sake of historical context and community insight, a GitHub Issue should be created to explain the reasoning and expectations for graduation. This is benefitial even in cases where community engagement is low. ### Project Graduation Notice The Community Project should have it’s `README` on it’s main branch updated to contain an appropriate _Graduation Notice_. An example might be: ``` > ℹ️ As of 7th November 2024, this community project has [graduated](https://contribute.sonatype.com/docs/project-lifecycle/) and is offered as part of Sonatype's commercial offerings - see [here](https://help.sonatype.com/en/configuring-blob-stores.html#google-cloud-blob-store) for full details. > > 🚧 This community project will receive no further updates or maintenance. ``` It’s good practice to be specific about **when** the project graduated, and where interested parties can head to find out more. ### CI/CD Closure Any existing CI/CD configuration should be removed and projects deprovisioned from CI/CD systems. ### Project Properties The project’s [Custom Properties](https://contribute.sonatype.com/docs/project-lifecycle/#custom-properties) should be updated to reflect the Graduated status. ### Open Issues Any open issues should be closed with a notice of the graduation. ## Graduating Once the preparation steps are executed, the project should be marked as archived in GitHub.