osrd stage 2

[flomonster]

Feedback:

• I don't know if editing the project_proposals/osrd.md file is the right thing to do for this request.
• The first three criteria are very similar. At least the only thing to fill in as a project is the link to the repository pulses.
• Not sure it was the best way to proof the usage of REUSE and DCO
• There are no criteria for the openness of communication channels with contributors. The fact that OSRD has a matrix server accessible to all makes it easier to integrate contributors from outside SNCF.
• Requiring projects to have dependencies security alerts and secret scanning alerts seems reasonable for stage 2 (it's a small proof of maturity).

[cornelius]

From yesterday's TC meeting:

• I don't know if editing the project_proposals/osrd.md file is the right thing to do for this request.

We will provide a separate questionnaire, so that the stages are separated and there is no confusion about what to add when and where.

• The first three criteria are very similar. At least the only thing to fill in as a project is the link to the repository pulses.

We will keep this relatively free-form. Adding an explanation and links to metrics such as the repo pulse is probably good
enough as a base for the evaluation for now.

• Not sure it was the best way to proof the usage of REUSE and DCO

We will add more details in the questionnaire (which is still to be created as a separate file).

• There are no criteria for the openness of communication channels with contributors. The fact that OSRD has a matrix server accessible to all makes it easier to integrate contributors from outside SNCF.

To be documented in more detail.

• Requiring projects to have dependencies security alerts and secret scanning alerts seems reasonable for stage 2 (it's a small proof of maturity).

Good point, should be added.

[cornelius]

Another interesting metric in this context would be the Contributor Absence Factor, i.e. how big is the dependence on individual people in the project.

[flomonster]

I was unable to retrieve this stat. The tools that can provide it are a bit complicated to set up.

[cornelius]

In addition to how the releases work from a technical point of view, it would be helpful to have information how users are affected by releases and how they can plan with releases. This would include things like the release cycle, stability of releases, if and how beta and other preview releases are available, and how this is communicated (e.g. is there a versioning scheme indicating stability of releases).

Related to this is information how users can provide feedback for releases, e.g. by opening issues, or how they can follow or even influence the roadmap, so that they can plan regarding future releases.

[cornelius]

I think we have to make clearer what exactly we mean with open governance, or is this already clear enough? Would maybe something like a checklist help what to look at regarding assessing the openness of the governance?