Skip to content

Feedback on the new matriculation process #1293

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
craigbox opened this issue Apr 4, 2024 · 3 comments
Closed

Feedback on the new matriculation process #1293

craigbox opened this issue Apr 4, 2024 · 3 comments
Assignees
Labels
process-documentation Doc changes for process and procedures

Comments

@craigbox
Copy link
Contributor

craigbox commented Apr 4, 2024

I have migrated Kubescape's incubation application from November 2023 to the new format. Here is my feedback on the process, and things I would change. It relates only to the incubation criteria, but I expect the graduation to be largely the same.

Using GitHub issues

  • Having this content exist in a GitHub issue means it can only be edited by one person. There's no facility to comment on certain sections, have suggestions written in by others, or indeed to have more than one person make commits.

  • You also end up with one set of documents as MD files in a repo (for older projects), and one set in issues (from this point on).

Recommendation: move back to using PRs and files.

Template content

  • I don't understand why there is a section marked "Incubation Criteria Summary" at the top. The draft criteria starts with "Application Process Principles".

    • The only thing being asked here is about adopters, which is also asked under "Ecosystem" at the end of the template.

    Recommendation: remove this section.

  • Mixing content which needs to be filled in by the project, with content which needs to be filled in by someone else, makes it hard to know when you're done. For example the "TAG insight" and "Due Diligence Review" sections under "Application Process Principles" are the responsibility of a TAG and the TOC, respectively.

    Recommendation: have an appendix section at the end of the document where the response to this document from TAG, TOC or other review is noted, and have all checklist items be things the project is expected to assert.

  • "Document agreement that project will adopt CNCF Code of Conduct" should only be required at Sandbox and/or if a project joins directly at incubation.

  • I merged two headings in two cases, as one answer addressed both points:

    • "Project must have, and document, at least one public communications channel for users and/or contributors." and "List and document all project communication channels". (This was proposed in the planning sheet but never actioned.)
    • "Document project goals and objectives" and "Document what the project does, and why it does it"

    Recommendation: merge these.

  • Having to document security procedures, perform a security self-assessment and achieve an OpenSSF Best Practices badge requires us to document the same data up to three times.

    Recommendation: consider dropping one of the external requirements and/or not asking security questions in the template.

TAG & TOC interaction

  • There is a requirement to get TAG guidance; the format of what should be provided has not been standardised by the TAGs.

    • Our TAG is aware of the project due to our sandbox application and updates provided since; we are hoping we do not need to burden them with a re-run just to get their feedback to mark this section complete.

Other

@linsun
Copy link
Contributor

linsun commented Dec 17, 2024

Karena plans to check this out later this week.

@angellk angellk moved this from Ready for assignment to Active Review & Discussion in CNCF TOC Board Feb 18, 2025
@angellk
Copy link
Contributor

angellk commented Feb 18, 2025

Using GitHub issues
Having this content exist in a GitHub issue means it can only be edited by one person. There's no facility to comment on certain sections, have suggestions written in by others, or indeed to have more than one person make commits.

You also end up with one set of documents as MD files in a repo (for older projects), and one set in issues (from this point on).

Recommendation: move back to using PRs and files.

Thanks @craigbox - for this recommendation, the move to GitHub issues has been working overall. Recommend the current process continue since the moving levels process has been increasing in efficiency. Notably: the Sandbox board was cleared in the last Sandbox review and is set up for an efficient review in the February 25th meeting. The Incubating and Graduating queues have also increased in efficiency.

@angellk
Copy link
Contributor

angellk commented Mar 5, 2025

Template content

@craigbox thank you! recommend opening a new issue for consolidating/de-duping the security requirements

For all other items - recommend reviewing post-TAG Reboot (after KubeCon) and opening separate issues for outstanding items.

Thanks again - hopefully you'll see recommendations incorporated within the new TOC changes.

@angellk angellk closed this as completed Mar 5, 2025
@github-project-automation github-project-automation bot moved this from Active Review & Discussion to Done in CNCF TOC Board Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
process-documentation Doc changes for process and procedures
Projects
Status: Done
Development

No branches or pull requests

3 participants