[Wikimedia-l] Editor retention implies social features

Nathan nawrich at gmail.com
Tue Apr 17 21:10:59 UTC 2012


Let's separate the two big issues here - the first is whether we want to
encourage large numbers of new editors, and the second issue encompasses
all the cool feature ideas we could add to accomplish the first.

On attracting new editors and improving editor retention - editor retention
explains itself, of course, and I think many people agree that improving
the "social fabric" of project communities (and specifically en.wp)
contributes to better retention metrics. There is some disagreement over
the value of large numbers of new contributors. Many people in the en.wp
community want to make contributions from these folks, especially
"anonymous" editors without a registered account, more difficult rather
than easier...

The position of the WMF has lately been that this is misguided; in fact a
large proportion of content, even the majority, has been added and improved
by anonymous IP contributors. While individual editors devoting hundreds or
thousands of hours to Wikimedia are highly valuable, the subset of
contributors who are anonymous are so vital to project success that we
should absolutely focus on increasing their numbers and encouraging them to
return often.

On cool features, we could brainstorm all day on different things that
would be great to have. I'm sure everyone has a list of things they'd like
to see, and most probably can think of much better features than I can.
Here's my quick list:

1) Internal messaging - using "e-mail this user" is cumbersome, especially
if you don't want to reveal your e-mail address, and divorces communication
from the project itself. It also doesn't lend itself well to communicating
with more than one individual. There is a place for non-public
communication in our projects, and we should improve that communication by
adding internal tools.

2) Discussion and comment threading. Not sure whatever happened to
LiquidThreads, but the ten year old method of discussing article content is
antiquated and far behind the current standard. You get better discussion
on Gawker. Why, for instance, is the newest content still added at the
bottom of every page instead of the top? Makes no sense.

3) Notifications and other quick, public communication. Warnings, bot
notices, system messages, hat tips, barnstars, and quick notes should all
be integrated as notification types in an internal notification system.
There might be ease of access issues,  but since these are focused on
editors and not readers I think those hurdles can be overcome. Talk pages
are as antiquated as the article discussion pages, and there are far better
ways of organizing message content.

4) Article feedback. Our article feedback progress is just getting started,
but it has a long way to go. I'd like to see a sidebar or footer that tells
me how many people approve or disprove of the article content, aged for
relevance to the current revision. Readers (logged in editors or otherwise)
should be able to add Tweet-length comments, which can be +'d or -'d by
others so a reader can get an 'at-a-glance' sense of what other readers
think about an article and why.

5) 'Request an article' - it should be a feature of MediaWiki to track what
article titles for pages that don't exist get the most hits, and it would
be a really cool scrollbox to show readers and editors "500 editors looked
for 'page XYZ' today and didn't find it - create this page now!" We might
have to curate it like TfA, but maybe not, and I guarantee you'd get an
article in OK shape for each featured redlink.


More information about the Wikimedia-l mailing list