📝 Break down what the different issue labels mean

[zspencer]

I'm starting to worry about how long this document is. I'm sure there's a better way to organize and structure this information that doesn't throw an intimidating document right on the critical path for contributors...

See: https://github.com/zinc-collective/compensated/issues/56

[zspencer]

@drllau - I'm trying to pull the tacit knowledge I have around the meaning of the labels into something more long-term. LMK if you have feedback!

[drllau]

That's why I wanted hierarchy /core/CONTRIBUTE.md vs /contrib/CONTRIBUTE.md vs common/CONTRIBUTE.md .... the top level is the basics, then a more graduated learning curve for contrib leading to core, with badgebot working on /common to train up helpful but non-coders.

[zspencer]

I think we are going to wind up pulling a lot of the content of CONTRIBUTING.md into a landing page on www.zinc.coop; since most of it applies across projects within the coop and because we want to enable contributions from folks who aren't particularly well-versed in Git/GitHub.

I think the idea of an "easy on-ramp" is really good, I'm not sure the core, common, contrib trichotomy is quite how I think I want to do it.

[drllau]

You say ruby is designed to be extendable and due to flow, no need for different /{core, contrib, common} subdirectories. Does this apply when you have multiple different languages of the exact same functionality? Or you need to stage interim artifacts (eg a logo placeholder for badges)? Before on unix I would use modules (something like cfengine) to manage my dotfiles and link to different library versions so I put archive multiple versions and just symbolic linked as needed. I can see that for operations, this would be a headache (rollbacks aside) though.

how I think I want to do it.

Well once Zinc Coop have a working sandbox, the test can be to set up their own payment interface and get $1 (credited towards their 1st week usage?? based on $50/yr fee) into it. Nothing like personal self-interest to get a student coder off their butt (I used to teach CompSci though the lecturer preferred chocolate fish as incentives).

[zspencer]

I can see a shared or assets module being extracted; the way that modern code and asset packaging works is you generally want to avoid linking to a common folder and instead have each shared module named expressively; and packaged independently then shipped to your package repository. This ensures that people who write code that doesn't wind up in this particular git repository and want to rely on the modules can reference them by pulling from the package repository; instead of requiring the entirety of common being pulled down.

By enforcing package "boundaries" between the shared code and the user code; we encourage encapsulation that's a bit more resilient than referencing the assets by file-path. If we link file-a to file-b using an implicit directory structure. This also makes it easier for people to write "contrib" code because they can write and distribute their contributions without requiring a blessing from the core compensated maintainers.

I think the goal you're shooting for (ease of contribution, clear delineation of IP ownership) is valid; and I want to recommend that we maintain that through peopel creating their own independent repositories that extend compensated instead of relying on the CVS/SVN inspired centralized core/common/contrib model.

[drllau]

peopel creating their own independent repositories that extend compensated

I'll take your word for it since you're more conversant with modern software engineering practices. I'd assumed that github allow whole repos to be forked as subbranches of other repos but apparently not so easy to synchronise. So you suggest assets, bots (for external testing & revalidation of core) or media (for contrbuting docs) instead of {core, contrib, and common}. bot would be any test code or regression testing outside dependencies want to maintain with compensated. Because Principle of Stability Above All, you;d want even overnight dev-builds running all those bottests to make sure that if an emergency security patch needs to be urgently emplaced, all but edge cases of sublicensees should not be affected. This is all good stuff which I'd normally lump under design philosophy.

Add explanation of package separation to CONTRIBUTION.md somewhere?

[zspencer]

This is great feedback! Unfortunately I have been flat on my back the past week, and I'd like to be able to put this to bed. If one of the other @zinc-collective/compensated-maintainers feels this is worth merging, please do so; otherwise I'm going to close the branch the next time I am working on Compensated.