Dashboard > FreeMarker > Home > DevelopmentPolicy
FreeMarker Log In | Sign Up   View a printable version of the current page.
DevelopmentPolicy
Added by Dániel Dékány, last edited by Dániel Dékány on Aug 31, 2007

Here are some rules... It's not that I (Dániel Dékány) want to tell what are the rules, just now we have something to start with. Dispute and edit it if you want.

  • All changes/improvements must be discussed on the developer list (nospm-freemarker-devel@lists.sourceforge.net, remove the "nospm-") before they are implemented, except trivial bugfixes and minor documentation/site changes.
  • The project lead is the people who works the most on the project. (S)he is not officially appointed, just everybody knows who is the that nowadays. In 2002-2007 it is Jonathan Revusky.
  • Non-bugfix releases should be pre-announced a few weeks before the release, so other developers have time to criticize it. Minor maintenance releases should be pre-announced at least few days before.
  • There are no exact voting rules. Usually the project lead decides. The project lead is expected to seriously consider what other people say.
  • Releases whose 1st and 2nd version number is the same must be 100% backward compatible (well, OK, 99.999% backward compatible). 2nd version number increases should indicate serious reworkings. 1st version number changes indicate paradigm changes.
  • The project lead should maintain an internal document, that contains a who-is-who, information about leased server spaces, domain registrations, etc. All admins should have an up-to-date copy of this documentation, so it never lost. Actually, could we create a closed wiki page for this?
  • Active developers should be subscribed to the SVN mailing list, and check the commitments of other developments. More eyes catch mistakes with greater chance.
  • Don't let things run out of control, never, not even for a moment! Do not add non-trivial methods without (proper) JavaDoc. Do not add features without test-cases. Adding features or fixing bugs without updating the Manual (especially the version history) is allowed only if there is a documentation maintainer person who surely does it (like Dániel Dékány, until he opts out from this role on the devel list).
  • The project uses sourceforge.net for managing the user rights. Thus for getting any special right (SVN commit access, project admin status, etc.), the user must be registered at sourceforge.net.
  • SVN write access is granted by a project administrator to a sourceforge.net user based on subjective judgment. In general, it should be quite easy to get write access. However, the admins get mail about all SVN commits (includes the diff), so commits are still fully controlled. If the contributed code is not of proper quality, it will be rolled back, and the write access may be revoked from the committer.
  • Project administrator right is granted by a project administrator to a sourceforge.net user after discussing that on the developer list. Administrator rights should be given only to persons who are active contributors at least for, like, six months. Project administrator rights should be revoked if the persons is practically gone for a very long time (like for a year). However, it's highly undesirable for the project to have a single administrator only (as what happens if he's gone).
Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 1.4.2 Build:#214 Jun 30, 2005) - Bug/feature request - Contact Administrators