| Re: [technology-pmc] Towards a project review checklist |
Wayne, The idea is good but the list is very, very long. Some of the items are hard to manage even for long established projects. For example: > * Articles, presentations, podcasts, webinars, etc. are being > developed and presented by non-committers. I remember that there are a few articles written by non-committers for some projects but the majority out there is written by committers or evangelists. ;) Anyway, having a checklist helps and also adds transparency to the decisions. We also have a small checklist for Planet Eclipse. What about capturing the points into a wiki page? This could be referenced by other projects as well. > * Must have a clear and concise description of the project. Get help > to determine whether or not the description is indeed clear and > concise. +1 > * 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. The reasonable appearance is a valid request. However, I would like to turn this into a more general "must be maintained and updated" requirement. Nothing is worse than a stale project page. > * Must have a link to the project info page. > * 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 we collect those into a general links section which should be part of the main project page or the menu? > * 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. +1 > * May include a list of the project committers, and mentors. +1 > * 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. +1 > 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. +1 > * Should have at least one Architecture Council mentor. Projects > that predate this requirement should find a mentor anyway. +1 > * Must have a publicly documented end-game. +1 (This sounds like a Technology project specific item.) > * Must provide timely responses to questions posed in the project > newsgroups and mailing lists. +1 > * Should blog regularly > * Should aggregate project-related blogs on Planet Eclipse and other > (possibly domain-specific) blog aggregators. +1 > * Should have code. > * Should be making regular code contributions. +1 > * 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. This is a tough one. The ideas and contributions need to fit the project goals/scope. This needs to be reviewed on a case-by-case basis. Not sure if a project will receive enough contributions before it moves out of Technology. Or do we simply count an "enhancement" request raised in Bugzilla from a non-committer that gets resolved FIXED (somehow) as an "integrated" idea? > * 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. +1 > Any thoughts/additions/subtractions? Let's put them into a Wiki page. :) -Gunnar -- Gunnar Wagenknecht gunnar@xxxxxxxxxxxxxxx http://wagenknecht.org/
Attachment:
signature.asc
Description: OpenPGP digital signature