Add package and mode status keywords and guide

[teutoburg]

Corresponding ScopeSim PR coming soon.

This allows a better overview (for both developers and users) about the status of our packages and their individual modes.

This keyword is completely optional, omitting it does not result in any error.

The values intended to be used with this key and their meaning is summarized in the pkg_status.md guide, which becomes part of the documentation. Feedback or additions to that list are of course welcome 🙂

To those with more "bigger picture" insight into the status of various packages and modes than myself: Please take a quick look at the statuses I used and simply request a change on this PR if you think a different one fits better for the current stage of the package or mode in question!

It is intended (at some point when there aren't as many other things to do - who am I kidding...) to incorporate the statuses in the respective package READMEs, probably as badges, together with the existing badge report thing...

[hugobuddel]

I'm not yet convinced this status keyword is useful in its current form, but not sure why, so I'm trying to organize my thoughts by typing them here.

I fear the label will be(come) meaningless. Maybe there should be some commitments attached to the labels. E.g. "Simulation results are validated with reference documents." (production) is on of the most important sentences, but what does this mean? What (and who) do we commit to?

I think we can only claim 'production' if we can also say who is responsible for maintaining that status, and that should be a collaboration of consortium people, 'assisted' by the ScopeSim people. As in, I believe there should be a scientist in the lead. (There can be overlapping roles though.)

Maybe 'who is committed' is a meaningful distinction in general:

• experimental: some quick experiments by X and Y (e.g. one of us and/or someone from the instrument), but no commitments, talk to them if you want to take it to the next level
• development: there is active effort by X, Y, and Z to make this happen, help is appreciated
• production: there is an more-or-less explicit agreement between X, Y, and Z to maintain this, you can hold us (which includes consortium members) accountable
• deprecated: no-one is maintaining this

I don't know whether we are in a position to make such claims though. But I think we need something strong to make the label useful.

(We can perhaps also have a similar thing for the effects. Or maybe that is transitive; an effect has the status of the highest package that uses it.)

Ultimately something like this is useful. (I know I got very frustrated with scipy; half of their code was utterly broken for a long time, but it was hard to figure out in which half the functionality you needed fell.) So maybe go for it?

Just my 2cnts.

[teutoburg]

Just my 2cnts.

Thanks for your thoughts, I do consider it valuable input and not just old man's rambling.

Agree with your "who is committed" list. Should I add it to the guide?

I don't think any of our packages or modes are close to "production" at the moment, there are issues everywhere. Well except the test_package that is, because that's just a mock really.

To go off on a not-so-serious tangent: Perhaps we could use a gamification approach to this and see the status stages as levels. You need to gather XP by making tests pass, form a guild of consortium members and defeat the final boss in the form of the reference validations. If your team dissolves, you get deprecated 😄

I was also thinking some kind of overview board for the status of all the packages (and modes) might be useful. Not sure if the GitHub Projects thing can be bent into that though. Then we would have an issue for every package and sub-issues (which are now a thing) for the modes? Seems a bit weird. So maybe just an overview on the docs page for now?

So maybe go for it?

Is that a merge approval? 🙃 I'm waiting for @astronomyk's feedback (probably in person tomorrow) on my assessment of the current statuses anyway...

[hugobuddel]

Just my 2cnts.

Thanks for your thoughts, I do consider it valuable input and not just old man's rambling.

Agree with your "who is committed" list. Should I add it to the guide?

The point is that it can be hard to get such commitments.

To go off on a not-so-serious tangent: Perhaps we could use a gamification approach to this and see the status stages as levels. You need to gather XP by making tests pass, form a guild of consortium members and defeat the final boss in the form of the reference validations. If your team dissolves, you get deprecated 😄

Add some financial rewards (through a blockchain of course).

I was also thinking some kind of overview board for the status of all the packages (and modes) might be useful. Not sure if the GitHub Projects thing can be bent into that though. Then we would have an issue for every package and sub-issues (which are now a thing) for the modes? Seems a bit weird. So maybe just an overview on the docs page for now?

That would be good yes.

So maybe go for it?

Is that a merge approval? 🙃 I'm waiting for @astronomyk's feedback (probably in person tomorrow) on my assessment of the current statuses anyway...

It's more a "I won't object beyond my old-man-ramblings if there is someone else to approve". Maybe from the perspective of "if you approve a PR, then you co-own the code", and I'm not sure I'm willing to commit to that, because maintaining this requires a group effort.

[astronomyk]

Verbally discussed. In Ordnung 👍