diff --git a/rfc/001-changing-github-org.rst b/rfc/001-changing-github-org.rst new file mode 100644 index 0000000..4b473c4 --- /dev/null +++ b/rfc/001-changing-github-org.rst @@ -0,0 +1,202 @@ +========================================== +Moving Projects to UXL GitHub Organization +========================================== + +Moving UXL projects from `oneapi-src`_ to an organization owned +by UXL. + +Background +========== + +All 6 of the original UXL projects are in the `oneapi-src`_ GitHub +organization. The org is owned by Intel and also contains projects that are not +part of UXL. We need to transfer ownership of the repos to UXL by moving them +to a new org. + +We considered various options: + +1. Move all the repos to the `uxlfoundation`_ org. +2. Move the oneapi-src org to UXL. +3. Move the repos to a project-specific org. + +We do not recommend (1) and (2) because they are a shared org. A shared org has +the following drawbacks: + +* Must share GitHub runners, permissions, and integrations +* Repo and team naming conflicts +* Community confusion. DPL and DNN have different communities and goals. +* Requires central management, and UXL does not have the resources to manage + the org + +Furthermore, (2) requires redefining the purpose of oneapi-src, which will lead +to confusion about the projects that go and stay. + +A shared org does have some advantages: + +* Central management can be more efficient and secure +* Sharing team definitions across projects when there are shared teams +* Provides more visibility for UXL as the host of the projects + +We recommend (3) because it is the common practice for large complex open +source projects. Projects will have the freedom to manage their org as they see +fit and not be affected by requirements or preferences of other projects. + +Repo Information +================ + +.. list-table:: + :header-rows: 1 + + * - Current Repo + - Primary Contact + - Migration Date + - New Org + - New Repo + * - onednn_ + - Vadim Pirogov + - Q4 2024 + - onednn-project_ + - oneDNN + * - onedal_ + - Nikolay Petrov + - Q4 2024 + - onedal-project_ + - oneDAL + * - oneccl_ + - Joel Rosenzweig + - Q4 2024 + - oneccl-project_ + - oneCCL + * - onemkl_ + - Irina Topinskaia + - Q4 2024 + - onemkl-project_ + - oneMKL-sycl-interfaces + * - onedpl_ + - Timmie Smith + - Q4 2024 + - onedpl-project_ + - oneDPL + * - onetbb_ + - Ekaterina Semenova + - Q4 2024 + - onetbb-project_ + - oneTBB + * - oneapi-spec + - Robert Cohn + - 5/2/2024 + - uxlfoundation_ + - oneapi-spec_ + +.. _onednn-project: https://github.com/onednn-project +.. _onedal-project: https://github.com/onedal-project +.. _oneccl-project: https://github.com/oneccl-project +.. _onetbb-project: https://github.com/onetbb-project +.. _onedpl-project: https://github.com/onedpl-project +.. _onemkl-project: https://github.com/onemkl-project +.. _uxlfoundation: https://github.com/uxlfoundation + +.. _onednn: https://github.com/oneapi-src/onednn +.. _onedal: https://github.com/oneapi-src/onedal +.. _oneccl: https://github.com/oneapi-src/oneccl +.. _onetbb: https://github.com/oneapi-src/onetbb +.. _onedpl: https://github.com/oneapi-src/onedpl +.. _onemkl: https://github.com/oneapi-src/onemkl +.. _oneapi-spec: https://github.com/uxlfoundation/oneapi-spec + + +Org Administration +================== + +The projects will have ownership of their org. To ensure continuity, select at +least 2 people to have the org ``owner`` role. It is not recommended to broadly +share ownership permissions. Prepare a basic set of recommended configurations +(e.g. 2fa) for the org or perhaps the org can be configured before handover of +the project. Each org will have Linux Foundation and UXL admins who are there +for emergency maintenance only. Need to share some guides on how to manage an +org. + +Process +======= + +This is a sketch of the activity. Each project should prepare its own schedule +and plan. Robert Dower, the maintainer of oneapi-src org will help with the +move by preparing the new org, transferring the teams, and moving the repos. + +Preparation: + +1. Create the new org and teams +2. Prepare a project specific test plan +3. Prepare a project specific communication plan +4. Identify URLs that are not redirected and prepare PR's to update them. + +Execution: + +1. Communicate the change to the community. +2. Move the repos to the new org. +3. Merge the PR's to update the URLs +4. Testing + +Cleanup: + +1. Update URLs that are redirected + +Moving the Repo +--------------- + +The recommended way to move the repo is to use the GitHub web interface to move +it to the new org. This will preserve the issues, PR's, and stars. The repo URL +will change, but GitHub will redirect the old URL to the new URL. Another +option is to fork the repo into the new org, but it will not do forwarding and +will not preserve the issues, PR's, and stars. + +It may be convenient to initially fork the repo to the new org for the purpose +of testing. I believe you can rename the repo in the new org to avoid confusion +about the active repo. Another possibility it to make the new repo private. In +either case, the fork would be deleted and the original repo moved. + +Robert Cohn has experience writing python scripts that use the GitHub APIs so +if there is some aspect of the move that you would like to automate, please let +him know. + +Project Web Sites +----------------- + +Most project web sites are hosted on GitHub pages. The URL is based on the org +and repo name. The URL will change when the repo is move. GitHub pages URLs are +not automatically forwarded, but we can manually forward individual URLs. + +Projects may want to consider moving their web site to a new URL that is not +based on the org and repo name. This will avoid the need to manually forward +URLs if the repo or org changes in the future. It also makes it possible to +change the web hosting provider without changing URLs. GitHub Pages is +preferred, but other providers allow dynamic content and bigger web sites. +Contact Robert Cohn to discuss web hosting if you want alternate hosting. + + +Risks and Mitigations +===================== + +This section includes some generic risks. Each project should identify its own +risks. + +Community confusion + Communicate the change to the community and ensure that they understand the + new org structure and schedules. +Community disruption + Ensure that the new org has the same teams, permissions, and integrations as + the current org. Leverage GitHub repo URL redirect and provide website + redirects. +Maintainer disruption + Ensure that maintainers are aware of the change and have the necessary + permissions to continue their work. +CI/CD disruption + Test plan. Ensure the CI/CD maintainers are available to address problems. +Unexpected breakage + Test the new org before the move. Have a rollback plan in case of unexpected + breakage. Search the repos for references to the old org. +Release disruption + Schedule moves during a time when releases are not planned. + +.. _`uxlfoundation`: https://github.com/uxlfoundation +.. _`oneapi-src`: https://github.com/oneapi-src