1. Have a place where we can run an instance for internal testing. It should be easy to deploy the latest version of the main branch after a story (or task?) is done.
2. Have a place where we can run an instance for showing the tool. This should be easily usable by people who don't have wiki-accounts or don't want to use them.

But these could share the same server right? No need for two servers? @Sebastian_Berlin-WMSE @Marc_Maillard_WMSE

With Toolforge you don't have servers, but rather tools. Each tool has it's own URL which is used if you have a web service. So if we want to have a test version and a production version, we'd likely want to separate tools, called something like wikispeech-sdc and wikispeech-sdc-dev.

Helpful resources when building a toolforge webservice tool:

How to use the "Toolforge Build Service"
Example: Django app
Start and stop a Toolforge webservice
Deplying a Python webservice

2. Have a place where we can run an instance for showing the tool. This should be easily usable by people who don't have wiki-accounts or don't want to use them.

We discussed this and it may not necessarily mean that you can save the recordings. This would require a wiki-account. It depends on what you wan to demo. If it's just the recording process it may be enough to just skip the save step.

sebastian-berlin-wmse opened https://gitlab.wikimedia.org/repos/wmse/wikispeech/speech-data-collector/-/merge_requests/13

Add Git commit to web page

sebastian-berlin-wmse merged https://gitlab.wikimedia.org/repos/wmse/wikispeech/speech-data-collector/-/merge_requests/13

Add Git commit to web page