Write `Contributing.md` That is more focused on the contributor and less CYA

[zspencer]

So, right now the contributing guide doesn’t tell anyone how to actually contribute; it just tells them we own their shit

We probably should rework this to be actually helpful for contributors and include things like:

0. Affirmation that we value non-code contributions (bug reports, documentation fixes, design proposals, etc)
1. Links to the help-wanted and good-first-issue issues
2. A link to Zinc’s “pathway to ownership” document (that is yet to be written)
3. Reframing to a more gentle explanation for why we need to own the code. and laying out commercial collaboration terms

[drllau]

Proposed set of changes

1. Make a distinction between public ZeroLicense DIY for say volunteers which just want to be compensated for non-labor materials

   If you combine my contributions to the project with other software in a larger application, you may sublicense my contributions to the project as part of your larger application, and allow further sublicensing in turn, under these rules:

2. Split contributors into 2.1 core (who will probably get a cross Zero License with pertinent legal priviledges; as above 2.2 contrib = basically bundled with acknowledgement (basically CC BY-ND 4.0) ... essentially whilst legal title is held by Zee, operational control is retained since the code is bundled as is 2.3. community is Feedback such as bug reports, testing, translation of documents, etc. Up to Zee to see what resources go back into supporting the community
3. Some background about the state of payment and why it sucks ... for a $10 credit-card payment, $2.20 goes to customer's bank, $0.23 to the clearing house, $0.19 to your bank, $0.13 to the credit card network which means 28% disappears and this is before state taxes.

[zspencer]

Thanks @Drlau!

Re: 1 - I don't think I understand the point you're making here? Like you're talking about a reciprocal license for folks who contribute? I think that's a great idea, but would want to use a license that is off-the-shelf for that. Do you know of anyone who has publicized such a thing?

Re: 2 - I worry that this creates a "multi-tiered" approach to valuing contributions. The person taking the time to send a bug report should be contributed equivalently from a time-and-attention-invested perspective as the developer who fixes it or the community manager who refines it into something that others can provide their additional reproduction steps. I would prefer to treat every contribution as highly valuable, so that we can break the cycle of "programmers are the only ones that matter" that was so toxic in open source through the 90s and 10s.

Re: 3 - This is a great idea! I'll noodle on it and consider making a patch.

[drllau]

Like you're talking about a reciprocal license for folks who contribute? I think that's a great idea, but would want to use a license

Look at thread here where I go through a few more worked contributor experiences.

I worry that this creates a "multi-tiered" approach to valuing contributions.

The nuance is that you are conflating monetary reward with psychic recognition with side dish of risk mitigation (some code in contrib might be not baked enough to be core). We probably need work-for-hire in the odd case where a commercial relationship is needed (say in a civil jurisidiction where IP laws are more murky) but I'm talking also Badges which the community (of which you are Director) aknowleges their contribution ... from code warrior to design ninja to info-architect (or more neutral names like butterfly, ant, bee and just simple +1 @zspencer which is like a clap for a very good point ... sorta done by emojis in some threads.

cycle of "programmers are the only ones that matter"

Isn't the whole point of open source is that every user is a potential programmer? We acknowledge different strengths which is why writers, artists and even line-editors are appreciated. That's why i added in line in the CONTRIBUTIONS where I think maintainers celebrate valued contributors ... perhaps a contributor of the week picking ordinary people to profile their bit to add to the long-tail, I'd especially want to document attack trees, encourage security thinking and trying things that break to get stability (Principle #1) as quickly as possible. As Director of Community wearing benevolent dictator for now hat this falls squarely in your ambit.

Can we close this and continue on issue#44 which can then be properly linked to a pull issue from the master?

[zspencer]

Re: Can we close? Yep! I think we're good. Going to close it but feel free to carry on the conversation :).

I've read the things and am going to think about them more as I work on the consumer-facing documentation.