Like many brigades, Open Twin Cities has deployed a version or two of Adopt-A. One of our more active projects at the moment is Adopt-A-Tree, which is a fork of this Adopt-A-Hydrant repo. Not surprisingly, we had to make some minor changes to our fork (trees instead of hydrants, Minneapolis instead of Boston). We've also made some more significant changes to the UI and data models based on the needs of our partner organization. Predictably, we're now in a situation in which it is difficult for our fork to pull in commits from this repo, and it is difficult for us to send merge requests for code that might be useful to all adopt-a users. Difficult enough, in fact, that we haven't rebased in 6 months. I'm guessing we're not the only people in this situation.
Given the nature of Adopt-A, and all the potential slightly (or significantly) different deployments it might have, it might be a good idea to create an AdoptA Rails Engine. This way, updates to the AdoptA platform could be pulled in by deployed AdoptA's by simply updating the engine, and there would be a much clearer path for coders to contribute back to the main repo. This would also make it much easier for groups deploying their own Adopt-A to manage their own bespoke code. Plus, it would get around GitHub's limit on how many forks of a repo a single person/org can have (1), which is problematic if your group wants to do Adopt-A-Hydrant, Adopt-A-Drain, Adopt-A-Tree, Adopt-A-Siren, Adopt-A-whateverEverythingCanBeAdopted.
ballPointPenguin
commented
9 years ago
Like many brigades, Open Twin Cities has deployed a version or two of Adopt-A. One of our more active projects at the moment is Adopt-A-Tree, which is a fork of this Adopt-A-Hydrant repo. Not surprisingly, we had to make some minor changes to our fork (trees instead of hydrants, Minneapolis instead of Boston). We've also made some more significant changes to the UI and data models based on the needs of our partner organization. Predictably, we're now in a situation in which it is difficult for our fork to pull in commits from this repo, and it is difficult for us to send merge requests for code that might be useful to all adopt-a users. Difficult enough, in fact, that we haven't rebased in 6 months. I'm guessing we're not the only people in this situation.
Given the nature of Adopt-A, and all the potential slightly (or significantly) different deployments it might have, it might be a good idea to create an AdoptA Rails Engine. This way, updates to the AdoptA platform could be pulled in by deployed AdoptA's by simply updating the engine, and there would be a much clearer path for coders to contribute back to the main repo. This would also make it much easier for groups deploying their own Adopt-A to manage their own bespoke code. Plus, it would get around GitHub's limit on how many forks of a repo a single person/org can have (1), which is problematic if your group wants to do Adopt-A-Hydrant, Adopt-A-Drain, Adopt-A-Tree, Adopt-A-Siren, Adopt-A-whateverEverythingCanBeAdopted.