I'm thinking a few possibilities... we can, as a possible option, give folks the opportunity to either register there install of web2py with additional user registration option (depending of your philosophy wrt that) - which could also serve as tracking mechanism to encourage people to keep up with updates (i.e. Flash screen: "you are on version 1.62. Latest stable release is 1.84. Would you like to update now? y/n/"). Or maybe offer the option to register as a web2py user only (which may help augment numbers). Perhaps users can be motivated to register? For example "register and get access to the web2py community, ask questions, get real case answers, LOG bugs, etc. which would be a hard requirement for this type of activity)
registration: * install/user registration on install (I.e. .msi on windows) * on launch of app admin * on error? (I.e. Exception is thrown, user can be prompted to send error to web2py.com db.errors to 1) report the problem b) if issue can be figured out automatically like one I seem to be getting lately where AMF fails on import (missing class) when I could actually see it ;) - just as an example :)) then 2) the system can return resolution if available, or automatically log a ticket (oh, and while were there, why not offer the option of registration?) * obviously on launch of "web2py bug tracker" * on web2py software update * maybe a nice feature when installing one of those cool fee apps, user gets prompted with option to register * etc... I think there are many ways to get user attention to register with valid Google account for reducing the risk of spam with bug logging (and can have a bit of value add as well - again if inline with your web2py philosophy). web2py already has great authentication capabilities with variety and ease, leveraging that should be do-able? Also, i assume it should also be possible to query Google DB for user authentication, if not user validation is done through web2py.com? Mart :) On Aug 26, 7:23 pm, mdipierro <mdipie...@cs.depaul.edu> wrote: > This is reasonable but how to check? > > On Aug 26, 6:18 pm, mart <msenecal...@gmail.com> wrote: > > > Interesting point... How about bugs can only be "truly submitted" if > > user is registered in web2py user group? Can we up authentication > > detail for users (if required)... True that it could be scary that > > folks start logging bugs left and right... If part of user group, > > would this only generate same amount of traffic? > > > Mart :) > > > On Aug 26, 4:56 pm, Michele Comitini <michele.comit...@gmail.com> > > wrote: > > > > 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? > >
