[09:12] <lotuspsychje> good morning to all
[09:16] <lotuspsychje> i have a question about making LP more efficiently for developers as the current situation we see alot of users creating bugs that really arent usefull, manual adds or support questions that really dont fit on LP
[09:17] <lotuspsychje> this said, would be nice to think of something to lighter the work of developers
[09:21] <marcustomlinson> hey, you guys aware of https://answers.launchpad.net/launchpad/+question/680736?
[09:26] <marcustomlinson> ok no worries, I see you're on it, thanks
[09:27] <lotuspsychje> marcustomlinson: you might direct mail that to someone
[09:27] <lotuspsychje> not sure who but :p
[09:27] <marcustomlinson> yeah thanks, I see though that wgrant is on it
[09:31] <cjwatson> I've suspended the user and will clean up
[09:31] <cjwatson> lotuspsychje: Direct mail gets to us no faster than answers.launchpad.net/launchpad tickets
[09:32] <lotuspsychje> oh ok cjwatson
[09:32] <cjwatson> So please don't suggest that
[09:45] <cjwatson> And the question about efficiency is too general to be actionable, really.  We always want to help make developers more efficient but being drawn into a super-general discussion about it is ... inefficient :)
[09:46] <lotuspsychje> cjwatson: we have a channel where ubuntu bugs are flood as news, and we noticing alot of bugs that really dont fit there
[09:48] <lotuspsychje> cjwatson: isnt there something that could be done?
[09:48] <cjwatson> If you have concrete suggestions then by all means make them
[09:49] <cjwatson> But Ubuntu is a big user-facing project and there are always going to be people who are a bit confused for one reason or another
[09:49] <cjwatson> So the goal cannot possibly be that nobody files things in the wrong places
[09:52] <lotuspsychje> cjwatson: i agree there will be always confused users, but its the system allowing them to file their confusion
[09:52] <lotuspsychje> cjwatson: would be nice to find a way to only file serious bugs
[09:54] <cjwatson> That would be horrible!
[09:54] <cjwatson> There are lots of non-serious bugs that nevertheless need to be filed (and hopefully fixed)
[09:54] <cjwatson> Anyway, unless there's something concrete I need to do some other urgent stuff before meetings next week, sorry
[09:55] <lotuspsychje> ok np
[15:30] <dkg> lotuspsychje: i think both you and cjwatson are right -- it's confusing and distracting to have these floods of confusing/confused issues; *and* it's necessary to accept most of the flood in order to learn what people are actually running into.  writing a quality bug report is a skill that needs to be learned, and yet unlearned users find some of the most interesting problems.
[15:32] <lotuspsychje> dkg: im only concerned about the work all the developers do, filtering out alot of bugs, they have better work to do i hope you understand where im going?
[15:32] <dkg> lotuspsychje: i've seen projects that actively discourage bug reporting by new/novice users, and that leads to two outcomes: (a) very few people are involved in the project, and (b) everyone who remains is so used to the idiosyncrasies of the project that they can't even imagine the improvements that a new user could imagine.
[15:32] <dkg> lotuspsychje: i totally understand
[15:32] <dkg> one approach is to build out the developer team
[15:32] <dkg> can you find not-yet-developers who understand the system well enough to figure out how to re-file?
[15:33] <dkg> can you encourage regular bug reporters with good bug reporting skills to triage some of the flood of confusion into more productive channels?
[15:34] <lotuspsychje> dkg: yeah that latter is a nice idea, involve more volunteers into our bug flood channel
[15:34] <dkg> the skills needed to redirect a confused bug report into a productive outcome are *vastly* different than the skills needed to craft a technical fix, though they both require some level of detailed knowledge of the system in question
[15:34] <lotuspsychje> dkg: by nature i also want to seek after the root problem of whats causing this
[15:35] <dkg> i understand -- but i think cjwatson pointed you toward the root -- the root is that it is a large user-facing project, with lots of users
[15:35] <dkg> by definition, many of those users will be unskilled at bug reporting
[15:35] <dkg> so either you can say "we don't want you" to those users (and lose their contributions)
[15:35] <lotuspsychje> dkg: on ubuntu for example, i found the docs filing a bug report easy, and not mentioning the irc support channel
[15:35] <dkg> or you can say "let us know!  we'll help you figure it out."
[15:36] <dkg> even using IRC well for bug triage is a learned skill :)
[15:36] <lotuspsychje> true
[15:37] <lotuspsychje> dkg: this is an example, https://bugs.launchpad.net/bugs/1828505
[15:37] <ubot5`> Ubuntu bug 1828505 in unattended-upgrades (Ubuntu) "sudo apt-get upgrade E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?" [Undecided,New]
[15:37] <dkg> good bug triage requires (a) knowledge of how the system is set up, to figure out what component really is likely to be failing, (b) empathy and communication skills to reflect on the understanding, goals, problems, and frustrations of the original bug reporter, and to keep them engaged in the process so that you can be sure their concerns are addressed, (c) technical skill in being able to craft a
[15:38] <dkg> replication of the reported problem, and (d) imagination, to conceive of how a problem *might* be fixed
[15:38] <lotuspsychje> dkg: yeah im really talking about to filter out the very unusefull stuff
[15:38] <lotuspsychje> not the bugs that actually could make sense
[15:39] <dkg> why is that report unuseful?
[15:39] <dkg> the person is doing a reasonable thing -- trying to upgrade their system
[15:39] <dkg> they ran into an error message that they didn't understand
[15:39] <dkg> that's a real problem
[15:39] <lotuspsychje> dkg: it happens all the time on ubuntu
[15:39] <lotuspsychje> and there's probably tons of dupes for that
[15:39] <dkg> that particular error message happens all the time?
[15:40] <lotuspsychje> yes
[15:40] <dkg> and lots of people don't understand it?
[15:40] <dkg> that's a real bug, then
[15:40] <dkg> this is where part (d) comes in
[15:40] <dkg> how can you make that situation better?
[15:40] <dkg> i can imagine a couple different approaches
[15:41] <dkg>  0) avoid the need for a lock in dpkg  -- this is technically ambitious, but it shouldn't be taken off the table
[15:41] <dkg>  1) make the error message more understandable
[15:41] <lotuspsychje> dkg: well i think we need to divide Os support questions and serious bugs
[15:41] <dkg>      (e.g. point to a web page that has documented explanation)
[15:42] <dkg>  2) when receiving that error message, actively interrogate the system and figure out how to report what is actually holding the lock, and make the report describe the results of that interrogation instead.
[15:42] <dkg> if you don't think that an issue that is reported "tons" of times on the issue tracker is a "serious bug" then i think we don't think about bug reporting the same way :)
[15:43] <dkg> as cjwatson said, this is a user-facing project.  if users are annoyed by something, it's a bug :)
[15:43] <lotuspsychje> dkg: well yes i agree its a bug, but when you see this issue for 10 years it looses some interest right
[15:43] <dkg> no, if i see the issue for 10 years, it *gains* interest
[15:44] <dkg> the stuff that everyone has been ignoring for 10 years but is still causing problems?  that's the meat of it right there.
[15:44] <lotuspsychje> it surely is a deeper problem
[15:45] <dkg> indeed, something worth documenting clearly and figuring out how to fix
[15:46] <dkg> if you want to avoid the flood of those particular bugs, the best way is to fix them :)
[15:46] <lotuspsychje> dkg: let me ask you this, what if tomorrow someone starts flooding LP with the same bug over and over
[15:47] <dkg> one person, as a malicious attack?
[15:47] <dkg> ban that person and close all their tickets
[15:47] <lotuspsychje> malicious, or the same computer making the same system error on boot
[15:50] <lotuspsychje> dkg: its also very easy for a new user, to create a LP bug after making the account, even without experience
[15:50] <lotuspsychje> that means anyone can file anything, serious or not
[15:53] <lotuspsychje> dkg: https://bugs.launchpad.net/bugs/1826667
[15:53] <ubot5`> Ubuntu bug 1826667 in gnome-terminal (Ubuntu) "MY UBUNTU IS HACKED SECURITY === ZEROO LOOK AT MY ACCOUNT HISTORY THERE IS SOMEONE ON IT" [Undecided,New]
[15:54] <lotuspsychje> https://bugs.launchpad.net/bugs/1826667
[15:54] <ubot5`> Ubuntu bug 1826667 in gnome-terminal (Ubuntu) "MY UBUNTU IS HACKED SECURITY === ZEROO LOOK AT MY ACCOUNT HISTORY THERE IS SOMEONE ON IT" [Undecided,New]
[15:55] <lotuspsychje> same sorry
[15:55] <lotuspsychje> just some examples of things we get
[16:03] <cjwatson> So ... somebody should probably close that bug, and malice is a different thing that we can and do deal with administratively when it's reported to us
[16:04] <cjwatson> I do think that most of the automatic stuff should be redirected to errors.ubuntu.com which is better able to deal with aggregate reports of that kind (most of it is, but there are surely some bits that haven't yet been, and somebody could productively work on that)
[16:07] <lotuspsychje> ok thanks cjwatson
[16:08] <cjwatson> It was an early design error to use LP bugs for lots of aggregate crash reports, because there was nothing better at the time
[16:09] <cjwatson> aggregatable, rather
[17:54] <rnpalmer> Spam comment in bug 283666
[17:54] <ubot5`> bug 283666 in openoffice.org (Ubuntu) "[upstream] impress slideshow does not show cropped .eps images" [Low,Won't fix] https://launchpad.net/bugs/283666
[18:57] <cjwatson> Removed, slightly too late for rnpalmer to see