An old presentation on community engagement practices, and communication in open source projects. Some of the references are a little outdated with current trends in open source (eg. github).

1. Developer
Training
Community dynamics

2. Outline
 Community communication forums
 How to ask questions that get answers
 Getting patches accepted upstream
 Gaining influence in a project & becoming a
committer/maintainer

3. Have you ever:
Asked a question on a
mailing list and not had it
answered

4. Have you ever:
Opened a bug and
wondered why no-one
comments on it for a year

5. Have you ever:
Submitted a patch, and
waited a year to have it
reviewed

8. What to do?

10. Listen for a while
Read mailing list archives
Read community news sites
Read commit logs
Track bugzilla

11. Build a relationship
Introduce yourself
Start small
Learn tone and style

12. Infrastructure

13. Mailing lists
 Archives
 Easier to handle asynchronously
 Easy off-line handling
 Email comes with return address

14. Forums
 Lower barrier to entry
 Often more focused towards newcomers
 Lower expectation that someone will read a
given message
 Requires internet access and time

15. IRC
 Real-time communication
 Often unarchived
 “If it didn't happen on the list, it didn't happen”
 Good for high-bandwidth problem-solving
 Good for wasting time
 Bad for keeping community informed

16. Bugzilla
 Bad for asking questions
 Assumption that reporter has done some work
to verify the bug
 Typically “triaged” before it gets to developer
 Valuable knowledge base
 Good to add proposed solution to bug –
developers are CCed

17. IM/Jabber
 Typically never used for project work
 Time waster/community building

18. Twitter/identi.ca/Jaiku
 Potential for broadcast w/ paid team
 Sometimes used for “workstreaming”
 Lack of archived conversation

19. Wiki
 Collaborative document editing
 Conversations happen in “talk” pages
 Discussions are expected to be short-term, will
be erased when contention is resolved

20. Source control
 ChangeLog entries/commit comments
 Valuable source of information in case of
regression bugs – and often under-used
 Not a conversation – but definitely
communication

21. Mailing list etiquette

22. You are asking lots of people for
their time

23. Ask in the right place

24. Check the FAQ

25. Show people you've tried your best
“I haven't failed, I've found 10000 ways that don't work”
Thomas Edison

26. Subject: [maemo-developers] Developing virtual keyboard plugin for Maemo 5
Hello All,
I downloaded an example virtual keyboard plugin, built it and install it on
emulator (sbox-FREMANTLE_X86).
I was able to successfully install and modify default plugin using GConf for,
/apps/osso/inputmethod/default-plugins/stylus
/apps/osso/inputmethod/default-plugins/finger
But on loading plugin, it gives error
"undefined symbol: hildon_im_ui_button_set_active"
Following documentation
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/
Generic_Platform_Components/Extending_Hildon_Input_Methods
says hildon_im_ui_button_set_* APIs are supported. But when verified in header
file hildon-im-ui.h there aren't any of the APIs starting from
hildon_im_ui_button_set_
So does it mean we cannot modify virtual keyboard plugin?
Or are these APIs moved somewhere else?
Please help..
Thanks,

27. Conventions
A: No.
Q: Should I include quotations after my reply?
Follow list norms for attachments, Reply-to, cross-posting, ...
Don't ask for private replies, or reply off-list
Let people know when the answer helped
Be patient - if you don't get an answer in a reasonable
timeframe, try rephrasing, asking if there's a better forum,
or (re)reading documentation

28. Conventions (2)
SHOUTING
Configure your email client to post plain text
There is no need to write email like SMSes or tweets

29. Reference: USENET and Mailing List
posting netiquette
http://linux.sgms-centre.com/misc/netiquette.php

30. Reference: Producing Open Source
Software: Ch. 6: Communications
http://producingoss.com/en/communications.html
Karl Fogel

31. Reference: “How to ask questions
the smart way”
http://www.catb.org/~esr/faqs/smart-questions.html
Eric S. Raymond

32. Counter-example 1

33. Subject: [MeeGo-dev] Need Help to develop New
application
Hi Friends,
I am new to Meego as well as Symbian.
I am planning to develop a Application which
can Download Video from YouTube or some other
streaming site.
My primary focus it YouTube.
Can some one help me which technology I should
Start With? I am planning to support application
on Symbian as well as Meego.
Thanks,
<new poster>

34. Counter-example 2

35. Subject: Re: [Gimp-developer] Tools
On Wed, 2007-03-14 at 12:47 -0700, XXX wrote:
> Hi
>
> I am interested in knowning if Gimp is written in
> C/C++, and which tools are needed to compile, debug,
> and test it?
What about downloading it and checking yourself?
ciao,
--mitch

36. “What we are, unapologetically, is hostile to people
who seem to be unwilling to think or to do
their own homework before asking questions“
Eric S. Raymond, Asking Smart Questions

37. Counter-example 3

38. Subject: [MeeGo-dev] please give the sollution
Dear meego-dev ,
I am trying to compile the alarmd code on arm
architecture, it is giving the following error
*make: *** No rule to make target
`/usr/include/clockd/libtime.h', needed by
`src/clockd_dbus.inc'. Stop.*
i think it is giving that clockd module not
avalaible.
When clockd module will come, please give the reply
for this.
Thanks & Regards,
Jamili Reddy.

39. Counter-example 4

40. Subject: [MeeGo-dev] I have a question why is mono
included in meego what legal status prevents its
default include in likes of Fedora.
Does Intel or Nokia have an patent agreement that
protects us downstream with the usage of mono?
What are the limits on that agreement. Is it like
Novell were we cannot legally build mono from source
and ship it and still keep the patent coverage. Heck
with the Novell agreement we have to always get the
mono binary from Novell to be legal. Also Novell
agreement expires in under 3 years time.
Please don't be we are out side the USA so we are
safe. Linux Foundation is inside the USA so has to
obey USA rules.
Really I cannot start handing meego out until I know
if I am legally safe or not...

41. Counter-example 5

42. Subject: [MeeGo-dev] 访问我的Netlog个人主页
嗨,
我创建了一个Ｎｅｔｌｏｇ个人主页，其中包括我的图片、视频、
博客和活动。非常希望邀请你成为我的朋友，一起共享我们的天地。
这需要你先在 Ｎｅｔｌｏｇ上注册哦！在登录后，
你也可以创建属于自己的个人主页了。
看一看:
http://zh.netlog.com/go/mailurl/-bT0xMTIzNDY5MjMmbD0x
JmdtPTM3JnU9JTJGZ28lMkZyZWdpc3RlciUyRmlkJTNEOTU2MzgyN
jkzJTI2aSUzRHQ5MQ__
祝好,
wangjihong

43. Counter-example 6

44. Subject: [MeeGo-dev] developer hardware mobile from nokia needed
Hello
i want a new mobile phone and did therefore a research for the
hardware and operating systems.
IPhone is too expensive and scanning all the environment for wlans.
Android it totally google tracking, but very popular at the moment
with the samsung galaxy i9000
[…]
So the community needs
a) TIME: an early involvement, so this summer
b) HARDWARE: a cheap nokia n900 for 250 euro as a developer version
with meego beta on it in August
c) COMMUNTIY: .deb as installers
d) a Qt 4.7 release with a meego compatible compiler.
[…]
and fifth, intel needs to develop an MeegoPad. So that meego on this
kind of netbook is a competitor of the Ipad.
The N8-01 - or at least the N8-00 with firmware update button, needs
to be present before chrsitmas 2010, and the same for the MeegoPad.
Sixth: The N8 needs wlan Tethering, so that the meegoPads can join the
wlan with any N8 in the room.
Is Tethering in the N8 given like in the Samsung android Galaxy i9000 ?
Any comments?

45. Counter-example 7

46. Subject: [MeeGo-dev] Difference between MeeGo and
Android?
So far, what would you say are the main difference
between MeeGo and Android?
What does it do better? And what does it do worse?
Benefits vs. shortcomings?
Just wondering what is your view is if any?
-Tim

47. Counter-example 8

48. Subject: [MeeGo-dev] How to build Meego
Hi,
I'm a newbie to Meego.
Does anyone know how to build Meego like Android did?
Steven
------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any
accompanying attachment(s) is intended only for the use of the intended
recipient and may be confidential and/or privileged of Neusoft Corporation,
its subsidiaries and/or its affiliates. If any reader of this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing,
disclosure or copying is strictly prohibited, and may be unlawful.If you have
received this communication in error,please immediately notify the sender
by return e-mail, and delete the original message and all copies from your
system. Thank you.
-----------------------------------------------------------------------------

49. Beware of cultural dissonance

51. After writing thousands of messages, you will probably find your
style tending toward the terse. This seems to be the norm in
most technical forums, and there's nothing wrong with it per se.
A degree of terseness that would be unacceptable in normal
social interactions is simply the default for free software hackers.
Karl Fogel, Producing Open Source Software

52. Break

53. Moving
upstream

54. One rule:
When in Rome...

55. Getting patches upstream
 Before you start coding
 Preparing the patch
 Submitting
 Shepherding
 Maintaining

56. Aside: Why bother?

57. 3 scenarios
 Maintain feature out-of-tree
 Submit feature months after work
 Build feature against upstream and back-port to
your tree

58. Maintain out-of-tree
 You lose all upstream development
 Substantial merge costs when upgrading

59. Submit after release
 Substantial revision may be required by
community
 Potential for conflict with other work
 Potential for feature to be rejected out-of-hand
 Continued maintenance work, potential impact
on goodwill

60. Develop upstream
 Avoid duplication of work
 Increased burden during development process
on developer → potential for schedule slip
 Requires back-porting to stable branch
 Cheapest long-term solution, but there is a
short-term cost

61. “I skate to where the puck is
going to be, not where it has been.”
Wayne Gretsky

62. Before you start
 MAINTAINERS, README, HACKING
 git log
 Mailing list archives
 Bug tracker

63. Before you start
 Propose feature on mailing list
 Design discussion in public (draft spec in wiki,
discussion on mailing list, open bug for feature
request)
 No feedback can mean:
 I'm too busy
 I don't care
 Looks good
 Not worth my time

64. Preparing your patch
 Publish git tree to allow ongoing review
 Continue to update spec, keep mailing list
copied on design discussion
 For bigger pieces of work, break into
manageable patches (make review easier)
 Ensure your patch is against the right branch to
be accepted!

65. Respect code conventions
 Indentation
 Header includes
 Use of macros/#ifdef
 Comments/inline docs
 Naming conventions

66. Preparing your patch
 Fix warnings (with -W), ensure no use of
deprecated symbols, etc.
 Test your code!
 Performance
 Memory usage
 diff -u, or git diff
 Legal review

67. Submitting
 Post patches to the right place (mailing list,
bugzilla)
 Patches in mailing lists should be plain text,
inline, unless maintainers ask otherwise
 For bug fixes, prepare a second patch for stable
branch

68. Shepherding
 Remember, no answer can mean:
 I'm too busy
 I don't care
 Looks good
 Not worth my time

69. Shepherding
 If you get feedback:
 Who is it from? Evaluate reputation
 Do you agree? If not, be prepared for technical
debate
 Revise, repost
 If you don't get feedback:
 Add comment on Bugzilla
 Contact maintainer via IRC or email
 Ping mailing list (remember: be patient)

70. Shepherding
 Different projects have different numbers of
code reviewers
 Linux Kernel = almost guaranteed swift review
 gnome-desktop/gnome-games = not so much

71. Shepherding
 Code review can be gladatorial
 Remember, code talks
 Technical criticism can seem rude. Sometimes it
is rude.
 You might receive patches at this stage

72. Shepherding
http://bugzilla.gnome.org/show_bug.cgi?id=9156
2000-12-18 Daniel Egger <egger@suse.de>
* plug-ins/ifcompose/ifscompose.c:
Added patch from David Neary to fix calulations.
Fixes bug #9156.
2000-12-18 Daniel Egger <egger@suse.de>
* plug-ins/ifcompose/ifscompose.c:
Second attempt from David Neary which should work
better.

73. Maintaining
 You still own code which is upstream
 Watch for bugs in your code – fixes will be
noticed
 Rinse, repeat

74. Becoming a committer
“I finally listened to Sebastien Bacher and applied for
GNOME commit rights yesterday, after hassling Seb once
more about committing an approved patch for me.
Surprisingly, it only took some 4 hours until my
application was approved and my account created, wow!
Apparently 71 patches are enough. :-)”
Martin Pitt
http://www.piware.de/2010/01/gnome-commit-powers/
http://live.gnome.org/NewAccounts

75. Duties of maintainer
 Decides what features & patches get committed
 Sets agenda for project
 Makes releases

76. Becoming a maintainer
 Level of bar varies from project to project
 Most active developer usually becomes
maintainer (eventually)
 As much social as it is technical
Generally the original author remains
maintainer as long as he is active
in project

77. Ways to maintainership
 Original author
 Invitation
 Volunteering
 By default

78. References
The Art of Community
Jono Bacon
Producing Open Source Software
Karl Fogel
How to Participate in the Linux
Community
Jonathan Corbet

79. Growing community

80. Infrastructure

81. Concentrate your community
Get critical mass

82. Promiscuous
Transparency

83. Champion a cause – start a movement

84. Have some fun

85. Thank you!