In brief: I have some questions around forking a FLOSS project. They tend to start with a question of etiquette ("what's the right thing to do?"), but then stray into more technical areas ("how do I do the right thing?")... such as what should I do with package.json
, how to organize things within my fork on GitHub.
Q: How technical can my question get? NOTE: I wouldn't be asking "what's the Git command-line to achieve...", but more what's the best/accepted practice within NPM/Git to fit with FLOSS ideals.
Background, in case it helps:
In a situation somewhat similar to "Etiquette around forks & npm", I've made some (local) changes to a Node module published on NPM and hosted on GitHub under an MIT license. The project hasn't had any commits in nearly a year, and the maintainer has indicated they're unlikely to have the time to actively maintain it.
I've created a fork of the original code, primarily as a place to store my personal changes. However, before I push my changes to it, I'd like to ask some etiquette/best practice questions, taking into account:
I don't want to exclude the possibility of submitting my changes as a PR, though at the moment it seems unlikely that one would be processed.
I'm not (at least currently) in a position to either take over active maintenance of the original module, nor for my fork to become an active replacement for it (but, again, I don't want to exclude either of these if possible).
If someone stumbles across my fork, I more than happy for them to use my changes if they want, but I don't want it to either look like I created the whole thing, nor for my forked-module to "clash" with the original one.