Get rid of config.json and have all the site-wide config options in dashboard

[olayway]

Why:

1. To keep site-wide configuration in one place
2. To make it simpler for non-tech users (no need to handle JSON structure)
3. To expose all the available config options in one place and encourage easy usage/testing thereof
4. Not to pollute your markdown repository with tool config (minor though)

[olayway]

@rufuspollock This is not for now but let me know wdyt.

[rufuspollock]

@olayway this is a tough one. My sense is i'd be a 👎 for now.

BTW I could swear i created an issue about the question of sequencing of config and making that logic documented e.g.

• defaults (whatever they are)
• config.json (overries defaults)
• dashboard

Reflections

Pros

• Having config all one place is better UX (less confusion)
• Dashboard UX is definitely much easier for most users than (that said our userbase is reasonably geeky to start with so may not be as big a deal as we think - e.g. they have to use github).
• Reduce our support surface: we don't have to handle two different areas.

Cons

• Supporting all config in dashboard is quite a bit of work (e.g. doing navlinks well requires a bit of effort
• Much faster to add new config via config.json and then (if necessary) add to dashboard later. Concrete example: a user has asked about configuring the giscus theme #746. In config.json this should be pretty easy - we just allow provision of giscus config and then just pass through (this is also something i want to customize my giscus setup in some cases).
• For power users (e.g. me) config.json is attractive for a couple of reasons
  • very quick to add via copy/paste from docs or even between different projects.
  • team management can manage via github which whole team has access to (whilst only one person (atm) has access to dashboard

My overall sense is we want to keep this under consideration but for now config.json offers sufficient advantages in terms of flexibility and speed of development that we stick with it .