Re: [Warzone-dev] Making trac friendlier?
On Sat, Aug 22, 2009 at 8:50 AM, Christian Ohmchr@gmx.net wrote: And if View Tickets brought up the list of open tickets, newest first instead of the current list of mostly useless reports, it might actually be useful. Is there a way to modify this report list? It always just distracted me with its pretence of usefulness, and I made a custom bookmark to get a simple bug list without being bothered by it. Well, Timeline is a mostly useful list of the latest tickets, and it's only one click. That's what I use a lot of the time. :P Otherwise, I generally do View Tickets, click the first report, and click ticket number twice (to sort descending). So it's not _completely_ useless. Oh, and to go completely off-topic, our wiki is currently listed under development, but also contains user stuff. It would be very nice to have the user side more visible, maybe then people read it and start adding info to it. We have user stuff in the wiki? Any user stuff that's in the wiki should also be in the Guide... -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
Am Samstag, 22. August 2009 14:50:46 schrieb Christian Ohm: On Friday, 21 August 2009 at 23:11, Zarel wrote: On Fri, Aug 21, 2009 at 9:16 PM, Stephen Swaney sswa...@centurytel.net wrote: Right now, we overload 'enhancement' to mean both patches and feature requests. Ideally, we want to be able to separate the bugs and patches from feature requests which are often useless. The last time I brought this up, the reply was to add [patch] to the subject line. [...] Seems to work well enough like that. Except that filtering for that is harder. A direct trac type would be nice. Basically if we want non-bugs in trac, we need an easy way to get a list of outstanding issues without the noise (and the contrary things to waste time on when bored list). That was my intention when I suggested making needinfo a priority (maybe not the best solution, but easy to do without plugins), you can just filter it out while keeping the bug open (autoclosing with the pending plugin might be nice, though). I think Trac allows tagging with custom keywords. If we allow only devs to do that, we could use it for this purpose, too. (See my last mail on the subject.) signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
sounds good with what you said... perhaps answer with 1 will be done eventually... 2 will be done only if you can find someone to do it... 3 can not be done due to game engine restraints... 4 will never be done as it is too code complicated / or / already exists in some other game ... etc. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
Hi! Am Samstag, 22. August 2009 00:29:03 schrieb bugs buggy: It has come up that some of the resolutions we currently use for trac can seem to be a bit harsh in tone. Mainly, the issue is, if a user has some kind of feature request, then what should be done with it? If we close it as invalid, that could be conscrewed as us telling them to bugger off... If we don't close it, then it clogs up the pipeline so to speak. Trac has (had?) some powerful filtering possibilities. Maybe they could be of use? In earlier versions, the most powerful variant were direct SQL queries, which could be saved and made available to regular users. It was considered to implement an easier report generator wizard, but I do not know whether they already implemented that in current versions. If not, maybe that feature could be made available to commiters/developers? It should then be able to filter based on type, state, tags, assignee, etc. in various ways. I would not generally forbid users to submit feature requests. Bad/stupid/insane requests can be closed, and good and reasonable tickets can gather ideas/opinions until someone finds the time to do them. Finaly, small requests can be implemented during lunchbreak, or whenever someone feels like doing just a little bit to push Warzone forward. (Also popular for spare time wz devs?) The same with other tickets that are more or less useless. We tried to fix some problems with the need info resolution, and that is what I mostly use, but, trac still says Closed, which can confuse some people. Ideally needinfo would start a countdown, which would closed/needinfo the ticket after X days. I would not be surprised if such a Trac plugin exists. Any ideas on how we can create a more friendlier trac? There are some suggestions that we should add more resolutions, and add more types. We now have task, defect, and enhancement. Should we have a feature request (which would be something that has no patches included), and would be closed with a resolution of One of these days... or whatever we come up with? You could try working more with keywords/tags. Remove the users ability to change them, and use it to track the state of the ticket. I.e. needinfo (like the resolution, just for not-yet-closed tickets), needtesting, needreview, ... This is just an idea for an experiment. I have no experience yet with whether and how well it works. About the additional resolution: You should use later instead. That is quite standard among most bugtrackers and usually means not now, but we will reconsider it. --Devu signature.asc Description: This is a digitally signed message part. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
On Fri, Aug 21, 2009 at 06:29:03PM -0400, bugs buggy wrote: ... Mainly, the issue is, if a user has some kind of feature request, then what should be done with it? If we close it as invalid, that could be conscrewed as us telling them to bugger off... If we don't close it, then it clogs up the pipeline so to speak. The same with other tickets that are more or less useless. We tried to fix some problems with the need info resolution, and that is what I mostly use, but, trac still says Closed, which can confuse some people. Right now, we overload 'enhancement' to mean both patches and feature requests. Ideally, we want to be able to separate the bugs and patches from feature requests which are often useless. One way is simply to have a separate tracker for feature requests. However, as cybersphinx points out in IRC, having everything in one database has certain advantages. If we had a separate 'feature request' type, it would solve that problem. Closing bugs that are in the 'need more info' state is misleading. Need info is *not* a resolution but a pending state or status. Can we create a Status of 'need more info' to go along with our accepted, assigned, closed, new and reopened values? -- Stephen Swaney sswa...@centurytel.net 231-271-7371 ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
On 8/21/09, Stephen Swaney sswa...@xxx wrote: One way is simply to have a separate tracker for feature requests. However, as cybersphinx points out in IRC, having everything in one database has certain advantages. If we had a separate 'feature request' type, it would solve that problem. Then again, the default search options available don't seem to support anything but the bare minimum. Closing bugs that are in the 'need more info' state is misleading. Need info is *not* a resolution but a pending state or status. Yeah, I agree... Can we create a Status of 'need more info' to go along with our accepted, assigned, closed, new and reopened values? I don't think we can do that, without modifying the source code. I think Giel would know what can / can't be done the best, he seems to know more about trac than the other devs. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
On Fri, Aug 21, 2009 at 9:16 PM, Stephen Swaney sswa...@centurytel.net wrote: Right now, we overload 'enhancement' to mean both patches and feature requests. Ideally, we want to be able to separate the bugs and patches from feature requests which are often useless. The last time I brought this up, the reply was to add [patch] to the subject line. enhancement - feature request enhancement [patch] - feature patch defect - bug report defect [patch] - bug patch task - request to change something task [patch] - patch to change something Seems to work well enough like that. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Making trac friendlier?
On 8/22/09, bugs buggy buginatorxx...@xxx.com wrote: I don't think we can do that, without modifying the source code. I think Giel would know what can / can't be done the best, he seems to know more about trac than the other devs. I just found this, this looks like it would be a nice enhancement for us. http://trac-hacks.org/wiki/PendingTicketPlugin Basically, after X days, it will autoclose the ticket. Just what we were looking for. :) There are quite a few others that look like we could use as well: http://trac-hacks.org/wiki ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
