On Jun 27, 2018, at 8:16 AM, Richard Hipp <d...@sqlite.org> wrote:
> If I leave [a feature request ticket] open, then
> people become alarmed at all the open bugs against Fossil.

I solve that problem in my repositories by distinguishing “Bugs” from “Feature 

First, I rename the default “All Tickets” report to “Bugs,” making little to no 
change to it.

Then I create a “Wish List” report with the following SQL, which is closely 
related to the default report:

  CASE priority
       WHEN 'Immediate' THEN '#f2dcdc'
       WHEN 'High' THEN '#e8e8bd'
       WHEN 'Medium' THEN '#cfe8bd'
       WHEN 'Low' THEN '#cacae5'
       ELSE '#c8c8c8' END as 'bgcolor',
  substr(tkt_uuid,1,10) AS '#',
  datetime(tkt_mtime) AS 'mtime',
FROM ticket
WHERE (type='Feature Request' or type='Documentation') and status != 'Closed'
ORDER BY substr(bgcolor, 2) DESC

Finally, I replace the Tickets navbar link with “Bugs” and “Wish List” links, 
which each take you to the report of the same name.

Not only does this solve the expectation problem, it means we can then use the 
ticket system as a release planning tool: 

- Immediate: features for the next release.  When all such features are 
implemented, the upcoming release goes into beta (feature-complete) state.

- High: things we want to get to in the next release, or maybe the one after 

- Medium: feature ideas we like, but which we aren’t willing to commit to a 
particular release

- Low: ideas worth keeping, but which we’re not likely to ever get to.  If 
nothing else, this prevents the same ideas from being re-filed: it says, “Yes, 
someone else has had this idea already, and we’re not likely to implement it; 
patches thoughtfully considered.” 

Feature requests generally move up and down one priority level at a time, if at 
all.  Ideally, all requests would move up towards Immediate, but in reality, 
many features never make it out of Medium and almost none make it out of Low.
fossil-users mailing list

Reply via email to