Difference between revisions of "Architecture Council/Top Ten Project Development Practices"

From Eclipsepedia

Jump to: navigation, search
(Engage your user community)
(Engage your user community)
Line 11: Line 11:
 
As outlined by the article, [http://www.agile-software-development.com/2007/02/principle-1-active-user-involvement-is.html "Active User Involvement is Imperative"], your project must actively engage your user community.  This means blogging, responding to newsgroup questions, responding to inquiries on your mailing lists.  Presenting at various eclipse related events.  Most importantly, you should respond to bugs as soon as possible.  The later is your most direct interface to your end users.  A bug report is one of your first and best interfaces with your users.  It sets the tone for how the rest of your project is viewed.
 
As outlined by the article, [http://www.agile-software-development.com/2007/02/principle-1-active-user-involvement-is.html "Active User Involvement is Imperative"], your project must actively engage your user community.  This means blogging, responding to newsgroup questions, responding to inquiries on your mailing lists.  Presenting at various eclipse related events.  Most importantly, you should respond to bugs as soon as possible.  The later is your most direct interface to your end users.  A bug report is one of your first and best interfaces with your users.  It sets the tone for how the rest of your project is viewed.
  
Release time, particularly your project's first release, is a critical time for catching wider attention for your project. You should focus heavily on preparing release-related material for the community as your release approaches. Write a [[Architecture_Council/New_and_Noteworthy | New & Noteworthy] document, write articles and blog posts, attend or present at an [[Eclipse DemoCamp]] in your area. Once the release comes out, pay attention to media response and be sure to follow up with comments on blogs to clear up inaccuracies. You should also expect an influx of bugs and newsgroup posts around this time. Prompt response to this release-related feedback is a powerful way to engage the community and draw in users, supporters, and even contributors.
+
Release time, particularly your project's first release, is a critical time for catching wider attention for your project. You should focus heavily on preparing release-related material for the community as your release approaches. Write a [[Architecture_Council/New_and_Noteworthy | New and Noteworthy] document, write articles and blog posts, attend or present at an [[Eclipse DemoCamp]] in your area. Once the release comes out, pay attention to media response and be sure to follow up with comments on blogs to clear up inaccuracies. You should also expect an influx of bugs and newsgroup posts around this time. Prompt response to this release-related feedback is a powerful way to engage the community and draw in users, supporters, and even contributors.
  
 
=Software Development=
 
=Software Development=

Revision as of 10:51, 26 May 2009

Contents

Introduction

There are many ways to develop software. There is no one right solution for every project. However, over the years, there are some principles and practices that have been found to work well for eclipse projects. Particularly these principles have been found to work well with the Eclipse Development Process. For background reading, see also these agile project management presentations.

Community Practices

The following are recommendations on how to help your project grow it's user community.

Engage your user community

As outlined by the article, "Active User Involvement is Imperative", your project must actively engage your user community. This means blogging, responding to newsgroup questions, responding to inquiries on your mailing lists. Presenting at various eclipse related events. Most importantly, you should respond to bugs as soon as possible. The later is your most direct interface to your end users. A bug report is one of your first and best interfaces with your users. It sets the tone for how the rest of your project is viewed.

Release time, particularly your project's first release, is a critical time for catching wider attention for your project. You should focus heavily on preparing release-related material for the community as your release approaches. Write a [[Architecture_Council/New_and_Noteworthy | New and Noteworthy] document, write articles and blog posts, attend or present at an Eclipse DemoCamp in your area. Once the release comes out, pay attention to media response and be sure to follow up with comments on blogs to clear up inaccuracies. You should also expect an influx of bugs and newsgroup posts around this time. Prompt response to this release-related feedback is a powerful way to engage the community and draw in users, supporters, and even contributors.

Software Development

The following are suggested practices that have been found to work well within the Eclipse Development Process, to meet the goals and criteria specified there.

Unit Test, Unit Test, Unit Test

Your project should incorporate unit testing into it's daily work flow. This means writing tests for every bug or feature. Some reasons for testing are outlined in "Agile Testing is Not for Dummies". If a test fails, it should be given the highest priority over anything else. Do not comment out failing tests, fix the test! Having a good suite of unit tests helps new committers, new contributors, and allows refactoring of the code with out changing functionality.

Tests should be automated and repeatable. They should not be environment dependent.

Continuous Integration

Synchronize with the repository daily. Eclipse projects have committers world wide, so code is always being changed. It's important to synchronize with the latest code, so that you have the same version as everyone else. This also helps eliminate failing unit tests as you catch items early instead of later.

Integrate in small steps

Integrate pieces in stages, don't make big giant change. Most processes can be broken down into smaller stages.