A small thing, but impressive. I really like that Storify notified me when a proposed fix I had voted on was implemented.

If you haven’t seen this already… a couple of persuasive examples of the power of crowdsourcing in journalism from Guardian Special Projects Editor Paul Lewis. He talks about how Twitter and other social media helped him find witnesses to the death of newspaper seller Ian Tomlinson during riots in London and track down passengers on the aircraft Jimmy Mubenga died on while being deported from the UK to Angola – providing quite different versions of events to those given by officials.

“Some people call this citizen journalism, other people call it collaborative journalism, but really it means this: for the journalist… it means accepting that you can’t know everything and allowing other people, through technology, to be your eyes and your ears. And for people like you, for other members of the public, it can mean not just being passive consumers of news but also co-producing news. I believe this can be a really empowering process – it can enable ordinary people to hold powerful organisations to account.”

New York Times chairman Arthur Sulzberger gave a speech a few days ago at Polis LSE, which Charlie Beckett kindly posted in full. In it, Sulzberger talks about why the NY Times (which recently said it now has 325,000 digital subscribers) is engaging with its readers.

The main Facebook page of The New York Times has more than 1.7 million fans.  Our main Twitter page has more than 3.8 million followers… We have more than 15.8 million followers on Twitter for all New York Times accounts.  And here is an astounding fact – a New York Times story is tweeted every 4 seconds.

He points to three NY Times reporters doing a fine job of using social media in their reporting and relationships with their readers:

Nick Kristof — has huge, real time communities on Facebook and Twitter and he uses them to great effect in his reporting, often from some of the world’s most troubled places.

Chris Chivers – uses Tumblr and Twitter to draw back the veil on his reporting, often posting story snippits on his Tumblr blog before they appear on nytimes.com. He also asks his audience to help crowd-source a question for him, for example about ammunition he’s found in the field in war torn Afghanistan, Pakistan or Iraq.

and…

Lydia Polgreen – She has used her Facebook page to build a community of readers interested in India, where she has been a Delhi-based correspondent.  Now that she’s moving to South Africa, I can only assume she will do the same there.

And he makes the point that the NY Times audience is one that is well worth tapping into:

There is a reason why we are so committed to social media at The Times and that reason rests with our audience.  We have an incredibly enlightened, intelligent and sophisticated group of users who are highly engaged with our products.  Our efforts in social media are meant to tap in to the knowledge from that readership.  We value what they can share with us and with other users.

For this specific reason, we are currently in the midst of an expansion of our online discussion and community features at NYTimes.com and we are redesigning our comments section later this year.

We’re also in the process of creating a Trusted Commenter program, which will be available to a select group of readers with a history of high-quality comments.  Their submissions will be published on our Opinion pages and across NYTimes.com without prior modification.

Last but not least, the business case:

The business result of all of these efforts is increasing levels of engagement with our site.  This includes more time spent, more stories read, more videos viewed…and more ads viewed.

Rest of the speech is here.

Via Mashable, a graphic showing how people use social networks in various parts of the globe:

In some countries, many of them Asian, most people were focused on content sharing. Others, like the UK and Canada, had more people who put a greater emphasis on sending messages.

New Zealand appears to have fallen of the map, created by Global Web Index and based on research conducted by Trendstream. Oh well.

(Click to see Mashable’s enlarged view)

Patrick Thornton has reviewed the Washington Post’s new visual ‘WebCom’ commenting system on Poynter online.

It’s not being used site-wide, only on “Flash-based video features such as onBeing and Scene In.”

[Steven] King [the site's editor of innovations] said the site will start using WebCom on other videos later this year. There are no plans to use it for articles and other text content.

WebCom displays comments in a dynamic web instead of a traditional list. As new comments come in, the web gets bigger. The web, however, is not organized by chronology. King and his team believe that the most valuable comments are those that are rated highly by peers and those that spur responses. WebCom uses those criteria to organize the web.

The web changes as users post new comments, as discussions develop and as users vote on the quality of comments. Comments that spur responses gravitate to the center of the web. Those rated highest by fellow users appear larger, while those with low ratings appear very small. And comments that are well-liked and garner a lot of responses are both larger and closer to the center. Comments are color-coded to help returning users see what’s new.

This visual metaphor should make it easier for people to jump into developed comment threads, and King hopes that it will lead to more and better discussions.

I didn’t spend a huge amount of time checking this out – the first few video stories I looked at had few or no comments – so haven’t got a feel for how useful it is. But an interesting idea.

If you’ve ever looked at everyblock.com and wondered how they do it, wonder no more. The creators have released the source code used to develop the site. Thanks to Kirk LaPointe for the link.

EveryBlock is the brainchild of Adrian Holovaty, a journalist and programmer, and development team Paul Smith, Wilson Miner, Daniel X O’Neil, Paul Wilson and Joseph Kocherhans.

The site pulls in a variety of official data such as crime and housing statistics, business licences, library catalogues and news feeds, and displays it by location.

It came about through a $1.1m grant from the Knight Foundation, the terms of which required the source code to be made public, although I gather the development team retain rights to the name EveryBlock.

This is great news for enterprising journalists/programmers anywhere in the world who want to see how EveryBlock was done and perhaps adapt the idea for their local area.

I’m no judge of code, but it would seem that it is a fine piece of work, if these quotes included in Regina McCombs’ piece on Poynter Online are anything to go by:

As Jeremy Bowers, news technologist at the St. Petersburg (Fla.) Times explains it, the programming language is iron and lumber, the web app framework is the hammer and nails. The chance to see how the guy who built the tools used them to build an elegant house is an important one.

Ben Welsh, a database producer at the Los Angeles Times, said that was the big draw for him. “It’s a high profile site that is recognized across the board for its sophistication, and I was curious to see how that sophistication was achieved.”

“All of this code is really simple, clean, really well written,” Bowers said. We’re working on something simliar, but Adrian’s code is much better than mine.”

Regina points out that a project like EveryBlock is not for everyone.

Welsh warns that it’s not something that someone new to Django will be able to just pick up and use. “The learning curve is pretty high. It’s advanced stuff.”

“If you think you just turn it on and put some ads on it and it will make money for you, you’re high,” said Matt Waite, news technologist at the St. Pete Times. “By the same token, it’s a real gift for the people like us who do this to see how the guy who built the framework eats his own dog food.” (With a silver spoon, Bowers added.)

I met Adrian very briefly at Webstock this year, where he was a speaker (his Webstock presentation is embedded below), and asked him what would happen next, given that his team have done all this work but are bound by the terms of their funding. He said, basically, ‘good question’. They were having to think hard about where to take the project next.

But on the EveryBlock blog, he says: “We’ve put a lot of love into this project over the past two years, and we’re going to continue operating the site as a private company. Beyond continuing our steady expansion of new cities and more data types in existing cities, we have some exciting ideas planned around revolutionizing the whole EveryBlock experience itself. We’re only getting started. :-)”

Whatever the team do next, it’s bound to be interesting. As for the EveryBlock code, Regina quotes Holovaty in her final paragraph:

“That’s what Holovaty said he is hoping people recognize: “A LOT of love and hard work has gone into it over the past two years. I hope that whoever uses it appreciates it and uses it for good, not evil.”

Here’s Adrian’s presentation from Webstock this year:

Adrian Holovaty at Webstock 09 from Webstock on Vimeo.

The New York Times is asking readers to cover local body meetings as part of its The Local – Fort Greene/Clinton Hill blog initiative.





In a recent post writer Andy Green said this:

We are about to get a lot more serious here at The Local about our mission to turn all of you into community reporters. Next week, over on the right side of your screen, we will launch our Virtual Assignment Desk. Through this mechanism, you will ask us to cover things and we will do it. We will ask you to cover things on a regular basis and, we hope, you will do it. More and more important neighborhood things will get covered. The blog will grow. It will be beautiful.

Here is your first assignment: We’re looking for someone to go to the 88th Precinct Community Council meeting next Wednesday, the 10th.

It’s at 7:30 p.m. at 333 Lafayette Ave, the Pratt Towers apartment complex, in the community room. At these things, the precinct commander, Capt. Anthony Tasso, or his appointed proxy, will field questions from the audience. There are a few other presenters. It’s usually pretty interesting, or at least the good parts are. Sometimes it even gets a little heated.

We’re looking for someone to go, take notes, take a photo and write up the festivities. Get exact quotes and names of the people you’re quoting. And send the results to us by early Thursday morning. We can explain the details and give you basic training.

One to watch.

Via @shanerichmond comes another list of pointers on running good communities online.

This one’s from web developer and podcaster Paul Boag in the UK, who outlines seven ‘harsh truths’ for website owners about choosing to start a community on their site.  What follows is an excerpt.

1. Technology does not create community

Community is about people and relationships, not technology. The technology is the easy part. You can have a forum like Vanilla up and running in minutes, but it will take months of hard work to build a vibrant community.

If you implement the technology and just sit back then your community will fail.

2.  Show some commitment

Too many website owners start communities only to give up when they do not see fast results. A community can take months to get off the ground and years before it shows real returns.

It also takes ongoing input. To make your community successful it must be nurtured on a daily basis.

3.  Learn how to lead

You need to mobilise people around a common cause and stamp your personality on the community.

4. An antisocial community is your fault

As the leader of your community, your personality sets the tone. As a result if the community behaves in ways you do not want, then you only have yourself to blame.

The rest of Paul’s post fleshes out these points and talks about handling criticism, avoiding ‘marketing’ to your community and making sure your community doesn’t languish.

More about online community management, this time from Paul Graham of Hacker News, a community site for programmers hosted by YCombinator.

Paul wrote a thoughtful post after Hacker News’ second anniversary with a focus on how to keep a community healthy as it gets bigger. A small community is much easier to manage than a large one and  users’ expectations and behaviour change in step with site growth.

The post has a nice mix of background thinking and examples of things they’ve done that have worked, and things that haven’t.

On Dilution:

It’s important to remember we’re trying to solve a new problem, because that means we’re going to have to try new things, most of which probably won’t work. A couple weeks ago I tried displaying the names of users with the highest average comment scores in orange. [1] That was a mistake. Suddenly a culture that had been more or less united was divided into haves and have-nots. I didn’t realize how united the culture had been till I saw it divided. It was painful to watch. [2]

So orange usernames won’t be back. (Sorry about that.) But there will be other equally broken-seeming ideas in the future, and the ones that turn out to work will probably seem just as broken as those that don’t.

Probably the most important thing I’ve learned about dilution is that it’s measured more in behavior than users. It’s bad behavior you want to keep out more than bad people. User behavior turns out to be surprisingly malleable. If people are expected to behave well, they tend to; and vice versa.

Though of course forbidding bad behavior does tend to keep away bad people, because they feel uncomfortably constrained in a place where they have to behave well. But this way of keeping them out is gentler and probably also more effective than overt barriers.

On Submissions:

There are two major types of problems a site like Hacker News needs to avoid: bad stories and bad comments. So far the danger of bad stories seems smaller. The stories on the frontpage now are still roughly the ones that would have been there when HN started.

I once thought I’d have to weight votes to keep crap off the frontpage, but I haven’t had to yet. I wouldn’t have predicted the frontpage would hold up so well, and I’m not sure why it has. Perhaps only the more thoughtful users care enough to submit and upvote links, so the marginal cost of one random new user approaches zero. Or perhaps the frontpage protects itself, by advertising what type of submission is expected.

The most dangerous thing for the frontpage is stuff that’s too easy to upvote. If someone proves a new theorem, it takes some work by the reader to decide whether or not to upvote it. An amusing cartoon takes less. A rant with a rallying cry as the title takes zero, because people vote it up without even reading it.

Hence what I call the Fluff Principle: on a user-voted news site, the links that are easiest to judge will take over unless you take specific measures to prevent it.

Hacker News has two kinds of protections against fluff. The most common types of fluff links are banned as off-topic. Pictures of kittens, political diatribes, and so on are explicitly banned. This keeps out most fluff, but not all of it. Some links are both fluff, in the sense of being very short, and also on topic.

…I think it’s important that a site that kills submissions provide a way for users to see what got killed if they want to. That keeps editors honest, and just as importantly, makes users confident they’d know if the editors stopped being honest. HN users can do this by flipping a switch called showdead in their profile. [4]

On Comments:

Bad comments seem to be a harder problem than bad submissions. While the quality of links on the frontpage of HN hasn’t changed much, the quality of the median comment may have decreased somewhat.

There are two main kinds of badness in comments: meanness and stupidity. There is a lot of overlap between the two—mean comments are disproportionately likely also to be dumb—but the strategies for dealing with them are different. Meanness is easier to control. You can have rules saying one shouldn’t be mean, and if you enforce them it seems possible to keep a lid on meanness.

Keeping a lid on stupidity is harder, perhaps because stupidity is not so easily distinguishable. Mean people are more likely to know they’re being mean than stupid people are to know they’re being stupid.

The most dangerous form of stupid comment is not the long but mistaken argument, but the dumb joke. Long but mistaken arguments are actually quite rare. There is a strong correlation between comment quality and length; if you wanted to compare the quality of comments on community sites, average length would be a good predictor. Probably the cause is human nature rather than anything specific to comment threads. Probably it’s simply that stupidity more often takes the form of having few ideas than wrong ones.

…Bad comments are like kudzu: they take over rapidly. Comments have much more effect on new comments than submissions have on new submissions. If someone submits a lame article, the other submissions don’t all become lame. But if someone posts a stupid comment on a thread, that sets the tone for the region around it. People reply to dumb jokes with dumb jokes.

Maybe the solution is to add a delay before people can respond to a comment, and make the length of the delay inversely proportional to some prediction of its quality. Then dumb threads would grow slower. [6]

Much more to read in Paul’s post.

Here are some notes from a workshop I participated in at Webstock about managing and sustaining communities online.

I went not because I currently manage an online community but because I think communities are a big part of the future of news and of education, which are my two areas of interest, and I wanted to understand more about how communities come together, work together, stay together and play together nicely, as it were.

The one-day workshop was led by Heather Champ, community manager for Flickr, and Derek Powazek, publisher of Fray and more recently involved with MagCloud, a web-to-print publishing site I’ve been meaning to link to for a while (but that’s for another post). You can’t get much more qualified than that.

Needless to say, Heather and Derek had a wealth of experience to draw on and some excellent stories to tell. But they also brought some real warmth and enthusiasm and had clearly thought a lot about how to structure the workshop and include plenty of discussion. If you get a chance to go to a workshop with them, go.

Dean Stringer from Waikato University was also in the workshop and wrote an excellent summary.

UPDATE. Courtney Johnston at Librarytechnz has also written a great summary of the workshop that’s well worth a read.

These are heavily paraphrased notes from workshop leaders and participants and any mistakes or misrepresentations are mine alone.

1. A definition

“Web communities happen when people are given tools to use their voice in a public and immediate way, forming intimate relationships over time.” – Derek Powazek’s definition of communities written for his book, Design for Community: the art of connecting real people in virtual places.

Don’t call what you do a community. Just give people these tools and over time the people who use it will call it a community.

2. Ask yourself these questions:

Why?
Who do you think the site is for?
What is it they are going to be able to do? (individuals, collaborative, sharing information?)
Why will they want to do it? What will they get out of it?

If you can’t answer these questions, don’t build the site.

3. The paperwork

Let people see this stuff before they sign up.

Privacy Policy
Twitter privacy policy is well written and human – read it.
People pay close attention to this stuff.

Copyright/Ownership
Report and takedown process is important.  Easier you can make it, the better.
Ownership – need clear information on who owns content.

Terms of Service
Read Flickr terms of service as a starting point.

Community Guidelines
Flickr Community Guidelines a list of dos and don’ts (not just don’ts).
Members probably refer to this more than the terms of service.
Doesn’t have to be perfect at the beginning, guidelines grow as the site grows.

Managing abuse
Think about ways people might abuse your site.
Think about what you will not tolerate.
Decide what you will do if it happens. Write it down.
Be prepared, know who’s going to deal with it and how.
Need multiple people in the business who can manage this, so it doesn’t matter if you’re away.

4. Structure

User friendly is important but every community excludes someone.
Think about where to put the barrier to entry (do you want everyone posting or only highly motivated folk?).
Wisdom of Crowds. Value is in the aggregate of thoughts, guesses, estimates. Value is not identifying the smart individuals to listen to but averaging out the voice.
Give people small, simple tasks. If not getting feedback you hope for, ask for something smaller.
Give them to a large, diverse group.
Design for selfishness. Flickr tags are selfish (I want to find image later) but selfishness of tags becomes usfeul to all. What are selfish reasons for someone to participate? If you can’t name one, you have a problem.
Aggregate the answers. Be aware of:

Popular tags – a behemoth, doesn’t move, hard to use.
Hot tags add dimension of time.
Have to continuously change algorithms. If creating leaderboard, say, some people will game it.
Scores create games. First post – game in which you win by being a dork and writing ‘first post’ – adds nothing.
How do you observe without changing the outcome? Don’t show tally during vote, don’t show outcome of poll until vote is cast.
Randomness – instead of a top 10 list, take a top 20 per cent and show nine randomly.

It’s okay to build in an editorial, human step at the end. Even if you can figure out algorithm and game it, you can’t game the editor.

5. Keeping things ticking over

Eventually you will need a community manager.
Manager = shepherd, editor, cheerleader, advocate, judge, executioner.
You only hear from unhappy people. Be prepared to deal with that.
Best place to look for a manager is in your own community.
Learn when to respond, don’t have to respond to everything.
Have to set tone in the beginning then members start to take on roles, become champions, start moderating.
Don’t keep all moderation tools at top level, have tools for members eg flag this photo, ability to block people, report abuse (simple process).

Reward good behaviour
Use blog to turn spotlight on good behaviour, content.
Behaviour speaks louder than pages of rules.
Your ambassadors can help hugely in forums.

Transparency
Tell people what’s going on, keep it updated.
Own it when you’re wrong: ‘Sometimes we suck’.
Don’t wait. If going to introduce change, explain it, give people time to learn about it, give them an option to pull out, then make the change.

6. Trolls

Identifying Trolls
Repeated disruptions, steering conversation, server logs
They’re not the freakout comment, but the one before it. They goad.
Sometimes people use two identities to fight with themselves – can see it’s the same IP address. Puppet accounts.
Sometimes they do it to back up the first comment.  “You may not create puppet accounts and talk to yourself”.

Stopping Trolls
Silent treatment. Set it so only the troll can see their posts.
Disable puppets.
Timeouts. Slow down server response time – takes ages to log in, they need instant gratification.

7. Final nugget of wisdom

Observe the ‘ask for forgiveness rule’: act first, then tell the boss.