---
# System prepended metadata

title: Onboarding new projects to OCP4

---

# Onboarding new projects to OCP4


## Resources
- https://fedoraproject.org/wiki/Creating_a_Fedora_SIG

## Objectives
- Have a rock solid process/SOP/Documentation in place, that gives even the most junior member the authority to decide whether or not to onboard a project.
- Have a place where potential new projects can be trialed
- Orient `fi-apprentice` to encourage participation in the OCP4 administration
- Have a concrete review process of the application/service nature and purpose
- Allow community members access projects in staging
- Allow community members to run workloads in staging
- Write down scripts to clean up the application/service resources after $(some) time
- 

## How does one propose a project?
- Should they follow the process call for resources
- What kind of projects can be accepted and what cannot be?
    - App/Project needs to be actively maintained
    - Do you have a SIG to support the proposed project?
        - Helps judge the sustainability of the project and the likeliness of it being served in the prod
- How big of a scale should the project have for it to be served?
    - No personal blogs please
    - Only apps/services which directly support the community, and have long term benefit to being hosted by us 
    - Potentially, the ones that can be maintained even after the actual project owner leaves
- Should we create an IPA group?
    - Maybe we do. We can map one IPA group to one namespace and add one user as the sponsor of _that_ IPA group.
    - Reduces work for the infrastructure team by allowing the group sponsors to add/remove/change members.
    - This will also require that we have a way to synchronise groups in IPA to groups in Openshift.
    - One of the minor downsides would of course be the IPA groups persisting back after the project is removed.
- should we request a list of IPA users as admins?

