This is a meta-task, which needs experimentation and breaking into sub-tasks.
Currently the scorer UI is mainly intended to be run locally. While we don't want to lose support for that, it means that each year some effort is needed to configure the machine which will be doing the score-entry.
As we typically use the same machine each year, it's really easy to end up missing some part of its setup which needs updating.
Deployment of the scores is done independently of the scorer UI as it involves more than just git push. This also needs setup on the machine as we need to be able to pull the scores off it.
Hosting the scorer centrally could help with this by (almost) removing the need for any setup on the machine -- it would just need a web browser.
We'd need to:
figure out some mechanism to authenticate access to the scorer UI
work out whether we want to allow the scorer by default on the "public" flavoured instances
work out how deployments of the scores work (does the scorer UI gain support for this? perhaps not in v1?)
This is a meta-task, which needs experimentation and breaking into sub-tasks.
Currently the scorer UI is mainly intended to be run locally. While we don't want to lose support for that, it means that each year some effort is needed to configure the machine which will be doing the score-entry.
As we typically use the same machine each year, it's really easy to end up missing some part of its setup which needs updating.
Deployment of the scores is done independently of the scorer UI as it involves more than just
git push. This also needs setup on the machine as we need to be able to pull the scores off it.Hosting the scorer centrally could help with this by (almost) removing the need for any setup on the machine -- it would just need a web browser.
We'd need to: