Skip to main content

Contributing and Community Dogma

caution

version: 2022.09.11

Preface

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.

Motivation

Manifold Finance (and by extension, OpenMEV) 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 subverters control the discourse. As such we must not internalize anticipatory surrender to these subverters.

Contributions come from happy users

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

Conquest’s Second Law.

  1. Everyone is conservative about what he knows best.

  2. Any organization not explicitly right-wing sooner or later becomes left-wing.

  3. 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 ](https://vogelwakefield.com/2018/12/tracking-down-conquests-law-on-organisations/)organizations

Principles

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.

Areas of Principled Discussion

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 Covenant

Our Contributor Covenant

source, Steve Francia "What every Open Source Project Needs"

Treat Contributors Well

• Happier developers will contribute more • The more welcome people feel the more they will help your project

Be Responsive

• Respond to Pull Requests in a timely manner • Provide and contribute to a channel where people can ask questions • Respond to issues quickly

Invite Contributors

• Overcommunicate that contributions are welcome • Ask people to contribute • Ask. Ask. Ask. Invite. Invite. Invite.

Pro Community

  • 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.1

  • 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

  • Pro-Professionalism. Although behavior within the OpenMEV 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.), we are 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.5

The Ethereum Ecosystem

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.

Social Rules

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 -isms6
  • Remember that everyone was new to Ethereum at some point.

The rules below are taken from the Recurse User Manual

No feigning surprise9

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's10

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 driving11

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 important, 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.

Why have social rules?

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.)

Coding Dogma

  1. Thou shalt provide attribution.

  2. Warn the users about what’s buggy and unstable in your release notes and the rest of your documentation.

  3. Document your assumptions where the user can see them.

  4. Keep a HACKING/ENGINEERING NOTES somewhere accessible.

  5. Make your build reproducible, or offer a packaged distribution of your code. Consider using nix.

  6. Have fun!

License

This document is distributed under a Creative Commons Attribution-ShareAlike license.

Citations

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