| title | description | version | authors |
|---|---|---|---|
Contributing and Community Dogma |
Contributing and Community Dogma and Social Rules |
2023.09.27 |
Manifold Finance Community |
:::caution
version: 2023.09.27
:::
This document is largely taken from/inspired by John A. De Goes. More specifically, the articles, "ZIO Professionalism", "Big Tent", and "Travis Brown, Abuser". Without his insight, this guideline would not be where it is today.
These rules extend to mevETH insofar as Manifold Finance is involved with the protocol's operation.
Manifold Finance (and by extension, OpenMEV and mevETH) supports the right of every OSS engineer/developer to contribute on their terms, whatever those terms may be. Non-paying users of free software should not get to dictate these terms.
Moreover, OpenMEV's stated objective of being a credible neutral org means that we must explicitly codify and formalize our ideals so that as it 'expands', there is a codified expectation of behavior from all contributors. See 'Conquest's Second Law'
There is an ongoing effort to corrupt effort the fundamental premises of the open-source culture. Instead of meritocracy and "show me the code"; we are now urged to behave so that no one will ever feel uncomfortable.
The effect – the intended effect – is to diminish the prestige and autonomy of people who do the work – write the code – in favor of self-appointed tone-policers. In the process, the freedom to speak necessary truths, even when how they are expressed is unpleasant, is being gradually strangled.
This is undesirable as it both directly damages our self-correction process – and in its second-order effects. The habit of institutional tone policing, even when well-intentioned, too easily slides into the active censorship of disfavored views. --The Right to be Rude
The cost of a culture in which avoiding offense trumps the liberty to speak is that subverts control the discourse. As such, we must not internalize anticipatory surrender to these subversives.
As the title says, contributions to projects come from happy users. Successful Open Source Projects need to communicate and help with communication to their ecosystems.
:::info
What is Communication • What you say • What you write • What you do • What you build
:::
-
Everyone is conservative about what they know best.
-
Any organization that is not explicitly right-wing eventually becomes left-wing.
-
The simplest way to explain the behavior of any bureaucratic organization is to assume that it is controlled by a cabal of its enemies.
We can take this 'Second Law' in the contrapositive argument to mean:
Any organization that does not wish to end up left-wing must become explicitly and constitutionally right-wing.
Which we can reduce to the following principle:
Any organization that does not wish to end up corrupted by ideological malcontents must explicitly codify and aggressively enforce its ideals.
Any organization that does not wish to end up corrupted by ideological malcontents must explicitly codify and aggressively enforce its ideals. As an organization grows and becomes more complex, it ends up acting primarily to ensure its perpetuation. The purpose for which it was founded becomes secondary to its survival. In fact, for many in the organization, possibly the vast majority, its continued survival becomes confused with the purpose it was originally founded to deliver. This can lead to behaviors that seem rational when viewed from the perspective of perpetuating the organization but look counter-intuitive when considered from the perspective of what the organization ostensibly exists to do. [^3, Tracking down conquests' law on organizations](https://vogelwakefield.com/2018/12/tracking-down-conquests-law-on-organisations/)
:::info
An example is when DerbyCon shutdown citing the increasing difficulty of holding conferences in the face of "a small, yet vocal group of people creating negativity, polarization, and disruption.1
:::
We must recognize that the actions of other organizations, protocols, etc. may have undesirable side effects on the OpenMEV community (and Ethereum at large):
- They undermine the trust that end-users and companies place in Ethereum
- They increase the risk involved in deploying solutions based on Ethereum
- They decrease the network value of Ethereum
- They make OpenMEV look unprofessional to many developers, especially compared to the Ethereum/other ecosystems, where major OSS projects would never behave in such a fashion.
Both contributors and users will have questions, • Need to establish a place for them to ask questions • Public is ideal:
- Others can respond
- Others benefit from the response
forums.manifoldfinance.com and the ethereum-magicians boards are considered the 'public forum ideals'. Ethereum R&D Discord, offical GitHub repo's are as well. If you think another venue should be added please submit a pull request to add it here.
Our Contributor Covenant
source, Steve Francia "What every Open Source Project Needs"
• Happier developers will contribute more • The more welcome people feel the more they will help your project
• Respond to Pull Requests in a timely manner • Provide and contribute to a channel where people can ask questions • Respond to issues quickly
• Overcommunicate that contributions are welcome • Ask people to contribute • Ask. Ask. Ask. Invite. Invite. Invite.
-
Pro-Community. All OpenMEV projects will gladly accept and host integrations for Flashbots, Eden Network, and other MEV or EVM ecosystems, without consideration of the relationships, dispositions, or politics between these projects and those ecosystems, and they will provide non-discriminatory support for end-users, regardless of their disposition to or affiliation or association with other OpenMEV community members or ecosystems.2
-
pro-community, as OpenMEV hosts integrations for Sushiswap projects swaps and bentobox, and hosts integrations for OlympusDAO,LayerZero to date. Conflicting incentives should be considered and debated if it is possible that adding support for another project would conflict with existing integrations. However, I believe that making this behavior official will further increase trust and expand integrations, and also clearly set expectations for new projects being integrated into the OpenMEV solution sets.
-
Pro-Professionalism. Although behavior within the OpenMEV and mevETH organization projects is already governed by the OpenMEV Code of Conduct, I want to strengthen this code of conduct by making it clear that ad hominem and career sabotage have no place within the community. Projects in the OpenMEV organization exist only to help engineers and developers solve problems, regardless of their religion, political affiliation, race, or disposition to or affiliation or association with other OpenMEV community members or ecosystems.
-
pro-professionalism, within OpenMEV official spaces (GitHub, Discourse, etc.), I have only ever seen welcoming, inclusive, and non-discriminatory behavior, without ad hominem or career sabotage. But explicitly committing to this high standard of professionalism can only help to set expectations and provide guidance for everyone as the organization continues to grow.3
It is not necessary that open source contributors have the same views or even like each other. We must put Ethereum first, and by being pro-community and pro-professionalism, we can find a way to co-exist peacefully inside this big tent, and together, we can, in different ways and with different audiences, show the world that Ethereum is a force to reckon with.
Most projects have very few contributors, so in order to help facilitate getting contributors, we enforce these social rules. These rules are from Recurse. The Recurse Center is an educational retreat for programmers who want to become dramatically better with a community of peers doing the same You must give if you want to get • Contributors are an investment in the future of the project • Contributors pay back many times what you put in. Make it easy to Contribute.
These rules are adopted from recurse.com/manual#sec-environment
- No well-actually's
- No feigning surprise
- No back-seat driving
- No subtle -isms4
- Remember that everyone was new to Ethereum at some point.
The rules below are taken from the Recurse User Manual
No feigning surprise5
The first rule means you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! I can't believe you don't know what the stack is!") and non-technical things ("You don't know who RMS is?!"). Feigning surprise has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's almost always the effect. As you've probably already guessed, this rule is tightly coupled to our belief in the importance of people feeling comfortable saying "I don't know" and "I don't understand."
No well-actually's6
A well-actually happens when someone says something that's almost - but not entirely - correct, and you say, "well, actually…" and then give a minor correction. This is especially annoying when the correction has no bearing on the actual conversation. This doesn't mean we are not about truth-seeking or that we don't care about being precise. Almost all well-actually's in our experience are about grandstanding, not truth-seeking. Moreover it points to a need for attention seeking, which is not a healthy behavior in general.
No back-seat driving7
If you overhear people working through a problem, you shouldn't intermittently lob advice in chat, on issues, etc. This can lead to the "too many cooks" problem, but more importantly, it can be rude and disruptive to half-participate in a conversation. This isn't to say you shouldn't help, offer advice, or join conversations. On the contrary, we encourage all those things. Rather, it just means that when you want to help out or work with others, you should fully engage and not just butt in sporadically.
These rules are designed to help all of us build a pleasant, productive, and robust community. Part of being a credible, neutral environment is having a baseline of interactions so that the environment does not introduce undesirable effects (social, political, drama, etc.)
-
Thou shalt provide attribution.
-
Warn the users about what’s buggy and unstable in your release notes and the rest of your documentation.
-
Document your assumptions where the user can see them.
-
Keep a
HACKING/ENGINEERING NOTESsomewhere accessible. -
Make your build reproducible, or offer a packaged distribution of your code. Consider using nix.
-
Have fun!
In general, we should handle disputes and violations of community guidelines quietly. We must maintain our reputability on this point by enforcing the guidelines and moderation policies appropriately.
However, occasionally, these events will spill out into public. In those cases, please let the npm executive team decide how best to communicate with the public.
Demonstrate that the Community Guidelines and moderation policy is being enforced fairly.
- Explain (briefly, neutrally, anonymously) what violation led to the enforcement action.
- Help the community understand that they are not in danger of being attacked by capricious, punitive or irrational administrative actions.
- When necessary, communicate via the official forums and/or changelog/devlog.
When it's necessary to communicate enforcement of our policy, a brief public statement such as this would suffice:8
"[xThing] happened. This was a violation of our policy. We have taken [yAction]. This is a good time for [people] to review our policy at [location]. If anyone would like to discuss this further they can [contact us somehow]."
People may be upset and wish to express their concerns to npm staff. We should be in "making the person feel heard" mode; it's important not to cross into "education mode". Hear them out, take notes as appropriate, thank them for their thoughts.
We should not share additional details of the incident with uninvolved parties.
If a user is upset and a staff member agrees that a wrong was done to them, it helps a lot to just say simply "I'm so sorry." (Rather than "but we tried really hard" or "no one told us" or etc., even if that was true. "I'm so sorry" goes a long way to defusing many people's anger.)
Whether or not a staffer agrees that a wrong was done to them, the user should be armed with an authority they can appeal to if talking wasn't enough. "Please open an abuse support ticket at https://forums.manifoldfinance.com"
Do not ask for an apology to the victim. We have no responsibility to enforce friendship, reconciliation, or anything beyond lack of harassment between any two given users, and in fact doing so can contribute to someone's lack of safety while using our service.
Forcing a victim of harassment to acknowledge an apology from their harasser forces further contact with their harasser. It also creates a social expectation that they will accept the apology, forgive their harasser, and return their social connection to its previous status. A person who has been harassed will often prefer to ignore or avoid their harasser entirely. Bringing them together with a third party mediator and other attempts to "repair" the situation which require further interaction between them should likewise be avoided.
If the harasser offers to apologize to the victim (especially in person), strongly discourage it. In fact, discourage any further interaction with the offended party.
If a community member relays an apology to the victim, it should be brief and not require a response. ("X apologizes and agrees to have no further contact with you" is brief. "X is very sorry that their attempts to woo you were not received in the manner that was intended and will try to do better next time, they're really sorry and hope that you can find it in your heart to forgive them" is emphatically not.)
If the harasser attempts to press an apology on someone who would clearly prefer to avoid them, or attempts to recruit others to relay messages on their behalf, this may constitute continued harassment.
This document is distributed under a Creative Commons Attribution-ShareAlike license.
Source for the Dogma: kb/community/guidelines
Citations and Attributions
The Scala Community, https://scala-lang.org/conduct/; 2022 June 10
The ZIO Community, https://github.com/zio; 2022 June 10
The Rust Code of Conduct, https://www.rust-lang.org/policies/code-of-conduct 2022 June 10
The Node.js Policy on Trolling, https://blog.izs.me/post/30036893703/policy-on-trolling
"ZIO Professionalism", 2022 June 10
"Big Tent". 2022 June 10
"Travis Brown, Abuser". 2022 June 10
"The Right to be Rude", 2022 July 01
"Tracking down Conquest’s law on organisations", Martin Vogel, 2022 July 01
DerbyCon2019 - Every Beginning has an End, DerbyCon Team.
Footnotes
-
See https://blog.brixit.nl/why-i-left-pine64/ for an example of when a large ecosystem (Pine64) stops supporting multiple integrations in favor of one for the deleterious effects of mono-culture. Additionally we can substantiate this negative community effect by other blog posts made by different community members, such as "Pine64's weird Priorities", and "Pine has let its community down" ↩
-
See this issue thread on the golang issues page for exactly how not to act. A positive example shown by a moderator, though YMMV. ↩
-
https://www.recurse.com/manual#:~:text=No%20feigning%20surprise ↩
-
https://www.recurse.com/manual#:~:text=I%20don%27t%20understand.%22-,No%20well%2Dactually%27s,-A%20well%2Dactually ↩
-
https://www.recurse.com/manual#:~:text=No%20back%2Dseat%20driving ↩
-
And then move on with the program. Do not revisit the issue. ↩