regarding bug-tracking , i have a very simple idea. how about , before we develop the bug-tracking system , at app admin , add a side box , just like web2py Recent Tweets box , add web2py Google Group box ?
Is there Google Group api which can get all the list of subjects? and put subject tagged [web2py] [bug] or how about iframe directly to Google Group? On 8/27/10, mart <msenecal...@gmail.com> wrote: > 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? >> >>
