Revision as of 21:14, 25 October 2006

As the Haskell community has grown, and emphasis on development has
moved from language to libraries, the need for a more formalised process
for contributing to libraries has emerged. This page documents our
'best practices' for proposing changes to library interfaces
(e.g. new modules or functions, removing functions), especially for modules in the base package.

In essence, we don't want proposals to go unnoticed, but changes to
basic interfaces also need thorough consideration.

Under the old ad hoc system, unless a proposal meets with a chorus of
approval, the only way to get a decision is from SimonM or unilateral
action by some committer. This slowed development.

1 Submitting a proposal

In order to ensure we have something concrete to discuss, please follow
the following guidelines when creating a new proposal:

Submission. Proposed changes should be submitted to libraries@haskell.org, as a darcs patch.

Patch. The patch must compile against the head branch of the relevant library.

2 At the end of the discussion period

The proposer adds to the ticket a summary of the relevant parts of the discussion. (The summary is needed for anyone wondering about the change later: it's not reasonable to point people at a 50-message thread.)

If consensus was achieved, the change is made, with the commit message referring back to the ticket.

The ticket is closed (usually as fixed or wontfix).

A deeply held disagreement at this point may require some form of government (voting, dictatorship, etc). This should be a rare event.