Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Community Development for Eclipse Projects"

Line 1: Line 1:
There is a set of things that a project should do to at least make it easier for folks to find out about them ("don't turn away your community"):
+
Community and Eco-system development are two things that every committer should spend at least some time thinking about, and—hopefully—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.
  
 
[http://ed-merks.blogspot.com Ed Merks] provides a lot of useful information in [http://ed-merks.blogspot.com/2008/10/service-and-support-fuel-for-your.html Service and Support: The Fuel for Your Ecosystem]
 
[http://ed-merks.blogspot.com Ed Merks] provides a lot of useful information in [http://ed-merks.blogspot.com/2008/10/service-and-support-fuel-for-your.html Service and Support: The Fuel for Your Ecosystem]
  
==Project website==
+
==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.
+
* 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 info 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 </div> tags.
 
* 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 </div> 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.
 +
* Should include one or more Team Project Sets or equivalent to make it easy for interested parties to load the code into a local workspace. For more complex configurations, consider using Buckminster.
 
* Should include links to articles, blogs, newsgroups, mailing lists, bug lists, and other sources of information about the project.
 
* Should include links to articles, blogs, newsgroups, mailing lists, bug lists, and other sources of information about the project.
 
* Must provide link for help (e.g. link to a newsgroup)
 
* Must provide link for help (e.g. link to a newsgroup)
Line 12: Line 16:
 
* 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 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.
 
* May include a list of the project committers, and mentors.
 
* May include a list of the project committers, and mentors.
* Should include one or more Team Project Sets or equivalent to make it easy for interested parties to load the code into a local workspace. For more complex configurations, consider using Buckminster.
 
  
==Project info page:==
+
==Project Summary Page==
 
* Must have a clear and concise description of the project.
 
* 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.
 
* 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. It is important that questions posed in these newsgroups be answered as quickly and politely as possible. Ed Merks provides the algorithm that he uses in [http://ed-merks.blogspot.com/2008/10/service-and-support-fuel-for-your.html Service and Support: The Fuel for Your Ecosystem].
 +
 +
Adopter questions posed in developer mailing lists (and other "inappropriate" forums) 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 an answer".
 +
 +
Avoid negativity, swearing, belittling, or other disparaging behaviour in your responses.
 +
 +
The more welcome you make your community feel, the more likely it is that your project will be successful.
  
 
==Other things==
 
==Other things==
 
* Should have at least one Architecture Council mentor. Projects that predate this requirement should find a mentor anyway.
 
* Should have at least one Architecture Council mentor. Projects that predate this requirement should find a mentor anyway.
 
* Must have a publicly documented end-game.
 
* Must have a publicly documented end-game.
* Must provide timely responses to questions posed in the project newsgroups and mailing lists.
 
 
* Should blog regularly
 
* Should blog regularly
 
* Should aggregate project-related blogs on Planet Eclipse and other (possibly domain-specific) blog aggregators.
 
* Should aggregate project-related blogs on Planet Eclipse and other (possibly domain-specific) blog aggregators.
Line 31: Line 42:
  
 
==Signs of success==
 
==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.
 
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.
  

Revision as of 13:30, 30 April 2009

Community and Eco-system development are two things that every committer should spend at least some time thinking about, and—hopefully—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.

Ed Merks provides a lot of useful information in Service and Support: The Fuel for Your Ecosystem

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 </div> 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.
  • Should include one or more Team Project Sets or equivalent to make it easy for interested parties to load the code into a local workspace. For more complex configurations, consider using Buckminster.
  • Should include links to articles, blogs, newsgroups, mailing lists, bug lists, and other sources of information about the project.
  • Must provide link for help (e.g. link to a newsgroup)
  • 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.
  • May include a list of the project committers, and mentors.

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. It is important that questions posed in these newsgroups be answered as quickly and politely as possible. Ed Merks provides the algorithm that he uses in Service and Support: The Fuel for Your Ecosystem.

Adopter questions posed in developer mailing lists (and other "inappropriate" forums) 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 an answer".

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

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

Other things

  • Should have at least one Architecture Council mentor. Projects that predate this requirement should find a mentor anyway.
  • Must have a publicly documented end-game.
  • Should blog regularly
  • Should aggregate project-related blogs on Planet Eclipse and other (possibly domain-specific) blog aggregators.
  • Should have code.
  • Should be making regular code contributions.
  • 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.
  • Should be diverse. Projects should work to attract committers from the community
  • Must seek out and exploit forums (such as tradeshows, conferences, webinars, etc.) that provide opportunities to develop 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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.