This page is obsolete, please see: change-requests.

A proposal for an official CHICKEN "Change Request" process

by Felix Winkelmann

This is a proposal for having a more formal process of making changes to the core system. Through the ever-increasing number of extensions and their more and more complex interdependencies it has become quite crucial to be careful when making changes that might introduce incompatibilities to older code and extensions. Another intent is to make the process of extending and enhancing the CHICKEN core more democratic and give all members of the CHICKEN team a chance to participate in finding, discussing and deciding over core changes.

It is probably worth trying to keep this process lightweight and efficient to avoid getting bogged down in endless discussions or the uncontrolled growth of "wish-list" items that never get done. A number of ideas are given to address these problems.

The proposed steps

A change-request ("CR") is made by creating a TRAC ticket containing a detailed description of the change, if possible including a patch or implementation code. The ticket should be marked as being a CR.

The existence of the ticket is announced on the "chicken-hackers" mailing list.

The proposal is discussed, with a minimal discussion period of two weeks. If no response or feedback has been received after this period, it must be assumed nobody cares or at least nobody has a problem with the change. If necessary, the discussion period is extended, at the discretion of the person that proposed the change and depending on the amount of input that comes up or questions that this proposal raises. Since all voting members should be able to scrutinize the proposal, it may be necessary to extend the discussion period to give everybody a chance to get involved. After a fixed maximum discussion period, it must be assumed that the proposal needs more thought or modifications to be accepted. In this case the ticket should be closed and possibly reopened once it has been re-evaluated or modified. When the initial discussion period is about to pass and the CR approaches voting, a message should be sent to the "chicken-hackers" mailing list as a reminder.

All members vote on the proposal. Members that abstain from giving a vote are assumed to accept it. If at least one member votes against the proposal, the proposal is rejected. The voting period should not exceed one week. The idea behind requiring unanimosity is to avoid creeping featurism.

If rejected, the CR ticket is closed, if accepted, the change should be implemented and the ticket closed once the implementation is complete and has been integrated into the "experimental" or "master" branches of the core git repository. Whoever is responsible for integrating changes (in the moment this is me) should review the implementation for obvious bugs and merge the change.

Note: The role of the reviewer/integrator is not specified in more detail here. In the interest of consistency it might be advisable to keep the group of reviewers/integrators as small as possible.

A rejected CR may be re-discussed and voted over a second time, if the person or group of persons responsible for the CR consider it important enough to try to convince opponents of the change. If rejected a second time, the CR should be dropped completely and moved into the wiki, to allow later review and to avoid that CRs for the same thing get submitted again and again.

This process should not apply to trivial changes or obvious bug-fixes. The distinction between trivial changes and bugfixes on the one hand and critical or complex enhancements on the other hand is naturally not always easy to make. Any change that may look trivial from the outset may turn out to break a lot of stuff, so it is advisable to follow this process even for small things.

Rationale

Currently changes are made in an ad-hoc manner - some core developers (actually, me) make changes based on the personal perception of an insufficiency or worthwhile enhancement in the core system and on personal matters of taste. Since CHICKEN is the result of a combined effort of a group of people, and because it is increasingly becoming more difficult to anticipate the side effects of a change it would be more democratic and more safe to consult and involve other members of the "inner" circle of CHICKEN hackers and maintainers. Changes made by someone considered the "main" hacker may also be perceived as arbitrary, and thus lead to animosity or frustration.

Latest changes: