You are looking at historical revision 20730 of this page. It may differ significantly from its current revision.

A proposal for an official CHICKEN "Change Request" process

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. If nothing happens after a week, 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 (1). 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.

All members vote on the proposal (2). 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 (3). The voting period should not exceed one week.

If rejected, the CR ticket is closed, if accepted, the change should be implemented (4) and the ticket closed once the implementation is complete and has been integrated into the "experimental" or "master" branches of the core git repository (5).

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.

This process should not apply to trivial changes or obvious bug-fixes (6).


(1) What should be the limit on the discussion period? It should also have a minimum length (1 week?) to give interested members a chance of getting involved.

(2) The definition of "member" needs more explanation. It would probably be a good idea to explicitly define a group of people that are entitled to vote on a CR. Changing the set of voters could, theoretically, be handled by this very same CR process.

(3) The idea behind this is to avoid creeping featurism. In my opinion, the unanimosity required in the old R(45)RS standardization process was a good thing. And aren't we reasonable, grown up people after all? (haha)

(4) We don't want a growing shelf of unimplementable "super" features.

(5) Is there a person who reviews and integrates this implementation? Currently, I (felix) have the role of reviewing and integrating changes to the core system. Should it stay that way? In the interest of consistency it might be advisable to keep this group of reviewers/integrators as small as possible.

(6) This distinction may not be completely trivial.


Currently changes are made in an ad-hoc manner - some core developers (actually, me (felix)) 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.

Final Note

This proposal is not intended to blindly introduce bureaucracy, but to increase consistency and care in the manner we make changes to the core system. If it turns out that we are unable to discuss modifications in a reasonable way and take discussions together as a community, then we should probably start doing something else.