View source for Community Development for Eclipse Projects

Community and Eco-system development are two things that every committer should spend at least some time thinking about, and&mdash;hopefully&mdash;some time doing something about. Ultimately, it is difficult to call your project a success without these things. It is from the community and eco-system that you will draw additional contributions and other helpful input to make your open source project a success.

This page is intended to provide some helpful advice for attracting and retaining a community.

==Transparency==
It's great when colleagues get together to discuss their plans for a project. In order to help your community know what's happening in the project and feel like they can be part of it, those back channel conversations need to be captured. Consider summarizing conversations in the project mailing list, on the project website, or in a bugzilla record. Bugzilla is particularly good for capturing these conversations as it facilitates follow-up conversation, and&mdash;since these conversations very often translate into features or fixes for the project&mdash;is probably the ultimate home for the results of the conversation.

== Project Website  ==

*Must have a clear and concise description of the project. Get help to determine whether or not the description is indeed clear and concise. ''The description on your website should be the same as the description on the project summary page.'' 
*Must have a link to the Project Summary page. 
*Must have a reasonable appearance. Make sure the page is rendering properly in (minimally) Firefox and IE. Make sure that the page, for example, isn't missing &lt;/div&gt; tags. 
*Must provide a "Getting Started" section with information to help adopters obtain and use the project output, and help developers obtain the code and configure their workspace (The [http://www.eclipse.org/egit EGit] project's [[EGit/Contributor_Guide|Contributor Guide]] is an excellent example). 
**Should include one or more [http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.user/tasks/tasks-cvs-project-set.htm Team Project Sets] or equivalent to make it easy for interested parties to load the code into a local workspace.
*Must provide link for help (e.g. link to a forum/newsgroup)
*Should include links to articles, blogs, newsgroups, mailing lists, bug lists, and other sources of information about the project. 
*Should include a link to the project proposal, plan, IP log, etc. 
*Should include a short presentation that describes the project in a "source" format (i.e. a PPT or ODP file) in addition to a portable format such as PDF. 
*Should include information on how to commit to the project and how to become a project committer. At a minimum, it should contain a link to the Eclipse Development Process document's section on [http://www.eclipse.org/projects/dev_process/development_process.php#4_7_Committers_and_Contributors Contributors and Committers].
*May include a list of important people (e.g. committers and contributers).

==Project Summary Page==
* Must have a clear and concise description of the project.
* Must contain as much information as possible about the project. Fill in as much detail as possible on the portal so that an interested party can find newsgroups, mailing lists, project plans, IP logs, etc.

==Newsgroups, Mailing lists, Outreaching Forums==
It is through newsgroups that adopters tend communicate with a project. Very often, it is the only real support channel provided for those adopters. Each project should have at least one committer monitor [news://news.eclipse.org/eclipse.newcomer eclipse.newcomer] to catch questions posed there and further extend the awareness of the project.

When your community asks questions, answer them as soon as possible. No question should go unanswered. Encourage all of the project committers to monitor the newsgroup, or&mdash;at very least&mdash;take turns. Of course all that support is a lot of work, and some people find it difficult to spend all that time on "menial" activities. Too bad for their misguided thinking, because it's a key to success. Don't leave your community out in the cold.

Here's a simple process you can follow for effectively and quickly dealing with your newsgroups (thanks to Ed Merks):

* Take a glance to see if someone else with appropriate skills is needed for the topic.
* If not, hit reply.
* Type in the person's name at the top to make it personal; try not to misspell, because it's rude.
* Type in "Comments below."
* Start reading and whenever a thought jumps to mind, type it in right then and there.
* Upon getting to the end, hope the question has been answered.
* If not, ask lots of questions so the person asking the questions has to answer yours instead.
* Rinse, lather, repeat.
* Avoid infinite loops.

When sensible, incorporate the answers into the FAQ or some type of wiki recipe. Repeat this process for as many newsgroups as possible (especially eclipse.newcomer), because Eclipse's overall success will be reflected in your personal success. Your dedication to high-quality service and support is the fuel for your ecosystem and the success of that ecosystem is the most effective way to achieve maximum influence with your limited individual capacity. 

Adopter questions posed in developer mailing lists (and other "inappropriate" forums such as personal e-mail) should be answered politely. It is reasonable to recommend that the question (or future questions) be posed in the newsgroup where it can be "viewed by a larger audience as is more likely to receive a timely answer".

Avoid negativity, swearing, belittling, or other disparaging behaviour in your responses.

All of the answers don't need to necessarily come from project committers: empower your community to answer questions in the newsgroup. When community members do provide answers that require further clarification (either they are not complete, or are not 100% correct), do so politely. 

The more welcome you make your community feel, the more likely it is that your project will be successful.

==Bugzilla==
When your community reports a problem, fix it as soon as possible. Be sure to make a distinction between wish list items (I want more goodness) and actual defects (it's broken because it's not working the way it was designed to work). A list of 1000 bugzillas that looks to the community like a list of 1000 defects rather than like a list of 1000 wishes is bad publicity. Having no responses in most of those reports, is also bad news. Your community will interpret it as a lack of respect, and no pleas about your lack of resource will help offset that negative perception.

Every commit in your project's source code repository should have a corresponding Bugzilla record. Provide linkage to the record in the commit comment so that somebody browsing the history of your code can follow the links to find any discussion, or other useful information related to that commit. Consider including bug numbers directly in comments in the source code when the discussion contained in that bug is particularly useful. This will help your community and committers better understand why your code is implemented the way it is and give them a pre-existing place (i.e. the bug) to pose further questions.

==Other things==

* Project plan must be in the standard format, and must include future milestones.
* Must have a publicly documented end-game.
* Must be inclusive and responsive to community feedback. Input and patches contributed by the community should be given due consideration; ideas from the community should be integrated into the project.
* Must seek out and exploit forums (such as tradeshows, conferences, webinars, etc.) that provide opportunities to develop community.

* Should have at least one Architecture Council mentor. Projects that predate this requirement should find a mentor anyway.
* Should blog regularly.  Committers can create their own blog (or a shared blog) the [http://blogs.eclipse.org/ Eclipse Blogs] site with their Bugzilla account, and ask it be part of [http://planeteclipse.org/ PlanetEclipse].
* Should aggregate project-related blogs on Planet Eclipse and other (possibly domain-specific) blog aggregators.
* Should have code.
* Should be making regular code contributions.
* Should be diverse. Projects should work to attract committers from the community

==Signs of success==
Ultimately, everything above is about making it possible for a community to find out about your project and provide opportunity to get involved. Providing that opportunity is one thing, actually attracting a community is another.

You are successful if (not an exclusive list):
* A significant number of bugs raised against your project come from non-committers.
* Non-committers are blogging about your project.
* Articles, presentations, podcasts, webinars, etc. are being developed and presented by non-committers.
* You cease to be the center of the universe for your project.

==Credit Where Credit is Due==
Be sure to give appropriate credit to your contributors.

Some of the content, specifically parts of the "Newsgroups" and "Bugzilla" sections where harvested from an excellent blog posting [http://ed-merks.blogspot.com/2008/10/service-and-support-fuel-for-your.html Service and Support: The Fuel for Your Ecosystem] by [http://ed-merks.blogspot.com Ed Merks].

[[Category:Architecture Council]]