Skip to content
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

Feedback on the new matriculation process #1293

Open
craigbox opened this issue Apr 4, 2024 · 1 comment
Open

Feedback on the new matriculation process #1293

craigbox opened this issue Apr 4, 2024 · 1 comment
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.

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: Ready for assignment
Development

No branches or pull requests

3 participants