TC meeting on 2024-02-08

[cornelius]

No description provided.

[cornelius]

Protocol of the meeting:

Present: Cornelius, Peter
Excused: Loic

• How to handle meeting agenda and minutes
  • We decide to prepare the agenda in an issue, put the protocol into a file we add to the meeting folder
  • Discussions about content should happen close to the content, e.g. as pull requests or issues on the concrete files which are being discussed (such as the incubation process document)
  • We will schedule a tutorial about how to use GitHub on Friday next week
  • Inspect & Adapt
• Onboarding of OSRD
  • Next steps:
    • Document project acceptance on GitHub (cornelius creates a pull request)
    • Add OSRD to web site (https://openrailassociation.org) on project list and as news entry
    • Plan meeting with OSRD maintainers to discuss onboarding and clear expectations, and plan next steps (naming representative in TC, move of repositories, roadmap for further incubation)
  • At least at the beginning all new projects should move their repositories into the OpenRailAssociation org, that makes sure that the OpenRail Association has the ownership (the TC should be GItHub owner of the org where the repo is), that it's a conscious step to join the association, and it simplifies the technical management, because we can use the org to have common settings etc.
  • Create a checklist with the steps we take, so we can reuse it for future projects
• Discuss later stages of incubation process (Naming of incubation process stages #24)
  • For Hackathon and similar projects we might need an actual sandbox space, which is not part of the incubation process but a space for experiments within the OpenRail Association. This space would be managed as community space by the TC, but not need board approval for acceptance. Maybe as extra GitHub org.
  • Production readiness should be communicated by stage 1 (currently Incubation) (maybe stage "production ready"?)
  • We think a small number of stages is good, because it is easier to manage and communicate
  • Stage 2 should have a security policy (SECURITY.md), Stage 3 should probably have something more advanced, such as security audits, we need to check that with the requirements of the organizations which are supposed to use the projects

Postponed:

• Discuss what is needed to define requirements for project governance (Draft requirements and template for project governance #8)
• Project badges