15:03:14 <adamw> #startmeeting Bugzappers meeting 2010-06-29
15:03:14 <zodbot> Meeting started Tue Jun 29 15:03:14 2010 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:19 <adamw> #meetingname bugzappers
15:03:19 <zodbot> The meeting name has been set to 'bugzappers'
15:03:24 <adamw> #topic gathering
15:03:26 <adamw> #chair tk009
15:03:26 <zodbot> Current chairs: adamw tk009
15:03:31 * tk009 *
15:03:40 * dafrito *
15:03:50 <tk009> =)
15:03:54 <adamw> hey, dafrito
15:04:08 <dafrito> hello all :)
15:04:56 <adamw> anyone else?
15:05:34 <tk009> should we have the meeting?
15:05:56 * nirik is lurking around in the back
15:06:10 <tk009> #topic VERIFIED Bugzilla state
15:06:30 <tk009> hmm that didnt see to work
15:06:34 <tk009> seem*
15:06:40 <adamw> ? yes it did
15:06:44 <adamw> --- zodbot has changed the topic to: VERIFIED Bugzilla state (Meeting topic: Bugzappers meeting 2010-06-29)
15:07:05 <tk009> #link https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#VERIFIED
15:07:16 <tk009> #link http://fedorahosted.org/fedora-qa/ticket/91
15:07:19 <adamw> looks good, thanks for bringing it up
15:07:47 <tk009> I have a question about this change
15:07:54 <tk009> or addition
15:08:04 <adamw> i'd say 'triagers or reporters'
15:08:12 <adamw> (for who should set it)
15:08:20 <adamw> hi jraber
15:08:38 <jraber> howdy.  I'm only available for a few minutes
15:08:53 <adamw> shall we quickly do jraber's topic then?
15:08:58 <adamw> we can come back to this
15:09:18 <tk009> sure
15:09:26 <adamw> #topic triage metrics
15:09:33 <adamw> so, jraber, what news?
15:09:37 <jraber> See https://fedoraproject.org/wiki/User_talk:Jraber
15:09:39 <tk009> https://fedoraproject.org/wiki/User:Jraber
15:09:44 <jraber> I have been working on the bugzilla CLI
15:09:44 <tk009> oops wrong link
15:10:00 <tk009> #link https://fedoraproject.org/wiki/User_Talk:Jraber
15:10:08 <adamw> i saw you sent a patch to wwoods
15:10:22 <adamw> loving the table!
15:10:23 <jraber> added the ability to get summary information by any bug field.  That gives us some decent reporting
15:10:59 <jraber> I am working on adding the ability to get the bug history info, to determine the 'triager'
15:11:50 <jraber> I had a few questions..
15:11:56 <adamw> go for it
15:11:59 <jraber> Should these metric be limited to bugs where Product=Fedora &  Classification=Fedora?
15:12:34 <jraber> Or should it just be where Product=Fedora?
15:13:33 <adamw> good question
15:13:42 <adamw> lemme see
15:14:11 <adamw> practically speaking, probably product and classification
15:14:42 <tk009> yes to both
15:14:54 <adamw> we don't really handle EPEL or management console bugs. documentation and l10n are kinda more borderline
15:15:51 <jraber> ok, great.  I have been using both.
15:15:57 <dafrito> Is the source for this hosted somewhere cloneable?
15:16:08 <jraber> Also, (I know I made the list of metrics here), but a couple of them didn't make sense to me, so I wanted to discuss them.  Specifically #7 & 8 in the table
15:16:20 <jraber> no
15:16:48 <jraber> But I'm happy to put it anywhere.
15:17:08 <jraber> I am hoping that the changes will be accepted and added to the official python-bugzilla
15:17:12 <adamw> "List of 'Triaged' bugs currently marked as NEEDINFO " - i can see the intent there, but practically speaking it's probably not super useful
15:17:46 <adamw> there are cases where it happens, in practice it's not always practical for the triager to gather _all_ necessary info
15:18:22 <jraber> agreed.  A simple webquery should find those, and since it should usually be 0 it won't be too interesting to look at.
15:18:28 <jraber> I'll drop it
15:18:35 <adamw> i like the idea of checking life expectancy of triaged bugs vs. un-triaged...
15:19:15 <adamw> it seems like something we wouldn't necessarily do on a regular basis, but it could be interesting. not sure exactly how to quantify it, though.
15:21:14 <dafrito> seems like life expectancy could vary pretty widely, depending on things like time needed for the fix, etc.
15:21:26 <j_dulaney> Indeed
15:21:27 <jraber> I not sure if it will ever return a meaningful result, since the expect lifetime changes based on the component, the resolution, point in release cycle, etc.
15:21:33 <dafrito> itd definitely be useful though, I think
15:21:36 <adamw> yeah, it might be hard to isolate the bugzappers effect vs. everything else
15:21:47 <adamw> stick it at the bottom of the priority list =)\
15:22:11 <jraber> ok, adding a new column to the table |priority|
15:23:24 <jraber> And I am open to any suggestions on metrics we should be tracking.
15:23:25 * mcepl is sorry ... got defeated by SELinux ....
15:24:11 <dafrito> If there was a way to categorize a bug based on its presumed difficulty, that might be useful. I imagine the priority or severity is at least somewhat correlated with lifetime
15:24:28 * jraber has to run.  Duty calls.
15:24:30 <adamw> i wouldn't say so
15:24:34 <adamw> thanks for the update jraber
15:24:39 <adamw> and remember, we're keeping things simple =)
15:24:51 <adamw> i think what jraber has so far is awesome, i'm hoping by next week we can start actually using it
15:24:54 <adamw> thanks a lot for your work!
15:25:11 <adamw> a 'severe' bug can be easy to fix, if it's a one-line typo causing the app to crash
15:25:24 <dafrito> true
15:25:24 <adamw> and 'minor' bugs can actually be very difficult to fix, even if the visible impact is small
15:25:50 <j_dulaney> I can relate to that
15:26:24 <j_dulaney> Of course, finding said bug if it is a typo can be a severe pain in the rear
15:26:30 <adamw> mcepl: hehe
15:26:51 <adamw> sure, but underlying point, i don't think we can rely on severity as an indication of how hard a bug is to fix
15:27:29 <dafrito> agreed
15:27:43 <j_dulaney> Include, instead of severity, an estimate on fix difficulty
15:28:05 <adamw> well, yeah, that's what we'd have to do. but that's added work for the exclusive purpose of statistical tracking, which i'd really like to avoid
15:28:16 <adamw> we don't have the manpower to crew a statistics bureau =)
15:28:56 <adamw> it's not a number that's vital enough for us to go to a lot of effort to produce, i would say
15:28:57 <j_dulaney> Time alone spent working on the bug is a decent indication
15:29:06 <j_dulaney> Indeed
15:29:12 <adamw> sure, but then we're in a chicken-and-egg
15:29:20 <j_dulaney> Interesting, though
15:29:22 <adamw> remember, the number we're talking about measuring here is how long bugs take to fix
15:29:31 <adamw> so we can't use...how long the bug takes to fix...as an input =)
15:29:35 <dafrito> hehe
15:29:46 <adamw> 'we have discovered that, on average, bugs that take longer to fix, take longer to fix'
15:29:50 <adamw> :P
15:30:53 <adamw> anyhoo...looks like jraber's doing awesome work...
15:30:57 <j_dulaney> Have a 'poll' with a 1-10 for difficulty to include with the fix report
15:31:20 <j_dulaney> Five seconds to fill in, and easy enough to count
15:31:41 <dafrito> definitely, I'd like to work with him a bit and maybe get some of these stats integrated with a few pages
15:31:42 <j_dulaney> Not even difficult to code
15:32:03 <dafrito> It wouldnt be difficult to stick a short summary on the bugzappers page, if that seems interesting?
15:32:27 <j_dulaney> That's what I'm trying to say, I reckon
15:32:40 <adamw> the way i was planning it in my evil mastermind brain was to wait until jraber has enough metrics done for us to start doing useful reports, then start by doing a few weekly email reports
15:32:52 <adamw> document what we're doing with the reports on the wiki around the same time as we start doing them
15:33:00 * tk009 is sorry for being no help, priority call
15:33:15 <j_dulaney> from Russia with love?
15:33:40 <adamw> dafrito: should probably mention that we have an overarching goal of keeping the bugzappers and qa front pages in the wiki *short*, ideally one screen at common resolutions (can't remember if we still make that at 1024x768, but that's the goal)
15:34:20 <adamw> i guess what i'd expect is a link added in 'tools and procedures' or 'communication' to a page which explains the metrics process in more detail
15:34:52 <dafrito> yeah, I wasn't thinking about c/ping the whole page in there or anything
15:35:13 <dafrito> more like a pretty graph, if it wasnt intrusive
15:35:58 <adamw> well always feel free to draft up whatever you think up and send it to the list
15:36:20 <adamw> general rule of thumb - if you see something that can be improved that's a fairly modest change with no impact on page size or overall organization, just go ahead and change it
15:36:41 <adamw> bigger/more disruptive changes, always feel free to propose them, please draft and send to list before doing them live
15:36:53 <adamw> but it's always good to have improvements :)
15:37:13 <dafrito> okay, that's fair
15:38:20 <adamw> let's go back to...
15:38:26 <adamw> #topic verified state
15:38:53 <dafrito> I added the "or reporters" to this section
15:38:58 <adamw> dafrito: cool, thanks
15:39:10 <adamw> mostly i think we had this on the agenda just as a heads-up about the change
15:39:19 <adamw> the idea being that we don't close bugs directly but let the Bodhi process do it
15:39:57 <dafrito> I'm rewording it slightly: it seems like there's much less emphasis on finding an exact fix.
15:40:42 <dafrito> Mostly putting in input from the trac ticket: that it should be marked as "verified" if the bug was found to be fixed by an update, even if it wasnt an intentional or explicit fix
15:40:51 <dafrito> Does this sound reasonable?
15:41:02 <adamw> seems so
15:42:35 <dafrito> I'll update the trac ticket when I change it, so the wording can be looked at
15:42:42 <adamw> perfect, thanks a bunch
15:43:29 <dafrito> youre welcome :)
15:43:40 <adamw> so, that's all we had on the agenda...
15:43:42 <adamw> #topic open floor
15:43:46 <adamw> anyone have anything for open floor?
15:44:12 <adamw> i know mcepl keeps bugging me to run his crazy bleeding-edge jetpack SDK browser script and i keep dodging him ;)
15:44:34 <dafrito> haha
15:44:44 <mcepl> adamw: and I am generating still new and new and more stable (hopefully) versoins
15:45:34 <dafrito> Is there, by chance, a wiki page on what the script does?
15:46:18 <mcepl> dafrito: this is probably the closest to it http://mcepl.blogspot.com/2010/01/jetpack-which-turned-into-mid-range.html
15:46:28 <mcepl> I should write some more updated status report
15:46:50 <adamw> dafrito: it's a replacement for the existing jetpack plugin script which most of us are using, that adds convenience buttons and so on to bug pages
15:47:08 <dafrito> I could work this post info into a new wiki page if you guys want, just so people can be aware of the script and what its goals are
15:47:47 <adamw> we have the tools page
15:47:52 <adamw> https://fedoraproject.org/wiki/BugZappers/Tools
15:48:01 <adamw> but it's pretty rough; if you want to sprinkle your wiki magic on it, please do =)
15:48:09 <mcepl> dafrito: feel free to extended the description there
15:48:23 <dafrito> okay, will do
15:48:42 <mcepl> the URL of the development version (really not ready for public consumption, only for lunatics like adamw) is https://fedorahosted.org/bugzilla-triage-scripts/
15:52:34 <adamw> #action dafrito to look at updating https://fedoraproject.org/wiki/BugZappers/Tools to make it shiny
15:52:40 <adamw> ok...i think that's everything
15:52:48 <adamw> closing meeting in 30 secs if no-one has anything else
15:53:01 <dafrito> would you guys also want me to write some a short summary of what the goals of the statistics are for? we mentioned a bit here, such as being simple/easy to gather and not requiring extra effort
15:53:19 <dafrito> it wouldnt be long at all, just basically put what was discussed here into his wiki page
15:53:34 <adamw> sure, sounds good to me
15:53:43 <adamw> you can check the last few weeks of meeting logs for info
15:53:55 <adamw> especially the meeting where i first proposed the idea, which i think would be about a month ago now
15:53:58 <dafrito> Is there a trac ticket for his stats?
15:54:07 <adamw> nope
15:54:34 <adamw> i was initially planning to JFDI myself and throw it on the list, jraber volunteered to take the job when i mentioned it in a meeting
15:54:59 <dafrito> hehe
15:55:19 <dafrito> do you think I should write a trac ticket up as well?
15:55:31 <adamw> sure, knock yourself out
15:55:44 * adamw is not great on the formal tracking side of things =)
15:56:01 <adamw> oh, you know there's a bugzappers trac space, right?
15:56:06 <adamw> separate from the qa one
15:56:20 <dafrito> there is?
15:56:25 <adamw> https://fedorahosted.org/triage/
15:56:34 <adamw> use that one for zappers stuff
15:56:44 <dafrito> okay, sweet
15:57:47 <dafrito> that's it for my stuff, I believe
15:58:18 <dafrito> Oh, I updated the bug flowchart, too, just to add "verified" in there
15:58:35 <adamw> okay, that's it, dafrito's in charge
15:58:43 <adamw> if anyone needs me i'll be golfing. don't need me.
15:58:43 <adamw> =)
15:58:54 <dafrito> hahah
15:59:04 <adamw> in other words, awesome job man
15:59:23 <dafrito> thank you
15:59:51 <dafrito> just hungry to contribute :)
16:00:52 <adamw> alrighty, let's wrap up
16:01:01 <adamw> thanks again everyone
16:01:15 <adamw> happy zapping
16:01:17 <adamw> #endmeeting