Nice writeup. Just brainstorming, here are the features I personally find vital for an issue tracker that would make me happy:
1. Web submission. The burden of creating a record should be on the submitter---it's not too much to ask, and it saves developer time. This also encourages reporters to provide relevant information like version, platform, Ruby version, etc. upfront, since they can be prompted for those data explicitly. 2. Developer discussion via email. This is vital. There's no way I would want to have a technical discussion using text boxes on a website. And this discussion should be attached to the issue, of course. 3. Canonicality. I want one name for a bug, and I want one URL that I can point people to when referring to it. That URL should have the entire history, including developer discussion, of the issue. 4. Browseability. There should be some public way of getting a view of all the open issues, at a minimum. (Web seems natural.) Other stuff like sorting by priority, attachign to releases, etc. are icing on the cake, but if people are going to be chipping in on development effort, or searching to see if other people have had this bug, they have to be able to browse what's out there. > About the issues identifier I see two options, either we try to > allocate simple integers like most of the trackers or we just keep the > unique (long) identifier. I want a simple one. I can remember JIRA-style "ABC-123" names and that's really handy sometimes. Just my two cents. -- William <wmorgan-...@masanjin.net> _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
