Making Talkyard contributor friendly

Talkyard is open source, and it'd be good if it was simpler to contribute, without running into confusion e.g. when building images, or reading the source code. This is a roadmap for making it simpler, to contribute.

1. A simpler build system. Assuming you have installed Docker-Compose, then, this:

   git clone https://github.com/debiki/talkyard
   cd talkyard
   make up   # GNU Make
   

   should be enough, for pulling down Javascript and Scala dependencies, compiling and packaging, building Docker development mode images, and starting Talkyard. Actually, this seems to work, I just tested in new repo :- ) ... Stop everything like so: make dead. Ok, so step 1 done?

2. A simple way for deploying one's own images with Docker Compose or Swarm, HTTPS-proxied with Traefik or Caddyserver. See K8s, Swarm, Traefik and Talkyard.

   Briefly, could be something like this?:

   vi .env  # fill in your repo name: DOCKER_REPOSITORY=...
   make prod-images
   make tag-and-push-lates-prod-images tag=v1.2.3  # pushes to your repo
   envsubst "VERSION_TAG=v1.2.3 REPO=..." < docker-stack.yml > my-stack.yml
   docker stack deploy -c my-stack.yml my-talkyard  # deploys your images
   

3. I'll write a Contributors Guide: A high level overview of how the source code is organized, to guide want-to-contribute people to the right places?

4. You, I and everyone create a todo list for improving the source code quality and clarity. E.g. refactoring, maybe adding something like Redux or MobX or ReactN. Using React Higher Order Components when appropriate. Renaming Scala classes. Fairly often, I ( @KajMagnus ) am probably the one who should do the actual source code changes, since I'm familiar with the code base — and you're the one who can tell me what needs to be done? Since I don't know what, from other people's perspectives, are the most annoying / confusing things.

   Here's the above-mentioned todo list: Cleaner Code Todo List

   — Feel free to post comments there. I won't start fixing things immediately. Instead, first, we'll just make a list. Then prioritizing.

5. Speed up the end-to-end tests. There are almost 100 end-to-end test suites, and they take about 50 minutes to run (in total). People cannot wait for that long, to find out if their code changes broke something? Instead, the e2e tests should run in parallel.

After these steps 1 to 5, it should be okay simple to read the contributor guide, find and edit the relevant files, and see if your changes work. And then deploying your custom images, or submitting a patch.