bpftrace
Add code of conduct
This is the same one used in the linux kernel. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a104f8b5867c682d994ffa7a74093c54469c11f
Checklist
- [ ] Language changes are updated in
man/adoc/bpftrace.adoc - [ ] User-visible and non-trivial changes updated in
CHANGELOG.md - [ ] The new behaviour is covered by tests
Before this gets merged we need an email accessible to all the maintainers where people can report conduct violations. Or we can just have people make sure to email all the maintainers to ensure visibilty
@ajor Fortunately this is not a problem we have yet but as we grow I think it's a good to have this as a backstop should any bad behavior or obvious COC violations occur. Is there a reason not to have it? I feel like it's fairly standard these days in many open source projects.
It is a standard practice now, and is primarily a signaling mechanism that the maintainers care about the community and will take complaints seriously. I'm not sure which formal rules are being objected to, but the contributor convenant is pretty in-objectionable as far as these things go.
Is there a specific reason "why not"? The code of conduct is best added long before any issues arise, not in response to them and does carry some amount of signaling power.
Codes of conduct are used in lots of projects, but there are also plenty of projects larger than us which don't use them. A search on Hacker News shows that codes of conduct are far from being universally accepted.
My personal objections are:
Bureaucracy
- It adds unnecessary bureaucracy, formal processes and duties for maintainers that take time away from doing real project work.
- An over-focus on bureaucracy can take away from the pleasure of writing code for fun.
- A new communication channel (email or google group) would have to be regularly checked, and I can picture it getting forgotten about if it goes unused for years.
Wording
The wording is not precise enough to be a proper set of rules, and two-thirds of the document is about enforcement. I have a few concerns about this:
- The vague wording about what's unacceptable leaves a lot open to interpretation, while still providing enough detail to point at as evidence of a rule violation. This is the kind of thing that I worry could lead to selective enforcement of the rules while giving a veneer of legitimacy. One clause I feel is unclear, for example, is: "conduct which could reasonably be considered inappropriate in a professional setting". What professional setting? In what country? There isn't a fixed worldwide "professional setting". I feel like this code of conduct was written from a corporate American point of view.
- A focus on enforcement guidelines could encourage heavy-handed enforcement of the code of conduct, where simply telling someone to be nicer would be enough. In particular, I don't like the clause setting out the possibility of forced public apologies.
Culture
This document feels like an encroachment of corporate culture into a non-corporate project. When I'm coding for free in my spare time, I don't want to deal with more rules. Simply put: I don't like being told what to do :)
In order to get behind a code of conduct, I'd like to see an argument for adopting one in bpftrace specifically. For example, what are the risks of not having a code of conduct?
- How likely is it that we will encounter some bad behaviour in this project in the next couple of years?
- What would the impact to bpftrace be if some bad behaviour were to occur and we did not have a formal code of conduct in place?
In particular, is the risk of not having a code of conduct large enough to override other concerns and be worth the time required to draft and implement it?
