Refactor Adopt-A-Tree for better development of core Adopt-A vs. tree specifics

[kjschiroo]

Adopt-A-Tree is a fork of Code for America's Adopt-A-Hydrant (which should more correctly be thought of as a general Adopt-A-Thing). Early on, we would rebase Adopt-A-Tree based on updates to Adopt-A-Hydrant, but now the code bases have deviated from each other enough that rebases are difficult.

The differences that Adopt-A-Tree has introduced fall into two categories:

1. Changes to meet the specific requirements of the Adopt-A-Tree project (e.g. changes to the user model, refering to 'tree' instead of 'hydrant')
2. Changes that improve the code or functionality of the Adopt-A platform (in our opinion) (e.g. DRYing some of the JavaScript).

Ideally, we should be pushing the changes in the second category upstream, so that all Adopt-As can benefit. Also, a lot of development has been happening on Adopt-A-Hydrant - development we can benefit from if we could easily pull those changes in.

It would be tremendously helpful if we could somehow sepearte the project specific code from the general platform code. I don't know what this looks like in practise, but an option to investigate is to have Adopt-A-Hydrant become a Rails engine and a gem.

[kjschiroo]

Created the Create an AdoptA Rails Engine ticket on the main Adopt-A-Hydrant repo.

[kjschiroo]

👍

[kjschiroo]

For a number of reasons, I'm inclined to close this:

• It's been over a year since this ticket and it's companion in Adopt-A-Hydrant were created, with no discussion or action occurring in either repo;
• Upstream, though still actively being maintained with dependency updates, does not appear to have active feature work occurring,
• Adopt-A-Tree, though still pretty similar to Adopt-A-Hydrant, has continued to evolve in its own direction (adoption history, deployment, (abandoned) promo codes),
• It is entirely possible for us to continue to develop Adopt-A-Tree, then at some point spin off our own generic Adopt-A-Thing repo for different uses by ourselves and others.

What I'm starting to think now is, rather than focus on the relationship between Adopt-A-Tree and Adopt-A-Hydrant, I'd like to set an independent development and architectural path for Adopt-A-Tree. Specifically, I'd like to:

1. Refactor the JavaScript to use a modern JS framework (anybody have thoughts on React?);
2. Move to a pure JavaScript UI that interactions entirely via RESTful API;
3. Continue to move configurations into yml files, making the server more generic

Given this, it seems like Adopt-A-Tree no longer operates as a fork of Adopt-A-Hydrant. In fact, being a fork of Adopt-A-Hydrant actually causes us some problems (OTC already has a fork of Adopt-A-Hydrant and can not contain another fork). (at)ballPointPenguin work do you think about unforking Adopt-A-Tree?