search

zinc-collective / compensated

Create value. Get Paid.
Other
13 stars 1 forks source link

📝 Contributors are required to assign copyright to Zinc Collective LLC #42

Closed zspencer closed 4 years ago

zspencer commented 4 years ago

In @drlau's patch; he made some really useful points that I wanted to integrate: https://github.com/zinc-collective/compensated/pull/41

However, I'm getting into some git-wigglyness because we had made some changes that made the 0.X branch in our repository go a bit too far ahead of @drlau's fork.

I've submitted a patch to his patch that brings it up to date for now; and have asked if he feels comfortable with us merging this directly (so long as it doesn't remove his authorship attribution)

drllau commented 4 years ago

There shouldn't be conflicts as I added several files and expanded around CONTRIBUTIONS ... you can try just replace that file holus bolus as it was basically a stub. I still need to update it as per Zees current plan on license including within each major version so I'll wait until people read and ack/nak the ideas to merge back into Master branch

zspencer commented 4 years ago

Re: What's needed here - Only your assent to assign the copyright for your commit in this patch to Zinc Collective. To do so, please follow the directions for assigning copyright in the contributing guide.

Re: Conflicts - Unfortunately, there are significant conflicts between the drlau/patch-2 branch and the zinc-collective/0.X branch. I believe this is because of a "rough edge" when someone creates a branch off of another branch that was merged in later, or when their master (aka 0.X) branch is behind the zinc-collective/0.X branch. This is a patch that does my best to remediate the conflicts but is by no means the only way forward. If you would like to take a stab at resolving the conflicts or creating a new patch off of the zinc-collective/0.X branch I'm happy to merge that instead.

Re: Versioning - The goal is to follow Semantic Versioning where once we hit 1.0; any breaking changes move us to 2.0. Any non-breaking changes are added to 1.0. A goal I have before calling this "1.0" is having a high degree of confidence that we can make significant additions (new payment processors, new languages/frameworks, etc.) without breaking the existing functionality. I am defining "breaking changes" as requiring any user to change their code in order to adopt the new version.

Re: Positivism - Yes! I 100% agree here. The RFC style syntax was added because I have been getting feedback from folks who are a bit less willing to put themselves out there that having clear and explicit guidelines about what one must and must not do makes it safer and easier for them to approach the project. I think the open badges project is quite interesting and am happy to hear suggestions on how we could apply it in a 'yes, and' method that complements the standard RFC must/should/may syntax?

Re: Line shuffling - I'm not entirely sure what you mean here? I am trying to merge the suggestions you in the drlau/patch-2 branch with the most up-to-date CONTRIBUTING.md in zinc-collective/0.X.