# 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?