Skip to content

Latest commit

 

History

History
32 lines (27 loc) · 3.08 KB

2024-07-23.md

File metadata and controls

32 lines (27 loc) · 3.08 KB

TC Meeting 2024-07-23

Present: Cornelius, Stephanie, Florian, Adrian, Frederik, Max; Excused: Peter, Loic

Agenda

Protocol

  • Onboarding liblrs, we will do next week, when maintainer is back
  • DCO bot for TC repo switched on
    • It works in the web interface automatically when the setting is enabled for the repo
    • In git you have to add the -s option to sign-off commits, automation is not possible by default as it is supposed to be an explicit statement by the developer
  • GitHub gave us teams plan for nonprofit organization
  • Managing OpenRail Association owned DNS entries: https://github.com/OpenRailAssociation/openrail-dns/
    • Semi-automatic automation via the data in the repository
    • Data is publicly available from DNS in principle anyway, so it is not a problem to have it in a public repo. There might be edge cases, where we could introduce GPG-signed commits to make sure that changes are only coming from the people they are supposed to come from, but might be not worth the effort right now.
    • Similar as with the GitHub team management there could be issues if within the people who have legitimate access to the files are changing things from other projects. This is prevented by the CODEOWNERS and review mechanisms, but there are still some technical possibilities left. We rely on the social contract that this is not happening.
    • Decision: We use the openrail-dns repo to manage the domains which are managed automatically as Max proposes.
  • Discussion: For describing projects, would it make sense to adopt something like https://github.com/publiccodeyml/publiccode.yml?
    • It's a standard for specifying metadata for open source projects coming from public administration
    • It's used for example by https://opencode.de
    • There is a formal specification, some fields like the scope field are defined for public administration purposes, we would need to adjust these
    • There is some duplication with fields which are already in the GitHub configuration, like name, license, etc. Maybe we can do a combination and use the publiccode.yml to only maintain the data which is not already on GitHub and take the data from GitHub which is already there. GitHub API is probably less stable than the format, so it might change and require adaptations. Maybe a background job to update publiccode.yml from GitHub data could also be an option, triggered by the CI for each release or so.
    • One use case is presenting OpenRail Association projects, e.g., on the web site. Other use cases could be collecting railway-related open-source projects which are not only part of the OpenRail Association.
    • Are there alternative formats or additional helper tools?
    • No decision today, we will revisit the topic at one of the next meetings.