Colouring-CityX repo

[edwardchalstrey1]

I was thinking about how the other Colouring Cities groups can best be helped to get started and was wondering about the possibility of extracting some of the components of the Colouring London repo to a separate master/template repo, from which other cities sites can be forked/extended. I noticed that @tomalrussell already may have had this idea previously: colouring-core.

It looks like Bahrain and Athens have copied most of the repo (but not forked), which means that even if they are being actively developed, they might not have the most recent general updates and could drift from Colouring London in ways that will be difficult to help them with, or end up having duplicate bugs that we have already fixed for CL etc.

In fact @gpanag has confirmed as much via email, when I mentioned our recently resolved node dependency conflicts:

I had some trouble setting it up, I guess due to the dependency conflicts you mention.

@matkoniecz @tomalrussell what do you think about this? A couple of things to consider:

1. Do we want to have a Colouring-Core repo, coupled with developer guidelines for other cities on how to fork the repo and get started with local modifications? It could act as a sub-module for each Colouring-CityX repo perhaps. We might not want this, perhaps it is too much work or even preferable to simply let each project do as they please with the codebase.
2. If we go down the route of automated deployment (see Best tools for automated deployment #765), this will be primarily be of use to other colouring city groups, rather than Colouring London (although for us it could be useful in case of a catastrophic failure of production env that requires a redeploy). So perhaps automating the deployment would be best saved for after we have implemented a Colouring-Core repo - what do you think?
3. @tomalrussell if we have the developer calls you mentioned, perhaps this discussion can be a question to crowdsource an answer to in the first one. Or even to link the attendees to this GH discussion (and any others) in advance?

[tomalrussell]

Thanks for opening this discussion @edwardchalstrey1 - warmly invite other opinions, especially from anyone who's taken a look at adapting the current or previous colouring-london codebase to run elsewhere.

A bit of history

Previously, we went with forking to get other city sites started, as this was a route to get something up and running with a few changes to hard-coded text and map configuration.

There's a limitation in GitHub that repositories cannot be forked within an organisation, so colouring-athens/bahrain are effectively forks without the GitHub fork association - they could still merge changes via a local repo with multiple remotes if desired, but this would take time and effort.

The colouring-core repo was created with the idea of being a clean refactor of the colouring-london codebase that could be configured, but we haven't managed to put effort into this.

My current opinion

A single codebase is desirable - we can benefit from shared work on features and bug fixes, generally work together on something, hopefully reduce complexity and overhead. We should identify and prioritise features that make it possible to customise and configure to deploy this codebase in different contexts.

I now think the simplest route to this would be to keep working on colouring-london and effectively aim to turn it into colouring-core. This avoids the risk and effort of making a "second system" and would focus our work in one place.

I don't think it should be a template repo. As I understand it (do correct if this is wrong), this would be functionally similar to forking - a one-time duplication from the template to an instance.

We could look at the pattern used by the discourse forum software - there's some sysadmin to set up and configure, but it's done from a single codebase, with a mechanism to update deployments when code changes are available.

Config might be files (JSON/YAML) we could version control in separate repositories, or it might end up in the database, backed up as appropriate.

I think these are the top priority things to configure:

• map center location
• home page text and site title
• remaining text content
• translation functionality and languages available

Later, also configure which user interface components are enabled. There's more to discuss about collecting different attributes in different places. One plausible approach would be to have everything available in the shared codebase, and toggle UI visibility and API acceptance of particular fields in the city/site configuration.

In short

1. Do we want to have a colouring-core repo? Yes, I think this is a reasonable aim, as a rename and development of colouring-london.
2. Perhaps automating the deployment would be best saved for after we have implemented a colouring-core repo? No strong feeling - if some automated deployment is set up earlier, that can always be built on.
3. Link developer call attendees to this discussion? Great idea.