some thoughts... Firstly it is important that tickets reach their fate (closed, wont fix, cant fix, not a bug, whatever ) soon, otherwise it would be worst than people writing for bugs already fixed. You can see many projects that have 3 year old tickets... This means that some individuals should handle the task of keeping an eye on tickets that stall and take actions. Secondly I would suggest that we put down a little howto on reporting bugs. Short, no one reads it otherwise. ;-) The answer to a user signalling something that sounds as a bug could be, "please read web2py.com/bugshowto and report the problem, thanks!".
I like the remote thing, but should it require a captha or similar, to avoid spammers and to make clear to the sender that something is going out of its machine? Else it would look much like those desktop applications that ask you to send info to someone you do not know, not only, you do not even know what data is going to be sent! Just "YES" or "NO"! Scaring stuff! ;-) Those ticket could contain really sensitive data! Has anyone already managed a similar situation? please speakup! mic 2010/8/26 mart <msenecal...@gmail.com>: > good plan! Do you have people dedicated to test purposes for the > monitoring help? Were you thinking on a something like a 2 tier > filtering system? first level bug validation (is this really a new > bug?) as automated filtering & second: trusted testers/dev folks who > can best help in filtering and pass best info to you? > > open a web2py ticket from the admin! Very innovative! Lots of > possibilities there! :). > > Also, do let me know if you would like to look at (or have thoughts > on) branching strategies as a means to allow testing phases while > continuing with on going development. > > Thanks, > Mart :) > > On Aug 26, 8:57 am, mdipierro <mdipie...@cs.depaul.edu> wrote: >> I am in favor of both proposals >> >> 1) user google code more >> 2) having a bug tracking application >> >> but >> - I would like some help in monitoring this list and opening bugs on >> google code when a new bug is suggested on the list. This is because I >> do not want to have to explain to new users how to open google code >> tickets and I do not want to have to open them myself (i.e. >> open,fix,close vs just fix it). >> >> - If we are doing this we should give it an edge: why not add to the >> web2py ticket system in admin to open a ticket remotely and eventually >> submit a local ticket?
