Difference between revisions of "Project policy"

Revision as of 18:43, 19 November 2007

This page represents an official policy of the MIT Kerberos project. Edit this page only in accordance with changes agreed by the community; other changes will be reverted.

The Project Policy describes how members of the community propose to make changes in MIT Kerberos. A project is a proposal to add new functionality or to change existing functionality in MIT Kerberos. Projects are reviewed by the community before the required changes can be integrated into MIT Kerberos. This review provides the community an opportunity to suggest improvements to the project and to confirm that the community believes that implementing the project would be a good idea.

When are projects needed?

Small changes and relatively simple bug fixes do not require a project. The project process is designed to provide sufficient community review. If a change is simple enough and uncontroversial enough then the change can be made without going through this process. If members of the development community,especially members of Krbcore, wish to review the change then it should go through a project process. If a change is committed outside of a project and objections are raised, then any member of Krbcore may revert the change until a project is approved.

The following always require the project process to be invoked:

1. Introduction of any public APIs
2. Changes in an API or the ABI. Such changes are rarely approved
3. Significant user interface changes such as the introduction of a new dialogue .
4. Introduction of configuration file variables

Proposing a Project

To propose a project, create a new page under Projects. For example a project to create a new administration protocol might be called "Projects/new administration protocol". At the beginning of that page include the following:

{{project-early}}

This will include the early project template which indicates that the project is being fleshed out by its supporters and is notyet under consideration for approval.

The project proposal page should include the following elements:

• A description of the desired change in functionality
• Any functional requirements that must be met for the project to be successful
• A design for how the desired functionality will be implemented
• A breakdown of tasks or milestones to judge progress of the project
• Screenshots or other proposed user interface descriptions
• Documentation and code for any APIs that are proposed
• Dependencies on other projects
• Information on desired integration and release goals

User Interface

It is expected that screenshots describing any proposed user interface will be included in any project that describes new interfaces. Discussion ofcustomer study groups that have evaluated the new interface or other information to validate the interface will help support the project.

Documenting proposed APIs

See Documenting APIs for current recommendations on how to document APIs that are introduced in a project.