Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[technology-pmc] Towards a project review checklist

Greetings Technology PMC,

I've been thinking a lot about the review process that we've started. Part of that thinking has been concerned with building some kind of checklist for the review. I'd like to avoid a sort of "you must do these things" list, but rather have something of a guideline for our projects to follow to make sure that they're doing the right sorts of things.

I've already captured some of this in other forums, but thought it would be a good idea to try and start capturing them more formally. Ultimately, this probably belongs on the project website.

--

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"):

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 link to the project info 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.
  • 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.
  • 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, considering using Buckminster.

Project info 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.
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.
  • Must provide timely responses to questions posed in the project newsgroups and mailing lists.
  • 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.
--

These are my initial thoughts. It's rough and I have almost certainly left out lots of stuff.

Any thoughts/additions/subtractions?

Wayne


Back to the top