Of course this does not stop people from requesting features!
By now we should think of tickets and milestones within Trac, but we do not need
a ticket for every feature. Instead, features should start out in the wiki. We need
a page, for e.g. ProposedFeatures, which would lists the proposed features along
with a summary for each and optionally have a separate page for those features
that require more detailed information or discussion. Since it is a wiki page, anyone
with access can modify this list, or features can be fleshed out in their own pages
before they are added to the list. Our development team can then review this list
when planning our next set of milestones and the features we intend to include in
each of them. As features make or miss the cut, they can be amended with links to
the relevant tickets or moved to another page e.g. PlannedFeatures. By using the
wiki and its versioning features we now have no excuse for losing sight of a feature
once it has been proposed. We should also use the same list to keep track of feature
requests that come in via tickets, perhaps using the ticket query macros as shown
in Chapter 5.
Now having decided that we are actually going to implement a particular feature
or not??”our if question??”it is time to raise a ticket.
Pages:
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104