Help Create an Email Charter! – TEDChris: The untweetable:
It is in fact a potent ‘tragedy of the commons’. The commons in question here is the world’s pool of attention. Email makes it just a little too easy to grab a piece of that attention. The unintended consequence of all those little acts of grabbing is a giant rats nest of voracious demands on our time, energy and sanity. To fix a ‘commons’ problem, a community needs to come together and agree new rules. That’s why it’s time for an Email Charter. One that can reverse the escalating spiral of obligation and stress. I have reserved the url emailcharter.org for the finished product.. But first let’s figure out what the charter should be. Let’s do this as a crowd. It’s a shared problem. Let’s come up with a shared solution. It will only work if lots of people agree to it. The Charter must focus on reversing the underlying cause. We need a world where it is much quicker to process email than to create it. Bearing that in mind. Here are some candidate rules for an Email Charter. (And btw, much of this applies equally to other online messaging, such as Facebook.)
Chris Anderson makes a call that we need an Email Charter. I felt a disturbance in the Force. I had to reply. So I am, in two parts.
The concept of an email charter is an honorable goal.
The reality of an email charter is that it will fail.
The practicality of an email charter is that you shouldn’t let that failure stop you.
Let me explain.
This concept is not new. It has been tried before (but if you need 26 rules to get the point across, it is too complex). Books have been written about it.
Back in 1983 I authored A Primer on How to Work With the Usenet Community, which we would now recognize as a crowdsourced document, but the word crowdsource wouldn’t be invented for another 20 years; it did, however, coin the term Netiquette, which ultimately made it into the dictionary (yay us). It’s been translated into 30-some languages (that I know of), it’s been referenced in thousands of other documents over the years, and it’s influenced countless people’s behavior over the 20-oh-do-I-feel-old-plus* years it’s been in existance.
Just look at USENET today, and see how well we succeeded at managing that commons.
So before you even start a project like this, realize that IT WILL FAIL. You are creating a document with a voluntary set of ruiles (sorry, guidelines**) and asking people to follow them. Doing so will fail if only because there is always going to be an influx of new, naive users who don’t know the guidelines exist and therefore can’t follow them. There will also always be people who don’t want to, don’t agree with them, don’t care what you think, or simply feel like being contrary. And the griefers and trolls who get off on screwing up stuff other people value. And the spammers who only see a free resource they can suck dry for their own personal benefit and profit.
And I am recommending that you accept this failure, embrace it and recognize it. And that you don’t let it stop you from pushing this to fruition.
Because if history is our guide, what you will see are the failures. What you must understand is that behind the failures, if you do this well, is an army of successes that don’t get noticed because, well, they aren’t failures. It took me a long time to really see that. A good document that institutionalizes best practices succeeds quietly — it influences people designing systems, it influences influencers and teachers. It gives a context for creation of teaching and training materials. People crib from it and use it in other documents, and spread it around. Users see it and learn from it and adopt it. Programmers innoculate it’s standards into the tools we end up using. And you’ll see almost none of that; and if you don’t understand that, eventually the weight of watching the failures may cause you to feel like the project failed, when in fact, it succeeded, but just not with a 100% perfect success.
So do it. Because if you do it well, it will help, and potentially help a lot. But understand from the very start that it won’t solve all of your problems or get 100% adoption, so it’s not a complete success. And if there’s something to be learned from the horrors that USENET became, it’s that asking nicely ultimately fails, because no matter how many people agree and abide, the ones that don’t will ultimately overrun the commons and destroy it.
But if your real goal is to prevent the tragedy of the commons in email that we saw in USENET, this is a useful tool, but it won’t be enough. We need to do more, because asking won’t succeed. What is going to be needed?
I have some ideas, and I’ll talk about them in Part 2.
* — you do not need to remind me that this document is older than most people reading this blog posting. Honest.
** — Sorry, usenet cabal in joke. wanna see the scars?
*** — Just checking to see if you realize I only have two footnotes…
(Hat tip: Duncan for finding this gem)


Pingback: Avoiding email bankruptcy (part 1) – Chuqui 3.0
Pingback: Email Charters & Lists as Parties | michael-mccracken.net
Pingback: Help Create an Email Charter (part 2) – Chuqui 3.0