> Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. Thi

> Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. This happens if you don't fork often, post your changes once in a very long time, and don't rebase your work very often. If you rebase often enough you shouldn't have the mergeability problem. > It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork. The alternative is letting people greenlight you to even go and do a proof of concept. It smells like bureaucracy to me. Having a fork and a working proof of concept can back your argument about feature development. The implementation is just a detail and can be adjusted or reworked as necessary. Otherwise you risk your ideas getting stalled (or worse, completely rejected) by people that don't even fully understand what you're talking about.