Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009: > Requirements collected: > - Store/track > - Formal attributes: Issue type, severity, priority, category, > person assigned, progress status, incriminated version and > platform, planned milestone/released > - Informal meta: Issue details, discussion, answers, attachments > - Web-interface (at least for issue submission, searching and displaying) > - Issue submission, commenting, attachments and editing attributes by email > - Notifications by email
Nice summary. > Nicolas Pouillard, 2009-11-01 23:52: > > OK lets forget Ditz[2] as an option. > > Why? (not that i have any reason why not, i've never used diz) At least temporarily, I think it also fails at staying simple. And while it is fun to hack that's fine but then it becomes burden and code to maintain. > > Note also that I would make no objection to using a traditional bug > > tracker. > > > > It seems that we do not find a tool we really like. > > Looks like this is a issue you have discussed in depth before. Any > pointers to list archives? Not really publicly, and I'm open to seeing tools I don't know. > > A simple question I asked me was: > > "Do we really need to invent this (big) tool?" > > Well... if somebody invented it for us already. :) Yes but a big tool imply development, extensions, upgrades... > > Especially for a bug tracker we need recipes, protocols more than a > > nice interface. > > Now we are talking! ...and when trying to choose a tool, we need to > think about what we need it to do for us. I would say that we need a collection of small and clear tools. > I tried to pick the requirements you used. > > > So we need a web interface for non technical users, great. > > OK, this seems reasonable requirement. > > > What about a pre-formatted email explained on a single web-page for > > reporting bugs. > ... > > A bot will receive emails on the mailing-list and process those > > which are in the right format. > > Requirement: Bug submission by email? > I'd say we need that. Yes some people tend to really dislike web UIs, and while it is not my case I prefer to keep a "by email" option anyway. > > I think that the bot will not have a lot of information to store: > > > > (correct me if you find something else) > > > > * Issue type, severity, priority, category, person assigned, > > progress status, incriminated version and platform, planned > > milestone/released. > > > > * Issue details, discussion, answers, attachments. > > This is pretty traditional. I'd still want to challenge a bit. Why > do we need severity and priority? What would they be used for? I don't say that we need all of those, that the flexibility point. The configuration will be something like: attributes: type: [defect, enhancement, task] severity: [critical, ...] priority: [high, low, ...] category: [UI, index, ...] assigned to: [someone, someoneelse, ...] progress status: [waiting, open, started, closed] ... This can be tweaked as needed, if we need one more 'type' we add it, if we do not need severity we remove it. > > I would store and manage the first category using a simple YAML > > file. The bot acknowledges its updates by simply answering to the > > discussion. > > Requirement: Email notifications to ticket "subscribers"? > That's reasonable. I would say that the mailing-list is the only subscriber, people choose to follow the discussion or not with their email-client. This only miss the "vote for this issue" feature, which we can avoid in the mean time and delegate to a polling tool afterward. > > Those of the second category can be managed using a single email > > discussion. > > Requirement: Issue comments/attachments and status changes by email? Right. > > I don't know yet how many issues I've forgotten > > I can't figure out anything really necessary you would have missed. I got some more input via other channels about the need of an UI to search, triage, sort issues. I would say that all of this can easily be done by playing with the YAML file. The only tool I see would be one to fetch the email discussion given a Message-ID, but this is a matter of another separated tool. Thanks for your input! -- Nicolas Pouillard http://nicolaspouillard.fr _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
