5 strategies of contribution

Contents

• The truth before emotions
• Editing before writing, writing before discussing
• Publishing before getting feedback
• Public by default
• Publish in a central place

We are a decentralized community, no bosses, no hard-and-fast rules. We still need some rules to play by, some guidelines to become a wonderful community. Most of these guidelines have the form of "X before Y". They are written in the spirit of the Agile Manifesto and of The Zen of Python. Read them before reacting to them :)

The truth before emotions

When you read a piece of writing, focus first on truth, not on your emotions. You may hate it, but is it right? If you looked at it from an all-knowing perspective, what would you think? Once you considered it from that angle, you can inspect your emotions and find out what they want to tell you.

It doesn't matter who is right. We are building something huge together. When someone looks at Taj Mahal or the Colosseum from far away, it makes no sense to label parts of the building, "this door was designed by X, the carpenter was Y, but Z helped her with the door handles". We look at the whole building.

The usual lifecycle of a post in a chatroom is largely influenced by the emotions it induces. If it's controversial or makes readers upset, they will comment a lot on it which makes that thread live longer. At the same time, an important statement may go unnoticed, because its readers simply agree.

Editing before writing, writing before discussing

This is stating the obvious: when you face an issue, do your homework and find out if someone else has already written about it. It will save you time. Take an existing article and edit it before deciding to write your own. If you disagree with the existing article, edit it an a way that shows readers the two different points of view.

If you can't find an article to edit or for any other reason decide to write your own, write it. Don't discuss your points. You may be ignorant of some aspects of the topic, that's alright. You may be even wrong. If someone has something to add to your article, they are free to edit it. Use discussion only as a last resort when you feel completely lost.

Publishing before getting feedback

We tend to seek approval from our fellows. We're working in an unchartered territory. Approval gives us feedback and support in the face of uncertainty. We don't have a hierarchy, it's not explicit who has power over whom, so we don't have a manager to get approval from.

Don't seek approval. Publish what you have, make it accessible to everybody. Those who might have an objection will react and edit it.

This article hasn't been approved by anybody. I was afraid of publishing it without getting feedback from my peers.

Sometimes we are afraid we can't articulate an idea well enough. Sometimes we are afraid some readers would misunderstand it, become upset, and write bad things to us. Having it out in the public helps. The misunderstandable parts will be edited and improved by time.

This article is not the result of a consensus seeking process. It's not approved by stakeholders whoever they might be.

There are lots of reasons why we don't publish what we write. We are afraid it's not true to our ideas, it doesn't express an idea well enough. It may be misunderstood which could result in angry reactions. That's all true. But making a half-baked idea out in the public will help you form it.

Public by default

Privacy has many levels. If it's implicit knowledge in a group and nobody talks about it, it's private. You may have many reasons not to talk about it. It's ok the way it is; it's not important; it's obvious; it's awkward even to mention it; it seems to matter only to you. Writing it down takes you one step closer to the flow of ideas.

If you publish your writing on a forum that anybody can join, but its content is not available to visitors, it's still private. If you write a google doc that anybody can read who has the link, it's still private. You say the door is open, but most people won't even know this door exists.

Make it public to everyone by default. Get inspiration from Gitlab's Handbook to see why transparency matters. If it's a delicate case, try to be prudent. Use the Chatham House Rule.

If you decide to use some level of privacy, make it clear to the readers why it's not public and when it will be public.

And yes, there are cases that you have to keep private, like some personal, financial, and business matters. You may want to list them.

Publish in a central place

Publish it in the most central place where most users would find it. It may sound strange for a decentralized community, but it has a number of benefits. If you write for a central public place, it changes your tone. It's easier for the reader than to collect pieces of information from personal websites. It helps the network, so some nodes will emerge as central ones.