Criteria for Evaluating Proposed Changes

------ NEEDS TO BE EXPANDED/REVIEWED -----

The following criteria are used by core developers in reviewing and approving
proposed changes:

• The changes support and enhance ProjectPier aims <link>.
• The proposed changes are current.Especially for new features, priority is usually given to development for the "HEAD"/"TRUNK" (the most recent development version of the code, also referred to as the SVN version) as opposed to released versions. There may have been significant changes since the last release, so developing for the SVN version means that there will be fewer or no merge collisions.
• The proposed change doesn't raise any significant issues or risks.Specifically, issues that have been raised in the review process have been satisfactorily addressed.
• The changes are well coded. At a minimum, this means coding in accordance with the ProjectPier coding standards. But it also means that the coding is intelligent and compact. Elegant solutions will have greater support than cumbersome ones that accomplish the same result.
• There is demonstrated demand and support for the change. Demand is indicated by, e.g., comments on the projectpier.org issues system or comments in forums or the projectpier-development email list.
• The change will be used by a significant portion of the installed ProjectPier base as opposed being relevant only to a small subset of users.
• The benefits of the change justifies additional code and resource demands. Every addition to the code base increases the quantity of code that must be actively maintained (e.g., updated to reflect new design changes or documentation approaches). Also, added code increases the overall ProjectPier footprint through, e.g., added procedure calls or database queries. Benefits of a change must outweigh these costs.