sfbrigade / Infrastructure-Team

The central location for the SF Brigade Infrastructure Team organizational issues and planning.
7 stars 1 forks source link

Discuss a strategy to maintain forks & deployments of Adopta #26

Open jszwedko opened 8 years ago

jszwedko commented 8 years ago

Originally posted as https://github.com/sfbrigade/sfbrigade.github.io/issues/134 by @afomi

From the original issue:

I feel like the community is all over the map in terms of managing Adopta (or any CfA/Brigade project) forks and deployments. I also feel that it'd be good to not have too much divergence in the space, because it could hamper maintainability and compatibility.

Just wanted to get this out and see what's being done in the Brigade community to manage such things.

jszwedko commented 8 years ago

It definitely feels like the current mode of operation is generally to copy/paste and customize (considering the Adopta project and our brigade website)..

Advantages:

Disadvantages:

An alternative is to design the projects in a more generic manner, e.g. storing assets, text copy, etc. outside of the app in a datastore of some sort, so that the code base could be more consistent between projects. However, even with this, I imagine that code customization to make the particular instance of the project fit the needs of the project will be inevitable. Ideally the project could be robust to this sort of thing via some sort of plugin/hook architecture, but it is difficult/significant overhead to architect projects like this. The originators of the forks may also be adverse to accepting these sorts of changes (as it is overhead for them too) so this approach is probably better for new projects (consider https://github.com/sfbrigade/adopt-a-drain/pull/24#issuecomment-154065018 which I understand and agree with).

Another alternative might be to have a "standard" implementation that we could contribute less controversial changes back to and pull from in the form of patches. This approach feels more tractable to me.

One other issue to consider is that it probably isn't readily apparent when creating/launching a project that people will want to copy it so you have to balance the overhead of creating it in a way that is easily reusable vs. the probability that it will actually be reused.

This may be an interesting thing to bring up on the CfA slack.