source: project/wiki/change-requests @ 37557

Last change on this file since 37557 was 28630, checked in by arthurmaciel, 7 years ago

Linked "chicken-hackers" to the mailing list subscription page.

File size: 3.8 KB
Line 
1== The CHICKEN "Change Request" process
2
3This is the description of a process for making changes to the core
4system. Through the ever-increasing number of extensions and their
5more and more complex interdependencies it has become quite crucial to
6be careful when making changes that might introduce incompatibilities
7to older code and extensions. Another intent is to make the process of
8extending and enhancing the CHICKEN core more democratic and give all
9members of the CHICKEN team a chance to participate in finding,
10discussing and deciding over core changes.
11
12It is probably worth trying to keep this process lightweight and
13efficient to avoid getting bogged down in endless discussions or the
14uncontrolled growth of "wish-list" items that never get done.
15
16=== Steps that should be taken to make a Change Request
17
18A change-request ("CR") is made by creating a TRAC ticket containing a
19detailed description of the change, if possible including a patch or
20implementation code. The ticket should be marked as being a CR.
21
22The existence of the ticket is announced on the [[https://lists.nongnu.org/mailman/listinfo/chicken-hackers/|"chicken-hackers"]] mailing list.
23
24The proposal is discussed, with a minimal discussion period of two
25weeks. If no response or feedback has been received after this period,
26it must be assumed nobody cares or at least nobody has a problem with
27the change. If necessary, the discussion period is extended, at the
28discretion of the person that proposed the change and depending on the
29amount of input that comes up or questions that this proposal
30raises. Since all voting members should be able to scrutinize the
31proposal, it may be necessary to extend the discussion period to give
32everybody a chance to get involved. After a fixed maximum discussion
33period, it must be assumed that the proposal needs more thought or
34modifications to be accepted. In this case the ticket should be closed
35and possibly reopened once it has been re-evaluated or modified.  When
36the initial discussion period is about to pass and the CR approaches
37voting, a message should be sent to the [[https://lists.nongnu.org/mailman/listinfo/chicken-hackers/|"chicken-hackers"]] mailing list
38as a reminder.
39
40All members vote on the proposal. Members that abstain from giving a
41vote are assumed to accept it. If at least one member votes against
42the proposal, the proposal is rejected. The voting period should not
43exceed one week. The idea behind requiring unanimosity is to avoid
44creeping featurism.
45
46If rejected, the CR ticket is closed, if accepted, the change should
47be implemented and the ticket closed once the implementation is
48complete and has been integrated into the "experimental" or "master"
49branches of the core git repository. Whoever is responsible for
50integrating changes (in the moment this is [[/users/felix-winkelmann|Felix]]) should review the
51implementation for obvious bugs and merge the change.
52
53Note: The role of the reviewer/integrator is not specified in more
54detail here. In the interest of consistency it might be advisable to
55keep the group of reviewers/integrators as small as possible.
56
57A rejected CR may be re-discussed and voted over a second time, if the
58person or group of persons responsible for the CR consider it
59important enough to try to convince opponents of the change. If
60rejected a second time, the CR should be dropped completely and moved
61into the wiki, to allow later review and to avoid that CRs for the
62same thing get submitted again and again.
63
64This process should not apply to trivial changes or obvious bug-fixes.
65The distinction between trivial changes and bugfixes on the one hand
66and critical or complex enhancements on the other hand is naturally
67not always easy to make. Any change that may look trivial from the
68outset may turn out to break a lot of stuff, so it is advisable to
69follow this process even for small things.
Note: See TracBrowser for help on using the repository browser.