Feedback is a big deal. As tech writers we want to receive adultation when the docs rock, or constructive criticism when there is cleanup required. Or EVEN BETTER, we want the engineers/community members/reddit readers/clowns giving the feedback to come on board and help fix the problems. But. Actually tweaking the signal to noise ratio to something useful is really difficult. Especially when you are curating a site as enormous as MDN, the content of which is open licensed, multilingual, and open for public editing. In this talk, MDN writer Chris Mills discusses topics such as how to choose the right feedback mechanism(s) for your situation, how to stem the torrent and get the right kind of feedback and contributions (actually useful), effective begging, stealing and borrowing, and how to balance being firm and keeping control of your product with being diplomatic and being able to sleep at night.

1. Feedback handling,
community wrangling,
panhandlin’
Chris Mills Mozilla

2. Who am I?
Tech writer at Mozilla
Writes about Web APIs on MDN
Heads up the MDN Learning Area
HTML.CSS.JS tinkerer
Accessibility whinge bag
Heavy metal drummer

4. Get the slides
http://www.slideshare.net/chrisdavidmills/
Comments to
@chrisdavidmills
cmills@mozilla.com

5. What are we talking about
here?

7. This...
Feedback mechanisms
Which ones are effective, when?
How does MDN do it?
Feedback ⇛ contributions

8. Feedback mechanisms

9. Email
https://xkcd.com/565/

10. Email pros
It’s the old school
It’s ubiquitous
You can share a lot
Easy to funnel and separate
Community involvement

11. Email cons
It’s not sexy
often slip into 1:1
It can bring you away from the
docs

12. IRC/Live chat

13. IRC/Live chat pros
Sync comms useful for
immediate help
Leads to rapid fixes
Nice to talk to real people
Strike up a relationship
Community involvement

14. IRC/Live chat cons
Can’t share things as easily
not persistent
IRC seen as archaic, or geeky
harder to filter or scale

15. Forums
http://www.wikihow.com/Laugh

16. Forum pros
Also see talk pages, discussion
pages
closer to the docs
GOOD FOR SHARING LOTS OF INFO
Lower effort than sync
easily see history

17. Forum cons
requires constant curation to
avoid rot
can turn into the docs
can be harder to search
conversations

18. Social media

19. Social media

20. Social media pros
Low effort and pressure
High coverage and engagement
great for marketing and
promotion
can be great for quickfire asks

21. Social media cons
Not so good for conversation or
contributions
harder to focus
can be low signal to noise
Can become toxic

22. Issue trackers

23. Issue tracker pros
great for sharing detail
conversations
community involvement
searching and history
information rot not as
problematic

24. Issue tracker cons
can pull you away from the
docs
can require engineering
overhead or be overkill
can be intimidating to non
techies

25. Community events

26. Comm. event pros
Great for making relationships
great for deep understanding
High quality feedback
high signal to noise

27. Comm. event cons
Costly
Time consuming
digesting all the things...

28. Automated feedback

29. Automated pros
Unintrusive, especially AB
testing
Very low to no ongoing effort
Great for collecting some
specific data

30. Automated cons
Not useful for other types of
data
initial Engineering overhead
Lack of contribution or
relationships

31. Enter MDN

32. MDN
We document the web platform
And Mozilla internals
Writing team of 6
Global volunteer community of
1000 monthly contributors

33. It’s big
Over 4.5 million readers per
month
Lots of pages
English 20,000 Japanese 6,000
French 5,000 Chinese 3,500
Polish 2,500 Spanish 2,500
russian 1,700 german 1,500

34. Some stuff works
Mailing lists
IRC
Bugzilla
AB tests, and quick fire
questions
Social media

35. Some stuff doesn’t
Comments on pages
Talk pages
Separate forums
Other separate channels, e.g.
Reddit

36. Acting on feedback

37. The Firehose
SO. MUCH. WORK.
Drowning in it
Prioritisation is important

38. Collect feedback
dev-doc-needed keyword and
doc requests on bugzilla
Other sources of feedback

39. Arranging things
Roadmap of prioritised major
tasks
Papercuts and isolated fixes,
Arranged by browser release

40. Working on things
Major tasks and browser
release fixes
Assigned to writers
Worked on during sprints
Spare time left for random
stuff that comes up
A lot of stuff in the backlog

41. Turning feedback into
contributions

42. It’s tricky
20,000 total contributors
Almost half only do one edit
630 have made more than 30
edits, or 3.5 percent
36 have made more than 500
edits, 0.2 percent

43. Still significant
75 percent of en-US pages
created by MDN staff
Most non-en-US pages created by
volunteers
Community work 3 x the amount
of work by MDN staff

44. How do we improve
contributions
It’s a Wiki - edit it yourself,
dumbass
Need to be kinder

45. How do we improve
contributions
Can’t be too pushy
Too big tasks generally don’t
work
Keep tasks granular
And make them findable, e.g.
Trello boards, bugsahoy

46. Harness passions
Some people are really into
contributing to certain things
Certain tech, learning, l10n
Harness that passion
“I need to contribute to an OS
project for my CS degree” is ok
And “I want a cool t-shirt”...

47. Mentor people
Take it slowly
Keep it realistic
Teach them the system
Don’t scare the crap out of
them

48. Keep people engaged
through comms channels
regular meetings
make them know they’re
appreciated
rewards or gaming systems

49. Look for other
contributions
Some people just do reviews
Some just fix bugs in the
platform
Some mostly just fight spam
or update structures
or spread the word

50. Finished!
Chris Mills Mozilla
cmills@mozilla.com
@chrisdavidmills