From mkanat at bugzilla.org Thu Jun 1 00:25:07 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Wed, 31 May 2006 17:25:07 -0700 Subject: Bugzilla::Object Message-ID: <1149121508.2785.20.camel@localhost.localdomain> Hi all. I've just checked in Bugzilla::Object to CVS, which should make writing new objects much easier. See the POD in Bugzilla/Object.pm, and see Bugzilla/Keyword.pm as a sample implementation. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From lpsolit at gmail.com Sat Jun 3 16:31:43 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Sat, 03 Jun 2006 18:31:43 +0200 Subject: Minutes of the Bugzilla meeting Message-ID: <4481B96F.7070502@gmail.com> We had a Bugzilla meeting on May 23: http://bugzilla.glob.com.au/irc/?c=bugzilla-meeting&a=date&s=23+May+2006&e=23+May+2006 * We plan to have a development release (2.23.2) very soon now. The most important changes are the Authentication code rewrite and the implementation of the Automatic Upgrade Notification feature (this feature should land very soon now, just before the release). The Authentication stuff requires special attention to avoid security holes and/or regressions in our next release later this year. Please play with it and report any bug you may find. * We need LDAP testers. If you use LDAP, help us testing it! :) * Now that the Authentication code has been rewritten and that we can use Bugzilla->params->{'foo'} instead of Bugzilla::Config::Param('foo'), we can go on with the removal of versioncache and globals.pl. There is a good hope that they will be removed on time, i.e. before the end of the month. * We will probably be late with the rewrite of Bug.pm though (the roadmap says "July" for it). If you want to see the Bugzilla 3.0 release on time, feel free to contribute. :) * Testopia reached its 1.0 beta stage. You can download it at http://landfill.bugzilla.org/testopia/testopia-1.0-beta.tar.gz and test it at http://landfill.bugzilla.org/testopia/. [Note: Testopia 1.0 beta has been released one week after the meeting. But as we are late with the minutes, let's give you updated information] * You can now use Bugzilla::Object to write new objects more easily. * No improvements about charts are expected in the near future, due to a lack of developers working on them. All contributions are welcome though. * Our next meeting will take place on Tuesday June, 6th at 18:00 GMT, as usual. LpSolit From bzorg-ml at rsz.jp Mon Jun 5 18:17:11 2006 From: bzorg-ml at rsz.jp (victory) Date: Tue, 06 Jun 2006 03:17:11 +0900 Subject: Bugzilla meeting on IRC tomorrow, June 6th, 2006 Message-ID: <20060606031544.CDAB.BZORG-ML@rsz.jp> Reminder: We will meet tomorrow, Tuesday June 6th, 2006 at 18:00 GMT (11:00 PST, 20:00 CET, 7th 03:00 JST) on IRC in the #bugzilla-meeting channel. The agenda is available at: http://wiki.mozilla.org/Bugzilla:Meetings Everyone who is interested can attend. -- victory From lpsolit at gmail.com Wed Jun 7 19:46:19 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 07 Jun 2006 21:46:19 +0200 Subject: "Special" Bugzilla meeting on Thurday, June 22, 2006 at 16:00 GMT Message-ID: <44872D0B.5010800@gmail.com> Hi all! Our next Bugzilla meeting will be special in at least two ways: 1) First of all, we won't meet on Tuesday as we used to do, but on *Thursday, June 22, 2006*, at 16:00 GMT (09:00 PDT, 18:00 CET). Be careful that that's 2 hours earlier than usual (but two days later, I know). The reason is that justdave cannot attend on Tuesday. As he is the project leader, it makes sense to have him at the meeting. That's why. :) 2) Secondly, we will have a special guest who will attend on Thursday: Mike Beltzner (aka beltzner on IRC), the UI lead for the Mozilla Corporation. Quoting himself: " "Phenomenologist" ;) but yeah, UI Lead for MoCo works. Generally provide UI/UX guidance to all mozilla products and projects, heavy focus on Firefox obviously, but my fingers are in many, many pies" As we are thinking about how to improve the UI for Bugzilla 3.0 (besides implementing AJAX and gandalf's work), we decided to ask someone who has a great experience in this area. Another advantage is that Mike will have a different look at Bugzilla than we, developers, have. Maybe Bugzilla 2.22 will be the last release where people could complain that the UI was hard to use for common users and that features were hard to discover. No matter what will be discussed and decided, we will need as much feedback as possible. So please attend if you can and if you are interested (or already involved in UI stuff). We will meet in the #bugzilla-meeting channel, as usual. See you on June 22, Fr?d?ric Buclin (LpSolit) From kevin.benton at amd.com Wed Jun 7 22:34:36 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 7 Jun 2006 15:34:36 -0700 Subject: "Special" Bugzilla meeting on Thursday, June 22, 2006 at Message-ID: > Our next Bugzilla meeting will be special in at least two ways: > > 1) First of all, we won't meet on Tuesday as we used to do, but on > *Thursday, June 22, 2006*, at 16:00 GMT (09:00 PDT, 18:00 CET). Be > careful that that's 2 hours earlier than usual (but two days later, I > know). The reason is that justdave cannot attend on Tuesday. As he is > the project leader, it makes sense to have him at the meeting. That's > why. :) East coasters (US) will have to join at 6 AM? > 2) Secondly, we will have a special guest who will attend on Thursday: > Mike Beltzner (aka beltzner on IRC), the UI lead for the Mozilla > Corporation. Quoting himself: > > " "Phenomenologist" ;) but yeah, UI Lead for MoCo works. Generally > provide UI/UX guidance to all mozilla products and projects, heavy focus > on Firefox obviously, but my fingers are in many, many pies" > > As we are thinking about how to improve the UI for Bugzilla 3.0 (besides > implementing AJAX and gandalf's work), we decided to ask someone who has > a great experience in this area. Another advantage is that Mike will > have a different look at Bugzilla than we, developers, have. Maybe > Bugzilla 2.22 will be the last release where people could complain that > the UI was hard to use for common users and that features were hard to > discover. > > No matter what will be discussed and decided, we will need as much > feedback as possible. So please attend if you can and if you are > interested (or already involved in UI stuff). We will meet in the > #bugzilla-meeting channel, as usual. > > > See you on June 22, > > Fr?d?ric Buclin (LpSolit) Just in case I can't make it... Let me say this before someone lops my head off for making these suggestions: I know that a lot of very good work has gone into the UI improvements proposed for 3.0, especially by Gandalf. My hat's off to you, Gandalf for being 1) brave enough to handle the comments that came, 2) for taking the time and putting in the effort to create something that could become leading-edge for web-based UI's regardless of the application, and 3) sharing your ideas with us. Having said that... I suggest that whomever works on the 3.0 Bugzilla UI be very familiar with the books - "Web Pages That Suck" and (or at least) "Son of Web Pages That Suck." I'm sure everyone here would agree that Bugzilla doesn't suck right now, but we could certainly introduce things that could make life difficult for novice users. When I first looked at the pages Gandalf did, I saw many very cool features, but what I didn't see was instruction on how to use the page. I didn't know I could move frames around till I tried it. Most users won't try moving frames and will therefore, miss out on that feature. Granted, it was just a demo, but I want to make sure we don't miss that point before distributing it as part of our UI. I also think we could do better at letting the browser handle some of the input validation for the user (not for Bugzilla, though). That way, users who try to navigate away from our form without saving changes will get prompted, preventing data loss. Users who supply invalid keywords will get a pop-up asking them to re-enter, and users can get warned if they attempt to set a flag to + or - without (where appropriate) going through ? first (as some examples). I say, "not for Bugzilla, though" because we need to validate input coming to Bugzilla no matter where the data comes from, a browser, a script, or a cracker. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From myk at mozilla.org Wed Jun 7 22:48:12 2006 From: myk at mozilla.org (Myk Melez) Date: Wed, 07 Jun 2006 15:48:12 -0700 Subject: "Special" Bugzilla meeting on Thursday, June 22, 2006 at In-Reply-To: References: Message-ID: <448757AC.7060006@mozilla.org> Benton, Kevin wrote: >> Our next Bugzilla meeting will be special in at least two ways: >> >> 1) First of all, we won't meet on Tuesday as we used to do, but on >> *Thursday, June 22, 2006*, at 16:00 GMT (09:00 PDT, 18:00 CET). Be >> careful that that's 2 hours earlier than usual (but two days later, I >> know). The reason is that justdave cannot attend on Tuesday. As he is >> the project leader, it makes sense to have him at the meeting. That's >> why. :) >> > > East coasters (US) will have to join at 6 AM? > No, the meeting will start at 12 noon for US east coasters, as EDT, the current time zone for such folk, is UTC (a.k.a. GMT) - 4 hours. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.beti at free.fr Thu Jun 8 16:33:54 2006 From: julien.beti at free.fr (Julien BETI) Date: Thu, 08 Jun 2006 18:33:54 +0200 Subject: Massive Version and Target milestone changes Message-ID: <44885172.6000202@free.fr> Hello, I'm working on a little program that will massively update Versions and Target Milestones on a regular expression matching basis. I just like to check with you guys that in order to do this without wipeout my preciiiiouuuus Bugzilla database, I have to: - Check that version length < 64 chrs. and Target Milestone length < 20 chrs - Check that the target name does not already exist for the given product - update bugs set version = where version = and product_id = - update versions set value = where value = and product_id = - do the same as 2 points above for Target Milestone Do I miss something? I'll of course make a backup before playing, but I do not want to discover 6 months later that something was missing in my process :p Thanks, Julien. -- Motofix La route est longue, mais la voie est libre... http://www.jujunie.com From kevin.benton at amd.com Thu Jun 8 17:48:33 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 8 Jun 2006 10:48:33 -0700 Subject: "Special" Bugzilla meeting on Thursday, June 22, 2006 at Message-ID: OOPS! :-) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. ________________________________ From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Myk Melez Sent: Wednesday, June 07, 2006 4:48 PM To: developers at bugzilla.org Subject: Re: "Special" Bugzilla meeting on Thursday, June 22, 2006 at Benton, Kevin wrote: Our next Bugzilla meeting will be special in at least two ways: 1) First of all, we won't meet on Tuesday as we used to do, but on *Thursday, June 22, 2006*, at 16:00 GMT (09:00 PDT, 18:00 CET). Be careful that that's 2 hours earlier than usual (but two days later, I know). The reason is that justdave cannot attend on Tuesday. As he is the project leader, it makes sense to have him at the meeting. That's why. :) East coasters (US) will have to join at 6 AM? No, the meeting will start at 12 noon for US east coasters, as EDT, the current time zone for such folk, is UTC (a.k.a. GMT) - 4 hours. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkgnu at mkgnu.net Sat Jun 10 01:28:14 2006 From: mkgnu at mkgnu.net (Kristis Makris) Date: Fri, 09 Jun 2006 18:28:14 -0700 Subject: Add a comment, wipe all existing ones. Message-ID: <1149902894.3783.7.camel@syd.mkgnu.net> Hello, After upgrading from Bugzilla 2.10 to 2.20.2 I noticed that every time I try to enter a comment in bugzilla on any bug (both existing and brand new) all existing comments disappear. After poking around in the database I see that: mysql> select count(*) from longdescs where bug_id=3149; +----------+ | count(*) | +----------+ | 8 | +----------+ 1 row in set (0.00 sec) But for bug 3149 I only see the last longdesc entered (the one with "thetext" = "Testing again". I'm wondering whether this is a side-effect of the upgrade. I originally thought the Scmbug integration broke this, but apparently this happens even if I just create new bugs and enter comments only through the Bugzilla UI. Is there a Parameter I need to configure specially ? This sounds too weird to be a misconfiguration issue. Thanks for any help! mysql> select bug_id, thetext from longdescs where bug_id=3149; +--------+--------------------------------------------------------------------------------------------------------------------------+ | bug_id | thetext | +--------+--------------------------------------------------------------------------------------------------------------------------+ | 3149 | Another test bug for WHS | | 3149 | Accepted. | | 3149 | accepted | | 3149 | Testing if the comments won't be wiped out again................. Affected files: --------------- NONE --> 1.1 file3 | | 3149 | nope. They got wiped out. | | 3149 | Wait... this is a bugzilla configuration issue | | 3149 | still a broken bugzilla ? | | 3149 | Testing again | +--------+--------------------------------------------------------------------------------------------------------------------------+ 8 rows in set (0.00 sec) From justdave at bugzilla.org Sat Jun 10 01:40:42 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 09 Jun 2006 21:40:42 -0400 Subject: Add a comment, wipe all existing ones. In-Reply-To: <1149902894.3783.7.camel@syd.mkgnu.net> References: <1149902894.3783.7.camel@syd.mkgnu.net> Message-ID: <448A231A.5020700@bugzilla.org> Kristis Makris wrote on 6/9/06 9:28 PM: > After upgrading from Bugzilla 2.10 to 2.20.2 I noticed that every time I > try to enter a comment in bugzilla on any bug (both existing and brand > new) all existing comments disappear. > But for bug 3149 I only see the last longdesc entered (the one with > "thetext" = "Testing again". I'm wondering whether this is a side-effect > of the upgrade. I originally thought the Scmbug integration broke this, > but apparently this happens even if I just create new bugs and enter > comments only through the Bugzilla UI. > > Is there a Parameter I need to configure specially ? This sounds too > weird to be a misconfiguration issue. Check the value of the "isprivate" column in the longdescs table. That's the only thing I can think of. You might have something in your customization that isn't paying attention to it or is and shouldn't be. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Sat Jun 10 01:41:39 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 09 Jun 2006 21:41:39 -0400 Subject: Massive Version and Target milestone changes In-Reply-To: <44885172.6000202@free.fr> References: <44885172.6000202@free.fr> Message-ID: <448A2353.2090208@bugzilla.org> Julien BETI wrote on 6/8/06 12:33 PM: > I'm working on a little program that will massively update Versions and > Target Milestones on a regular expression matching basis. > I just like to check with you guys that in order to do this without > wipeout my preciiiiouuuus Bugzilla database, I have to: > Do I miss something? I'll of course make a backup before playing, but I > do not want to discover 6 months later that something was missing in my > process :p Nothing is jumping out at me, but that doesn't necessarily mean anything. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Sat Jun 10 01:42:35 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 09 Jun 2006 21:42:35 -0400 Subject: Online schema doc updated In-Reply-To: <74677.1147983259@thrush.ravenbrook.com> References: <74677.1147983259@thrush.ravenbrook.com> Message-ID: <448A238B.6070109@bugzilla.org> Nick Barnes wrote on 5/18/06 4:14 PM: > I have added the February and April releases (2.16.11, 2.18.5, 2.20.1, > 2.22rc1, 2.20.2, 2.22, 2.23.1) to my online Bugzilla schema doc. > > This is a bit of a late reply, but I just want to thank you again for putting this together and continuing to update it. It's an awesome resource. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Sat Jun 10 05:16:02 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 09 Jun 2006 22:16:02 -0700 Subject: Add a comment, wipe all existing ones. In-Reply-To: <1149902894.3783.7.camel@syd.mkgnu.net> References: <1149902894.3783.7.camel@syd.mkgnu.net> Message-ID: <1149916562.2394.0.camel@es-lappy> On Fri, 2006-06-09 at 18:28 -0700, Kristis Makris wrote: > After upgrading from Bugzilla 2.10 to 2.20.2 I noticed that every time I > try to enter a comment in bugzilla on any bug (both existing and brand > new) all existing comments disappear. That sounds like checksetup did not complete properly. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Mon Jun 12 00:23:36 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Sun, 11 Jun 2006 17:23:36 -0700 Subject: Help Out With 2.23.2 Release (Easy)! Message-ID: <1150071816.2521.17.camel@localhost.localdomain> Hey folks! We're going to be releasing a development snapshot pretty soon, and I need some help with a lot of simple things for the release. Basically it's a lot of different, easy web pages updates and so on. It will get done faster if we have a lot of people working on it. Here's the list: https://bugzilla.mozilla.org/showdependencytree.cgi?id=341192&hide_resolved=1 If you want to do any of them, just assign the bug to yourself and post a patch! Details for each of them are at: http://www.bugzilla.org/docs/release.html#web_site_updates -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From patrick.campbell at ourvacationstore.com Wed Jun 14 23:23:25 2006 From: patrick.campbell at ourvacationstore.com (Patrick Campbell) Date: Wed, 14 Jun 2006 16:23:25 -0700 Subject: status/resolution in newchangedmail? Message-ID: I see that %product% works in newchangedmail - could anyone tell me how to get status and resolution to work like that in 2.20.2? -- Patrick From julien.beti at free.fr Thu Jun 15 15:44:03 2006 From: julien.beti at free.fr (Julien BETI) Date: Thu, 15 Jun 2006 17:44:03 +0200 Subject: Increasing Target Milestone field length Message-ID: <44918043.9060003@free.fr> Hello, Fimasys (http://www.fimasys.com) is using Bugzilla for several years now, as our internal bugs, enhancement and tasks tracking system, and we have to say that we are more than happy as it always answered to our needs. But recently, it comes out that 20 characters to store the target milestone is not enough to meet our version numbering normalisation. We would like then to change the size of the field to 65 characters, as version field. Is there any risk doing so? Do I have to change something in the code (except I suppose the Target Milestone update/creation pages)? Thank you, Julien BETI. -- Motofix La route est longue, mais la voie est libre... http://www.jujunie.com From mkanat at bugzilla.org Thu Jun 15 23:12:35 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 15 Jun 2006 16:12:35 -0700 Subject: status/resolution in newchangedmail? In-Reply-To: References: Message-ID: <1150413155.2452.18.camel@localhost.localdomain> On Wed, 2006-06-14 at 16:23 -0700, Patrick Campbell wrote: > I see that %product% works in newchangedmail - could anyone tell me how > to get status and resolution to work like that in 2.20.2? Hey Patrick. That question would be more appropriate for the bugzilla-support list. You can see details on that list here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jun 15 23:13:16 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 15 Jun 2006 16:13:16 -0700 Subject: Increasing Target Milestone field length In-Reply-To: <44918043.9060003@free.fr> References: <44918043.9060003@free.fr> Message-ID: <1150413197.2452.21.camel@localhost.localdomain> On Thu, 2006-06-15 at 17:44 +0200, Julien BETI wrote: > But recently, it comes out that 20 characters to store the target > milestone is not enough to meet our version numbering normalisation. > We would like then to change the size of the field to 65 characters, as > version field. > [snip] Hi Julien. This question would be more appropriate for the bugzilla-support list: http://www.bugzilla.org/support/ has the details. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Mon Jun 19 12:23:03 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 19 Jun 2006 05:23:03 -0700 Subject: The Basic of mod_perl Support Message-ID: <1150719783.2746.26.camel@es-lappy> Hey all. I just realized that with all of our work toward mod_perl, some people might not know *why* we're doing the re-architecture that we're doing. Basically, the most important thing to know is this: Under mod_perl, your .pm files will be compiled once. Ever. You can reload that page 100 times, but it will only compile the .pm files the first time. For you, or for anybody who ever accesses the server. (Technically, it happens once for every httpd process, but you don't have to worry about that too much.) So just think with that when you're writing your code. Your .pms only get compiled once. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From dennis.melentyev at infopulse.com.ua Mon Jun 19 12:44:06 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Mon, 19 Jun 2006 15:44:06 +0300 Subject: The Basic of mod_perl Support In-Reply-To: <1150719783.2746.26.camel@es-lappy> References: <1150719783.2746.26.camel@es-lappy> Message-ID: <1150721046.90475.12.camel@D-MELENTYEV.HOME> Max, Could you please also tell us, what other things we should know to make code compatible with mod_perl? I mostly mean common mistakes and good code patterns/practices. I personally am not really aware of data objects scopes/accessibility. Do we need anything like mutexes to access module common data, etc... And also mod_perl related comments in code are not clear enough. Or, just point me to some good docs on mod_perl. PS. Googling does not work for me so far... ? ??, 19/06/2006 ? 05:23 -0700, Max Kanat-Alexander ?????: > Hey all. I just realized that with all of our work toward mod_perl, > some people might not know *why* we're doing the re-architecture that > we're doing. > > Basically, the most important thing to know is this: > > Under mod_perl, your .pm files will be compiled once. Ever. You can > reload that page 100 times, but it will only compile the .pm files the > first time. For you, or for anybody who ever accesses the server. > > (Technically, it happens once for every httpd process, but you don't > have to worry about that too much.) > > So just think with that when you're writing your code. Your .pms only > get compiled once. > > -Max From mkanat at bugzilla.org Mon Jun 19 13:26:09 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 19 Jun 2006 06:26:09 -0700 Subject: The Basic of mod_perl Support In-Reply-To: <1150721046.90475.12.camel@D-MELENTYEV.HOME> References: <1150719783.2746.26.camel@es-lappy> <1150721046.90475.12.camel@D-MELENTYEV.HOME> Message-ID: <1150723569.2746.40.camel@es-lappy> On Mon, 2006-06-19 at 15:44 +0300, Dennis Melentyev wrote: > Could you please also tell us, what other things we should know to make > code compatible with mod_perl? I mostly mean common mistakes and good > code patterns/practices. The rule I said below pretty much covers it. You just have to imagine that you're re-using the same compiled module over and over. For example, let's pretend that your module looks like this: package Foo; my $user = Bugzilla->user; First time you load the page, $user will be correct. Second time, somebody else loads the page, the $user variable won't even exist. Why? Because "my" puts something in the scope of the currently-running script. In general, it's just not a good idea to ever have code execute outside of a subroutine, in a .pm file. If you follow that rule, you'll be safe. There are some exceptions, but don't worry about it unless you *reall* have to. Just put everything in a subroutine. > Or, just point me to some good docs on mod_perl. This is for mod_perl 1.x, and we're going to be using 2.x, but the ideas are basically the same: http://perl.apache.org/docs/1.0/guide/porting.html -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From dennis.melentyev at infopulse.com.ua Mon Jun 19 14:09:01 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Mon, 19 Jun 2006 17:09:01 +0300 Subject: The Basic of mod_perl Support In-Reply-To: <1150723569.2746.40.camel@es-lappy> References: <1150719783.2746.26.camel@es-lappy> <1150721046.90475.12.camel@D-MELENTYEV.HOME> <1150723569.2746.40.camel@es-lappy> Message-ID: <1150726141.90475.15.camel@D-MELENTYEV.HOME> ? ??, 19/06/2006 ? 06:26 -0700, Max Kanat-Alexander ?????: > On Mon, 2006-06-19 at 15:44 +0300, Dennis Melentyev wrote: > > Could you please also tell us, what other things we should know to make > > code compatible with mod_perl? I mostly mean common mistakes and good > > code patterns/practices. > > The rule I said below pretty much covers it. You just have to imagine > that you're re-using the same compiled module over and over. > > For example, let's pretend that your module looks like this: > > package Foo; > > my $user = Bugzilla->user; > > First time you load the page, $user will be correct. Second time, > somebody else loads the page, the $user variable won't even exist. Why? > Because "my" puts something in the scope of the currently-running > script. > > In general, it's just not a good idea to ever have code execute outside > of a subroutine, in a .pm file. If you follow that rule, you'll be safe. > There are some exceptions, but don't worry about it unless you *reall* > have to. Just put everything in a subroutine. Ok, got it. Thank you a lot! > > Or, just point me to some good docs on mod_perl. > > This is for mod_perl 1.x, and we're going to be using 2.x, but the > ideas are basically the same: > > http://perl.apache.org/docs/1.0/guide/porting.html And one more thank! The great page! :) From dwilliss at microimages.com Mon Jun 19 14:37:50 2006 From: dwilliss at microimages.com (Dave Williss) Date: Mon, 19 Jun 2006 09:37:50 -0500 Subject: The Basic of mod_perl Support References: <1150719783.2746.26.camel@es-lappy> <1150721046.90475.12.camel@D-MELENTYEV.HOME> <1150723569.2746.40.camel@es-lappy> Message-ID: <55e501c693ad$f10045b0$4b00000a@opus2> Another thing to keep in mind with mod_perl, is that the .cgi is also only compiled once. Also, as Max said, things defined at a global scope with "my" are evil. Things defined at a global scope without "my" end up having a global scope across all instances. This is also evil. I have a tendency in my perl and cgi scripts to assume that any variable I declare gets initialized to an undefined state. With mod_perl, this only happens on the first instance. So if you use an array or hash and assume it will start out empty and just keep adding things to it, you'll be surprised to find that it keeps growing each time the cgi is called. This can also be used in a good way though... There are tables which could be read once and kept in memory rather than having to do a query every time the cgi is run. Of course, since you've just spent a lot of effort go get rid of globals.pl, that may be a step backwards :-) ----- Original Message ----- From: "Max Kanat-Alexander" To: Sent: Monday, June 19, 2006 8:26 AM Subject: Re: The Basic of mod_perl Support > On Mon, 2006-06-19 at 15:44 +0300, Dennis Melentyev wrote: >> Could you please also tell us, what other things we should know to make >> code compatible with mod_perl? I mostly mean common mistakes and good >> code patterns/practices. > > The rule I said below pretty much covers it. You just have to imagine > that you're re-using the same compiled module over and over. > > For example, let's pretend that your module looks like this: > > package Foo; > > my $user = Bugzilla->user; > > First time you load the page, $user will be correct. Second time, > somebody else loads the page, the $user variable won't even exist. Why? > Because "my" puts something in the scope of the currently-running > script. > > In general, it's just not a good idea to ever have code execute outside > of a subroutine, in a .pm file. If you follow that rule, you'll be safe. > There are some exceptions, but don't worry about it unless you *reall* > have to. Just put everything in a subroutine. > >> Or, just point me to some good docs on mod_perl. > > This is for mod_perl 1.x, and we're going to be using 2.x, but the > ideas are basically the same: > > http://perl.apache.org/docs/1.0/guide/porting.html > > -Max > -- > http://www.everythingsolved.com/ > Everything Solved: Competent, Friendly Bugzilla and Linux Services > > - > To view or change your list settings, click here: > From mkanat at bugzilla.org Mon Jun 19 15:00:06 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 19 Jun 2006 08:00:06 -0700 Subject: The Basic of mod_perl Support In-Reply-To: <55e501c693ad$f10045b0$4b00000a@opus2> References: <1150719783.2746.26.camel@es-lappy> <1150721046.90475.12.camel@D-MELENTYEV.HOME> <1150723569.2746.40.camel@es-lappy> <55e501c693ad$f10045b0$4b00000a@opus2> Message-ID: <1150729207.2746.45.camel@es-lappy> On Mon, 2006-06-19 at 09:37 -0500, Dave Williss wrote: > Another thing to keep in mind with mod_perl, is that the .cgi is also > only compiled once. Right. But as I understand it, all of the CGI code pretty much runs every time you load the page, so it's not as bad as a .pm, which only really "runs" once. (You just have to make sure you don't have anything silly like a BEGIN block in your CGI, which will only run once.) -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From bzorg-ml at rsz.jp Mon Jun 19 20:56:03 2006 From: bzorg-ml at rsz.jp (victory) Date: Tue, 20 Jun 2006 05:56:03 +0900 Subject: Bugzilla meeting on IRC not tomorrow but 3 days after, June 22th, 2006 Message-ID: <20060620055153.8C1B.BZORG-ML@rsz.jp> Reminder: We will meet Thusday June 22th, 2006 at 16:00 GMT (9:00 PST, 18:00 CET, 23th 01:00 JST) on IRC in the #bugzilla-meeting channel. NOTE THAT this is NOT Tuesday but Tursday, and 2 hours earlier than usual, don't miss it ;-) The agenda is available at: http://wiki.mozilla.org/Bugzilla:Meetings Everyone who is interested can attend. -- victory From wurblzap at gmail.com Mon Jun 19 21:26:35 2006 From: wurblzap at gmail.com (Marc Schumann) Date: Mon, 19 Jun 2006 23:26:35 +0200 Subject: Bugzilla meeting on IRC not tomorrow but 3 days after, June 22th, 2006 In-Reply-To: <20060620055153.8C1B.BZORG-ML@rsz.jp> References: <20060620055153.8C1B.BZORG-ML@rsz.jp> Message-ID: > We will meet Thusday June 22th, 2006 at 16:00 GMT > on IRC in the #bugzilla-meeting channel. Despite the agenda saying otherwise, I definitely won't be able to make it this time :( Marc -- http://wurblzap.net/ Bugzilla hosting and professional support From mkanat at bugzilla.org Tue Jun 20 07:44:24 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 20 Jun 2006 00:44:24 -0700 Subject: SendSQL is GONE! Message-ID: <1150789465.5326.14.camel@localhost.localdomain> Today is a day of celebration! We have finally, finally, after more than two years of effort, removed all of the deprecated Bugzilla::DB routines from Bugzilla. That is, SendSQL, FetchOneColumn(), all those things are GONE. I'd like to congratulate everybody who contributed, particularly Fr?d?ric who really pushed it all through at the end. The other great primary contributors were (besides me): wicked, bkor, ghendricks, gabriel, batosti, timello, and bbaetz. Thank you so much to everybody! -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Wed Jun 21 01:01:05 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 20 Jun 2006 18:01:05 -0700 Subject: globals.pl is dead! :-D Message-ID: <1150851666.2494.23.camel@localhost.localdomain> Wow, right on the heels of our SendSQL removal, we've completely removed globals.pl! Finally, CGI.pl and globals.pl are totally gone. All functions live either inside of the CGI that use them, or inside of a module. This was a huge effort over several years. I'd really like to thank LpSolit for pushing it through at the end, there, in addition to everybody who helped. That's pretty much the whole Bugzilla team, and all of the contributors who submitted patches. :-) I think just about everybody helped remove a function from globals.pl or CGI.pl at some point. :-) Where do we go from here? Well, we still have some important requirements for mod_perl support. You can see them at: https://bugzilla.mozilla.org/showdependencytree.cgi?id=87406&hide_resolved=1 I'll be working on some of them, but if you have any mod_perl experience, please chime in with your thoughts on the best way to fix them! I have more experience *theoretically* working with mod_perl (that is, reading the documentation and fixing our code) than I have experience working with it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From justdave at bugzilla.org Wed Jun 21 02:24:55 2006 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Jun 2006 22:24:55 -0400 Subject: SendSQL is GONE! In-Reply-To: <1150789465.5326.14.camel@localhost.localdomain> References: <1150789465.5326.14.camel@localhost.localdomain> Message-ID: <4498ADF7.70605@bugzilla.org> Max Kanat-Alexander wrote on 6/20/06 3:44 AM: > Today is a day of celebration! We have finally, finally, after more > than two years of effort, removed all of the deprecated Bugzilla::DB > routines from Bugzilla. > > That is, SendSQL, FetchOneColumn(), all those things are GONE. Max forgot to mention just why it is this is significant. :) It means we've finally completed the transition from using home-brewed functions to using Perl's modern DBI database interface. This makes things not only smoother for cross-database compatibility, but also cleans up a lot of old code that depended on global variables, which means one less roadblock to mod_perl compatibility. :) Let me repeat that thanks to everyone that helped, this has been a long time coming! -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bzorg-ml at rsz.jp Wed Jun 21 17:18:02 2006 From: bzorg-ml at rsz.jp (victory) Date: Thu, 22 Jun 2006 02:18:02 +0900 Subject: Bugzilla meeting on IRC tomorrow, June 22th, 2006 Message-ID: <20060622021533.1533.BZORG-ML@rsz.jp> Reminder: We will meet tomorrow, Thusday June 22th, 2006 at 16:00 GMT (9:00 PST, 18:00 CET, 23th 01:00 JST) on IRC in the #bugzilla-meeting channel. NOTE THAT this meeting start time is 2 hours earlier than usual. Don't miss it ;-) The agenda is available at: http://wiki.mozilla.org/Bugzilla:Meetings Everyone who is interested can attend. -- victory From wicked at etlicon.fi Wed Jun 21 21:52:24 2006 From: wicked at etlicon.fi (wicked at etlicon.fi) Date: Thu, 22 Jun 2006 00:52:24 +0300 Subject: SendSQL is GONE! In-Reply-To: <1150789465.5326.14.camel@localhost.localdomain> References: <1150789465.5326.14.camel@localhost.localdomain> Message-ID: <4499BF98.80907@etlicon.com> On 20.6.2006 10:44, Max Kanat-Alexander wrote: > That is, SendSQL, FetchOneColumn(), all those things are GONE. Wohoo! \o/ -- Teemu Mannermaa System Specialist "Anything is possible. It's all about probabilities." From mkanat at bugzilla.org Thu Jun 22 12:27:21 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 22 Jun 2006 05:27:21 -0700 Subject: mod_perl: "our" vs. "my" in CGI scripts Message-ID: <1150979242.2543.5.camel@localhost.localdomain> Hey everybody. Here's another important thing to know for mod_perl. In a CGI, the following code doesn't work: my $var = 0; sub foo {print $var;} The following code *does* work: our $var = 0; sub foo {print $var;} That's because "my" isn't really supposed to make variables available to subroutines, but it works normally because of some strangeness in normal perl. If you have an "our" outside of a function, though, you always have to initialize the variable to something. That is, don't do "our $var", always do "our $var = 'something'". If you don't have anything to initialize it to, you can do "local our $var;" -- that works fine. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From lpsolit at gmail.com Thu Jun 22 12:43:20 2006 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Thu, 22 Jun 2006 14:43:20 +0200 Subject: {Spam?} Re: mod_perl: "our" vs. "my" in CGI scripts In-Reply-To: <1150979242.2543.5.camel@localhost.localdomain> References: <1150979242.2543.5.camel@localhost.localdomain> Message-ID: <449A9068.4080101@gmail.com> > The following code *does* work: > > our $var = 0; > sub foo {print $var;} Much better is to pass $var to foo() as argument: foo($var). I think only a few scripts use this kind of pseudo-global variables anyway. We should fix them (e.g. process_bug.cgi and maybe token.cgi too). LpSolit From mkanat at bugzilla.org Thu Jun 22 12:56:55 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 22 Jun 2006 05:56:55 -0700 Subject: mod_perl: "our" vs. "my" in CGI scripts In-Reply-To: <449A9068.4080101@gmail.com> References: <1150979242.2543.5.camel@localhost.localdomain> <449A9068.4080101@gmail.com> Message-ID: <1150981015.2543.10.camel@localhost.localdomain> On Thu, 2006-06-22 at 14:43 +0200, Fr?d?ric Buclin wrote: > Much better is to pass $var to foo() as argument: foo($var). Yes, agreed. > I think > only a few scripts use this kind of pseudo-global variables anyway. We > should fix them (e.g. process_bug.cgi and maybe token.cgi too). Unfortunately, many scripts assume $cgi and $template are globals. I'm working on that now. In some scripts I'm fixing the assumption. In others I'm making them globals, depending on whichever is easier for now. The only global we should normally have is $vars. Subroutines do have a real reason to modify that. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From dennis.melentyev at infopulse.com.ua Thu Jun 22 15:30:55 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Thu, 22 Jun 2006 18:30:55 +0300 Subject: mod_perl: "our" vs. "my" in CGI scripts In-Reply-To: <1150981015.2543.10.camel@localhost.localdomain> References: <1150979242.2543.5.camel@localhost.localdomain> <449A9068.4080101@gmail.com> <1150981015.2543.10.camel@localhost.localdomain> Message-ID: <1150990255.90475.41.camel@D-MELENTYEV.HOME> ? ??, 22/06/2006 ? 05:56 -0700, Max Kanat-Alexander ?????: > On Thu, 2006-06-22 at 14:43 +0200, Fr?d?ric Buclin wrote: > > Much better is to pass $var to foo() as argument: foo($var). > > Yes, agreed. I also like this more than [local] our. > > I think > > only a few scripts use this kind of pseudo-global variables anyway. We > > should fix them (e.g. process_bug.cgi and maybe token.cgi too). > > Unfortunately, many scripts assume $cgi and $template are globals. I'm > working on that now. In some scripts I'm fixing the assumption. In > others I'm making them globals, depending on whichever is easier for > now. > > The only global we should normally have is $vars. Subroutines do have a > real reason to modify that. What about passing it to subroutine by reference? Or, use helpers like Bugzilla::cgi(), Bugzilla::template() or Bugzilla::vars() to get the instances (anyway by ref)? From lpsolit at gmail.com Fri Jun 23 09:57:33 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 23 Jun 2006 11:57:33 +0200 Subject: Bugzilla meetings: disappointment, disaster and chaos Message-ID: <449BBB0D.9090007@gmail.com> Hey all, "disappointment, disaster and chaos" Here are some of the words which appeared to summarize our last Bugzilla meeting which took place yesterday. And considering that all our meetings look similar (which is quite true), here is how we could summarize all our meetings on IRC. So you all remember that yesterday was a bit "special" with Mike Beltzner being our "special" guest. I invited him to let him share with us some of his experience about User Experience and what could be good for us to do in the near future to improve the UI of our product. And after 28 minutes started the chaos: this is chaos I don't know how you guys do meetings like this and expect to get anything done - Chaos because everybody started talking at the same time, mostly ignoring guest's review and interrupting him. Chaos also because comments appeared in the IRC channel faster than one could read. - Disaster because we haven't been able to take the best of what Mike Beltzner could offer. Maybe is this due to our inabilities to take decisions? If you want a UI module owner, nominate one. Stop saying you want it. If you want to do a full rewrite of the UI, say that. Tell me that incremental changes aren't what you're looking for. Tell me that you want to just say "fuck bugzilla 2.*, if people want better UI, they have to move to bugzilla 3.*" If I'm quoting Beltzner out of the context of the meeting, please those who attended tell me. - Disappointment because as being the one who invited him, I expected some better discussion, with less chaos and better decisions from our... ah yes, do we have module owners and leaderships? This email is not about debating about the lack of a UI module owner. This will be in a separate email I plan to write in a few minutes, to separate threads. This email is about the way we should manage our IRC meetings. Here is an example of how a meeting could take place (thanks to vladd for pointing me to this URL): http://fedoraproject.org/wiki/Ambassadors/Meetings/2006-06-15?action=AttachFile&do=get&target=fedora-ambassadors-2006-06-15.txt Pretty boring, isn't it? So what? How should we proceed? Someone suggested per /msg to moderate the meeting, for instance using /mode +m and giving voice /mode +v to the next speaker only (people could ask the moderator per /msg to talk, and the moderator would manage this). Is that what we should do to avoid these "caf? du commerce" talks? Or should we simply have leaders, owners or whatever you like who take decisions? LpSolit From gerv at mozilla.org Fri Jun 23 09:58:27 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jun 2006 10:58:27 +0100 Subject: SendSQL is GONE! In-Reply-To: <1150789465.5326.14.camel@localhost.localdomain> References: <1150789465.5326.14.camel@localhost.localdomain> Message-ID: <449BBB43.80803@mozilla.org> Max Kanat-Alexander wrote: > That is, SendSQL, FetchOneColumn(), all those things are GONE. But now you've broken all my patches! ;-) Well done :-) Gerv From lpsolit at gmail.com Fri Jun 23 10:03:46 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 23 Jun 2006 12:03:46 +0200 Subject: UI module owner Message-ID: <449BBC82.30209@gmail.com> Hi all, As said in my previous email, we definitely need a UI module owner. From what I have seen so far, Byron Jones (glob on IRC) seems a good candidate for this role. In my opinion, he has very good and sensible ideas. His last one can be seen at: http://landfill.bugzilla.org/tabbededitbug/show_bug.cgi?id=1 Assuming he could have limited time for this role, we could imagine that we have two co-owners (wurblzap, gandalf?). From what we saw in our last meeting, it seems we have no other choice. Thoughts? LpSolit From gerv at mozilla.org Fri Jun 23 10:23:22 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jun 2006 11:23:22 +0100 Subject: Bugzilla meetings: disappointment, disaster and chaos In-Reply-To: <449BBB0D.9090007@gmail.com> References: <449BBB0D.9090007@gmail.com> Message-ID: <449BC11A.9090603@mozilla.org> Fr?d?ric Buclin wrote: > So you all remember that yesterday was a bit "special" with Mike > Beltzner being our "special" guest. I invited him to let him share with > us some of his experience about User Experience and what could be good > for us to do in the near future to improve the UI of our product. Perhaps, in hindsight, our discussions on the future goals of the project and on the UI have not yet reached the point where inviting Mike to the meeting was the right thing to do. I actually think Mike's presence was pretty important, because he got us thinking in a goal-oriented way rather than just "Hey, would it be good to Ajax our interface a bit? What Ajaxy stuff do you think we should do, Mike?" > - Chaos because everybody started talking at the same time, mostly > ignoring guest's review and interrupting him. Chaos also because > comments appeared in the IRC channel faster than one could read. Are you saying that you asked Mike to do a UI review of Bugzilla, and this meeting was the time for him to present the results? If so: a) I didn't realise that (maybe I'm alone, maybe not) b) IRC is a really bad way to present the results of a usability review. > - Disappointment because as being the one who invited him, I expected > some better discussion, with less chaos and better decisions from our... > ah yes, do we have module owners and leaderships? Well, quite. We need to sort out our own problems first. > http://fedoraproject.org/wiki/Ambassadors/Meetings/2006-06-15?action=AttachFile&do=get&target=fedora-ambassadors-2006-06-15.txt > > Pretty boring, isn't it? So what? How should we proceed? I think a more important initial question is: why do we have IRC meetings? What do they give us that exchanging email on the mailing list does not? After all, they have some obvious disadvantages with respect to email, so if we are going to have them, we need to know what the advantages are, and why we need those advantages. Gerv From gerv at mozilla.org Fri Jun 23 10:31:10 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jun 2006 11:31:10 +0100 Subject: UI module owner In-Reply-To: <449BBC82.30209@gmail.com> References: <449BBC82.30209@gmail.com> Message-ID: <449BC2EE.8060605@mozilla.org> Fr?d?ric Buclin wrote: > As said in my previous email, we definitely need a UI module owner. From > what I have seen so far, Byron Jones (glob on IRC) seems a good > candidate for this role. In my opinion, he has very good and sensible > ideas. Let's step back again. 1) Why do we need a UI module owner at all? Suggested answer, for working purposes: because someone needs to take the final decisions about what changes we make to the UI. 2) What qualifications does such a person need? a) They need to have a consistent and coherent vision of what the UI should look and work like. b) Therefore, they need to have a good understanding of Bugzilla's target user market(s), and their needs. c) They need to have a good understanding of the basic principles of UI design and interaction design. Given that we are about to start doing work on personas to establish b), implying that we don't have a good idea of what the answer is, arguably now is not the time to be appointing a UI module owner because they wouldn't be able to do their job properly... Also, note that "has good ideas for UI changes we could make" is not a necessary qualification for UI module owner. They are not expected to come up with all the ideas themselves; the skill required is sorting the suggestions and arranging them into a coherent vision, saying Yes to some and No to others. In fact, arguably, the UI module owner should have no ideas of their own, because then they will treat all suggestions equally :-) > His last one can be seen at: > > http://landfill.bugzilla.org/tabbededitbug/show_bug.cgi?id=1 What problem is this change trying to solve? > Assuming he could have limited time for this role, we could imagine that > we have two co-owners (wurblzap, gandalf?). Why do we need UI co-owners? Why do we need two rather than one or three? What role does a UI co-owner serve? > From what we saw in our last meeting, it seems we have no other choice. Is it a good idea to make a "choice" because you have no other choices? We do have at least two other choices: a) decide never to have a UI owner b) decide to postpone the decision If you are arguing that we should appoint someone, you need to explain why those two options are the wrong thing to do. Gerv From kevin.benton at amd.com Fri Jun 23 16:08:28 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 23 Jun 2006 09:08:28 -0700 Subject: Bugzilla meetings: disappointment, disaster and chaos Message-ID: > "disappointment, disaster and chaos" Here are some of the words which > appeared to summarize our last Bugzilla meeting which took place > yesterday. And considering that all our meetings look similar (which is > quite true), here is how we could summarize all our meetings on IRC. ... much deleted ... > This email is not about debating about the lack of a UI module owner. > This will be in a separate email I plan to write in a few minutes, to > separate threads. This email is about the way we should manage our IRC > meetings. Here is an example of how a meeting could take place (thanks > to vladd for pointing me to this URL): ... more deleted ... I think it would be fair to say we ought to look at using Roberts Rules of Order (or some derivative) for the meeting. As an amateur radio operator and SkyWarn network manager, we had a protocol for handling emergency traffic. It seems the same methodology could be used in our meetings. If a moderator were appointed for each meeting, that moderator could take the lead on directing the conversation. If someone had something to say, the participant could simply do "/me raises hand" in the channel, then politely wait for the moderator to recognize him/her. As long as the person recognized continued to speak, they could pass the "speaker" role to others in the channel. I know, it sounds like a lot of red tape, but I think it (or something like it --- please!) would be better than what we have now. One of the challenges I've seen in the channel meetings is we get three or four discussions going at the same time. It's difficult to understand who is speaking to whom after a while. I like that we have a Wiki, but I think there are times when a blog (Wordpress?) would make more sense. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Fri Jun 23 16:32:44 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 23 Jun 2006 09:32:44 -0700 Subject: UI module owner Message-ID: > Fr?d?ric Buclin wrote: > > As said in my previous email, we definitely need a UI module owner. From > > what I have seen so far, Byron Jones (glob on IRC) seems a good > > candidate for this role. In my opinion, he has very good and sensible > > ideas. > > Let's step back again. > > 1) Why do we need a UI module owner at all? > > Suggested answer, for working purposes: because someone needs to take > the final decisions about what changes we make to the UI. > > 2) What qualifications does such a person need? > > a) They need to have a consistent and coherent vision of what the UI > should look and work like. > b) Therefore, they need to have a good understanding of Bugzilla's > target user market(s), and their needs. > c) They need to have a good understanding of the basic principles of UI > design and interaction design. > > Given that we are about to start doing work on personas to establish b), > implying that we don't have a good idea of what the answer is, arguably > now is not the time to be appointing a UI module owner because they > wouldn't be able to do their job properly... > > Also, note that "has good ideas for UI changes we could make" is not a > necessary qualification for UI module owner. They are not expected to > come up with all the ideas themselves; the skill required is sorting the > suggestions and arranging them into a coherent vision, saying Yes to > some and No to others. I don't disagree with any of this; however, by appointing an "interim UI module owner," we can have an individual charged with directing us toward a point where we have someone who meets the necessary qualities. By itself, that has significant advantages over asking the entire team to work in a coordinated way without having someone to coordinate things. If Bugzilla were my for-profit product and I knew I needed a completely re-designed UI and I didn't have the time or expertise to do it by myself, I would appoint an employee to oversee the task of getting it done. I wouldn't necessarily expect them to do the work, but I would charge that person with being responsible for the end result - a project manager. IMNSHO, that's what we really need for the UI module - a project manager. Because we're a volunteer organization, we need someone to step forward to the task. > In fact, arguably, the UI module owner should have no ideas of their > own, because then they will treat all suggestions equally :-) I'm all for anyone who can be reasonably impartial and fair regardless of whether or not they've made suggestions of their own. > > From what we saw in our last meeting, it seems we have no other choice. > > Is it a good idea to make a "choice" because you have no other choices? Actually, we choose whether or not we want to. We've chosen not to have a UI module owner/manager. > We do have at least two other choices: > > a) decide never to have a UI owner This hasn't been as effective as it could have been. > b) decide to postpone the decision Postpone it until what conditions are met? Who is going to be in charge of making sure those conditions get met? > If you are arguing that we should appoint someone, you need to explain > why those two options are the wrong thing to do. How about c)? (suggested above) What about d)? (someone else's better idea :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From gerv at mozilla.org Fri Jun 23 17:53:11 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jun 2006 18:53:11 +0100 Subject: UI module owner In-Reply-To: References: Message-ID: <449C2A87.9090509@mozilla.org> Kevin, Thanks for your thoughts, and for interacting with them in the way I intended :-) Benton, Kevin wrote: > If Bugzilla were my for-profit product and I knew I needed a > completely re-designed UI and I didn't have the time or expertise to > do it by myself, I would appoint an employee to oversee the task of > getting it done. Absolutely. However, "a completely re-designed UI" is not a goal - it's a means to some end. What is the goal we are trying to reach which requires we completely redesign the UI? If we decide that there is no such goal, then we don't need to redesign the UI, and we don't need a UI module owner (as much). Gerv From kevin.benton at amd.com Fri Jun 23 18:26:32 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 23 Jun 2006 11:26:32 -0700 Subject: UI module owner Message-ID: > Benton, Kevin wrote: > > If Bugzilla were my for-profit product and I knew I needed a > > completely re-designed UI and I didn't have the time or expertise to > > do it by myself, I would appoint an employee to oversee the task of > > getting it done. > > Absolutely. However, "a completely re-designed UI" is not a goal - it's > a means to some end. What is the goal we are trying to reach which > requires we completely redesign the UI? > > If we decide that there is no such goal, then we don't need to redesign > the UI, and we don't need a UI module owner (as much). Key - "as much" - I agree. It's not a bad idea for someone to still be a project manager over the overall UI, whether or not we need a redesign. We all know that the UI is a significant part of Bugzilla and probably deserves a lot of attention by itself. The challenge is to prevent "design by committee" problems that could arise out of over-managing projects. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Thu Jun 22 19:56:07 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 22 Jun 2006 12:56:07 -0700 Subject: mod_perl: "our" vs. "my" in CGI scripts Message-ID: > On Thu, 2006-06-22 at 14:43 +0200, Fr?d?ric Buclin wrote: > > Much better is to pass $var to foo() as argument: foo($var). > > Yes, agreed. > > > I think > > only a few scripts use this kind of pseudo-global variables anyway. We > > should fix them (e.g. process_bug.cgi and maybe token.cgi too). > > Unfortunately, many scripts assume $cgi and $template are globals. > I'm > working on that now. In some scripts I'm fixing the assumption. In > others I'm making them globals, depending on whichever is easier for > now. > > The only global we should normally have is $vars. Subroutines do > have a > real reason to modify that. I wonder, does it make sense to get rid of $vars completely and replace it in a part of our interface (maybe a UI class)? I don't know, but it seems to me that using a UI class to handle all the interaction with the user would be a better way to go than to have global $cgi and $vars floating around... :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From justdave at bugzilla.org Fri Jun 23 19:04:38 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 23 Jun 2006 15:04:38 -0400 Subject: UI module owner In-Reply-To: <449C2A87.9090509@mozilla.org> References: <449C2A87.9090509@mozilla.org> Message-ID: <449C3B46.7080504@bugzilla.org> Gervase Markham wrote on 6/23/06 1:53 PM: > Absolutely. However, "a completely re-designed UI" is not a goal - it's > a means to some end. What is the goal we are trying to reach which > requires we completely redesign the UI? > > If we decide that there is no such goal, then we don't need to redesign > the UI, and we don't need a UI module owner (as much). The goal is ease-of-use (people constantly complain that Bugzilla is too hard to use) and interoperability with mobile and accessibility devices. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From gerv at mozilla.org Fri Jun 23 19:28:23 2006 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Jun 2006 20:28:23 +0100 Subject: UI module owner In-Reply-To: <449C3B46.7080504@bugzilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> Message-ID: <449C40D7.8010207@mozilla.org> David Miller wrote: >> Absolutely. However, "a completely re-designed UI" is not a goal - it's >> a means to some end. What is the goal we are trying to reach which >> requires we completely redesign the UI? >> >> If we decide that there is no such goal, then we don't need to redesign >> the UI, and we don't need a UI module owner (as much). > > The goal is ease-of-use (people constantly complain that Bugzilla is too > hard to use) and interoperability with mobile and accessibility devices. I spent some time today working on the personas. It'll be interesting, when we are discussing them, to see which if any personas might use Bugzilla on a mobile device. Taking the accessibility one for a moment: if the goal is "make Bugzilla accessible" (to people with which sorts of disability? Do we include deaf-blind quadraplegics?), why is a _complete_ UI redesign required to achieve this? Also, for the ease-of-use goal: do we have any more specific data than "people complain Bugzilla is hard to use"? Is the entire UI so poor that a complete redesign is required? Or would we be better off finding the tasks that people find hardest, and incrementally improving the UI in those areas towards a defined goal? (The answer to these things may be yes; but they are questions we need to ask.) Gerv From justdave at bugzilla.org Fri Jun 23 20:12:26 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 23 Jun 2006 16:12:26 -0400 Subject: Project Blog and such In-Reply-To: References: Message-ID: <449C4B2A.4030404@bugzilla.org> Benton, Kevin wrote on 6/23/06 12:08 PM: > I like that we have a Wiki, but I think there are times when a blog > (Wordpress?) would make more sense. I'd been toying with the idea for a while of putting together a "Planet Bugzilla" if you will, kind of like Planet Mozilla, Planet Gnome, and so forth, but specifically for Bugzilla. There's enough Bugzilla devs that blog now to make it worthwhile I think. Would that be close to what you had in mind, or are you thinking more a general "devnews" type blog that we get a few people accounts to post to? -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Fri Jun 23 20:39:46 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 23 Jun 2006 16:39:46 -0400 Subject: UI module owner In-Reply-To: <449BBC82.30209@gmail.com> References: <449BBC82.30209@gmail.com> Message-ID: <449C5192.1040908@bugzilla.org> Fr?d?ric Buclin wrote on 6/23/06 6:03 AM: > As said in my previous email, we definitely need a UI module owner. I believe in the meeting yesterday I said (or at least I intended to if I didn't, I'm too lazy to go look at the transcript, so if I really didn't, consider this saying it) we were going to forgo picking an overall UI lead for the short term since nobody had stepped forward yet, and allow Gerv to spearhead the persona gathering. Once we had a lineup of UI goals based on those personas we'd attempt to get someone to spearhead the management of getting there (and by that point, because of the data gathering already done, people who might step up and do it would have a better idea what they're getting into instead of this nebulous "fix the UI" description that we have in front of us currently. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From kevin.benton at amd.com Fri Jun 23 20:59:02 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 23 Jun 2006 13:59:02 -0700 Subject: Project Blog and such Message-ID: > > I like that we have a Wiki, but I think there are times when a blog > > (Wordpress?) would make more sense. > > I'd been toying with the idea for a while of putting together a "Planet > Bugzilla" if you will, kind of like Planet Mozilla, Planet Gnome, and so > forth, but specifically for Bugzilla. > > There's enough Bugzilla devs that blog now to make it worthwhile I think. > > Would that be close to what you had in mind, or are you thinking more a > general "devnews" type blog that we get a few people accounts to post to? I really didn't have any specifics in mind other than I think it's appropriate that we're able to post major topics on the "blog" and see what follow-up comes back as part of the discussion of each issue. I see it as more than a mailing list, but not as restrictive as a Wiki if that make sense. For example - I wouldn't want to update a Wiki to change what someone else said, but I sure would want to be able to comment for public discussion. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Fri Jun 23 21:18:58 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Fri, 23 Jun 2006 14:18:58 -0700 Subject: UI module owner Message-ID: > David Miller wrote: > >> Absolutely. However, "a completely re-designed UI" is not a goal - it's > >> a means to some end. What is the goal we are trying to reach which > >> requires we completely redesign the UI? > >> > >> If we decide that there is no such goal, then we don't need to redesign > >> the UI, and we don't need a UI module owner (as much). > > > > The goal is ease-of-use (people constantly complain that Bugzilla is too > > hard to use) and interoperability with mobile and accessibility devices. > > I spent some time today working on the personas. It'll be interesting, > when we are discussing them, to see which if any personas might use > Bugzilla on a mobile device. > > Taking the accessibility one for a moment: if the goal is "make Bugzilla > accessible" (to people with which sorts of disability? Do we include > deaf-blind quadraplegics?), why is a _complete_ UI redesign required to > achieve this? > > Also, for the ease-of-use goal: do we have any more specific data than > "people complain Bugzilla is hard to use"? Is the entire UI so poor that > a complete redesign is required? Or would we be better off finding the > tasks that people find hardest, and incrementally improving the UI in > those areas towards a defined goal? > > (The answer to these things may be yes; but they are questions we need > to ask.) I agree. I also think we ought to consider our overall goals. I've lost track of how many times we've seen the "custom fields" discussion flare up, yet I haven't seen anyone discuss how to comprehensively integrate those fields into the UI. I think it'd be good if we had a real poll of some sort asking users what they think the most important improvements to Bugzilla would be first before getting overly drawn into the UI specifics. I can tell you that some of the customizations we have are: ChangeStatusToNewOnReassign (as an optional field) Commitment DesignStage ErrataToRev FoundInRev FixedInRev NoOpSys ReassignOnClosure ReassignOnReopen ReassignOnResolve ReassignOnVerify rep_platform (as an optional field) ThirdPartyEmailGateway InitalCCList ... Finding a good way to display those customizations reliably without messing up the other displays was a challenge, but not a big deal. Doing that for custom fields may be more difficult though I can think of a display model that might work that would involve allowing admins to decide where custom fields appear relative to other fields. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From justdave at bugzilla.org Fri Jun 23 22:32:29 2006 From: justdave at bugzilla.org (David Miller) Date: Fri, 23 Jun 2006 18:32:29 -0400 Subject: UI module owner In-Reply-To: <449C40D7.8010207@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> Message-ID: <449C6BFD.8000708@bugzilla.org> Gervase Markham wrote on 6/23/06 3:28 PM: > I spent some time today working on the personas. It'll be interesting, > when we are discussing them, to see which if any personas might use > Bugzilla on a mobile device. I gotta wonder how important actually putting names and pictures on them is. :) Makes it look pretty > Taking the accessibility one for a moment: if the goal is "make Bugzilla > accessible" (to people with which sorts of disability? Do we include > deaf-blind quadraplegics?), why is a _complete_ UI redesign required to > achieve this? I don't think a complete redesign is needed to achieve that. In fact, the app is pretty decently accessible now (we've reordered table cells and everything to make the pages flow nicely in screen readers for example). I think that portion of the goal is more of a "let's not break that along the way, or keep that stuff in mind as you design new things." > Also, for the ease-of-use goal: do we have any more specific data than > "people complain Bugzilla is hard to use"? Is the entire UI so poor that > a complete redesign is required? Or would we be better off finding the > tasks that people find hardest, and incrementally improving the UI in > those areas towards a defined goal? I don't think we need a complete redesign at all. Perhaps one or two screens might, for workflow reasons, but that's an answer we probably won't have until we have our use cases put together. It can certainly use from prettying up and organization though. :) I think a lot of it isn't necessarily really hard to use, just that it's information overload because there's so much data visible on a bug. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Sat Jun 24 00:05:18 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Jun 2006 17:05:18 -0700 Subject: UI module owner In-Reply-To: <449BBC82.30209@gmail.com> References: <449BBC82.30209@gmail.com> Message-ID: <1151107518.2344.35.camel@es-lappy> On Fri, 2006-06-23 at 12:03 +0200, Fr?d?ric Buclin wrote: > As said in my previous email, we definitely need a UI module owner. From > what I have seen so far, Byron Jones (glob on IRC) seems a good > candidate for this role. In my opinion, he has very good and sensible > ideas. His last one can be seen at: Except that he isn't around to do reviews much, right? I think we need a UI Designer more than we need a UI Owner. We do have gandalf for the Designer part, to a large extent. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Sat Jun 24 00:04:11 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Jun 2006 17:04:11 -0700 Subject: Bugzilla meetings: disappointment, disaster and chaos In-Reply-To: <449BBB0D.9090007@gmail.com> References: <449BBB0D.9090007@gmail.com> Message-ID: <1151107451.2344.33.camel@es-lappy> On Fri, 2006-06-23 at 11:57 +0200, Fr?d?ric Buclin wrote: > Pretty boring, isn't it? So what? How should we proceed? The way we have meetings normally is fine, when you, I, and justdave are there. If we're not there or can't pay attention to the meeting, we need to appoint somebody who confidently feels they can control the meeting, and who has admin rights. If the meeting gets hectic, there's nothing wrong with temporarily +m'ing the channel. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Sat Jun 24 00:08:03 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Jun 2006 17:08:03 -0700 Subject: mod_perl: "our" vs. "my" in CGI scripts In-Reply-To: References: Message-ID: <1151107683.2344.38.camel@es-lappy> On Thu, 2006-06-22 at 12:56 -0700, Benton, Kevin wrote: > I wonder, does it make sense to get rid of $vars completely and > replace it in a part of our interface (maybe a UI class)? I considered making a Bugzilla->template_vars. We could also make it a property of Bugzilla::Template, perhaps, which would make sense. At this point it would a pretty significant coding effort to change it, and I don't think I'd be doing it any time soon. Though anybody with extra time on their hands is welcome to suggest and implement something. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Sat Jun 24 00:01:43 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Jun 2006 17:01:43 -0700 Subject: mod_perl: "our" vs. "my" in CGI scripts In-Reply-To: <1150990255.90475.41.camel@D-MELENTYEV.HOME> References: <1150979242.2543.5.camel@localhost.localdomain> <449A9068.4080101@gmail.com> <1150981015.2543.10.camel@localhost.localdomain> <1150990255.90475.41.camel@D-MELENTYEV.HOME> Message-ID: <1151107303.2344.31.camel@es-lappy> On Thu, 2006-06-22 at 18:30 +0300, Dennis Melentyev wrote: > > The only global we should normally have is $vars. Subroutines do have a > > real reason to modify that. > > What about passing it to subroutine by reference? I think it's easier to make that one variable ($vars) be global. Most of our scripts already assume it is anyway. > Or, use helpers like > Bugzilla::cgi(), Bugzilla::template() or Bugzilla::vars() to get the > instances (anyway by ref)? That's what I do in my patch, except in files where it would have been a huge effort. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Sat Jun 24 00:10:12 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Jun 2006 17:10:12 -0700 Subject: Project Blog and such In-Reply-To: <449C4B2A.4030404@bugzilla.org> References: <449C4B2A.4030404@bugzilla.org> Message-ID: <1151107812.2344.41.camel@es-lappy> On Fri, 2006-06-23 at 16:12 -0400, David Miller wrote: > I'd been toying with the idea for a while of putting together a "Planet > Bugzilla" if you will, kind of like Planet Mozilla, Planet Gnome, and so > forth, but specifically for Bugzilla. I like that idea. The only problem is that my blog is a LiveJournal, and it's simultaneously my technical blog and personal blog. I'd only want the technical posts (all tagged as "tech") on Planet, but LiveJournal doesn't have a way to syndicate only certain tags. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From mkanat at bugzilla.org Sat Jun 24 00:14:04 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 23 Jun 2006 17:14:04 -0700 Subject: UI module owner In-Reply-To: <449C5192.1040908@bugzilla.org> References: <449BBC82.30209@gmail.com> <449C5192.1040908@bugzilla.org> Message-ID: <1151108044.2344.46.camel@es-lappy> On Fri, 2006-06-23 at 16:39 -0400, David Miller wrote: > Once we had a lineup > of UI goals based on those personas we'd attempt to get someone to > spearhead the management of getting there [snip] I'd feel capable of doing it. I've been extremely occupied with mod_perl, though, and I'm going to probably be quite occupied with XML-RPC sometime in the coming future. I have some definite ideas about Bugzilla's UI, but I've never had the time to even write them down in a sensible way. I'm not promising that I *can* do it, I'm just saying that it's a possibility. I know some folks who are UI designers or usability experts, also, and maybe I can convince them to contribute a little time to Bugzilla and give us some direction. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From dennis.melentyev at infopulse.com.ua Sun Jun 25 10:39:57 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Sun, 25 Jun 2006 13:39:57 +0300 Subject: UI module owner In-Reply-To: <449C40D7.8010207@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> Message-ID: <1151231997.90475.69.camel@D-MELENTYEV.HOME> ? ??, 23/06/2006 ? 20:28 +0100, Gervase Markham ?????: [...] > Also, for the ease-of-use goal: > do we have any more specific data than > "people complain Bugzilla is hard to use"? Well... Trying to put some more specific data, I'd say: Bugzilla UI (Search page at the first place followed closely by bug entry page) are way too overloaded with controls and lots of them are not intuitive. It's getting intuitive when you getting more and more familiar with Bugzilla process, but is a complete mess for a newbie. IMO the best idea is to have a wizard-like search and bug entry pages, with ability to switch back to current pages when "the wizard" will start abuse you. > Is the entire UI so poor that > a complete redesign is required? There are also some design/style issues. It doesn't looks sexy/serious/cool/whatever word you know for a big, well-known and full featured application. It looks like knee-knitted helper thingy. This doesn't mean any functionality is missed. It just does not impress from the very first look :) > Or would we be better off finding the > tasks that people find hardest, and incrementally improving the UI in > those areas towards a defined goal? As for the previous issue, I think out there should be a lot of young and clever web-designers who would be able to create a couple of good skins while on summer vacation. Yet another idea is to have several default (pre-shipped?) skins selectable by USER in his profile: 1. Just current (classic) skin 2. Sexy-dumb-n-bullet-proof-wizardry (anyway, we definitely need one for collecting bug reports from customers, who could not always be smart!) 3. wap-enabled minimalistic 4. special skin for disabled people All this skins should have some requirements, like #2 require CSS/JavaScript/other modern features while #1 should be lynx-friendly. We do have all inder the hood to do that, just missed this idea for Google Summer of Code. :) > (The answer to these things may be yes; but they are questions we need > to ask.) 100% agree. From bugzilla at glob.com.au Sun Jun 25 15:26:34 2006 From: bugzilla at glob.com.au (byron) Date: Sun, 25 Jun 2006 23:26:34 +0800 Subject: UI module owner In-Reply-To: <449BBC82.30209@gmail.com> References: <449BBC82.30209@gmail.com> Message-ID: <20060625152634.GA9255@bur.st> Looks like I missed a bit, so forgive me for replying to a collection of points from different threads.. > As said in my previous email, we definitely need a UI module owner. > From what I have seen so far, Byron Jones (glob on IRC) seems a good > candidate for this role. In my opinion, he has very good and sensible > ideas. While I sincerely appreciate the sentiment, I fear that if don't have the time nor the skill set to act as an overall UI module owner. As Max pointed out, you'd want someone who is available more often than I am in order to get stuff reviewed. > There are also some design/style issues. It doesn't looks > sexy/serious/cool/whatever word you know for a big, well-known and > full featured application. It looks like knee-knitted helper thingy. > This doesn't mean any functionality is missed. It just does not impress > from the very first look :) I second that. > http://landfill.bugzilla.org/tabbededitbug/show_bug.cgi?id=1 > What problem is this change trying to solve? Bluntly: Bugzilla is ugly. I'm trying to make it prettier. By splitting the page into tabs it gives us the room to layout the sections in a way that's clear instead of having to squeeze it into the space that currently exists. begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== ==== From vladd at bugzilla.org Sun Jun 25 23:08:50 2006 From: vladd at bugzilla.org (Vlad Dascalu) Date: Sun, 25 Jun 2006 16:08:50 -0700 (PDT) Subject: UI module owner In-Reply-To: <1151231997.90475.69.camel@D-MELENTYEV.HOME> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> Message-ID: <42842.86.124.16.68.1151276930.squirrel@syndicomm.com> Hey, > IMO the best idea is to have a wizard-like search and bug entry pages, > with ability to switch back to current pages when "the wizard" will > start abuse you. Actually if you recently checked the trunk, it has a great UI for uploading a new attachment right on the new bug entry form. The entire UI (made by Marc) is a single clickable button, "Add an attachment". When you click it, the entire contents of the add attachment form (which was hidden until now) unfolds, and the user can upload the attachment. Clicking the button again restores the previous UI. It's hard to describe in words, but it really kicks asses. Instead of wizards or tabs, I'd suggest something like that from place to place to hide out complexity. When the user needs something, he can click the button (we could have several of them, each one having as label an important topic or category-name in a given taxonomy) and have the form in front. I prefer this approach to the wizard/tab thing, but there's also the Lynx support decision issue. The UI requires Javascript, I think. I invite you to check it out on Bugzilla-trunk if you haven't already: http://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi?product=FoodReplicator --Vlad From dennis.melentyev at infopulse.com.ua Mon Jun 26 08:29:27 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Mon, 26 Jun 2006 11:29:27 +0300 Subject: UI module owner In-Reply-To: <42842.86.124.16.68.1151276930.squirrel@syndicomm.com> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <42842.86.124.16.68.1151276930.squirrel@syndicomm.com> Message-ID: <1151310567.90475.91.camel@D-MELENTYEV.HOME> ? ??, 25/06/2006 ? 16:08 -0700, Vlad Dascalu ?????: > Hey, > > > IMO the best idea is to have a wizard-like search and bug entry pages, > > with ability to switch back to current pages when "the wizard" will > > start abuse you. > > Actually if you recently checked the trunk, it has a great UI for > uploading a new attachment right on the new bug entry form. It's nice. Could we change all other operations in Bugzilla to use this UI approach? Just for consistency of Look'n'Feel. > Instead of wizards or tabs, I'd suggest something like that from place to > place to hide out complexity. When the user needs something, he can click > the button (we could have several of them, each one having as label an > important topic or category-name in a given taxonomy) and have the form in > front. Well, just to put another point of view: Why don't have a button on top of the window and clicking it will just hide/unhide controls at the same place? But that would be the tabbed view again :) And, also lynx - compatible (if it can do JavaScript and css properties like visibility) > I prefer this approach to the wizard/tab thing, but there's also the Lynx > support decision issue. The UI requires Javascript, I think. Yes. I definitely like this approach. OTOH, wizard/tabbed is good for newbies. It guides them through all the required fields, probably providing help/hints text boxes. Anyway, do we have any real web-designer? I mean not coder, but stylist / UI profi. > I invite you to check it out on Bugzilla-trunk if you haven't already: > > http://landfill.bugzilla.org/bugzilla-tip/enter_bug.cgi?product=FoodReplicator > Thanks for the link. From gerv at mozilla.org Mon Jun 26 08:41:00 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 09:41:00 +0100 Subject: UI module owner In-Reply-To: <449C6BFD.8000708@bugzilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <449C6BFD.8000708@bugzilla.org> Message-ID: <449F9D9C.9050202@mozilla.org> David Miller wrote: > I gotta wonder how important actually putting names and pictures on them > is. :) Makes it look pretty It's extremely important. If the personas aren't people, then you can't identify with them, and you end up just substituting the phrase "the personas" for "the users" and your discussion is no further forward. >> Taking the accessibility one for a moment: if the goal is "make Bugzilla >> accessible" (to people with which sorts of disability? Do we include >> deaf-blind quadraplegics?), why is a _complete_ UI redesign required to >> achieve this? > > I don't think a complete redesign is needed to achieve that. In fact, > the app is pretty decently accessible now (we've reordered table cells > and everything to make the pages flow nicely in screen readers for > example). I think that portion of the goal is more of a "let's not > break that along the way, or keep that stuff in mind as you design new > things." I agree. So, the original question: what goal are we trying to reach with "a completely re-designed UI"? (That's not my phrase.) > I don't think we need a complete redesign at all. Perhaps one or two > screens might, for workflow reasons, but that's an answer we probably > won't have until we have our use cases put together. It can certainly > use from prettying up and organization though. :) I think a lot of it > isn't necessarily really hard to use, just that it's information > overload because there's so much data visible on a bug. Let's say, for the sake of argument, that we have identified "information overload" as a problem with the current interface. Then we ask: - Which personas suffer from information overload? - Do each of those personas actually need all the information presented, or is some never useful? - If they need it all, do they need it all at the same time, or do they need different information for different tasks? My point here is that the "tabbed show_bug" UI that has been mentioned earlier in this thread seems guaranteed to make sure that no-one _ever_ has all the information they want in front of them at once. We need some much more careful analysis of the problem before we start showing/hiding bits. Gerv From gerv at mozilla.org Mon Jun 26 08:40:57 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 09:40:57 +0100 Subject: UI module owner In-Reply-To: <1151231997.90475.69.camel@D-MELENTYEV.HOME> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> Message-ID: <449F9D99.8020501@mozilla.org> Dennis Melentyev wrote: > ? ??, 23/06/2006 ? 20:28 +0100, Gervase Markham ?????: > [...] >> Also, for the ease-of-use goal: >> do we have any more specific data than >> "people complain Bugzilla is hard to use"? > Well... Trying to put some more specific data, I'd say: > Bugzilla UI (Search page at the first place followed closely by bug > entry page) are way too overloaded with controls and lots of them are > not intuitive. So we ask: - Are all the controls necessary? - Which controls are used more and which less? (We could get such data by instrumenting bugzilla.mozilla.org) - Which ones do people classify as "not intuitive"? - Can we fix that by changing the widget used to make them work more like people expect? - Does anyone actually do complicated searches, or are 100% of Bugzilla searches merely searches on Subject? - If we don't have a page with all the controls on somewhere, how are people going to be able to do those complicated searches? > It's getting intuitive when you getting more and more familiar with > Bugzilla process, but is a complete mess for a newbie. So we ask: - Is that page supposed to be used by newbies? > IMO the best idea is to have a wizard-like search and bug entry pages, > with ability to switch back to current pages when "the wizard" will > start abuse you. What, like the guided bug entry page we already have? :-) > There are also some design/style issues. It doesn't looks > sexy/serious/cool/whatever word you know for a big, well-known and full > featured application. It looks like knee-knitted helper thingy. This > doesn't mean any functionality is missed. It just does not impress from > the very first look :) So we ask: - Which of our personas cares about sexiness/coolness? (If the answer is "none", it doesn't mean we can't make it look more sexy. It just means that it's not a high priority.) > Yet another idea is to have several default (pre-shipped?) skins > selectable by USER in his profile: This clearly has a maintenance cost, so we ask: - Which persona needs this feature, and why? > 1. Just current (classic) skin > 2. Sexy-dumb-n-bullet-proof-wizardry (anyway, we definitely need one for > collecting bug reports from customers, who could not always be smart!) We already have customisation mechanisms for this sort of thing; and it's not called a "skin". > 3. wap-enabled minimalistic Which persona needs to access Bugzilla over WAP, and why? Gerv From gerv at mozilla.org Mon Jun 26 09:32:27 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 10:32:27 +0100 Subject: UI module owner In-Reply-To: <20060625152634.GA9255@bur.st> References: <449BBC82.30209@gmail.com> <20060625152634.GA9255@bur.st> Message-ID: <449FA9AB.4030107@mozilla.org> byron wrote: >> http://landfill.bugzilla.org/tabbededitbug/show_bug.cgi?id=1 >> What problem is this change trying to solve? > > Bluntly: Bugzilla is ugly. I'm trying to make it prettier. > > By splitting the page into tabs it gives us the room to layout the > sections in a way that's clear instead of having to squeeze it into the > space that currently exists. You realise these two paragraphs are entirely different motivations? The first is an argument from aesthetics; the second is an argument from usability. Taking the usability argument: A web page has an infinite amount of space available; you just keep going down the page. So presumably you have an extra, implicit constraint "and keep it all within the size of a single screenful"? If so, why is that a constraint? - Why is the current layout "unclear"? - Why does a new "clear" layout need more room than an unclear layout? That is to say, what makes you think that lack of whitespace separation between the fields is the cause of the unclarity? - Why did you choose tabs rather than e.g. collapsible sections, or role-based style sheets which hide some of the fields? I suggest (although, as I've said in other messages, we'd need some metrics) that the tabs would be a major usability decrease, because people would be endlessly switching tabs to try and take in an overall view of the state of the bug. Did you consider the workflows of different types of Bugzilla user when deciding how many tabs to have, and which fields to put on each? Gerv From dennis.melentyev at infopulse.com.ua Mon Jun 26 10:07:32 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Mon, 26 Jun 2006 13:07:32 +0300 Subject: UI module owner In-Reply-To: <449F9D99.8020501@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> Message-ID: <1151316452.90475.142.camel@D-MELENTYEV.HOME> ? ??, 26/06/2006 ? 09:40 +0100, Gervase Markham ?????: > Dennis Melentyev wrote: > > ? ??, 23/06/2006 ? 20:28 +0100, Gervase Markham ?????: > > [...] > >> Also, for the ease-of-use goal: > >> do we have any more specific data than > >> "people complain Bugzilla is hard to use"? > > Well... Trying to put some more specific data, I'd say: > > Bugzilla UI (Search page at the first place followed closely by bug > > entry page) are way too overloaded with controls and lots of them are > > not intuitive. > > So we ask: > > - Are all the controls necessary? > - Which controls are used more and which less? > (We could get such data by instrumenting bugzilla.mozilla.org) > - Which ones do people classify as "not intuitive"? > - Can we fix that by changing the widget used to make them work more > like people expect? Some controls are definitely "Advanced". Will try to collect opinions of our developers on this. (Idea! Need to add a usability survey link to useful-links! :) I really like the way it done in tabbed show_bug. But I'd rather move all comments to their own tab. > - Does anyone actually do complicated searches, or are 100% of Bugzilla > searches merely searches on Subject? > - If we don't have a page with all the controls on somewhere, how are > people going to be able to do those complicated searches? I have to do a lot of reports and even more, I can't do some searches, so I had to hack a page for some special ones (not usable for others and definitely lacks security). But, basic search is too minimalistic, while advanced is over-bloated for freshmens. So we need something in between for them and better structured advanced view (better separated/grouped visually). > > It's getting intuitive when you getting more and more familiar with > > Bugzilla process, but is a complete mess for a newbie. > > So we ask: > > - Is that page supposed to be used by newbies? No. But they do often need somewhat advanced, but not over-helming pages. Another user role is "Customer The Great" often under-qualified to fill-out all controls, not patient and not willing to learn this "ugly pages". But their reports are gold for us. Yes, It is already customizable, but this increase the cost of ownership. Well, this might be answered like "so go'n'buy any commercial soft!", but we are here to develop/promote Bugzilla, aren't we? > > IMO the best idea is to have a wizard-like search and bug entry pages, > > with ability to switch back to current pages when "the wizard" will > > start abuse you. > > What, like the guided bug entry page we already have? :-) Which one? bugzilla.mozilla.org? Kind of... But in distrib. (I could miss recent 1-2 month changes at tip) > > There are also some design/style issues. It doesn't looks > > sexy/serious/cool/whatever word you know for a big, well-known and full > > featured application. It looks like knee-knitted helper thingy. This > > doesn't mean any functionality is missed. It just does not impress from > > the very first look :) > > So we ask: > > - Which of our personas cares about sexiness/coolness? > > (If the answer is "none", it doesn't mean we can't make it look more > sexy. It just means that it's not a high priority.) Yeah, It isn't high priority task. But Bugzilla as a product suffer from that. Just try to imagine it a commercial product with just price cut down to zero. > > Yet another idea is to have several default (pre-shipped?) skins > > selectable by USER in his profile: > > This clearly has a maintenance cost, so we ask: > > - Which persona needs this feature, and why? Every company it uses. Because of TCO and general attractiveness (Is there such a word in English? :). > > 1. Just current (classic) skin > > 2. Sexy-dumb-n-bullet-proof-wizardry (anyway, we definitely need one for > > collecting bug reports from customers, who could not always be smart!) > > We already have customisation mechanisms for this sort of thing; and > it's not called a "skin". We just need a samples bundled in distro. > > > 3. wap-enabled minimalistic > > Which persona needs to access Bugzilla over WAP, and why? Dunno, someone just mentioned it here :) From gerv at mozilla.org Mon Jun 26 10:27:17 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 11:27:17 +0100 Subject: UI module owner In-Reply-To: <1151316452.90475.142.camel@D-MELENTYEV.HOME> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> Message-ID: <449FB685.5070305@mozilla.org> Dennis Melentyev wrote: > Some controls are definitely "Advanced". - For whom are they "definitely Advanced"? One person's advanced control may be another's most important. > Will try to collect opinions of > our developers on this. (Idea! Need to add a usability survey link to > useful-links! :) Of course, this survey will not necessarily shed light on the views of all of Bugzilla's focal personas. I guess it depends what sort of people you have working for you. If you are going to do a survey, please try and separate out the views of coders, managers and QA people into separate pots. >> - Does anyone actually do complicated searches, or are 100% of Bugzilla >> searches merely searches on Subject? >> - If we don't have a page with all the controls on somewhere, how are >> people going to be able to do those complicated searches? > I have to do a lot of reports and even more, I can't do some searches, so I had to hack a page for some special ones (not usable for others and definitely lacks security). > But, basic search is too minimalistic, while advanced is over-bloated > for freshmens. Why is basic search "too minimalistic"? And for whom? I assume you don't mean "because it doesn't have enough widgets"; so do you mean "because it doesn't find what you want some of the time"? If so, an alternative solution would be to consider looking at ways to improve the quality of the search results returned by the basic search. That would benefit everyone. >>> It's getting intuitive when you getting more and more familiar with >>> Bugzilla process, but is a complete mess for a newbie. >> So we ask: >> >> - Is that page supposed to be used by newbies? > No. But they do often need somewhat advanced, but not over-helming > pages. What evidence do you have that people who have graduated from the simple search form (and therefore already have some familiarity with Bugzilla) still find the complicated one hard to understand? > Another user role is "Customer The Great" often under-qualified to > fill-out all controls, not patient and not willing to learn this "ugly > pages". But their reports are gold for us. Why are you pointing your customers at the advanced search page? What do you expect them to accomplish there? > Yes, It is already customizable, but this increase the cost of > ownership. So Bugzilla needs to ship with versions of the search page to meet every possible need from every company which uses it? >>> IMO the best idea is to have a wizard-like search and bug entry pages, >>> with ability to switch back to current pages when "the wizard" will >>> start abuse you. >> What, like the guided bug entry page we already have? :-) > Which one? bugzilla.mozilla.org? Kind of... But in distrib. (I could > miss recent 1-2 month changes at tip) We do distribute it, and have for years. It's create-guided.html.tmpl. >> - Which of our personas cares about sexiness/coolness? >> >> (If the answer is "none", it doesn't mean we can't make it look more >> sexy. It just means that it's not a high priority.) > Yeah, It isn't high priority task. But Bugzilla as a product suffer from > that. > Just try to imagine it a commercial product with just price cut down to > zero. But Bugzilla is not a proprietary product with a price of zero. If it was, most of us wouldn't be working on it. Let's turn the question on its head: is one of the goals of the Bugzilla project to get as many companies and organisations using it as possible? As this is a value judgement, personal opinions are allowed :-) I personally don't think that should be a particularly high priority goal. Clearly, it's not good to have only a few places using it - but we are well past that stage. >>> Yet another idea is to have several default (pre-shipped?) skins >>> selectable by USER in his profile: >> This clearly has a maintenance cost, so we ask: >> >> - Which persona needs this feature, and why? > Every company it uses. Because of TCO and general attractiveness (Is > there such a word in English? :). Re-skinning an application (in the usual sense of the word "skin" - i.e. changing colours and logos) has no effect on TCO. >>> 1. Just current (classic) skin >>> 2. Sexy-dumb-n-bullet-proof-wizardry (anyway, we definitely need one for >>> collecting bug reports from customers, who could not always be smart!) >> We already have customisation mechanisms for this sort of thing; and >> it's not called a "skin". > We just need a samples bundled in distro. They are. Gerv From bugzilla at joostdevalk.nl Mon Jun 26 10:28:10 2006 From: bugzilla at joostdevalk.nl (Joost de Valk) Date: Mon, 26 Jun 2006 12:28:10 +0200 Subject: UI module owner In-Reply-To: <449F9D99.8020501@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> Message-ID: <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> Just a quick note: > - Does anyone actually do complicated searches, or are 100% of > Bugzilla > searches merely searches on Subject? Yes. I know for a fact that on bugzilla.opendarwin.org complicated searches are used a LOT. Problem is that searching with dates is not intuitive, and that there's no help available in the advanced search form to tell you that you need to do "-2w" for the last two weeks, or stuff like that. Regards, Joost From gerv at mozilla.org Mon Jun 26 11:03:04 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 12:03:04 +0100 Subject: UI module owner In-Reply-To: <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> Message-ID: <449FBEE8.3050000@mozilla.org> Joost de Valk wrote: > Just a quick note: > >> - Does anyone actually do complicated searches, or are 100% of Bugzilla >> searches merely searches on Subject? Just to be clear: that was a rhetorical question, used to demonstrate the sort of things we should be asking. I'm 100% sure, even without doing any research, that not every single search on Bugzilla is merely a search on Subject, because I do some complex searches myself :-) > Yes. I know for a fact that on bugzilla.opendarwin.org complicated > searches are used a LOT. Problem is that searching with dates is not > intuitive, and that there's no help available in the advanced search > form to tell you that you need to do "-2w" for the last two weeks, or > stuff like that. Ah, now you see, this is a much more specific usability issue, rather than "it's all hard to use/unintuitive". Do any of the people find it this problem ever click the "Give me some help" link at the top of the page? If not, why not - because they didn't notice it? Because they didn't think it would help? If they do, did they figure out how the help system worked? Did they get the info from hovering over the Date boxes? Was it sufficient? Gerv From timeless at gmail.com Mon Jun 26 11:13:23 2006 From: timeless at gmail.com (timeless) Date: Mon, 26 Jun 2006 14:13:23 +0300 Subject: UI module owner In-Reply-To: <449FB685.5070305@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> Message-ID: <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> On 6/26/06, Gervase Markham wrote: > So Bugzilla needs to ship with versions of the search page to meet every > possible need from every company which uses it? Bugzilla should ship such that most companies don't feel the need to implement dozens of horrible hacks that cause them to refuse to upgrade to a newer version of Bugzilla later. > Let's turn the question on its head: is one of the goals of the Bugzilla > project to get as many companies and organisations using it as possible? Bugzilla should be the standard tracking system that companies and organizations use, so that when I have a problem with any product anywhere, I can turn to a comfortable fairly standard Bugzilla installation which I can easily log into, select my standard per user custom settings and feel right at home explaining my problem or finding out the status of a preexisting report that I was able to find about my problem. Bugzilla should enable any company to easily send a problem report to the next company or organization's Bugzilla without resorting to hacks. Note that in almost all cases this communication is bidirectional, it's not just a "move", it's some sort of "keep these bugs in sync" or "share comments across bugs" or "establish a dependency between these bugs". It's fairly rare for anything to be a simple "move" (the hack implemented for bugscape), most customers or consumers appreciate at least being told "this is fixed in the next version" and "the next version shipped with this fixed, you can actually download it now", which are things you don't get if you just "move" a bug. > Clearly, it's not good to have only a few places using it - but we are > well past that stage. It's not good for every single consumer of this product to fork it just to make it work for them. It's not good for every single organization that does this to end up w/ dozens or hundreds of complaints which are lost in some internal problem report area. Every single organization I visit is either using or has tried to setup or use (sometimes both depending on the size of the organization) Bugzilla, and they all have valuable feedback about what's wrong or unusable about it. But we lose most of that feedback because it's internal. > Re-skinning an application (in the usual sense of the word "skin" - i.e. > changing colours and logos) has no effect on TCO. The skinning we're interested in is more akin to guided, it's not the same as modern v. classic, it's the difference between advanced and simplified. > > We just need a samples bundled in distro. > They are. We have samples half bundled, we still have people asking how to integrate things very much like the guided entry form, which if they were fully integrated shouldn't happen. From timeless at gmail.com Mon Jun 26 11:39:19 2006 From: timeless at gmail.com (timeless) Date: Mon, 26 Jun 2006 14:39:19 +0300 Subject: UI module owner In-Reply-To: <449FBEE8.3050000@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> <449FBEE8.3050000@mozilla.org> Message-ID: <1a75cc570606260439j7cff7b38x8c5ab6719dd6f072@mail.gmail.com> Gerv wrote: > Do any of the people find it this problem ever click the "Give me some > help" link at the top of the page? I've never seen or heard of anyone clicking it. But let's pretend I did. Zero, there's no What's This widget by that link, so I'd never click it. First, there's no hint as to which things have help, so I don't know what I can hover over, simply using dotted or doubled underlines would help (alternatively offering whats this hover anchors would also work). Second, here's the actual help text for that box: Specify the start and end dates either in YYYY-MM-DD format (optionally followed by HH:mm, in 24 hour clock), or in relative dates such as 1d, 2w, 3m, 4y, which respectively mean one day, two weeks, three months, or four years ago. 0d is last midnight, and 0w, 0m, 0y is the beginning of this week, month, or year. What part of this says to use -2m or -2w or -*ANYTHING* if you want to go backwards?! > If not, why not - because they didn't notice it? > Because they didn't think it would help? Having used it once, I can assure you, I'd never use it again, it's barely more helpful than a Unix document. Even Microsoft help which people love to complain about is considerably better. Especially given that the number one search anyone ever wants to do is something like -1m. The problem here is that we don't give people examples or walk through documents for using our features. If you show anyone how to use these features it becomes instantly intuitive and they'll remember and use it (ask smaug, I showed him over the weekend), but no one will guess. > If they do, did they figure out how the help system worked? This is "First" in my list > Did they get the info from hovering over the Date boxes? > Was it sufficient? This is "Second" in my list. From gerv at mozilla.org Mon Jun 26 11:44:55 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 12:44:55 +0100 Subject: UI module owner In-Reply-To: <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> Message-ID: <449FC8B7.5030200@mozilla.org> timeless wrote: > Bugzilla should ship such that most companies don't feel the need to > implement dozens of horrible hacks that cause them to refuse to > upgrade to a newer version of Bugzilla later. Gregg completely agrees with you. http://wiki.mozilla.org/Bugzilla:Personas:Gregg (BTW, everyone, the personas are still works in progress. Let me do a bit more work before you lay into them :-)) > Bugzilla should be the standard tracking system that companies and > organizations use, so that when I have a problem with any product > anywhere, I can turn to a comfortable fairly standard Bugzilla > installation which I can easily log into, select my standard per user > custom settings and feel right at home explaining my problem or > finding out the status of a preexisting report that I was able to find > about my problem. How likely do you think it is that these different companies/organisations requirements will be similar enough that all the Bugzillas will be "fairly standard"? Thought: none of the current personas use multiple Bugzillas. Does that mean that this is a niche use, or that we've failed to capture something in the existing persona set? > Bugzilla should enable any company to easily send a problem report to > the next company or organization's Bugzilla without resorting to > hacks. Note that in almost all cases this communication is > bidirectional, it's not just a "move", it's some sort of "keep these > bugs in sync" or "share comments across bugs" or "establish a > dependency between these bugs". It's fairly rare for anything to be a > simple "move" (the hack implemented for bugscape), most customers or > consumers appreciate at least being told "this is fixed in the next > version" and "the next version shipped with this fixed, you can > actually download it now", which are things you don't get if you just > "move" a bug. Observation: even if we have "get as many people as possible using it" as a goal, that doesn't by itself imply that moving bugs from one Bugzilla to another, or linking them together, is a requirement. Given that your aim is to have lots of people using Bugzilla in a standard way, which makes it easy to just grab an account and log in, why is the right solution to this problem just "move the bug across/refile it, and have interested parties track it in the other Bugzilla"? Let's look analogous situations. If a user files a bug, and it turns out that it's a duplicate of another one, do we "link them together and share comments"? No, we mark it as a dupe, it gets closed and the filer watches the other bug. If a user files a bug in the Firefox product, and it turns out that the problem is actually in the Core, do we open a core bug and link them together? No, we move the bug to the Core product, and have it fixed there - even if the bug report then becomes about fixing the underlying problem, rather than the particular symptoms the user sees. So why is it that we can't say that if someone files a bug in Mandrake's Bugzilla about their browser, and it turns out to be a bug in Firefox, we file a bug in b.m.o, close the Mandrake one and tell the users to watch the b.m.o. bug? Yes, this could be made a bit easier by something like the current "bug moving" mechanism but less hacky. But I don't see the need for bi-directional linking, given that we don't use it in other analogous situations. [There's also the issue that I suspect that it would be a real pain to implement, test and keep working, particularly when the Bugzilla versions start getting out of step, and after a few years when we've released four releases and the testing compatibility matrix starts getting larger and larger.] >> Clearly, it's not good to have only a few places using it - but we are >> well past that stage. > > It's not good for every single consumer of this product to fork it > just to make it work for them. The number of logical issues with that statement take my breath away. Firstly, you start out by using a perjorative word ("fork") to buttress your position, when what we are actually talking about is customisation, which can be more or less of a "fork" depending on the customisation mechanism used and the level of customisation required. Secondly, you use over-generalisaion ("every single consumer") when quite clearly by observation, not every single consumer of Bugzilla makes significant customisations to it. Thirdly, you over-exaggerate ("just to make it work for them"); again clearly, by observation, Bugzilla already works in its default configuration, and can meet a lot of people's needs. All in all, not a good start as a basis for arguing for a particular change. > It's not good for every single organization that does this to end up > w/ dozens or hundreds of complaints which are lost in some internal > problem report area. Every single organization I visit is either using > or has tried to setup or use (sometimes both depending on the size of > the organization) Bugzilla, and they all have valuable feedback about > what's wrong or unusable about it. But we lose most of that feedback > because it's internal. OK... So what stops that feedback from ending up in bugzilla.mozilla.org? And is there anything we can do about it? >> Re-skinning an application (in the usual sense of the word "skin" - i.e. >> changing colours and logos) has no effect on TCO. > > The skinning we're interested in is more akin to guided, it's not the > same as modern v. classic, it's the difference between advanced and > simplified. Then it might help not to call it skinning. The usual use of the word "skinning" (and the Bugzilla use - see the skins/ directory) is making graphical/cosmetic changes which do not have significant effects on the underlying functionality. For that, we have historically used "customisation". >> > We just need a samples bundled in distro. >> They are. > > We have samples half bundled, we still have people asking how to > integrate things very much like the guided entry form, which if they > were fully integrated shouldn't happen. The original rationale for the way they are bundled is that we wanted to keep the distribution generic, rather than Mozilla-specific. So, we said we would include the Mozilla-specific guided format as an example of what could be done, and put a big comment at the top saying "this is an example". Are you suggesting that we should fully integrate Mozilla-specific customisations into the stock Bugzilla, so they serve as better examples? (That might be a reasonable thing to suggest.) If not, what are you suggesting we change about the current method of bundling? Gerv From bugzilla at joostdevalk.nl Mon Jun 26 11:45:04 2006 From: bugzilla at joostdevalk.nl (Joost de Valk) Date: Mon, 26 Jun 2006 13:45:04 +0200 Subject: UI module owner In-Reply-To: <449FBEE8.3050000@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> <449FBEE8.3050000@mozilla.org> Message-ID: <4278CDC8-B090-49F1-BA78-EE027B4593FB@joostdevalk.nl> On Jun 26, 2006, at 1:03 PM, Gervase Markham wrote: > Joost de Valk wrote: >> Just a quick note: >> >>> - Does anyone actually do complicated searches, or are 100% of >>> Bugzilla >>> searches merely searches on Subject? > > Just to be clear: that was a rhetorical question, used to demonstrate > the sort of things we should be asking. I'm 100% sure, even without > doing any research, that not every single search on Bugzilla is > merely a > search on Subject, because I do some complex searches myself :-) I thought it was, just wanted to be sure :) > >> Yes. I know for a fact that on bugzilla.opendarwin.org complicated >> searches are used a LOT. Problem is that searching with dates is not >> intuitive, and that there's no help available in the advanced search >> form to tell you that you need to do "-2w" for the last two weeks, or >> stuff like that. > > Ah, now you see, this is a much more specific usability issue, rather > than "it's all hard to use/unintuitive". > > Do any of the people find it this problem ever click the "Give me some > help" link at the top of the page? If not, why not - because they > didn't > notice it? Because they didn't think it would help? I've been using bugzilla an awful lot the last years, and i've never noticed that link :). I think "relative dates" should be a link to an explanation of the term relative date, perhaps in a pop-up, or an iframe coming up or so. > If they do, did they figure out how the help system worked? Did > they get > the info from hovering over the Date boxes? Was it sufficient? I think it's to hard, even when i see it... where are the examples? :) Joost de Valk: | www.joostdevalk.nl contact | joost at joostdevalk.nl | 06 - 24 555 808 Never be afraid to try something new. Remember, amateurs built the ark, and professionals built the Titanic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Mon Jun 26 12:24:42 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 26 Jun 2006 05:24:42 -0700 Subject: UI module owner In-Reply-To: <449FC8B7.5030200@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> Message-ID: <1151324683.2353.13.camel@es-lappy> On Mon, 2006-06-26 at 12:44 +0100, Gervase Markham wrote: > (BTW, everyone, the personas are still works in progress. Let me do a > bit more work before you lay into them :-)) They look good. Could we name them by role instead of by name, though? I'm never going to be able to remember what the random names all mean. We can give them names inside of the page, but I'd rather the URL and their standard names just be their role. Like "QA Technician" or "Manager." -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From gerv at mozilla.org Mon Jun 26 12:32:29 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 13:32:29 +0100 Subject: UI module owner In-Reply-To: <4278CDC8-B090-49F1-BA78-EE027B4593FB@joostdevalk.nl> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> <449FBEE8.3050000@mozilla.org> <4278CDC8-B090-49F1-BA78-EE027B4593FB@joostdevalk.nl> Message-ID: <449FD3DD.1050605@mozilla.org> Joost de Valk wrote: > I've been using bugzilla an awful lot the last years, and i've never > noticed that link :). Fair enough. Why do you think that is? Do your eyes skip over it because they are immediately moving on to the form controls, which is what you care about? When you realised you didn't know how to work those form fields, can you remember where you looked for help? Did you look around for question marks to click on? Or did you use Google? Or something else? > I think "relative dates" should be a link to an > explanation of the term relative date, perhaps in a pop-up, or an iframe > coming up or so. It used to be; we removed it when we rationalised the help. It seems like that was a mistake. One option would be to have the help always present, but instead of mousing over form controls, have a little [?] icon beside each label, which you click to get the help popup. That might be a bit more discoverable. >> If they do, did they figure out how the help system worked? Did they get >> the info from hovering over the Date boxes? Was it sufficient? > > I think it's to hard, even when i see it... where are the examples? :) OK... There isn't really room to fit examples into the current boxes. So we need to do one of: - Make the boxes bigger - Work out a different way of integrating help - Hyperlink from the boxes to further documentation (e.g. the Guide) Gerv From bugzilla at joostdevalk.nl Mon Jun 26 12:28:00 2006 From: bugzilla at joostdevalk.nl (Joost de Valk) Date: Mon, 26 Jun 2006 14:28:00 +0200 Subject: UI module owner In-Reply-To: <449FC8B7.5030200@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> Message-ID: <10FB3FC0-7676-459A-844A-EFB6D81AB889@joostdevalk.nl> On Jun 26, 2006, at 1:44 PM, Gervase Markham wrote: > > Are you suggesting that we should fully integrate Mozilla-specific > customisations into the stock Bugzilla, so they serve as better > examples? (That might be a reasonable thing to suggest.) If not, what > are you suggesting we change about the current method of bundling? I am, for quite obvious reasons i think, being a WebKit dev, very much opposed to any Mozilla-specific, or any other browser specific customisation into stock bugzilla. Let's not become the next Microsoft here... Joost de Valk: | www.joostdevalk.nl contact | joost at joostdevalk.nl | 06 - 24 555 808 Never be afraid to try something new. Remember, amateurs built the ark, and professionals built the Titanic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Mon Jun 26 12:34:43 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 13:34:43 +0100 Subject: UI module owner In-Reply-To: <1a75cc570606260439j7cff7b38x8c5ab6719dd6f072@mail.gmail.com> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> <449FBEE8.3050000@mozilla.org> <1a75cc570606260439j7cff7b38x8c5ab6719dd6f072@mail.gmail.com> Message-ID: <449FD463.3090900@mozilla.org> timeless wrote: > Zero, there's no What's This widget by that link, so I'd never click it. Are you saying that "Give me some help" is not a sufficient indication of what the link does, or sufficient encouragement to click it? What do you think the link text should say? Or do you think the Help trigger should be elsewhere? Or that it should be present even in the base page? > First, there's no hint as to which things have help, so I don't know > what I can hover over, simply using dotted or doubled underlines would > help (alternatively offering whats this hover anchors would also > work). Well, the top of the newly-reloaded page does say "For help, mouse over the page elements." So you can find out what has help by mousing over things. Having said that, all the widgets should have help - do any of them not? It's hard to dotted-underline a widget... > Second, here's the actual help text for that box: > > Specify the start and end dates either in YYYY-MM-DD format > (optionally followed by HH:mm, in 24 hour clock), or in relative > dates such as 1d, 2w, 3m, 4y, which respectively mean one day, > two weeks, three months, or four years ago. 0d is last midnight, > and 0w, 0m, 0y is the beginning of this week, month, or year. > > What part of this says to use -2m or -2w or -*ANYTHING* if you want to > go backwards?! The original poster was incorrect in their understanding. There is no need for a minus sign, and it is ignored if present. The help text is correct (if perhaps a little terse). For things changed between 3 weeks and 2 days ago, you put "3w" into the first box, and "2d" into the second box. We should probably permit a more verbose version of this syntax. >> If not, why not - because they didn't notice it? >> Because they didn't think it would help? > > Having used it once, I can assure you, I'd never use it again, it's > barely more helpful than a Unix document. Even Microsoft help which > people love to complain about is considerably better. Especially given > that the number one search anyone ever wants to do is something like > -1m. What is incorrect about that help text? Suggestions for better wording are most welcome. > The problem here is that we don't give people examples or walk through > documents for using our features. If you show anyone how to use these > features it becomes instantly intuitive and they'll remember and use > it (ask smaug, I showed him over the weekend), but no one will guess. How do you suggest integrating such help into the interface? Or are you suggesting changes to the Bugzilla Guide? Gerv From bugzilla at joostdevalk.nl Mon Jun 26 13:34:45 2006 From: bugzilla at joostdevalk.nl (Joost de Valk) Date: Mon, 26 Jun 2006 15:34:45 +0200 Subject: Fwd: UI module owner References: Message-ID: <130ACE8A-DAC4-423F-BB8C-70530ED0A460@joostdevalk.nl> Wrong from address, resending :) Begin forwarded message: > From: Joost 'AlthA' de Valk > Date: June 26, 2006 3:11:23 PM CEDT > To: developers at bugzilla.org > Subject: Re: UI module owner > > > On Jun 26, 2006, at 2:32 PM, Gervase Markham wrote: > >> Joost de Valk wrote: >>> I've been using bugzilla an awful lot the last years, and i've never >>> noticed that link :). >> >> Fair enough. Why do you think that is? Do your eyes skip over it >> because >> they are immediately moving on to the form controls, which is what >> you >> care about? > > yes, exactly, and the only part i needed help with was that > specific part, and it's on the other end of the page. > >> When you realised you didn't know how to work those form fields, >> can you >> remember where you looked for help? Did you look around for question >> marks to click on? Or did you use Google? Or something else? > > i went to LpSpolit on #mozwebtools ;) > >> >>> I think "relative dates" should be a link to an >>> explanation of the term relative date, perhaps in a pop-up, or an >>> iframe >>> coming up or so. >> >> It used to be; we removed it when we rationalised the help. It seems >> like that was a mistake. >> > yes i think so. >> One option would be to have the help always present, but instead of >> mousing over form controls, have a little [?] icon beside each label, >> which you click to get the help popup. That might be a bit more >> discoverable. > > yes. > >> >>>> If they do, did they figure out how the help system worked? Did >>>> they get >>>> the info from hovering over the Date boxes? Was it sufficient? >>> >>> I think it's to hard, even when i see it... where are the >>> examples? :) >> >> OK... >> >> There isn't really room to fit examples into the current boxes. So we >> need to do one of: >> >> - Make the boxes bigger >> - Work out a different way of integrating help > > the [?] icons are the best options imho, especially because users > are used to that in other applications. > >> - Hyperlink from the boxes to further documentation (e.g. the Guide) > > the [?] links could point to information, which would give basic > usage information, and point to more information which would be in > there, there being "the Guide" :) > >> >> Gerv >> - >> To view or change your list settings, click here: >> > Joost de Valk: | www.joostdevalk.nl contact | joost at joostdevalk.nl | 06 - 24 555 808 Never be afraid to try something new. Remember, amateurs built the ark, and professionals built the Titanic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Mon Jun 26 14:02:35 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 15:02:35 +0100 Subject: Fwd: UI module owner In-Reply-To: <130ACE8A-DAC4-423F-BB8C-70530ED0A460@joostdevalk.nl> References: <130ACE8A-DAC4-423F-BB8C-70530ED0A460@joostdevalk.nl> Message-ID: <449FE8FB.8020208@mozilla.org> Joost de Valk wrote: >>> One option would be to have the help always present, but instead of >>> mousing over form controls, have a little [?] icon beside each label, >>> which you click to get the help popup. That might be a bit more >>> discoverable. >> >> yes. I've filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=342740 to re-look at the usability of the query page help. Gerv From timeless at gmail.com Mon Jun 26 14:04:05 2006 From: timeless at gmail.com (timeless) Date: Mon, 26 Jun 2006 17:04:05 +0300 Subject: UI module owner In-Reply-To: <449FC8B7.5030200@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> Message-ID: <1a75cc570606260704j39366ac3i10fa4be5cea721c9@mail.gmail.com> THIS ISN'T WORTH MY TIME. discussions don't work. i've already written a blog article explaining why your ideas are failures. wikis and discussions are *huge* wastes of my time. This thread already has 6 more items that i have to read, and the one you wrote to me is amazingly long. this can't be good. at least with irc people realize when they've written too much. (well, i eventually rewrite my conversations into blogs). I'm about 1 message away from unsubscribing and i've been subscribed for less than one week. From timeless at gmail.com Mon Jun 26 14:40:18 2006 From: timeless at gmail.com (timeless) Date: Mon, 26 Jun 2006 17:40:18 +0300 Subject: UI module owner In-Reply-To: <449FD463.3090900@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> <449FBEE8.3050000@mozilla.org> <1a75cc570606260439j7cff7b38x8c5ab6719dd6f072@mail.gmail.com> <449FD463.3090900@mozilla.org> Message-ID: <1a75cc570606260740s6e5bf7e9u61f6a90d92bdf59a@mail.gmail.com> On 6/26/06, Gervase Markham wrote: > Are you saying that "Give me some help" is not a sufficient indication > of what the link does, or sufficient encouragement to click it? I'll never read it. It's in the wrong place with the wrong text and no glitz. > What do you think the link text should say? Or do you think the Help > trigger should be elsewhere? Or that it should be present even in the > base page? Probably, using a design I'll describe elsewhere the widgets should come with the help in such a way that until a user uses or tells bugzilla a list of things that the user knows (by importing settings), bugzilla should offer help for things it doesn't think the user has used. > Well, the top of the newly-reloaded page does say "For help, mouse over > the page elements." So you can find out what has help by mousing over > things. Having said that, all the widgets should have help - do any of > them not? No idea, it's not worth my time to do it. and clearly it wasn't worth your time to try. > It's hard to dotted-underline a widget... A widget that doesn't have text is buggy. In fact, Given that I'm suggesting using examples (see below) instead of explanations of features, you should stop hovertipping the actual form fields. so "Only bugs changed between" would get the underlines and hovertip. > The original poster was incorrect in their understanding. There is no > need for a minus sign, and it is ignored if present. The help text is > correct (if perhaps a little terse). Everyone I know uses -2w not 2w. There's actually too much text and yet it still fails miserably. Explanation without example doesn't work. Sorry. And it should be obvious what the recourse to this is. > For things changed between 3 weeks and 2 days ago, you put "3w" into the > first box, and "2d" into the second box. See, this is considerably shorter than what's in the box right now, and yet, it's actually useful. > We should probably permit a more verbose version of this syntax. I wouldn't use it. And I wouldn't doc it. But there's nothing wrong with supporting it. Unless that developer could have been fixing hundreds of other bugs we have. > What is incorrect about that help text? Suggestions for better wording > are most welcome. In fact, I think we should probably ditch help text in favor of example uses (possibly with pictures), include a link to the documentation in the box. > How do you suggest integrating such help into the interface? Or are you > suggesting changes to the Bugzilla Guide? Looks like I'm suggesting the items actually be instructions for an example plus a picture (or just a prefilled inline form in the tip box, not sure I care too much) and a link to the full doc for any extra details. Note that you don't have to have just one example, you can use expander widgets > search for bugs changed last week > search for bugs changed between three months ago and last month v search for bugs that changed between January 14, 2004 and November 15, 2005. [ 2004-1-14 ] and [ 2004-11-15] From timeless at gmail.com Mon Jun 26 14:54:39 2006 From: timeless at gmail.com (timeless) Date: Mon, 26 Jun 2006 17:54:39 +0300 Subject: UI module owner In-Reply-To: <449FC8B7.5030200@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> Message-ID: <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> I wrote: > Bugzilla should ship such that most companies don't feel the need to > implement dozens of horrible hacks that cause them to refuse to > upgrade to a newer version of Bugzilla later. On 6/26/06, Gervase Markham wrote: > Gregg completely agrees with you. > http://wiki.mozilla.org/Bugzilla:Personas:Gregg I'm glad I'm not alone, but I really don't care. I know I'm not alone. gerv wrote: > (BTW, everyone, the personas are still works in progress. Let me do a > bit more work before you lay into them :-)) As I said, I already laid into them, they're bad and I'm not going to spend my time helping you prop up something which I know doesn't work. > How likely do you think it is that these different > companies/organisations requirements will be similar enough that all the > Bugzillas will be "fairly standard"? I've used a number of Bugzillas, most of the changes are fairly similar. I think it's fairly safe, as long as you accept some other bits which I'm proposing in a blog entry which I'm *not* writing because I'm *wasting* time writing this email. As I've said before, your personas don't work and it's a waste of my time to support them. they don't work. > Observation: even if we have "get as many people as possible using it" > as a goal, that doesn't by itself imply that moving bugs from one > Bugzilla to another, or linking them together, is a requirement. That's nice of you to think. > Given that your aim is to have lots of people using Bugzilla in a > standard way, which makes it easy to just grab an account and log in, > why is the right solution to this problem just "move the bug > across/refile it, and have interested parties track it in the other > Bugzilla"? I can't log into corporate Bugzillas. I can't log into bugs.opera or Bugscape, I can't log into the Mozilla Foundation Partner Products Bugzilla, we can't log into Cenzic's Bugzilla, you can't log into the Bugzilla where I work. > Let's look analogous situations. If a user files a bug, and it turns out > that it's a duplicate of another one, do we "link them together and > share comments"? No, we mark it as a dupe, it gets closed and the filer > watches the other bug. This is a mistake. > If a user files a bug in the Firefox product, and it turns out that the > problem is actually in the Core, do we open a core bug and link them > together? This is a mistake. > No, we move the bug to the Core product, and have it fixed > there - even if the bug report then becomes about fixing the underlying > problem, rather than the particular symptoms the user sees. This is a mistake. what actually happens is the end user starts spamming the core bug. I've been proposing for a while switching to a system where we split reports from bugs. end user Firefox items would be reports. If you get a bug, you refile it as a dependency into core. This avoids getting lots of bad comments from end users like "me too". Yes it means that Firefox product would be responsible for having gateway people (QA) who actually translate requests for more information into the bugs reported by he end users. But it also means that devs don't have to sit there explaining things. Just like I shouldn't have to sit here repeating to you something i already wrote in a blog. > So why is it that we can't say that if someone files a bug in Mandrake's > Bugzilla about their browser, and it turns out to be a bug in Firefox, > we file a bug in b.m.o, close the Mandrake one and tell the users to > watch the b.m.o. bug? Because you wrongly assume that all Bugzillas are public. > Yes, this could be made a bit easier by something > like the current "bug moving" mechanism but less hacky. But I don't see > the need for bi-directional linking, given that we don't use it in other > analogous situations. The analogous situations actually do need it, again, there needs to be someone doing translations, and in fact, other Bugzilla or bug tracking people usually do. when we get a bug in GCC, we don't just file the entire bug report into GCC's Bugzilla, we reduce it and file a shorter bug about the specific problem. and then the person who files it acts as the gateway. The fact is you're absolutely out of touch with how Bugzillas are used. which is why you shouldn't be doing any of the persona or equivalent UI design. > [There's also the issue that I suspect that it would be a real pain to > implement, test and keep working, particularly when the Bugzilla > versions start getting out of step, and after a few years when we've > released four releases and the testing compatibility matrix starts > getting larger and larger.] This is discussed elsewhere. It's possible to manage. Note that there are two forms of linking, one is a full link where you basically have a foreign fields table for dealing w/ foreign bug trackers (Bugzilla of other versions or any Bugzilla really being included here) which has some provisions for trying to map fields. > Firstly, you start out by using a perjorative word ("fork") to buttress > your position, when what we are actually talking about is customisation, > which can be more or less of a "fork" depending on the customisation > mechanism used and the level of customisation required. FWIW, it's pejorative, and Yes I am using it as such. And there's a better way to do it which does not require code modifications, and face it, our skins are code, so are our localizations. Most customizations I've seen have resulted in people not upgrading. Any time people don't upgrade, I consider this to be a fork. And yes, I don't like it when people make customizations and then don't upgrade. > Secondly, you use over-generalisaion ("every single consumer") when > quite clearly by observation, not every single consumer of Bugzilla > makes significant customisations to it. Just about every one I've ever used has. And I'm fairly certain that it's safe to say must Bugzillas aren't running tip. yet if there were no risks associated and no effort required, people should be willing to upgrade and most people should be current. They aren't. This is issue is addressed in the rant I'm not writing now because I'm wasting time writing this message. > Thirdly, you over-exaggerate ("just to make it work for them"); again > clearly, by observation, Bugzilla already works in its default > configuration, and can meet a lot of people's needs. I'd like someone to name 5 Bugzillas where the people choosing the Bugzilla said, "OK, we're going to use Bugzilla, because it's perfect, there's not a single thing we'd want to change, there are no bugs in it, there's nothing that we'd want fixed." If you're a Bugzilla developer and you make any of those statements, you're smoking something, because it means you don't know anything about the Bugzilla bug database and its open bug list. > OK... So what stops that feedback from ending up in > bugzilla.mozilla.org? This should be obvious > And is there anything we can do about it? Yes. But as everyone keeps reminding you, sticking any answers here is feeding the troll which is a terrible idea. > Then it might help not to call it skinning. The usual use of the word > "skinning" (and the Bugzilla use - see the skins/ directory) is making > graphical/cosmetic changes which do not have significant effects on the > underlying functionality. For that, we have historically used > "customisation". It's not my fault, we don't have provisions for customizations. and by the way, we don't write "customisation" we call it a customization with a Z. Please install and use a US English spellchecker (the one in minefield should work quite nicely). > Are you suggesting that we should fully integrate Mozilla-specific > customisations into the stock Bugzilla, so they serve as better > examples? Yes. Note that specific browser pieces should be adapted so that they're less specific. FWIW, the Bugzilla I'm using internally has a URL field, and I specifically deal w/ bugs about a web browser, but for some incomprehensible reason people don't fill in the URL field! if the customization was available and I could specify it for my product, I'd be very happy to force it. From mkanat at bugzilla.org Mon Jun 26 15:30:31 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Mon, 26 Jun 2006 08:30:31 -0700 Subject: mod_perl: All paths must be absolute Message-ID: <1151335831.6419.1.camel@es-lappy> When running under mod_perl, we can't guarantee what directory we're currently in. So, if you specify a path, it must be absolute. You can use bz_locations->{'libdir'} (see Bugzilla::Constants on the tip) to get Bugzilla's absolute path, as soon as I check in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=342744 -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From dennis.melentyev at infopulse.com.ua Mon Jun 26 16:47:35 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Mon, 26 Jun 2006 19:47:35 +0300 Subject: UI module owner In-Reply-To: <449FB685.5070305@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> Message-ID: <1151340455.90475.174.camel@D-MELENTYEV.HOME> ? ??, 26/06/2006 ? 11:27 +0100, Gervase Markham ?????: > Dennis Melentyev wrote: > > Some controls are definitely "Advanced". > > - For whom are they "definitely Advanced"? One person's advanced control > may be another's most important. Well, it's mostly role-dependent. What about putting some role schemes/UI/WorkFlow/etc in? > > Will try to collect opinions of > > our developers on this. (Idea! Need to add a usability survey link to > > useful-links! :) > > Of course, this survey will not necessarily shed light on the views of > all of Bugzilla's focal personas. I guess it depends what sort of people > you have working for you. Yup. > If you are going to do a survey, please try and separate out the views > of coders, managers and QA people into separate pots. Sure. Also there are customers. But I'm afraid I'd better will not offer them a survey. At least w/o higher management permissions. > >> - Does anyone actually do complicated searches, or are 100% of Bugzilla > >> searches merely searches on Subject? > >> - If we don't have a page with all the controls on somewhere, how are > >> people going to be able to do those complicated searches? > > I have to do a lot of reports and even more, I can't do some searches, so I had to hack a page for some special ones (not usable for others and definitely lacks security). > > But, basic search is too minimalistic, while advanced is over-bloated > > for freshmens. > > Why is basic search "too minimalistic"? And for whom? I assume you don't > mean "because it doesn't have enough widgets"; so do you mean "because > it doesn't find what you want some of the time"? It's more like "I'd like to specify also Open/closed flag, user and some date-related stuff". Yes, of cause it's doable via AdvSearch page. But each time you open it, you have to re-read it twice or so to remember what all that controls do. It's not a surprise to miss the help link. It's invisible at the first grasp. Good alternative would be expandable panels like in show_bug with button mentioned already here. > If so, an alternative solution would be to consider looking at ways to > improve the quality of the search results returned by the basic search. > That would benefit everyone. > >>> It's getting intuitive when you getting more and more familiar with > >>> Bugzilla process, but is a complete mess for a newbie. > >> So we ask: > >> > >> - Is that page supposed to be used by newbies? > > No. But they do often need somewhat advanced, but not over-helming > > pages. > > What evidence do you have that people who have graduated from the simple > search form (and therefore already have some familiarity with Bugzilla) > still find the complicated one hard to understand? It has too many controls and no place to concentrate the sight at. Current layout offer more details moving from
to
, with main/primary controls at the top of the page. The biggest problem is: one have to pay too much attention. (And, better, need internals understanding to some degree) > > Another user role is "Customer The Great" often under-qualified to > > fill-out all controls, not patient and not willing to learn this "ugly > > pages". But their reports are gold for us. > > Why are you pointing your customers at the advanced search page? What do > you expect them to accomplish there? They are working with us on bugs related to their products/components. > > Yes, It is already customizable, but this increase the cost of > > ownership. > > So Bugzilla needs to ship with versions of the search page to meet every > possible need from every company which uses it? No. Just not dump all the possible handles and buttons to one page. > >>> IMO the best idea is to have a wizard-like search and bug entry pages, > >>> with ability to switch back to current pages when "the wizard" will > >>> start abuse you. > >> What, like the guided bug entry page we already have? :-) > > Which one? bugzilla.mozilla.org? Kind of... But in distrib. (I could > > miss recent 1-2 month changes at tip) > > We do distribute it, and have for years. It's create-guided.html.tmpl. I need to check it to comment further. > >> - Which of our personas cares about sexiness/coolness? > >> > >> (If the answer is "none", it doesn't mean we can't make it look more > >> sexy. It just means that it's not a high priority.) > > Yeah, It isn't high priority task. But Bugzilla as a product suffer from > > that. > > Just try to imagine it a commercial product with just price cut down to > > zero. > > But Bugzilla is not a proprietary product with a price of zero. If it > was, most of us wouldn't be working on it. But that's not the reason to stop improving it marketing abilities. See firefox for example. It IS being marketing. We don't need any advertisement, but the first impression should not distract users. And first impression is "Mama, what's that heap of pages is for?" > Let's turn the question on its head: is one of the goals of the Bugzilla > project to get as many companies and organisations using it as possible? I think so. Otherwise we loose at least developers. > As this is a value judgement, personal opinions are allowed :-) I > personally don't think that should be a particularly high priority goal. > Clearly, it's not good to have only a few places using it - but we are > well past that stage. ... but could develop faster. > >>> Yet another idea is to have several default (pre-shipped?) skins > >>> selectable by USER in his profile: > >> This clearly has a maintenance cost, so we ask: > >> > >> - Which persona needs this feature, and why? > > Every company it uses. Because of TCO and general attractiveness (Is > > there such a word in English? :). > > Re-skinning an application (in the usual sense of the word "skin" - i.e. > changing colours and logos) has no effect on TCO. Yes, but adapting workflow to corporate standards should be much easier than it is now. I think we could cover at least several cases. (Yes, this will require more effort to collect them, implement, etc) > >>> 1. Just current (classic) skin > >>> 2. Sexy-dumb-n-bullet-proof-wizardry (anyway, we definitely need one for > >>> collecting bug reports from customers, who could not always be smart!) > >> We already have customisation mechanisms for this sort of thing; and > >> it's not called a "skin". > > We just need a samples bundled in distro. > > They are. Unsorted, undocumented, stale... No. Bugzilla should be a product, not a pile of scripts. With recent changes in code, it got much more potential and it's probably the time to think about the next big step. From gerv at mozilla.org Mon Jun 26 12:56:11 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 13:56:11 +0100 Subject: UI module owner In-Reply-To: <10FB3FC0-7676-459A-844A-EFB6D81AB889@joostdevalk.nl> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <10FB3FC0-7676-459A-844A-EFB6D81AB889@joostdevalk.nl> Message-ID: <449FD96B.5040205@mozilla.org> Joost de Valk wrote: > I am, for quite obvious reasons i think, being a WebKit dev, very much > opposed to any Mozilla-specific, or any other browser specific > customisation into stock bugzilla. Let's not become the next Microsoft > here... You see, this is the problem :-) Some people are saying that examples of Bugzilla customisation need to be "better integrated"; others are saying that's bad, because they'd have to de-integrate them before using them! :-) I personally think we have struck the right balance. The customisation examples are there, and documented in the Guide if you want to use them, but are not visible in the default interface. Gerv From jdevalk at opendarwin.org Mon Jun 26 13:11:23 2006 From: jdevalk at opendarwin.org (Joost 'AlthA' de Valk) Date: Mon, 26 Jun 2006 15:11:23 +0200 Subject: UI module owner In-Reply-To: <449FD3DD.1050605@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> <449FBEE8.3050000@mozilla.org> <4278CDC8-B090-49F1-BA78-EE027B4593FB@joostdevalk.nl> <449FD3DD.1050605@mozilla.org> Message-ID: On Jun 26, 2006, at 2:32 PM, Gervase Markham wrote: > Joost de Valk wrote: >> I've been using bugzilla an awful lot the last years, and i've never >> noticed that link :). > > Fair enough. Why do you think that is? Do your eyes skip over it > because > they are immediately moving on to the form controls, which is what you > care about? yes, exactly, and the only part i needed help with was that specific part, and it's on the other end of the page. > When you realised you didn't know how to work those form fields, > can you > remember where you looked for help? Did you look around for question > marks to click on? Or did you use Google? Or something else? i went to LpSpolit on #mozwebtools ;) > >> I think "relative dates" should be a link to an >> explanation of the term relative date, perhaps in a pop-up, or an >> iframe >> coming up or so. > > It used to be; we removed it when we rationalised the help. It seems > like that was a mistake. > yes i think so. > One option would be to have the help always present, but instead of > mousing over form controls, have a little [?] icon beside each label, > which you click to get the help popup. That might be a bit more > discoverable. yes. > >>> If they do, did they figure out how the help system worked? Did >>> they get >>> the info from hovering over the Date boxes? Was it sufficient? >> >> I think it's to hard, even when i see it... where are the >> examples? :) > > OK... > > There isn't really room to fit examples into the current boxes. So we > need to do one of: > > - Make the boxes bigger > - Work out a different way of integrating help the [?] icons are the best options imho, especially because users are used to that in other applications. > - Hyperlink from the boxes to further documentation (e.g. the Guide) the [?] links could point to information, which would give basic usage information, and point to more information which would be in there, there being "the Guide" :) > > Gerv > - > To view or change your list settings, click here: > From gerv at mozilla.org Mon Jun 26 13:39:23 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 14:39:23 +0100 Subject: UI module owner In-Reply-To: <1151324683.2353.13.camel@es-lappy> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1151324683.2353.13.camel@es-lappy> Message-ID: <449FE38B.7000505@mozilla.org> Max Kanat-Alexander wrote: > They look good. Could we name them by role instead of by name, though? > I'm never going to be able to remember what the random names all mean. I think it's important to name them, and think of them as people first. Just as you know me as "Gerv", not as "Mozilla Foundation employee #2", you'll get to know and love Mitch, the coder, and Peter, his manager :-) Also, just as you use unique IDs for bugs because all other things about them may change, defining personas by name means that if we decide that Mitch needs modifying in some way, there's no danger that we'd need to change his name to fit his new description. http://www.cooper.com/newsletters/2001_07/perfecting_your_personas.htm "Personas represent behavior patterns, not job descriptions" Gerv From dberlin at dberlin.org Mon Jun 26 16:09:16 2006 From: dberlin at dberlin.org (Daniel Berlin) Date: Mon, 26 Jun 2006 12:09:16 -0400 Subject: UI module owner In-Reply-To: <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> Message-ID: <44A006AC.4050304@dberlin.org> timeless wrote: > Because you wrongly assume that all Bugzillas are public. > >> Yes, this could be made a bit easier by something >> like the current "bug moving" mechanism but less hacky. But I don't see >> the need for bi-directional linking, given that we don't use it in other >> analogous situations. > > The analogous situations actually do need it, again, there needs to be > someone doing translations, and in fact, other Bugzilla or bug > tracking people usually do. when we get a bug in GCC, we don't just > file the entire bug report into GCC's Bugzilla, we reduce it and file > a shorter bug about the specific problem. and then the person who > files it acts as the gateway. In turn, GCC bugzilla does the same thing for classpath and gmp bugs (IE places where GCC is the consumer of some library). As for the later point about upgrading bugzilla, they really are forks. I have maintained many Bugzillae, and I have *never had a single Bugzilla where all i had to do was change templates*. Thus, I've *always* had to fork the code, and *always* had to do my own version control on it. Some of this is just to implement solution to bugs that rot in mozilla.org's Bugzilla system, awaiting review (cc list merging on duplicate marking, etc), or nitpicking clearly sane design decisions because someone isn't willing to accept that there may be more than one good design for something. The claim that "Bugzilla already works in its default configuration, and can meet a lot of people's needs" shows a fundamental lack of understanding of how Bugzilla is used. The only people i've met who *ever* use Bugzilla in it's default configuration are those who are using it very temporarily, and don't want to "fuss with code to get it to work how I want". That's an exact quote, btw. Note the use of the word "code". This is not a mistake. No interesting customization people perform can be performed to Bugzilla without modifying the *existing code*. In short, timeless is exactly right. This is also why GCC Bugzilla does not run tip. Because I don't have time to continually edit the schema changes into our small schema changes, and then hack at the upgrade so it works properly. I keep hoping maybe someday certain personalities in Bugzilla will stop bickering over useless bullshit and just get things done (see, e.g., whether a certain implementation strategy for custom fields scales to a billion bugs or not). It's been 5 years though. I watch with hope as bugzilla moves away from globals and whatnot, and that work seems to progress fine. However, the fundamental customization issues never seem to be solved. A large organizational hint: The amount of process that is involved in Bugzilla in general is not in line with the amount of code it is. I gave up filing bug reports against Bugzilla when i saw the amount of comment typo nitpicking that went on to people who produce patches. From gerv at mozilla.org Mon Jun 26 17:06:50 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 18:06:50 +0100 Subject: UI module owner In-Reply-To: <1151340455.90475.174.camel@D-MELENTYEV.HOME> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1151340455.90475.174.camel@D-MELENTYEV.HOME> Message-ID: <44A0142A.90502@mozilla.org> Dennis Melentyev wrote: > Well, it's mostly role-dependent. What about putting some role > schemes/UI/WorkFlow/etc in? Now we're thinking along the right lines :-) >> Why is basic search "too minimalistic"? And for whom? I assume you don't >> mean "because it doesn't have enough widgets"; so do you mean "because >> it doesn't find what you want some of the time"? > It's more like "I'd like to specify also Open/closed flag, user and some > date-related stuff". You can specify an open/closed flag on the basic search. Date-related stuff seems to me to be well into the realm of advanced queries. After all, you can get simple date-related stuff for filing date just by searching by bug number. And, assuming we fix up the sorting on the results page, you could sort by last-changed-date to get recently-changed bugs too. > Yes, of cause it's doable via AdvSearch page. But each time you open it, > you have to re-read it twice or so to remember what all that controls > do. Are the labels not clear enough that one reading is enough? :-) > Good alternative would be expandable panels like in show_bug with button > mentioned already here. I do think expandable panels is worth looking at on that page. But we would need to study people's queries to see which fields to group onto particular panels. >>>> - Is that page supposed to be used by newbies? >>> No. But they do often need somewhat advanced, but not over-helming >>> pages. >> What evidence do you have that people who have graduated from the simple >> search form (and therefore already have some familiarity with Bugzilla) >> still find the complicated one hard to understand? > It has too many controls and no place to concentrate the sight at. > Current layout offer more details moving from
to
, with > main/primary controls at the top of the page. > The biggest problem is: one have to pay too much attention. (And, > better, need internals understanding to some degree) Which parts need understanding of internals? How would you change them to not require such understanding? (Boolean charts require some internals understanding, but I think that's OK, because you couldn't have them stay that powerful if you removed that requirement.) >>> Another user role is "Customer The Great" often under-qualified to >>> fill-out all controls, not patient and not willing to learn this "ugly >>> pages". But their reports are gold for us. >> Why are you pointing your customers at the advanced search page? What do >> you expect them to accomplish there? > They are working with us on bugs related to their products/components. But don't you use groups to make sure that bugs in their products/components are the only ones they can see anyway? > Yes, but adapting workflow to corporate standards should be much easier > than it is now. I agree with that. Evidence from the newsgroup suggests that customising the workflow (statuses and resolutions) is an extremely common request, and currently to do it I believe you have to hack Bugzilla in a way which makes it hard to upgrade. Gerv From kevin.benton at amd.com Mon Jun 26 18:12:16 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 11:12:16 -0700 Subject: UI module owner Message-ID: > Dennis Melentyev wrote: > > ? ??, 23/06/2006 ? 20:28 +0100, Gervase Markham ?????: > > [...] > >> Also, for the ease-of-use goal: > >> do we have any more specific data than > >> "people complain Bugzilla is hard to use"? > > Well... Trying to put some more specific data, I'd say: > > Bugzilla UI (Search page at the first place followed closely by bug > > entry page) are way too overloaded with controls and lots of them are > > not intuitive. > > So we ask: > > - Are all the controls necessary? > - Which controls are used more and which less? > (We could get such data by instrumenting bugzilla.mozilla.org) > - Which ones do people classify as "not intuitive"? > - Can we fix that by changing the widget used to make them work more > like people expect? > > - Does anyone actually do complicated searches, or are 100% of Bugzilla > searches merely searches on Subject? > - If we don't have a page with all the controls on somewhere, how are > people going to be able to do those complicated searches? > > > It's getting intuitive when you getting more and more familiar with > > Bugzilla process, but is a complete mess for a newbie. > > So we ask: > > - Is that page supposed to be used by newbies? > > > IMO the best idea is to have a wizard-like search and bug entry pages, > > with ability to switch back to current pages when "the wizard" will > > start abuse you. > > What, like the guided bug entry page we already have? :-) > > > There are also some design/style issues. It doesn't looks > > sexy/serious/cool/whatever word you know for a big, well-known and full > > featured application. It looks like knee-knitted helper thingy. This > > doesn't mean any functionality is missed. It just does not impress from > > the very first look :) > > So we ask: > > - Which of our personas cares about sexiness/coolness? > > (If the answer is "none", it doesn't mean we can't make it look more > sexy. It just means that it's not a high priority.) > > > Yet another idea is to have several default (pre-shipped?) skins > > selectable by USER in his profile: > > This clearly has a maintenance cost, so we ask: > > - Which persona needs this feature, and why? > > > 1. Just current (classic) skin > > 2. Sexy-dumb-n-bullet-proof-wizardry (anyway, we definitely need one for > > collecting bug reports from customers, who could not always be smart!) > > We already have customisation mechanisms for this sort of thing; and > it's not called a "skin". > > > 3. wap-enabled minimalistic > > Which persona needs to access Bugzilla over WAP, and why? When Bugzilla is used as a support database for network engineers, WAP access allows those engineers to read "all about it" before they get to the site to fix issues. If we want to cover those users better, we need to make bug displays work well in a WAP environment. I don't have an immediate *need* for it today, though it would be helpful to me. I wouldn't count it on a short list of current priorities, personally. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From vladd at bugzilla.org Mon Jun 26 18:12:42 2006 From: vladd at bugzilla.org (Vlad Dascalu) Date: Mon, 26 Jun 2006 11:12:42 -0700 (PDT) Subject: UI module owner In-Reply-To: <1151108044.2344.46.camel@es-lappy> References: <449BBC82.30209@gmail.com> <449C5192.1040908@bugzilla.org> <1151108044.2344.46.camel@es-lappy> Message-ID: <32994.86.124.16.68.1151345562.squirrel@www.syndicomm.com> >> we'd attempt to get someone to >> spearhead the management of getting there [snip] > > I'd feel capable of doing it. I've been extremely occupied with > mod_perl, though > -Max > http://www.everythingsolved.com/ Absolutely not! No. No way. Ever. The way you act as Release Manager is really disappointing. In https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188359 , an official site of the RedHat network, you state in comment #14: ** Also, I released 2.22 lately ** which is simply unacceptable for a Bugzilla Release Manager. All you did is to commit some patches from different bug numbers. We did all the hard work, and because you got to push the final button, that makes you the one that released 2.22? Incredible. I'm simply speechless. Since I really don't want to see from you in the future statements like "I've redone the entire Bugzilla UI", justdave, please, make sure Max never gets any kind of additional manager privileges in the Bugzilla world. Resigning current managerial privs would make me also very happy; I'm tired (physically) of reading Everything advertisements all over the place when I want to contribute to Bugzilla. Vlad. > Everything Solved: Competent, Friendly Bugzilla and Linux Services > > - From kevin.benton at amd.com Mon Jun 26 18:33:47 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 11:33:47 -0700 Subject: UI module owner Message-ID: > byron wrote: > >> http://landfill.bugzilla.org/tabbededitbug/show_bug.cgi?id=1 > >> What problem is this change trying to solve? > > > > Bluntly: Bugzilla is ugly. I'm trying to make it prettier. > > > > By splitting the page into tabs it gives us the room to layout the > > sections in a way that's clear instead of having to squeeze it into the > > space that currently exists. > > You realise these two paragraphs are entirely different motivations? The I agree. > first is an argument from aesthetics; the second is an argument from > usability. Taking the usability argument: > > A web page has an infinite amount of space available; you just keep >From a technical perspective, I agree. From a usability perspective, I disagree completely. When a page is overly full, it becomes unusable. If that weren't the case, then we would need sites like Google. > going down the page. So presumably you have an extra, implicit > constraint "and keep it all within the size of a single screenful"? If > so, why is that a constraint? "A single screen-full" is a relative term depending on the active font and the size of the window. I think it's fair to say that it's difficult to define a "global" clear-cut understanding of "too much" versus "under-utilized." IMHO, it's a good thing that the line between under-utilized and too much is fuzzy because I know I tend to look at smaller fonts on larger screens than most, though I design for those that run their browser at the 800x600 frame size with default fonts at the most typical sizes. I want the "most critical information" available in that first screen. Users that want more than the most critical information, can scroll down or select tabs depending on the application. > - Why is the current layout "unclear"? I think what Byron is getting at is there are times when it's appropriate for us to give the user more of a dashboard look at what they user is interested in. For example (here at AMD), when the user first hits Bugzilla, they're typically interested in the results of the "my bugs" query, along with some kind of information describing new bugs to that user, and some overall product statistics. > - Why does a new "clear" layout need more room than an unclear layout? > That is to say, what makes you think that lack of whitespace separation > between the fields is the cause of the unclarity? While I'm not a big fan of RT, I think they've done a good job of helping the user see a clear division between the "most commonly used fields" and others. > - Why did you choose tabs rather than e.g. collapsible sections, or > role-based style sheets which hide some of the fields? > > I suggest (although, as I've said in other messages, we'd need some > metrics) that the tabs would be a major usability decrease, because > people would be endlessly switching tabs to try and take in an overall > view of the state of the bug. > > Did you consider the workflows of different types of Bugzilla user when > deciding how many tabs to have, and which fields to put on each? I'm on the fence about this one for the moment. Tabs would be "less pretty" but they would work for WAP and browsers that don't support CSS block:hide; On the other hand, I believe the majority of users would rather see the collapsible fields than tabs. I'm also thinking that giving the user the ability to re-order fields would be helpful for those that can. Then, each user can determine what they need to see most frequently. That'd be a major change to the UI, however. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From timeless at gmail.com Mon Jun 26 18:57:17 2006 From: timeless at gmail.com (timeless) Date: Mon, 26 Jun 2006 21:57:17 +0300 Subject: UI module owner In-Reply-To: References: Message-ID: <1a75cc570606261157p35067aeawd6258a566928299e@mail.gmail.com> I mentioned earlier that I was delayed in writing some blog articles because of this thread, anyway, here they are: http://viper.haque.net/~timeless/blog/117/ http://viper.haque.net/~timeless/blog/118/ FWIW, there are literally over a hundred entries in my "blog". they're in more or less finished states, I don't mind if people read them, and at some point I will try to make more of them public and finalized. From kevin.benton at amd.com Mon Jun 26 19:13:08 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 12:13:08 -0700 Subject: UI module owner Message-ID: > > Will try to collect opinions of > > our developers on this. (Idea! Need to add a usability survey link to > > useful-links! :) > > Of course, this survey will not necessarily shed light on the views of > all of Bugzilla's focal personas. I guess it depends what sort of people > you have working for you. > > If you are going to do a survey, please try and separate out the views > of coders, managers and QA people into separate pots. > > >> - Does anyone actually do complicated searches, or are 100% of Bugzilla > >> searches merely searches on Subject? > >> - If we don't have a page with all the controls on somewhere, how are > >> people going to be able to do those complicated searches? > > I have to do a lot of reports and even more, I can't do some searches, > so I had to hack a page for some special ones (not usable for others and > definitely lacks security). > > But, basic search is too minimalistic, while advanced is over-bloated > > for freshmens. > > Why is basic search "too minimalistic"? And for whom? I assume you don't > mean "because it doesn't have enough widgets"; so do you mean "because > it doesn't find what you want some of the time"? > > If so, an alternative solution would be to consider looking at ways to > improve the quality of the search results returned by the basic search. > That would benefit everyone. I'm looking at http://landfill.bugzilla.org/bugzilla-2.22-branch/query.cgi from a selection criteria perspective. I see that the user can select one (and only one) status, one and only one Product, and Words. It's unclear where Words are looked for (short_desc only? longdescs table and short_desc? ...?). I don't see a way to select a component, or a way to adequately specify criteria for "My Unseen Bugs" (bugs that are assigned to me in a new status) here or "My Stale Bugs" (bugs that I haven't updated in the past n days based on user prefs or system params). Thinking like a new user for a moment, I may not know enough to use the Advanced Search page properly, but I want to know what I need to address right now. Without having to know too much about Bugzilla, what I need to address are new and stale bugs. This page doesn't help me find that information. > >>> It's getting intuitive when you getting more and more familiar with > >>> Bugzilla process, but is a complete mess for a newbie. > >> So we ask: > >> > >> - Is that page supposed to be used by newbies? > > No. But they do often need somewhat advanced, but not over-helming > > pages. > > What evidence do you have that people who have graduated from the simple > search form (and therefore already have some familiarity with Bugzilla) > still find the complicated one hard to understand? See my example above - in order to find bugs that are "new to me", the user can't get that currently from the "Find a Specific Bug" page. We also don't give the user a way to limit the specific bug searches to bugs that the user is assigned to, is the QA contact on, is a CC on, or is a commenter on. > > Another user role is "Customer The Great" often under-qualified to > > fill-out all controls, not patient and not willing to learn this "ugly > > pages". But their reports are gold for us. > > Why are you pointing your customers at the advanced search page? What do > you expect them to accomplish there? See above :) > > Yes, It is already customizable, but this increase the cost of > > ownership. > > So Bugzilla needs to ship with versions of the search page to meet every > possible need from every company which uses it? Not at all, but it seems fair that we should consider what the general user needs in order to accomplish day-to-day tasks without needing to go through a steep learning curve. > >>> IMO the best idea is to have a wizard-like search and bug entry pages, > >>> with ability to switch back to current pages when "the wizard" will > >>> start abuse you. > >> What, like the guided bug entry page we already have? :-) > > Which one? bugzilla.mozilla.org? Kind of... But in distrib. (I could > > miss recent 1-2 month changes at tip) > > We do distribute it, and have for years. It's create-guided.html.tmpl. How does a new user get to that page? How does an experienced user get to the non-guided page? I haven't seen that at http://.../enter_bug.cgi page. > >> - Which of our personas cares about sexiness/coolness? > >> > >> (If the answer is "none", it doesn't mean we can't make it look more > >> sexy. It just means that it's not a high priority.) > > Yeah, It isn't high priority task. But Bugzilla as a product suffer from > > that. > > Just try to imagine it a commercial product with just price cut down to > > zero. > > But Bugzilla is not a proprietary product with a price of zero. If it > was, most of us wouldn't be working on it. > > Let's turn the question on its head: is one of the goals of the Bugzilla > project to get as many companies and organisations using it as possible? > > As this is a value judgement, personal opinions are allowed :-) I > personally don't think that should be a particularly high priority goal. > Clearly, it's not good to have only a few places using it - but we are > well past that stage. Axosoft.com has an AdSense ad on Google if you search for just "Bugzilla" that says... Think Bugzilla is Free? Think again. Save time & money on an easy-to-use bug tracker www.Axosoft.com My company felt that it was worth their while to hire more than one person to manage and develop Bugzilla for use within AMD. Whether or not it cost AMD to get Bugzilla initially, it certainly does cost to maintain. Proprietary or not, one clear goal of mine is to contribute Bugzilla code where it makes sense to do so. If I don't do that, I'm wasting my time and AMD's money. Is Bugzilla proprietary? IMHO - only slightly. Is Bugzilla free? Free to download - yes. Free to get working and use - no, just like all the rest of the open source software. Someone has to have the expertise to get it working and keep it working. > >>> Yet another idea is to have several default (pre-shipped?) skins > >>> selectable by USER in his profile: > >> This clearly has a maintenance cost, so we ask: > >> > >> - Which persona needs this feature, and why? > > Every company it uses. Because of TCO and general attractiveness (Is > > there such a word in English? :). > > Re-skinning an application (in the usual sense of the word "skin" - i.e. > changing colours and logos) has no effect on TCO. It does if it's a requirement that company-supported tools have a certain look... It took real time to make the modifications necessary to make Bugzilla look like it needed to for AMD use. Granted, it wasn't a lot of time, but it is part of TCO. The better the examples, the easier it is to reduce that part of TCO. Is it worth creating a few more skins to get that net result? I don't know. Gerv - thanks for leading this discussion. :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From jochen.wiedmann at gmail.com Mon Jun 26 19:20:39 2006 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Mon, 26 Jun 2006 21:20:39 +0200 Subject: mod_perl: All paths must be absolute In-Reply-To: <1151335831.6419.1.camel@es-lappy> References: <1151335831.6419.1.camel@es-lappy> Message-ID: <44A03387.7030703@gmail.com> Max Kanat-Alexander wrote: > When running under mod_perl, we can't guarantee what directory we're > currently in. So, if you specify a path, it must be absolute. I suggest, that a better solution might be to switch to the Bugzilla directory at the beginning of a CGI script. The required changes and the required know how are fewer. Jochen From kevin.benton at amd.com Mon Jun 26 19:37:25 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 12:37:25 -0700 Subject: UI module owner Message-ID: > Gerv wrote: > > Do any of the people find it this problem ever click the "Give me some > > help" link at the top of the page? > > I've never seen or heard of anyone clicking it. But let's pretend I did. > > Zero, there's no What's This widget by that link, so I'd never click it. > First, there's no hint as to which things have help, so I don't know > what I can hover over, simply using dotted or doubled underlines would > help (alternatively offering whats this hover anchors would also > work). In Vincent Flanders's book "Son Of Web Pages That Suck - Learning Good Design by Looking at Bad Design", he calls this "Mystery Meat Navigation." It's not intuitive and hides capabilities from users. We could say the same thing for the shortcut keys on the Advanced Search page. How is a user supposed to know they can hit Alt-R to jump to the resolution field? When capabilities/features are hidden from users, it creates a supportability issue. > The problem here is that we don't give people examples or walk through > documents for using our features. If you show anyone how to use these > features it becomes instantly intuitive and they'll remember and use > it (ask smaug, I showed him over the weekend), but no one will guess. In the US, we have a saying - "a picture is worth a thousand words." What I'd like to see in a lot of our help is just what timeless is talking about - examples with visual reference - screen shots or reproductions. > > If they do, did they figure out how the help system worked? > > This is "First" in my list Many users found out by trial and error (not a good use of time). Others found out by asking a co-worker that knew (why make a user ask another how to use a tool - the tool should be able to explain itself). Others simply don't know. > > Did they get the info from hovering over the Date boxes? > > > Was it sufficient? > > This is "Second" in my list. I hate mystery meat navigation. If we're going to use tool tips, we need to tell users when a tool tip is available by supplying a ? or some other consistent glyph that tells users - here's help about this widget/field/control. If the user mouses-over, they get a brief help screen. If the user clicks on it, they get the same brief help followed up by at least one example of how to use the widget. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From dennis.melentyev at infopulse.com.ua Mon Jun 26 20:10:49 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Mon, 26 Jun 2006 23:10:49 +0300 Subject: UI module owner In-Reply-To: <44A0142A.90502@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1151340455.90475.174.camel@D-MELENTYEV.HOME> <44A0142A.90502@mozilla.org> Message-ID: <1151352649.90475.200.camel@D-MELENTYEV.HOME> ? ??, 26/06/2006 ? 18:06 +0100, Gervase Markham ?????: > Dennis Melentyev wrote: > > Well, it's mostly role-dependent. What about putting some role > > schemes/UI/WorkFlow/etc in? > > Now we're thinking along the right lines :-) :) > >> Why is basic search "too minimalistic"? And for whom? I assume you don't > >> mean "because it doesn't have enough widgets"; so do you mean "because > >> it doesn't find what you want some of the time"? > > It's more like "I'd like to specify also Open/closed flag, user and some > > date-related stuff". > > You can specify an open/closed flag on the basic search. Well, missed that, anyway I go directly to Advanced one. :) > Date-related stuff seems to me to be well into the realm of advanced > queries. After all, you can get simple date-related stuff for filing > date just by searching by bug number. And, assuming we fix up the > sorting on the results page, you could sort by last-changed-date to get > recently-changed bugs too. I personally hate remembering the numbers. Also, having lot's of bugs it's really hard to keep them all in mind. > > Yes, of cause it's doable via AdvSearch page. But each time you open it, > > you have to re-read it twice or so to remember what all that controls > > do. > > Are the labels not clear enough that one reading is enough? :-) There are tooo much labels to read them all. I have to pay attention to each of them to find one I really need. While looking at the page one would need to see the blocks first, then go to these blocks and look for something particular. Currently, AdvSearch page does not split good enough.
is not enough, help link is hardly visible along the other controls. Eyes needs "anchors" to stop at. Then you could easily narrow your task. > > Good alternative would be expandable panels like in show_bug with button > > mentioned already here. > > I do think expandable panels is worth looking at on that page. But we > would need to study people's queries to see which fields to group onto > particular panels. > > >>>> - Is that page supposed to be used by newbies? > >>> No. But they do often need somewhat advanced, but not over-helming > >>> pages. > >> What evidence do you have that people who have graduated from the simple > >> search form (and therefore already have some familiarity with Bugzilla) > >> still find the complicated one hard to understand? > > It has too many controls and no place to concentrate the sight at. > > Current layout offer more details moving from
to
, with > > main/primary controls at the top of the page. > > The biggest problem is: one have to pay too much attention. (And, > > better, need internals understanding to some degree) > > Which parts need understanding of internals? How would you change them > to not require such understanding? Well, I'm still not sure how to specify e-mail patterns in different fields/pages (review req, search page, groups administrating). There are regexps and simple patterns. Actually I often grep the code as it is just faster then find a document. > (Boolean charts require some internals understanding, but I think that's > OK, because you couldn't have them stay that powerful if you removed > that requirement.) Well, semi-agree. > >>> Another user role is "Customer The Great" often under-qualified to > >>> fill-out all controls, not patient and not willing to learn this "ugly > >>> pages". But their reports are gold for us. > >> Why are you pointing your customers at the advanced search page? What do > >> you expect them to accomplish there? > > They are working with us on bugs related to their products/components. > > But don't you use groups to make sure that bugs in their > products/components are the only ones they can see anyway? Yes. Sure! But there are still more then one item available for them. > > Yes, but adapting workflow to corporate standards should be much easier > > than it is now. > > I agree with that. Evidence from the newsgroup suggests that customising > the workflow (statuses and resolutions) is an extremely common request, > and currently to do it I believe you have to hack Bugzilla in a way > which makes it hard to upgrade. Yup! The most annoying thing about Bugzilla. PS. My previous post died somewhere in list-processor bubbling about header longer than 4 hundred and a drop. Pity, but I not fond of trying to re-post it... From kevin.benton at amd.com Mon Jun 26 20:04:01 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 13:04:01 -0700 Subject: UI module owner Message-ID: > So why is it that we can't say that if someone files a bug in Mandrake's > Bugzilla about their browser, and it turns out to be a bug in Firefox, > we file a bug in b.m.o, close the Mandrake one and tell the users to > watch the b.m.o. bug? Yes, this could be made a bit easier by something > like the current "bug moving" mechanism but less hacky. But I don't see > the need for bi-directional linking, given that we don't use it in other > analogous situations. In a for-profit situation, bi-directional links could create problems with the inappropriate release of intellectual property, but that shouldn't prevent companies from deciding to link bugs from one installation to another within the company. One could say that the fact that we display URLs in the comments should suffice, but that doesn't set the link off enough. If we were to implement a URL field for each potential dependency, blocker, duplicate, etc., then the problem would be solved. > [There's also the issue that I suspect that it would be a real pain to > implement, test and keep working, particularly when the Bugzilla > versions start getting out of step, and after a few years when we've > released four releases and the testing compatibility matrix starts > getting larger and larger.] I don't believe that would be an issue if we would simply implement a hyperlink for "other" installation bug ID's. > >> Clearly, it's not good to have only a few places using it - but we are > >> well past that stage. > > > > It's not good for every single consumer of this product to fork it > > just to make it work for them. > > The number of logical issues with that statement take my breath away. > > Firstly, you start out by using a perjorative word ("fork") to buttress > your position, when what we are actually talking about is customisation, > which can be more or less of a "fork" depending on the customisation > mechanism used and the level of customisation required. Please don't make the assumption that we haven't forked. AMD has made enough customizations to the code itself that it really is a fork. While we work hard to make our customizations parallel to the mainline, it really isn't the same code. In my mind, a customization is a small set of changes that are easily maintained that generally only affect what the user sees, not the underlying method of processing that information. > Secondly, you use over-generalisaion ("every single consumer") when > quite clearly by observation, not every single consumer of Bugzilla > makes significant customisations to it. Obviously, however, without empirical data, I believe that there enough forks out there to at least consider what impact it will have. I believe it should be our goal to find out why others have forked and find out if there are things we should be doing that make sense to implement so those entities that have forked can re-join us in the main code line. > Thirdly, you over-exaggerate ("just to make it work for them"); again > clearly, by observation, Bugzilla already works in its default > configuration, and can meet a lot of people's needs. I'm not looking at the original, but I can certainly say that there are times when a requirement is just that - a requirement. If a product doesn't meet certain requirements, the product is unusable for the potential customer's (user's) purpose. Does that mean it can't be adapted? Generally, no. Sometimes, however, the cost of adapting is too great, thus making the product unusable to the customer. > All in all, not a good start as a basis for arguing for a particular > change. It's not? It seems to have gotten a good discussion going. :) > >> Re-skinning an application (in the usual sense of the word "skin" - > i.e. > >> changing colours and logos) has no effect on TCO. > > > > The skinning we're interested in is more akin to guided, it's not the > > same as modern v. classic, it's the difference between advanced and > > simplified. > > Then it might help not to call it skinning. The usual use of the word > "skinning" (and the Bugzilla use - see the skins/ directory) is making > graphical/cosmetic changes which do not have significant effects on the > underlying functionality. For that, we have historically used > "customisation". It seems to me we need to decide on what terminology we're going to use here. I've seen fork, customization, and skinning. Depending on the user, each word has meant different things. > >> > We just need a samples bundled in distro. > >> They are. > > > > We have samples half bundled, we still have people asking how to > > integrate things very much like the guided entry form, which if they > > were fully integrated shouldn't happen. > > The original rationale for the way they are bundled is that we wanted to > keep the distribution generic, rather than Mozilla-specific. So, we said > we would include the Mozilla-specific guided format as an example of > what could be done, and put a big comment at the top saying "this is an > example". > > Are you suggesting that we should fully integrate Mozilla-specific > customisations into the stock Bugzilla, so they serve as better > examples? (That might be a reasonable thing to suggest.) If not, what > are you suggesting we change about the current method of bundling? Why not? It seems to me that the guided template method would appeal to most admins and new users. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From gerv at mozilla.org Mon Jun 26 17:08:45 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 18:08:45 +0100 Subject: UI module owner In-Reply-To: <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> Message-ID: <44A0149D.9050706@mozilla.org> timeless wrote: > As I said, I already laid into them, they're bad and I'm not going to > spend my time helping you prop up something which I know doesn't work. I'm afraid I must have missed your critique of the idea of personas. There seemed to be a reasonable amount of support for using them as a design tool in the last IRC meeting. > I've used a number of Bugzillas, most of the changes are fairly > similar. I think it's fairly safe, as long as you accept some other > bits which I'm proposing in a blog entry which I'm *not* writing > because I'm *wasting* time writing this email. I'm quite happy to attempt to continue a civilised discussion about Bugzilla's requirements and UI design. If you feel you don't have time to contribute to it, or that you can't make the effort to be civilised, that's very sad; we'll just have to have it without you. Gerv From dennis.melentyev at infopulse.com.ua Mon Jun 26 17:11:33 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Mon, 26 Jun 2006 20:11:33 +0300 Subject: UI module owner In-Reply-To: <449FD96B.5040205@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <10FB3FC0-7676-459A-844A-EFB6D81AB889@joostdevalk.nl> <449FD96B.5040205@mozilla.org> Message-ID: <1151341893.90475.182.camel@D-MELENTYEV.HOME> ? ??, 26/06/2006 ? 13:56 +0100, Gervase Markham ?????: > Joost de Valk wrote: > > I am, for quite obvious reasons i think, being a WebKit dev, very much > > opposed to any Mozilla-specific, or any other browser specific > > customisation into stock bugzilla. Let's not become the next Microsoft > > here... > > You see, this is the problem :-) Some people are saying that examples of > Bugzilla customisation need to be "better integrated"; others are saying > that's bad, because they'd have to de-integrate them before using them! :-) Afraid, both of you misread each-other's text. Joost think it's browser-specific, you think it's project specific. BTW, mozilla's approach is a good one. And worth to incorporate it with EASILY tunable details. > I personally think we have struck the right balance. The customisation > examples are there, and documented in the Guide if you want to use them, > but are not visible in the default interface. I'd like to see different of them based on users role (for the default) AND personal preferences. PS. Timeless, sorry for keeping this flame burning, but this *might* result in some vision of directions of future development, IMO. If not, I'll shut up. From kevin.benton at amd.com Mon Jun 26 20:53:17 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 13:53:17 -0700 Subject: UI module owner Message-ID: ... more follow-up from this email... > timeless wrote: > > Bugzilla should ship such that most companies don't feel the need to > > implement dozens of horrible hacks that cause them to refuse to > > upgrade to a newer version of Bugzilla later. > > Gregg completely agrees with you. > http://wiki.mozilla.org/Bugzilla:Personas:Gregg > > (BTW, everyone, the personas are still works in progress. Let me do a > bit more work before you lay into them :-)) > > > Bugzilla should be the standard tracking system that companies and > > organizations use, so that when I have a problem with any product > > anywhere, I can turn to a comfortable fairly standard Bugzilla > > installation which I can easily log into, select my standard per user > > custom settings and feel right at home explaining my problem or > > finding out the status of a preexisting report that I was able to find > > about my problem. > > How likely do you think it is that these different > companies/organisations requirements will be similar enough that all the > Bugzillas will be "fairly standard"? > > Thought: none of the current personas use multiple Bugzillas. Does that > mean that this is a niche use, or that we've failed to capture something > in the existing persona set? The later - I think we've failed to capture this in the existing persona set. I may be a typical admin/developer that did not install Bugzilla initially for some AMD users, however, I continue to maintain it. I maintain a number of installations that I am still merging code on, and I also use Bugzilla outside AMD (BMO, for example). > > Bugzilla should enable any company to easily send a problem report to > > the next company or organization's Bugzilla without resorting to > > hacks. Note that in almost all cases this communication is > > bidirectional, it's not just a "move", it's some sort of "keep these > > bugs in sync" or "share comments across bugs" or "establish a > > dependency between these bugs". It's fairly rare for anything to be a > > simple "move" (the hack implemented for bugscape), most customers or > > consumers appreciate at least being told "this is fixed in the next > > version" and "the next version shipped with this fixed, you can > > actually download it now", which are things you don't get if you just > > "move" a bug. > > Observation: even if we have "get as many people as possible using it" > as a goal, that doesn't by itself imply that moving bugs from one > Bugzilla to another, or linking them together, is a requirement. I think that linking to a foreign Bugzilla installation is a reasonable requirement. I have a Bugzilla product on one of my installations here that is used to track Bugzilla in general as well as customizations related to Bugzilla here inside AMD. It's helpful to be able to resolve my local bug 12345 is a duplicate of BMO bug 4214657. That's not currently possible using distributed code. > why is the right solution to this problem just "move the bug > across/refile it, and have interested parties track it in the other > Bugzilla"? A bug in the distributed code needs to be fixed and usually benefits everyone including the one reporting it or tracking it if it's fixed there. Initially, it'll be reported in the local installation, then filtered up to BMO (assuming I take the time to re-file it there and verify it's really a distributed code issue and not a local customization). > Let's look analogous situations. If a user files a bug, and it turns out > that it's a duplicate of another one, do we "link them together and > share comments"? No, we mark it as a dupe, it gets closed and the filer > watches the other bug. Actually, it doesn't get closed, it gets resolved as a duplicate. Inside AMD, it doesn't get closed till the installation(s) it impacts have been verified as fixed. > If a user files a bug in the Firefox product, and it turns out that the > problem is actually in the Core, do we open a core bug and link them > together? No, we move the bug to the Core product, and have it fixed > there - even if the bug report then becomes about fixing the underlying > problem, rather than the particular symptoms the user sees. That's true because Firefox also belongs to Mozilla. The problem with my situation is that I may have intellectual property (IP) that I can't release to MF in my bug, so I have to create a duplicate on BMO then link my local bug to it. > So why is it that we can't say that if someone files a bug in Mandrake's > Bugzilla about their browser, and it turns out to be a bug in Firefox, > we file a bug in b.m.o, close the Mandrake one and tell the users to > watch the b.m.o. bug? Yes, this could be made a bit easier by something > like the current "bug moving" mechanism but less hacky. But I don't see > the need for bi-directional linking, given that we don't use it in other > analogous situations. IP rights may prevent us from doing that. > [There's also the issue that I suspect that it would be a real pain to > implement, test and keep working, particularly when the Bugzilla > versions start getting out of step, and after a few years when we've > released four releases and the testing compatibility matrix starts > getting larger and larger.] --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Mon Jun 26 21:08:59 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 14:08:59 -0700 Subject: Give me some help (was: UI module owner) Message-ID: Subject changed due to overly broad description > timeless wrote: > > Zero, there's no What's This widget by that link, so I'd never click it. > > Are you saying that "Give me some help" is not a sufficient indication > of what the link does, or sufficient encouragement to click it? > > What do you think the link text should say? Or do you think the Help > trigger should be elsewhere? Or that it should be present even in the > base page? I suggest that the "Give me some help" page is not sufficient. Users need more help than what field is used for what - they need sample applications, tutorials, etc. It's great for those that already have a basic understanding of how to use the Advanced Search page, but for the first timer, it's daunting at best. While the Bugzilla User's Guide is there, most users aren't given a copy when they hit Bugzilla for the first time. I think this is our fault in part as developers. I think we ought to provide our users with a form of the User's Guide right from the initial login page. > > First, there's no hint as to which things have help, so I don't know > > what I can hover over, simply using dotted or doubled underlines would > > help (alternatively offering whats this hover anchors would also > > work). > > Well, the top of the newly-reloaded page does say "For help, mouse over > the page elements." So you can find out what has help by mousing over > things. Having said that, all the widgets should have help - do any of > them not? I believe all the inputs should have help, even the bug summary. If the user puts their mouse over a field, help should be provided either in the form of tool tips or as a clickable link somewhere. > It's hard to dotted-underline a widget... > > > Second, here's the actual help text for that box: > > > > Specify the start and end dates either in YYYY-MM-DD format > > (optionally followed by HH:mm, in 24 hour clock), or in relative > > dates such as 1d, 2w, 3m, 4y, which respectively mean one day, > > two weeks, three months, or four years ago. 0d is last midnight, > > and 0w, 0m, 0y is the beginning of this week, month, or year. > > > > What part of this says to use -2m or -2w or -*ANYTHING* if you want to > > go backwards?! > > The original poster was incorrect in their understanding. There is no > need for a minus sign, and it is ignored if present. The help text is > correct (if perhaps a little terse). > > For things changed between 3 weeks and 2 days ago, you put "3w" into the > first box, and "2d" into the second box. > > We should probably permit a more verbose version of this syntax. How about we provide examples next to the description? > >> If not, why not - because they didn't notice it? > >> Because they didn't think it would help? > > > > Having used it once, I can assure you, I'd never use it again, it's > > barely more helpful than a Unix document. Even Microsoft help which > > people love to complain about is considerably better. Especially given > > that the number one search anyone ever wants to do is something like > > -1m. > > What is incorrect about that help text? Suggestions for better wording > are most welcome. See above. > > The problem here is that we don't give people examples or walk through > > documents for using our features. If you show anyone how to use these > > features it becomes instantly intuitive and they'll remember and use > > it (ask smaug, I showed him over the weekend), but no one will guess. > > How do you suggest integrating such help into the interface? Or are you > suggesting changes to the Bugzilla Guide? I think we ought to do both - provide examples through simulating the user input and describing what it would do at the help level, and providing the same help in the guide. I think that the Bugzilla Guide should be a part of the distribution in such a way that the help system refers users directly to the proper section in the guide. That can give users the context they may be looking for. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Mon Jun 26 21:34:52 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Mon, 26 Jun 2006 14:34:52 -0700 Subject: UI module owner Message-ID: > I mentioned earlier that I was delayed in writing some blog articles > because of this thread, anyway, here they are: > > http://viper.haque.net/~timeless/blog/117/ > http://viper.haque.net/~timeless/blog/118/ > > FWIW, there are literally over a hundred entries in my "blog". they're > in more or less finished states, I don't mind if people read them, and > at some point I will try to make more of them public and finalized. Hey Timeless - it's hard to read your blog in context if you don't tell us where the whole blog is... :) --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From gerv at mozilla.org Mon Jun 26 21:57:46 2006 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 26 Jun 2006 22:57:46 +0100 Subject: UI module owner In-Reply-To: <44A006AC.4050304@dberlin.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> Message-ID: <44A0585A.8040802@mozilla.org> Daniel Berlin wrote: > I have maintained many Bugzillae, and I have *never had a single > Bugzilla where all i had to do was change templates*. Did you make the same changes each time, or different changes depending on the circumstances? Or, to phrase the question another way, do you think it's realistic to aim to have a bug system which works for a significant percentage of people without requiring code changes? Which changes did you most commonly have to make? > The only people i've met who *ever* use Bugzilla in it's default > configuration are those who are using it very temporarily, and don't > want to "fuss with code to get it to work how I want". That's an exact > quote, btw. Note the use of the word "code". This is not a mistake. No > interesting customization people perform can be performed to Bugzilla > without modifying the *existing code*. There are loads of "interesting" customisations you can make without modifying code. Perhaps you meant "useful"? If so, I'd be interested to know why bug entry templates, the format system, the skin system, the custom templates system and the hooks system are all not useful? Did we solve all the wrong problems? Or did we start solving the right problems but not go far enough? Gerv From justdave at bugzilla.org Tue Jun 27 03:02:42 2006 From: justdave at bugzilla.org (David Miller) Date: Mon, 26 Jun 2006 20:02:42 -0700 Subject: Give me some help (was: UI module owner) In-Reply-To: References: Message-ID: <44A09FD2.4090703@bugzilla.org> Benton, Kevin wrote on 6/26/06 2:08 PM: > I think we ought to provide our users with a form of the User's Guide right from the initial login page. This isn't a bad idea. Probably what we should do is separate the existing docs into a "Users' Guide" (all the user facing stuff), an "Application Admin's Guide" (all the admin pages accessible via the web), and a "System Admin's Guide" (installation, and stuff you can do from the shell). They're fairly distinct audiences, and I can easily imagine enterprise installations wanting to customize the first two of those for their local policies and procedures. The first can be linked off the index page, the second off the top of the params page (or a new admin landing page or something). -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Tue Jun 27 03:08:51 2006 From: justdave at bugzilla.org (David Miller) Date: Mon, 26 Jun 2006 20:08:51 -0700 Subject: UI module owner In-Reply-To: References: Message-ID: <44A0A143.4020802@bugzilla.org> Benton, Kevin wrote on 6/26/06 11:12 AM: >>> 3. wap-enabled minimalistic >> Which persona needs to access Bugzilla over WAP, and why? > > When Bugzilla is used as a support database for network engineers, WAP access allows those engineers to read "all about it" before they get to the site to fix issues. If we want to cover those users better, we need to make bug displays work well in a WAP environment. I don't have an immediate *need* for it today, though it would be helpful to me. I wouldn't count it on a short list of current priorities, personally. I'll give you a direct example of this. :) When I'm the on-call sysadmin at Mozilla, and someone files a bug in the Server Ops component with a critical or blocker severity, our monitoring system will notice the bug and page me with the bug number and summary. If I'm not in front of a computer at the time, it'd be *really* useful to be able to check and find out what the bug is about (sometimes people write pretty useless summaries) to see if it really needed to be critical or not before I drop whatever I'm involved in and travel somewhere to find a computer. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Tue Jun 27 03:44:36 2006 From: justdave at bugzilla.org (David Miller) Date: Mon, 26 Jun 2006 20:44:36 -0700 Subject: UI module owner In-Reply-To: References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <9A7212FC-47B7-4D40-A067-67F14CB09B26@joostdevalk.nl> <449FBEE8.3050000@mozilla.org> <4278CDC8-B090-49F1-BA78-EE027B4593FB@joostdevalk.nl> <449FD3DD.1050605@mozilla.org> Message-ID: <44A0A9A4.5090900@bugzilla.org> Joost 'AlthA' de Valk wrote on 6/26/06 6:11 AM: >> - Work out a different way of integrating help > > the [?] icons are the best options imho, especially because users are > used to that in other applications. I like this idea, too. This is a good use for AJAX, you dynamically load the contents of a popup
when the user clicks the icon. An icon with a question mark is a LOT more obvious than hyperlinking the field names. Something else I've seen done in other software is to have really short descriptions of the fields in a column on the right-hand side, which is shown by default, with links to "more info" on the ones that need more description, and a user preference to hide that help column. Can't get much more obvious than that :) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Tue Jun 27 03:50:42 2006 From: justdave at bugzilla.org (David Miller) Date: Mon, 26 Jun 2006 20:50:42 -0700 Subject: UI module owner In-Reply-To: References: Message-ID: <44A0AB12.9020307@bugzilla.org> Benton, Kevin wrote on 6/26/06 1:53 PM: > I think that linking to a foreign Bugzilla installation is a reasonable > requirement. I have a Bugzilla product on one of my installations here > that is used to track Bugzilla in general as well as customizations > related to Bugzilla here inside AMD. It's helpful to be able to resolve > my local bug 12345 is a duplicate of BMO bug 4214657. That's not > currently possible using distributed code. Red Hat already does this on their Bugzilla, and I really like their implementation of it. All they're doing is providing a link to the upstream bug though. It would be way cool to have a cron job that periodically polls such bugs for their status and displays it on the local bug (or perhaps do it right when a user views the local version - cache it of course to avoid DoSsing the upstream server) if the upstream system is public, and mail the local CC list on upstream status changes. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Tue Jun 27 03:57:02 2006 From: justdave at bugzilla.org (David Miller) Date: Mon, 26 Jun 2006 20:57:02 -0700 Subject: UI module owner In-Reply-To: <449FC8B7.5030200@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> Message-ID: <44A0AC8E.9000700@bugzilla.org> Gervase Markham wrote on 6/26/06 4:44 AM: > timeless wrote: >> It's not good for every single consumer of this product to fork it >> just to make it work for them. > > Secondly, you use over-generalisaion ("every single consumer") when > quite clearly by observation, not every single consumer of Bugzilla > makes significant customisations to it. Mozilla even forks Bugzilla from the upstream version now. See https://bugzilla.mozilla.org/CUSTOMIZATIONS/ That directory of patch files isn't exactly small. :) Several of those are things that are definitely Mozilla-specific, and probably nobody else would ever have a use for them, so it's not appropriate to port them upstream. Others are things that are hacky ways to do something that probably would be done upstream if someone patched it, but really need to be done in a much cleaner way if it gets distributed. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Tue Jun 27 03:38:43 2006 From: justdave at bugzilla.org (David Miller) Date: Mon, 26 Jun 2006 20:38:43 -0700 Subject: UI module owner In-Reply-To: <1151352649.90475.200.camel@D-MELENTYEV.HOME> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1151340455.90475.174.camel@D-MELENTYEV.HOME> <44A0142A.90502@mozilla.org> <1151352649.90475.200.camel@D-MELENTYEV.HOME> Message-ID: <44A0A843.7010109@bugzilla.org> Dennis Melentyev wrote on 6/26/06 1:10 PM: > PS. My previous post died somewhere in list-processor bubbling about > header longer than 4 hundred and a drop. Pity, but I not fond of trying > to re-post it... Yeah, the References: line is getting too long ;) I upped that limit this afternoon because I got tired of approving posts. :) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bugzilla at joostdevalk.nl Tue Jun 27 09:34:11 2006 From: bugzilla at joostdevalk.nl (Joost de Valk) Date: Tue, 27 Jun 2006 11:34:11 +0200 Subject: UI module owner In-Reply-To: <44A0585A.8040802@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> Message-ID: <44A0FB93.10407@joostdevalk.nl> Gervase Markham wrote: > Daniel Berlin wrote: > >> The only people i've met who *ever* use Bugzilla in it's default >> configuration are those who are using it very temporarily, and don't >> want to "fuss with code to get it to work how I want". That's an exact >> quote, btw. Note the use of the word "code". This is not a mistake. No >> interesting customization people perform can be performed to Bugzilla >> without modifying the *existing code*. >> > > There are loads of "interesting" customisations you can make without > modifying code. Perhaps you meant "useful"? > I must agree with Daniel here, my experience is that some stuff simply isn't there to play with. One of the simple customizations i'm thinking of here is the fact that you have to expose the bug variable to the template in attachment.cgi, to do ANYTHING based on which product you're adding an attachment for. Simple stuff like that requires you to fiddle with the code, so i think a lot of useful and quite simple customizations would require you to change code. Regards, Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: From timeless at gmail.com Tue Jun 27 10:06:09 2006 From: timeless at gmail.com (timeless) Date: Tue, 27 Jun 2006 13:06:09 +0300 Subject: UI module owner In-Reply-To: References: Message-ID: <1a75cc570606270306k7098ae6bk969173c320c5ae0f@mail.gmail.com> I wrote: > http://viper.haque.net/~timeless/blog/117/ > http://viper.haque.net/~timeless/blog/118/ On 6/27/06, Benton, Kevin wrote: > Hey Timeless - it's hard to read your blog in context if you don't tell > us where the whole blog is... :) That's a secret. <#mozwebtools> word timeless's blog? rumour has it timeless's blog is http://viper.haque.net/~timeless/blog/ All entries are numbers, just enter numbers starting with 1 and work your way through 118 :). From timeless at gmail.com Tue Jun 27 10:11:06 2006 From: timeless at gmail.com (timeless) Date: Tue, 27 Jun 2006 13:11:06 +0300 Subject: UI module owner In-Reply-To: <44A0FB93.10407@joostdevalk.nl> References: <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A0FB93.10407@joostdevalk.nl> Message-ID: <1a75cc570606270311v57aab8e2xf055e93174d7c8e5@mail.gmail.com> On 6/27/06, Joost de Valk wrote: > I must agree with Daniel here, my experience is that some stuff simply > isn't there to play with. One of the simple customizations i'm thinking of > here is the fact that you have to expose the bug variable to the template in > attachment.cgi, to do ANYTHING based on which product you're adding an > attachment for. https://bugzilla.mozilla.org/show_bug.cgi?id=342837 Is someone planning on actively reaping all the ideas that are coming out of this amazingly long discussion? it takes hours just to read it, and making sure we don't miss things is among the many reasons I hate threads like this. At least irc is fairly short and I can eventually linearly pick out the ideas and write them into articles. From timeless at gmail.com Tue Jun 27 10:16:28 2006 From: timeless at gmail.com (timeless) Date: Tue, 27 Jun 2006 13:16:28 +0300 Subject: UI module owner In-Reply-To: <44A0149D.9050706@mozilla.org> References: <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A0149D.9050706@mozilla.org> Message-ID: <1a75cc570606270316q7803f58l90e087247e6edd00@mail.gmail.com> timeless wrote: > As I said, I already laid into them, they're bad and I'm not going to > spend my time helping you prop up something which I know doesn't work. On 6/26/06, Gervase Markham wrote: > I'm afraid I must have missed your critique of the idea of personas. That was intentional. If I showed you the critique, you'd have adapted personas and claimed that it didn't fail as badly as it did. You can find the entry, but I expect that you will honor my request and *not* add things listed in it. Because the act of reading it and adding the items listed constitutes cheating. I proposed a 2 week moratorium before I published it for you to view so that people could see how spectacularly your proposal *failed* to capture the world it purported to describe. > There seemed to be a reasonable amount of support for using them as a > design tool in the last IRC meeting. Sorry, I had a life and had to deal with it instead of attending the IRC meeting. The time slot was bad for me, justdave and a number of others. It also wasn't the normal slot, so you can't blame me for not being available. I'd also like to go on record as saying that you guys screwed up by pissing off beltzner and not treating him with respect. From mkanat at bugzilla.org Tue Jun 27 10:50:55 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 27 Jun 2006 03:50:55 -0700 Subject: mod_perl: All paths must be absolute In-Reply-To: <44A03387.7030703@gmail.com> References: <1151335831.6419.1.camel@es-lappy> <44A03387.7030703@gmail.com> Message-ID: <1151405455.2377.4.camel@es-lappy> On Mon, 2006-06-26 at 21:20 +0200, Jochen Wiedmann wrote: > I suggest, that a better solution might be to switch to the Bugzilla > directory at the beginning of a CGI script. The required changes and the > required know how are fewer. Yeah, it's possible, but it wouldn't work at compile-time, and I also need it to work there. (Trust me, it's basically impossible under mod_perl at compile-time to switch to the directory of the currently-running script, without knowing the absolute path of the directory in advance.) I actually already made pretty much all the required changes, in a patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=342744 -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From dennis.melentyev at infopulse.com.ua Tue Jun 27 11:13:11 2006 From: dennis.melentyev at infopulse.com.ua (Dennis Melentyev) Date: Tue, 27 Jun 2006 14:13:11 +0300 Subject: UI module owner In-Reply-To: <44A0A843.7010109@bugzilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1151340455.90475.174.camel@D-MELENTYEV.HOME> <44A0142A.90502@mozilla.org> <1151352649.90475.200.camel@D-MELENTYEV.HOME> <44A0A843.7010109@bugzilla.org> Message-ID: <1151406791.90475.203.camel@D-MELENTYEV.HOME> ? ??, 26/06/2006 ? 20:38 -0700, David Miller ?????: > Dennis Melentyev wrote on 6/26/06 1:10 PM: > > > PS. My previous post died somewhere in list-processor bubbling about > > header longer than 4 hundred and a drop. Pity, but I not fond of trying > > to re-post it... > > Yeah, the References: line is getting too long ;) I upped that limit > this afternoon because I got tired of approving posts. :) Thanks a lot! It was kind of you. From dberlin at dberlin.org Tue Jun 27 13:11:02 2006 From: dberlin at dberlin.org (Daniel Berlin) Date: Tue, 27 Jun 2006 09:11:02 -0400 Subject: UI module owner In-Reply-To: <44A0585A.8040802@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> Message-ID: <44A12E66.8070302@dberlin.org> Gervase Markham wrote: > Daniel Berlin wrote: >> I have maintained many Bugzillae, and I have *never had a single >> Bugzilla where all i had to do was change templates*. > > Did you make the same changes each time, or different changes depending > on the circumstances? > Usually the same changes, but i've had to rewrite them several times in the past few versions, as every version doesn't just seem to move code (which i don't really mind), but rewrite the same code again and again (This is not simple mod_perlification remnants) > Or, to phrase the question another way, do you think it's realistic to > aim to have a bug system which works for a significant percentage of > people without requiring code changes? Yes, but I don't believe Bugzilla is doing a good job of it, at all. In fact, I know of an large bugzilla user (supporting about 40 products, with >100k bugs total) that just completely gave up on Bugzilla very very recently because they got tired of trying to support their own changes in the face of the code changes Bugzilla is currently going through. Most of their changes consisted of what I have done for GCC: adding a few fields, removing a few fields, and the validation associated with this. Other than that, they wanted to do nice ajax'y things, but the workflow and code of bugzilla just doesn't give you the necessary hooks to do this without hacking up every source file in sight. Given all this, they just decided to put a couple engineers on the task of making a nice sane bug tracker, and surprisingly, in about 2 man years, they have *done just that*. > Which changes did you most commonly have to make? Let's see: Exposing any new variable to the bugs templates requires changing the code. Hiding a field that Bugzilla believes is required but is useless to your installation requires hacking up the edit script and the templates. Adding any sort of validation routines for some of the more freeform fields requires hacking up post_bug.cgi, the templates, the error list, the xml importer, etc. Adding or removing a field from the actual database is worse than any of this, and the way custom fields are progressing, it's unlikely to solve it for another 5 years. It's even worse if i want to add a "did you mean?" style page for misentered input to a field. The problem isn't even that I have to write code, it's that i have to hack up the standard source files to do it, and I should not have to, because then i have to maintain these hacks as the source files change and move. Bugzilla seems to have missed the entire idea that people need to write source code to do things, and to provide *standard source code hooks* in places to let me do these things that load files from some standard dir. That way, you guys can rewrite and move your code around, and just give me a damn bug object or a bug transaction or something, and i'll do my validation or whatever, and throw an error if there is a problem. As a side note, I've actually always been surprised that bugzilla has no transaction objects, considering that things either look really ugly, or are just broke, if the database is left half-modified. IE bugs with no initial comment, etc. Why the process of modifying a bug in some manner, from beginning to end, for a single request that may change the bug, the duplicates list, and the comments, is not encapsulated in some transaction object is beyond me. But back to the topic at hand: half the time in changing this stuff between versions is figuring out where the code moved, then just rewriting it to whatever the new style of the day is for that code. It doesn't really do anything different, it just seems to have changed coding style because someone felt it looked cleaner (again I'm *not* talking about the obviously necessary changes for mod_perl'ification, like removing globals, etc). The template system is nice, but most of Bugzilla changes affect the dynamic workflow of Bugzilla in some small way, and templates don't provide enough to let you do this. > >> The only people i've met who *ever* use Bugzilla in it's default >> configuration are those who are using it very temporarily, and don't >> want to "fuss with code to get it to work how I want". That's an exact >> quote, btw. Note the use of the word "code". This is not a mistake. No >> interesting customization people perform can be performed to Bugzilla >> without modifying the *existing code*. > > There are loads of "interesting" customisations you can make without > modifying code. Perhaps you meant "useful"? I disbelieve you :). Then again, I don't consider changing the colors and look to be interesting > > If so, I'd be interested to know why bug entry templates, the format > system, the skin system, the custom templates system and the hooks > system are all not useful? Did we solve all the wrong problems? Mostly, yes. The only templates people I know change are maybe the front template, and whatever is required to hide or move around some field. The hooks system is mostly useless, because you still can't do anything interesting without hacking up shipped source files that you really don't want to be touching. Ideally, all the code *I* need to write to do what I want should be in separately source files that bugzilla loads and calls, and to be honest, for what i'm doing for GCC Bugzilla, I don't think this is unreasonable at all. --Dan From bugreport at peshkin.net Tue Jun 27 13:42:14 2006 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 27 Jun 2006 06:42:14 -0700 Subject: Personas Message-ID: <44A135B6.4010901@peshkin.net> The concept of personas is pretty cool. I did notice that none of our personas are working for a company that is metric-happy. Having worked for management that insisted on all sorts of fancy charts showing bug distribution times and similar functions, I am quite aware that we have room for more development in that area. Should we either add new personas that take this into account or add that to some of the existing ones? From lpsolit at gmail.com Tue Jun 27 13:44:32 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Tue, 27 Jun 2006 15:44:32 +0200 Subject: UI module owner In-Reply-To: <44A12E66.8070302@dberlin.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A12E66.8070302@dberlin.org> Message-ID: <44A13640.7010906@gmail.com> > Exposing any new variable to the bugs templates requires changing the code. > > Hiding a field that Bugzilla believes is required but is useless to your > installation requires hacking up the edit script and the templates. > > Adding any sort of validation routines for some of the more freeform > fields requires hacking up post_bug.cgi, the templates, the error list, > the xml importer, etc. > As a side note, I've actually always been surprised that bugzilla has no > transaction objects, considering that things either look really ugly, or > are just broke, if the database is left half-modified. IE bugs with no > initial comment, etc. Why the process of modifying a bug in some > manner, from beginning to end, for a single request that may change the > bug, the duplicates list, and the comments, is not encapsulated in some > transaction object is beyond me. > Ideally, all the code *I* need to write to do what I want should be in > separately source files that bugzilla loads and calls, and to be honest, > for what i'm doing for GCC Bugzilla, I don't think this is unreasonable > at all. Related to what Daniel Berlin wrote about bug changes: several patches going in the direction you suggest are under review, see e.g. bug 340278, bug 122922, bug 305136, bug 174988 and in a less direct manner bug 297791. They should make customization much easier. There is a good hope to see them fixed for Bugzilla 3.0. LpSolit From tcunningham at vfa.com Tue Jun 27 13:45:15 2006 From: tcunningham at vfa.com (Cunningham, Tom) Date: Tue, 27 Jun 2006 09:45:15 -0400 Subject: Making Bugzilla read-only? Message-ID: Hi, I'm doing some migration and I'd like to make a bugzilla read-only so that no one is able to make changes, but they still need the ability to browse bugs in Bugzilla. Is there an easier way to do this other than restricting insert/update/delete access to the bugzilla mysql user? Is dealing with this through mysql the best way to go about this? Thanks for the help in advance, Tom Cunningham -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Tue Jun 27 14:02:28 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 27 Jun 2006 07:02:28 -0700 Subject: Use Bugzilla->params instead of Param Message-ID: <1151416948.2377.7.camel@es-lappy> Just to let you guys know, everybody should be using Bugzilla->params->{'paramname'} everywhere instead of Param('paramname'), now. Param('paramname') will be going away. I haven't yet decided how we're going to do that in the templates, yet, but it will probably be params.paramname or bz_params.paramname. -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From justdave at bugzilla.org Tue Jun 27 14:21:20 2006 From: justdave at bugzilla.org (David Miller) Date: Tue, 27 Jun 2006 07:21:20 -0700 Subject: Personas In-Reply-To: <44A135B6.4010901@peshkin.net> References: <44A135B6.4010901@peshkin.net> Message-ID: <44A13EE0.9070404@bugzilla.org> Joel Peshkin wrote on 6/27/06 6:42 AM: > The concept of personas is pretty cool. I did notice that none of our > personas are working for a company that is metric-happy. Having worked > for management that insisted on all sorts of fancy charts showing bug > distribution times and similar functions, I am quite aware that we have > room for more development in that area. > > Should we either add new personas that take this into account or add > that to some of the existing ones? Perhaps add new ones, as the existing ones obviously reflect how someone deals with it somewhere. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mkanat at bugzilla.org Tue Jun 27 14:28:27 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 27 Jun 2006 07:28:27 -0700 Subject: Making Bugzilla read-only? In-Reply-To: References: Message-ID: <1151418508.2377.9.camel@es-lappy> On Tue, 2006-06-27 at 09:45 -0400, Cunningham, Tom wrote: > I?m doing some migration and I?d like to make a bugzilla read-only so > that no one is able to make changes, but they still need the ability > to browse bugs in Bugzilla. Is there an easier way to do this other > than restricting insert/update/delete access to the bugzilla mysql > user? Is dealing with this through mysql the best way to go about > this? Hey Tom. This question would be best for the support-list. You can see details on that here: http://www.bugzilla.org/support/ -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From gerv at mozilla.org Tue Jun 27 15:13:22 2006 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 27 Jun 2006 16:13:22 +0100 Subject: Personas In-Reply-To: <44A135B6.4010901@peshkin.net> References: <44A135B6.4010901@peshkin.net> Message-ID: <44A14B12.9080302@mozilla.org> Joel Peshkin wrote: > The concept of personas is pretty cool. I did notice that none of our > personas are working for a company that is metric-happy. Having worked > for management that insisted on all sorts of fancy charts showing bug > distribution times and similar functions, I am quite aware that we have > room for more development in that area. No criticism, but can we try and have personas discussion on the relevant Talk pages, just to see if that works as a way of keeping it all together? I think we could alter one of the personas (probably the manager) to make the company a bit more metric-happy. Let's not multiply them without a strong reason; the ideal number of Focal personas is three or four, and we already have three. But we'd need to come up with something a bit more concrete and specific than "Company is metric-happy". Gerv From mkanat at bugzilla.org Wed Jun 28 01:33:59 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Tue, 27 Jun 2006 18:33:59 -0700 Subject: Working mod_perl installation Message-ID: <1151458440.4354.18.camel@es-lappy> This installation runs under mod_perl and works entirely, as far as I can see: http://landfill.bugzilla.org/mod_perl/ It has these patches applied, which should soon be reviewed and checked-in: https://bugzilla.mozilla.org/show_bug.cgi?id=173629 https://bugzilla.mozilla.org/show_bug.cgi?id=342114 https://bugzilla.mozilla.org/show_bug.cgi?id=342121 https://bugzilla.mozilla.org/show_bug.cgi?id=342736 https://bugzilla.mozilla.org/show_bug.cgi?id=342744 https://bugzilla.mozilla.org/show_bug.cgi?id=342757 Feel free to mess around with it and test. :-) -Max -- http://www.everythingsolved.com/ Everything Solved: Competent, Friendly Bugzilla and Linux Services From justdave at bugzilla.org Wed Jun 28 02:56:10 2006 From: justdave at bugzilla.org (David Miller) Date: Tue, 27 Jun 2006 19:56:10 -0700 Subject: Componant list on enter_bug.cgi In-Reply-To: <193f01c67933$d08507b0$4b00000a@opus2> References: <193f01c67933$d08507b0$4b00000a@opus2> Message-ID: <44A1EFCA.1000405@bugzilla.org> Dave Williss wrote on 5/16/06 2:58 PM: > On enter_bug.cgi, why are the Component list and Version list a > scrolled list 5 high instead of being a combo box? Because there's no combo box available in the standard HTML Forms feature set? If other sites have them it's probably a javascript hack. We've tended to avoid javascript in the past if it would break people using it without javascript. There's probably a creative way to pull it off though. > We have control over what show up in the OS, Severity, Platform and > Priority lists. Why not Status and Resolution? Because there is too much of those still hard-coded on the back end, and allowing them to be edited in the UI would risk breaking things. There's work being done to clean up that back end code, and eventually they'll be editable in the UI, but they weren't safe yet at the time 2.22 shipped. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From timeless at gmail.com Wed Jun 28 12:33:22 2006 From: timeless at gmail.com (timeless) Date: Wed, 28 Jun 2006 15:33:22 +0300 Subject: Componant list on enter_bug.cgi In-Reply-To: <44A1EFCA.1000405@bugzilla.org> References: <193f01c67933$d08507b0$4b00000a@opus2> <44A1EFCA.1000405@bugzilla.org> Message-ID: <1a75cc570606280533q504f0e28v392468e59d064bbd@mail.gmail.com> Dave Williss wrote on 5/16/06 2:58 PM: > On enter_bug.cgi, why are the Component list and Version list a > scrolled list 5 high instead of being a combo box? On 6/28/06, David Miller wrote: > Because there's no combo box available in the standard HTML Forms > feature set? If other sites have them it's probably a javascript hack. Actually, Dave Williss was rightfully flamed for the wrong word. But he meant dropdown single select. Which is used in a number of places in the UI. One very important thing to remember though, is that the drop down widgets are really very very painful to use for sizable lists. Especially since you get terrible hinting about what might be in the list. Your average user can figure out from: OS: [ Windows XP |v] That there are other OS's in the list and that he probably doesn't care. Note that you can't have a dropdown with *nothing* selected, whereas a select box starts that way, so you can easily force people to actually pick a component. The alternatives are: 1. Component: [ ----------------- |v] 2. Component: [ Please Pick a Component |v] Both of these are *terrible* UIs, on average the user has no idea that they actually *must* pick something and that the form can't *guess* the right value. Note: any replies to this thread are likely to be anonymized into my blog, if you don't like this, then you probably shouldn't be writing email since the email archives are publicly available anyway. (If you really want credit/blame for comments that in my blog, you may specify as such, but in general I think most people find being anonymized considerably better.) Ignoring the first problem I've diagrammed, consider that you have: Component: [ General |v] That seems reasonable, right? why should a user bother looking through the list. Compare with: .__________________. Component: | Administration |^| | Attachments ||| | bugzilla.org | | | Importing Bugs | | | Exporting Bugs | | | Moving Bugs | | |________________|v| The user can clearly see that the option they have selected isn't really the one they want because one of the other options they see seems *better*. And ideally they'll choose it. Or maybe one of the options sounds familiar and reading a few more gives them an idea that they think they can find a better option in the list. The space cost of 4 extra rows is well worth the savings in bugs filed with whatever useless defaults the fields offer. Note that Platform/OS in Bugzilla are generally correctly guessed. Severity of normal is perfectly fine, the default targetmilestone specified by the admin for the product should be a good default (and if it isn't, that's the admin's fault). And the initial state of either Unconfirmed if you are not allowed to filed confirmed bugs or New (if you are) are all perfectly reasonable defaults and can almost always be left alone. From gerv at mozilla.org Wed Jun 28 13:00:56 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 14:00:56 +0100 Subject: Working mod_perl installation In-Reply-To: <1151458440.4354.18.camel@es-lappy> References: <1151458440.4354.18.camel@es-lappy> Message-ID: <44A27D88.5040204@mozilla.org> Max Kanat-Alexander wrote: > This installation runs under mod_perl and works entirely, as far as I > can see: > > http://landfill.bugzilla.org/mod_perl/ The big thing about it is that it's faster, right? Perhaps there are caching issues, but a search for all bugs on this installation returns the first result after 26 seconds, but on the tip installation on the same box it takes 20. (Admittedly, these are very rough results with no scientific rigour whatsoever.) Is there any test we can do to prove that mod_perl is making a difference to something? Gerv From lpsolit at gmail.com Wed Jun 28 13:16:03 2006 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Wed, 28 Jun 2006 15:16:03 +0200 Subject: {Spam?} Re: Working mod_perl installation In-Reply-To: <44A27D88.5040204@mozilla.org> References: <1151458440.4354.18.camel@es-lappy> <44A27D88.5040204@mozilla.org> Message-ID: <44A28113.2090405@gmail.com> > Is there any test we can do to prove that mod_perl is making a > difference to something? mod_perl on landfill looks reeeaaally slow. There is probably something wrong either with this installation itself or with the apache conf. We have serious perf issues IMO. LpSolit From Nick.Barnes at pobox.com Wed Jun 28 13:50:22 2006 From: Nick.Barnes at pobox.com (Nick Barnes) Date: Wed, 28 Jun 2006 14:50:22 +0100 Subject: Working mod_perl installation In-Reply-To: <44A27D88.5040204@mozilla.org> from Gervase Markham of "Wed, 28 Jun 2006 14:00:56 +0100" Message-ID: <47539.1151502622@thrush.ravenbrook.com> At 2006-06-28 13:00:56+0000, Gervase Markham writes: > Max Kanat-Alexander wrote: > > This installation runs under mod_perl and works entirely, as far as I > > can see: > > > > http://landfill.bugzilla.org/mod_perl/ > > The big thing about it is that it's faster, right? As I understand it, mod_perl is more about throughput than speed: it should be able to handle a million requests in less overall CPU time, but any individual request might not see much of an elapsed-time speedup. Nick B From dwilliss at microimages.com Wed Jun 28 15:41:33 2006 From: dwilliss at microimages.com (Dave Williss) Date: Wed, 28 Jun 2006 10:41:33 -0500 Subject: Componant list on enter_bug.cgi References: <193f01c67933$d08507b0$4b00000a@opus2> <44A1EFCA.1000405@bugzilla.org> <1a75cc570606280533q504f0e28v392468e59d064bbd@mail.gmail.com> Message-ID: <44e001c69ac9$5d47ac00$4b00000a@opus2> ----- Original Message ----- From: "timeless" To: Sent: Wednesday, June 28, 2006 7:33 AM Subject: Re: Componant list on enter_bug.cgi > Dave Williss wrote on 5/16/06 2:58 PM: >> On enter_bug.cgi, why are the Component list and Version list a >> scrolled list 5 high instead of being a combo box? > > On 6/28/06, David Miller wrote: >> Because there's no combo box available in the standard HTML Forms >> feature set? If other sites have them it's probably a javascript hack. > > Actually, Dave Williss was rightfully flamed for the wrong word. But > he meant dropdown single select. Which is used in a number of places > in the UI. "rightfully" flamed? I wouldn't even consider it a flame. We alway refer to those things as a "combo box" here, although I guess technically it's only a combo box if you can also edit text. So, OK, I meant drop down list. > One very important thing to remember though, is that the drop down > widgets are really very very painful to use for sizable lists. > Especially since you get terrible hinting about what might be in the > list. But a dropdown list takes up less room on the page, making the overall interface cleaner looking. [ snip ] > > Note that you can't have a dropdown with *nothing* selected, whereas a > select box starts that way, so you can easily force people to actually > pick a component. > > The alternatives are: > > 1. Component: [ ----------------- |v] > > 2. Component: [ Please Pick a Component |v] > > Both of these are *terrible* UIs, on average the user has no idea that > they actually *must* pick something and that the form can't *guess* > the right value. With the long scrolled list, there's nothing to indicate that you must pick something there either. In either case, you have to have some kind of Javascript validation of the form to make sure something was selected. The "Please Pick a Component" seems pretty clear to me that I should pick a component. If you want to make it more obvious, remove the word "please" :-) From gerv at mozilla.org Wed Jun 28 17:59:12 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 18:59:12 +0100 Subject: Componant list on enter_bug.cgi In-Reply-To: <1a75cc570606280533q504f0e28v392468e59d064bbd@mail.gmail.com> References: <193f01c67933$d08507b0$4b00000a@opus2> <44A1EFCA.1000405@bugzilla.org> <1a75cc570606280533q504f0e28v392468e59d064bbd@mail.gmail.com> Message-ID: <44A2C370.9020807@mozilla.org> timeless wrote: > One very important thing to remember though, is that the drop down > widgets are really very very painful to use for sizable lists. This is very true. However, the current arrangement doesn't make it obvious from the widget that you have to choose a component. Yes, I know there is text. I suspect we have the best of a bad set of answers here already. Gerv > The alternatives are: > > 1. Component: [ ----------------- |v] > > 2. Component: [ Please Pick a Component |v] > > Both of these are *terrible* UIs, on average the user has no idea that > they actually *must* pick something and that the form can't *guess* > the right value. I suppose you could disable the Submit button until they did... > Note: any replies to this thread are likely to be anonymized into my > blog, if you don't like this, then you probably shouldn't be writing > email since the email archives are publicly available anyway. (If you > really want credit/blame for comments that in my blog, you may specify > as such, but in general I think most people find being anonymized > considerably better.) I haven't quite got the hang of your blog yet. You are, of course, welcome to post there, but surely if we are having a discussion it's best to have it all in the one place, rather than half on the mailing list and half in your blog comments? Gerv From gerv at mozilla.org Wed Jun 28 18:27:12 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 19:27:12 +0100 Subject: UI module owner In-Reply-To: References: Message-ID: <44A2CA00.6030708@mozilla.org> Benton, Kevin wrote: > From a technical perspective, I agree. From a usability perspective, I > disagree completely. When a page is overly full, it becomes unusable. > If that weren't the case, then we would need sites like Google. As a usability point, I don't think that's always true. For example, a 50-question survey on a single page is arguably more usable than 10 5-question pages, because the user isn't distracted with paging all the time. The question is: if you think that Bugzilla's default view of a bug is "overly full", is hiding 80% of the fields at any one time the correct solution? > I want the "most critical information" > available in that first screen. Users that want more than the most > critical information, can scroll down or select tabs depending on the > application. I agree, to an extent. Currently, they scroll down. You are proposing a switch to tabs. I suggest that the latter requires much more work to get a picture of the entire bug's state than the former. > I think what Byron is getting at is there are times when it's > appropriate for us to give the user more of a dashboard look at what > they user is interested in. For example (here at AMD), when the user > first hits Bugzilla, they're typically interested in the results of the > "my bugs" query, along with some kind of information describing new bugs > to that user, and some overall product statistics. I agree there are sometimes uses for that type of view; but that fact doesn't have much relationship to the question of what the default view of a bug should be. > While I'm not a big fan of RT, I think they've done a good job of > helping the user see a clear division between the "most commonly used > fields" and others. Do you have a screenshot of RT? > I'm on the fence about this one for the moment. Tabs would be "less > pretty" but they would work for WAP and browsers that don't support CSS > block:hide; Er, what about display: none? That hides blocks fine. > On the other hand, I believe the majority of users would > rather see the collapsible fields than tabs. I'm also thinking that > giving the user the ability to re-order fields would be helpful for > those that can. Why do you think this ability is necessary in addition to the other abilities? Do your other proposals not solve the problem? Gerv From gerv at mozilla.org Wed Jun 28 18:37:38 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 19:37:38 +0100 Subject: UI module owner In-Reply-To: References: Message-ID: <44A2CC72.30700@mozilla.org> Benton, Kevin wrote: > Thinking like a new user for a moment, I may not know enough to use the > Advanced Search page properly, but I want to know what I need to address > right now. Without having to know too much about Bugzilla, what I need > to address are new and stale bugs. This page doesn't help me find that > information. Let's accept that, for the sake of argument. But that doesn't mean the solution is a new query page. An alternative example solution would be: "It looks like there are some queries almost all newbies want to do which are hard to set up. Let's create some default saved searches with sensible names that everyone gets - e.g. My Unseen Bugs and My Stale Bugs". Let's nail down problems rather than argue for particular solutions. > See my example above - in order to find bugs that are "new to me", the > user can't get that currently from the "Find a Specific Bug" page. We > also don't give the user a way to limit the specific bug searches to > bugs that the user is assigned to, is the QA contact on, is a CC on, or > is a commenter on. But if we added all these features to the simple search page, it would be half way to being the complicated search page! There's also no way to limit it to particular components, dates (as Timeless wanted), priorities or versions - shall we add all those too? > Not at all, but it seems fair that we should consider what the general > user needs in order to accomplish day-to-day tasks without needing to go > through a steep learning curve. My assertion is that users' needs are sufficiently diverse that there is no 50% subset of the complicated search page which would meet 95% of their needs. Of course, we'd need to do some research to determine whether that was true. >> We do distribute it, and have for years. It's create-guided.html.tmpl. > > How does a new user get to that page? If they don't have canconfirm, they get directed to it by default. > How does an experienced user get > to the non-guided page? If they have canconfirm, they are directed to it by default. (At least I think those are the rules. Also, both sorts are linked from the front page.) > My company felt that it was worth their while to hire more than one > person to manage and develop Bugzilla for use within AMD. Whether or > not it cost AMD to get Bugzilla initially, it certainly does cost to > maintain. Proprietary or not, one clear goal of mine is to contribute > Bugzilla code where it makes sense to do so. If I don't do that, I'm > wasting my time and AMD's money. > > Is Bugzilla proprietary? IMHO - only slightly. Is Bugzilla free? Free > to download - yes. Free to get working and use - no, just like all the > rest of the open source software. Someone has to have the expertise to > get it working and keep it working. Right... what's your point? That it _should_ be free-as-in-maintenance? Gerv From gerv at mozilla.org Wed Jun 28 18:39:05 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 19:39:05 +0100 Subject: UI module owner In-Reply-To: References: Message-ID: <44A2CCC9.7030202@mozilla.org> Benton, Kevin wrote: > In Vincent Flanders's book "Son Of Web Pages That Suck - Learning Good > Design by Looking at Bad Design", he calls this "Mystery Meat > Navigation." It's not intuitive and hides capabilities from users. Yeah, OK, OK. I've filed a bug on fixing it :-) https://bugzilla.mozilla.org/show_bug.cgi?id=342740 > In the US, we have a saying - "a picture is worth a thousand words." > What I'd like to see in a lot of our help is just what timeless is > talking about - examples with visual reference - screen shots or > reproductions. Dave may be right - we should split the user manual out of the Bugzilla Guide, and focus on it for a while. Bugzilla is too complicated not to need a manual, even if we work hard to make as many features as intuitive as possible. Gerv From gerv at mozilla.org Wed Jun 28 18:42:53 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 19:42:53 +0100 Subject: UI module owner In-Reply-To: References: Message-ID: <44A2CDAD.3080704@mozilla.org> Benton, Kevin wrote: > The later - I think we've failed to capture this in the existing persona > set. I may be a typical admin/developer that did not install Bugzilla > initially for some AMD users, however, I continue to maintain it. I > maintain a number of installations that I am still merging code on, and > I also use Bugzilla outside AMD (BMO, for example). If we think that using or maintaining multiple Bugzillas is a common thing, I'll try and add a flavour of that to the personas. > I think that linking to a foreign Bugzilla installation is a reasonable > requirement. I have a Bugzilla product on one of my installations here > that is used to track Bugzilla in general as well as customizations > related to Bugzilla here inside AMD. It's helpful to be able to resolve > my local bug 12345 is a duplicate of BMO bug 4214657. That's not > currently possible using distributed code. This does, I think, raise security issues. Off the top of my head - what's to prevent someone DOSing the project by sending bogus duplicate requests in from the outside? > That's true because Firefox also belongs to Mozilla. The problem with > my situation is that I may have intellectual property (IP) that I can't > release to MF in my bug, so I have to create a duplicate on BMO then > link my local bug to it. Right. So (an observation) timeless's bug migration suggestion is not the right answer in this case. Gerv From gerv at mozilla.org Wed Jun 28 18:46:40 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 19:46:40 +0100 Subject: UI module owner In-Reply-To: <44A0A143.4020802@bugzilla.org> References: <44A0A143.4020802@bugzilla.org> Message-ID: <44A2CE90.6030901@mozilla.org> David Miller wrote: > When I'm the on-call sysadmin at Mozilla, and someone files a bug in the > Server Ops component with a critical or blocker severity, our monitoring > system will notice the bug and page me with the bug number and summary. > If I'm not in front of a computer at the time, it'd be *really* useful > to be able to check and find out what the bug is about (sometimes people > write pretty useless summaries) to see if it really needed to be > critical or not before I drop whatever I'm involved in and travel > somewhere to find a computer. OK. But one way we could meet this need is by doing "format=micro", which invoked a new, minimalist template. If we want the same markup to be usable on both standard PCs and Dave's Blackberry, we need to come up with a compelling reason why it has to be that way rather than having two different pages (aside from "Because it proves the Jedi power of CSS!"). The BBC website has "lo" and "hi" versions of all the content, for example. Gerv From gerv at mozilla.org Wed Jun 28 18:49:58 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 19:49:58 +0100 Subject: UI module owner In-Reply-To: References: Message-ID: <44A2CF56.2050706@mozilla.org> Benton, Kevin wrote: > Obviously, however, without empirical data, I believe that there enough > forks out there to at least consider what impact it will have. I > believe it should be our goal to find out why others have forked and > find out if there are things we should be doing that make sense to > implement so those entities that have forked can re-join us in the main > code line. I completely agree with that. The things other people have been forced to change is good evidence for usage patterns, and what we should make easier. > I'm not looking at the original, but I can certainly say that there are > times when a requirement is just that - a requirement. If a product > doesn't meet certain requirements, the product is unusable for the > potential customer's (user's) purpose. Does that mean it can't be > adapted? Generally, no. Sometimes, however, the cost of adapting is > too great, thus making the product unusable to the customer. True - but at least, with Bugzilla, you have the right and ability to adapt. >> All in all, not a good start as a basis for arguing for a particular >> change. > > It's not? It seems to have gotten a good discussion going. :) I meant that particular paragraph that I was taking apart :-) >> Are you suggesting that we should fully integrate Mozilla-specific >> customisations into the stock Bugzilla, so they serve as better >> examples? (That might be a reasonable thing to suggest.) If not, what >> are you suggesting we change about the current method of bundling? > > Why not? It seems to me that the guided template method would appeal to > most admins and new users. But the "guidance" is very specific to the Mozilla project. Wouldn't they'd be better off writing a new template using that one for inspiration? Remember, the mechanism and the existence of the template are in the docs. It's not like it's hidden away in a "samples" directory somewhere. Gerv From timeless at gmail.com Wed Jun 28 19:14:16 2006 From: timeless at gmail.com (timeless) Date: Wed, 28 Jun 2006 22:14:16 +0300 Subject: Componant list on enter_bug.cgi In-Reply-To: <44A2C370.9020807@mozilla.org> References: <193f01c67933$d08507b0$4b00000a@opus2> <44A1EFCA.1000405@bugzilla.org> <1a75cc570606280533q504f0e28v392468e59d064bbd@mail.gmail.com> <44A2C370.9020807@mozilla.org> Message-ID: <1a75cc570606281214n7e79eb52yc32e5af9a26a3ce8@mail.gmail.com> Gerv wrote: > I suspect we have the best of a bad set of answers here already. finally something with which I agree :). > I suppose you could disable the Submit button until they did... FWIW, I'm really not a fan of trying to use JavaScript or disabling buttons or similar magic. consider which is slightly sanitized from a real Bugzilla installation. The names have been changed to protect everyone involved. Just load the page and click "commit". For kicks, try to make it happy, see how much work it takes. Don't worry, there's no Bugzilla or even cgi support attached to viper, it's just showing you html files that a web browser once saw. On 6/28/06, Gervase Markham wrote: > but surely if we are having a discussion it's > best to have it all in the one place, rather than half on the mailing > list and half in your blog comments? Certainly not. who wants to read through millions of mailinglists or hundreds of messages and not get any conclusions? email lists like this one don't reach conclusions, at best they peter out. at some point more of my articles will actually appear to the public, there are too many typos and things i want to improve before i actually "publish" them. From gerv at mozilla.org Wed Jun 28 19:08:57 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 20:08:57 +0100 Subject: UI module owner In-Reply-To: <1a75cc570606270316q7803f58l90e087247e6edd00@mail.gmail.com> References: <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A0149D.9050706@mozilla.org> <1a75cc570606270316q7803f58l90e087247e6edd00@mail.gmail.com> Message-ID: <44A2D3C9.2010604@mozilla.org> timeless wrote: > That was intentional. If I showed you the critique, you'd have adapted > personas and claimed that it didn't fail as badly as it did. You can > find the entry, but I expect that you will honor my request and *not* > add things listed in it. Because the act of reading it and adding the > items listed constitutes cheating. I proposed a 2 week moratorium > before I published it for you to view so that people could see how > spectacularly your proposal *failed* to capture the world it purported > to describe. I'm speechless. Is this the way you "cooperate" with your colleagues on a software project? Gerv From gerv at mozilla.org Wed Jun 28 19:04:40 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 20:04:40 +0100 Subject: UI module owner In-Reply-To: <44A12E66.8070302@dberlin.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A12E66.8070302@dberlin.org> Message-ID: <44A2D2C8.10907@mozilla.org> Daniel Berlin wrote: > In fact, I know of an large bugzilla user (supporting about 40 products, > with >100k bugs total) that just completely gave up on Bugzilla very > very recently because they got tired of trying to support their own > changes in the face of the code changes Bugzilla is currently going > through. Most of their changes consisted of what I have done for GCC: > adding a few fields, removing a few fields, and the validation > associated with this. Adding and removing fields from bugs has always been hard. That's just the way it is. It's a weakness of Bugzilla - fair enough. > Other than that, they wanted to do nice ajax'y things, but the workflow > and code of bugzilla just doesn't give you the necessary hooks to do > this without hacking up every source file in sight. We have a hooks mechanism exactly for this - did they ask for any? Or put in their own, for that matter? > Given all this, they just decided to put a couple engineers on the task > of making a nice sane bug tracker, and surprisingly, in about 2 man > years, they have *done just that*. 2 man years? They couldn't have fixed their problems by putting those people to work full time on Bugzilla for less than that long? >> Which changes did you most commonly have to make? > > Let's see: > > Exposing any new variable to the bugs templates requires changing the code. How would you have it work otherwise? I agree with timeless that there are a couple (user, bug) which should always be there. > Hiding a field that Bugzilla believes is required but is useless to your > installation requires hacking up the edit script and the templates. Actually, it only requires hacking the templates. But we should probably fix that. > Adding any sort of validation routines for some of the more freeform > fields requires hacking up post_bug.cgi, the templates, the error list, > the xml importer, etc. Well, any scheme would require hacking in at least two places, because you'd need a Perl version and a JavaScript version. Are you talking about freeform fields still used for their originally defined purpose, or ones you have repurposed? > The problem isn't even that I have to write code, it's that i have to > hack up the standard source files to do it, and I should not have to, > because then i have to maintain these hacks as the source files change > and move. Have you discovered the template hooks mechanism? You can insert code into any place in any template with a single added line. > As a side note, I've actually always been surprised that bugzilla has no > transaction objects, considering that things either look really ugly, or > are just broke, if the database is left half-modified. IE bugs with no > initial comment, etc. Why the process of modifying a bug in some > manner, from beginning to end, for a single request that may change the > bug, the duplicates list, and the comments, is not encapsulated in some > transaction object is beyond me. I believe that getting rid of our old SQL stuff (just done this week, I believe) is a prerequisite for this sort of thing. I think also MySQL didn't support transactions until recently. But I could be wrong. > But back to the topic at hand: half the time in changing this stuff > between versions is figuring out where the code moved, then just > rewriting it to whatever the new style of the day is for that code. It > doesn't really do anything different, it just seems to have changed > coding style because someone felt it looked cleaner (again I'm *not* > talking about the obviously necessary changes for mod_perl'ification, > like removing globals, etc). Can you give a concrete example? >> If so, I'd be interested to know why bug entry templates, the format >> system, the skin system, the custom templates system and the hooks >> system are all not useful? Did we solve all the wrong problems? > > Mostly, yes. > The only templates people I know change are maybe the front template, > and whatever is required to hide or move around some field. So most of your customisations are Perl customisations? Gerv From gerv at mozilla.org Wed Jun 28 19:07:26 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 20:07:26 +0100 Subject: UI module owner In-Reply-To: <44A0AC8E.9000700@bugzilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <44A0AC8E.9000700@bugzilla.org> Message-ID: <44A2D36E.6040208@mozilla.org> David Miller wrote: > Mozilla even forks Bugzilla from the upstream version now. See > https://bugzilla.mozilla.org/CUSTOMIZATIONS/ Y'see, we've done a bunch of those the wrong way... 10-createaccount-privacy-notice.diff should have used a hook. 03-mozilla-subsite-skin.diff shouldn't this be a separate skin in skins/custom? Gerv From gerv at mozilla.org Wed Jun 28 18:56:13 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 19:56:13 +0100 Subject: UI module owner In-Reply-To: <44A0FB93.10407@joostdevalk.nl> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A0FB93.10407@joostdevalk.nl> Message-ID: <44A2D0CD.1040708@mozilla.org> Joost de Valk wrote: > I must agree with Daniel here, my experience is that some stuff simply > isn't there to play with. One of the simple customizations i'm thinking > of here is the fact that you have to expose the bug variable to the > template in attachment.cgi, to do ANYTHING based on which product you're > adding an attachment for. > > Simple stuff like that requires you to fiddle with the code, so i think > a lot of useful and quite simple customizations would require you to > change code. OK... you say that is "simple stuff", but in fact, it's incredibly niche. Let's break the sentence down: You have to expose the FOO variable to the template in BAR.cgi, to do ANYTHING based on which WIDGET you're VERBing a FRED for. That sentence could just have easily have been: "You have to expose the user variable to the template in showdependencygraph.cgi to do ANYTHING based on which user you're showing the dependencies to. Simple stuff like that requires you to fiddle with the code..." My point is that there could be thousands and thousands of these "simple" requirements, each entirely dependent on the particular situation and need of the company in question. Is it really feasible to meet any significant proportion of requests like this? I'm not sure that we're capable of reaching a place where the majority of requests like your "Simple stuff" above will be doable without having to change the code. Perhaps I'm being pessimistic. But if there are 1000 companies, there seem to be 1001 ways of bug tracking. Take CheckCanChangeField() for an example. We didn't try and produce a web-based interface to determining who can change what field when, we just documented the function. And the number of different things people have wanted to do in there over the years is incredible - read the newsgroup back for a bit. Gerv From timeless at gmail.com Wed Jun 28 19:49:30 2006 From: timeless at gmail.com (timeless) Date: Wed, 28 Jun 2006 22:49:30 +0300 Subject: UI module owner In-Reply-To: <44A2D3C9.2010604@mozilla.org> References: <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A0149D.9050706@mozilla.org> <1a75cc570606270316q7803f58l90e087247e6edd00@mail.gmail.com> <44A2D3C9.2010604@mozilla.org> Message-ID: <1a75cc570606281249x18176051hbdc6558f854e03b6@mail.gmail.com> On 6/28/06, Gervase Markham wrote: > I'm speechless. Is this the way you "cooperate" with your colleagues on > a software project? You've proposed a development model that I don't think works. I've pointed out to others why I don't think it works by listing a number of things that you almost certainly won't get because of the model you're using. i don't have time to hunt for hundreds of wikis and thousands of talk pages and i certainly don't have time to fit my 20 or so people into your 4 personas. you claim that there should be only 4 personas. but that really doesn't fit the real world. and i don't want to waste my breath telling you that because i know just how utterly pointless that is. the best i can do is write a prediction, share it so that people accept that i wrote it, and *wait* for you to fail as you deserve to do. sometimes ideas just have to fail. From gerv at mozilla.org Wed Jun 28 20:10:12 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 21:10:12 +0100 Subject: UI module owner In-Reply-To: <1a75cc570606281249x18176051hbdc6558f854e03b6@mail.gmail.com> References: <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A0149D.9050706@mozilla.org> <1a75cc570606270316q7803f58l90e087247e6edd00@mail.gmail.com> <44A2D3C9.2010604@mozilla.org> <1a75cc570606281249x18176051hbdc6558f854e03b6@mail.gmail.com> Message-ID: <44A2E224.5030405@mozilla.org> timeless wrote: > You've proposed a development model that I don't think works. I've > pointed out to others why I don't think it works by listing a number > of things that you almost certainly won't get because of the model > you're using. Except that you've hidden the list away and forbidden me to look for it. > i don't have time to hunt for hundreds of wikis and > thousands of talk pages and i certainly don't have time to fit my 20 > or so people into your 4 personas. Received wisdom with personas is that if you have more than four focal ones, then your product will be over-broadly targetted. I presume you disagree? If you have 20, how do you sensibly mediate between e.g. the competing claims of 1 and 17 against 6 and 11? Gerv From justdave at bugzilla.org Wed Jun 28 20:12:02 2006 From: justdave at bugzilla.org (David Miller) Date: Wed, 28 Jun 2006 13:12:02 -0700 Subject: UI module owner In-Reply-To: <44A2D36E.6040208@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <44A0AC8E.9000700@bugzilla.org> <44A2D36E.6040208@mozilla.org> Message-ID: <44A2E292.3000904@bugzilla.org> Gervase Markham wrote on 6/28/06 12:07 PM: > David Miller wrote: >> Mozilla even forks Bugzilla from the upstream version now. See >> https://bugzilla.mozilla.org/CUSTOMIZATIONS/ > > Y'see, we've done a bunch of those the wrong way... > > 10-createaccount-privacy-notice.diff > should have used a hook. Is there one for that page? If not, maybe we want one. We should probably provide a link to a privacy policy on the createaccount page by default (and probably in small type in the footer somewhere). We can put a page.cgi page in with some default template for people that don't already have one. > 03-mozilla-subsite-skin.diff > shouldn't this be a separate skin in skins/custom? Yep, except that the version of Bugzilla we're running didn't support that completely enough to implement that at the time. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From zach at zachlipton.com Wed Jun 28 20:12:38 2006 From: zach at zachlipton.com (Zach Lipton) Date: Wed, 28 Jun 2006 13:12:38 -0700 Subject: Bugzilla Extensions/Hooks Mechanism (was Re: UI module owner) In-Reply-To: <44A2D2C8.10907@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A12E66.8070302@dberlin.org> <44A2D2C8.10907@mozilla.org> Message-ID: <956ECBA5-0FB5-4675-AC8D-11B491D3407A@zachlipton.com> On Jun 28, 2006, at 12:04 PM, Gervase Markham wrote: > We have a hooks mechanism exactly for this - did they ask for any? Or > put in their own, for that matter? I get the sense in this discussion that a lot of folks don't know about the extensions mechanism that we have. Bugzilla provides a way for installations to drop into hooks in both templates and code. Modifications can be packaged up as extensions, which get live in a single directory (bugzilla/extensions/extension_name). Since extensions contain code and template customizations, they may require updating to work with newer versions of Bugzilla, but they avoid the need for the patch management and conflicts that occur when making modifications directly to Bugzilla source. Extensions can be used for simple local customizations, or for more advanced needs, such as integration with testcase management, SCM tools, etc... The system is documented at http://www.bugzilla.org/docs/tip/html/ cust-hooks.html. Information about template hooks in general is available at http://www.bugzilla.org/docs/tip/html/cust-templates.html. Right now, there aren't very many code hooks in the code at all, but extension developers can easily request them and they will be added to the source. --zach From justdave at bugzilla.org Wed Jun 28 20:06:49 2006 From: justdave at bugzilla.org (David Miller) Date: Wed, 28 Jun 2006 13:06:49 -0700 Subject: UI module owner In-Reply-To: <44A2CA00.6030708@mozilla.org> References: <44A2CA00.6030708@mozilla.org> Message-ID: <44A2E159.6020004@bugzilla.org> Gervase Markham wrote on 6/28/06 11:27 AM: > Benton, Kevin wrote: >> I want the "most critical information" >> available in that first screen. Users that want more than the most >> critical information, can scroll down or select tabs depending on the >> application. > > I agree, to an extent. Currently, they scroll down. You are proposing a > switch to tabs. I suggest that the latter requires much more work to get > a picture of the entire bug's state than the former. What about the Printable Version/Long Format? That continues to have everything in one place. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From bugzilla at joostdevalk.nl Wed Jun 28 20:12:45 2006 From: bugzilla at joostdevalk.nl (Joost de Valk) Date: Wed, 28 Jun 2006 22:12:45 +0200 Subject: UI module owner In-Reply-To: <44A2D0CD.1040708@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A0FB93.10407@joostdevalk.nl> <44A2D0CD.1040708@mozilla.org> Message-ID: <287C0E59-1B99-434D-BF96-75B521D64050@joostdevalk.nl> I'm astonished, compare this: > Exposing any new variable to the bugs templates requires changing > the code. > How would you have it work otherwise? I agree with timeless that there are a couple (user, bug) which should always be there. with your answer here: On Jun 28, 2006, at 8:56 PM, Gervase Markham wrote: > Joost de Valk wrote: >> I must agree with Daniel here, my experience is that some stuff >> simply >> isn't there to play with. One of the simple customizations i'm >> thinking >> of here is the fact that you have to expose the bug variable to the >> template in attachment.cgi, to do ANYTHING based on which product >> you're >> adding an attachment for. >> >> Simple stuff like that requires you to fiddle with the code, so i >> think >> a lot of useful and quite simple customizations would require you to >> change code. > > OK... you say that is "simple stuff", but in fact, it's incredibly > niche. Let's break the sentence down: > > You have to expose the FOO variable to the template in BAR.cgi, to do > ANYTHING based on which WIDGET you're VERBing a FRED for. > > That sentence could just have easily have been: > > "You have to expose the user variable to the template in > showdependencygraph.cgi to do ANYTHING based on which user you're > showing the dependencies to. Simple stuff like that requires you to > fiddle with the code..." > > My point is that there could be thousands and thousands of these > "simple" requirements, each entirely dependent on the particular > situation and need of the company in question. Is it really > feasible to > meet any significant proportion of requests like this? > > I'm not sure that we're capable of reaching a place where the majority > of requests like your "Simple stuff" above will be doable without > having > to change the code. Perhaps I'm being pessimistic. But if there are > 1000 > companies, there seem to be 1001 ways of bug tracking. i'm not asking you to expose them all and never did, i didn't write the sentence you thought i did. IF user and bug are always available, that would probably make 80% of the stuff easier. if you think that there is no way we can improve bugzilla for all, or at least a big part of our community, why the heck are you even coding on it? Joost de Valk: | www.joostdevalk.nl contact | joost at joostdevalk.nl | 06 - 24 555 808 Never be afraid to try something new. Remember, amateurs built the ark, and professionals built the Titanic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Wed Jun 28 22:10:16 2006 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 28 Jun 2006 23:10:16 +0100 Subject: UI module owner In-Reply-To: <287C0E59-1B99-434D-BF96-75B521D64050@joostdevalk.nl> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A0FB93.10407@joostdevalk.nl> <44A2D0CD.1040708@mozilla.org> <287C0E59-1B99-434D-BF96-75B521D64050@joostdevalk.nl> Message-ID: <44A2FE48.3050901@mozilla.org> Joost de Valk wrote: > i'm not asking you to expose them all and never did, i didn't write the > sentence you thought i did. IF user and bug are always available, that > would probably make 80% of the stuff easier. OK, then let's do that :-) > if you think that there is > no way we can improve bugzilla for all, or at least a big part of our > community, why the heck are you even coding on it? I don't think there's no way it can be improved. I just think that it's unrealistic to expect that we can make Bugzilla flexible enough that most people won't have to change any code at all, because requirements are so different. And hey, opinions can change. That's the purpose of discussion. Don't sound so surprised that you persuaded me of something :-) Gerv From justdave at bugzilla.org Wed Jun 28 22:11:37 2006 From: justdave at bugzilla.org (David Miller) Date: Wed, 28 Jun 2006 15:11:37 -0700 Subject: UI module owner In-Reply-To: <44A2E224.5030405@mozilla.org> References: <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A0149D.9050706@mozilla.org> <1a75cc570606270316q7803f58l90e087247e6edd00@mail.gmail.com> <44A2D3C9.2010604@mozilla.org> <1a75cc570606281249x18176051hbdc6558f854e03b6@mail.gmail.com> <44A2E224.5030405@mozilla.org> Message-ID: <44A2FE99.2010603@bugzilla.org> Gervase Markham wrote on 6/28/06 1:10 PM: > timeless wrote: >> i don't have time to hunt for hundreds of wikis and >> thousands of talk pages and i certainly don't have time to fit my 20 >> or so people into your 4 personas. > > Received wisdom with personas is that if you have more than four focal > ones, then your product will be over-broadly targetted. I presume you > disagree? We do have more than 4 types of people using Bugzilla, just within a single organization. And we have two major types of organizations that we target, which have distinct usage patterns. (corporate environment vs public projects) -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From mdanjou at neterion.com Wed Jun 28 18:58:44 2006 From: mdanjou at neterion.com (Martin d'Anjou) Date: Wed, 28 Jun 2006 14:58:44 -0400 (EDT) Subject: UI module owner In-Reply-To: <44A2CC72.30700@mozilla.org> References: <44A2CC72.30700@mozilla.org> Message-ID: > My assertion is that users' needs are sufficiently diverse that there is > no 50% subset of the complicated search page which would meet 95% of > their needs. Of course, we'd need to do some research to determine > whether that was true. Can you do just that? Ask the users and see what they say? If you ask me to ask my users, I will collect the feedback and send it to this mailing list if it can help you. Just give me a week to collect feedback. Martin From bbaetz at acm.org Wed Jun 28 22:18:23 2006 From: bbaetz at acm.org (Bradley Baetz) Date: Thu, 29 Jun 2006 08:18:23 +1000 Subject: Working mod_perl installation In-Reply-To: <47539.1151502622@thrush.ravenbrook.com> References: <44A27D88.5040204@mozilla.org> <47539.1151502622@thrush.ravenbrook.com> Message-ID: <99435f5b0606281518r6f36775i3916466a9c1f3169@mail.gmail.com> On 28/06/06, Nick Barnes wrote: > As I understand it, mod_perl is more about throughput than speed: it > should be able to handle a million requests in less overall CPU time, > but any individual request might not see much of an elapsed-time > speedup. The speedup for buglist.cgi will be minimal - its mostly DB and parsing. The speedup is more for show_bug and similar. I posted some speedups for a working show_bug.cgi under mod_perl a couple of years ago - see the list archives for details. Bradley From kevin.benton at amd.com Thu Jun 29 05:52:29 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 28 Jun 2006 22:52:29 -0700 Subject: Personas Message-ID: > Joel Peshkin wrote: > > The concept of personas is pretty cool. I did notice that none of our > > personas are working for a company that is metric-happy. Having worked > > for management that insisted on all sorts of fancy charts showing bug > > distribution times and similar functions, I am quite aware that we have > > room for more development in that area. > > No criticism, but can we try and have personas discussion on the > relevant Talk pages, just to see if that works as a way of keeping it > all together? > > I think we could alter one of the personas (probably the manager) to > make the company a bit more metric-happy. Let's not multiply them > without a strong reason; the ideal number of Focal personas is three or > four, and we already have three. > > But we'd need to come up with something a bit more concrete and specific > than "Company is metric-happy". Ok - here's a specific we don't track yet - A manager wants historical data on estimated time to completion by project stage versus actual. Right now, our time tracking tables don't track estimate ranges using the "cone of uncertainty" (estimate +/- uncertainty factors for similar projects). It would be helpful if we could do the following: At each project stage, (pre-planning, planning, requirements gathering, architecture specification, design stage, construction, testing, ...), what were the estimated and actual values for amount of work to be done, time to project complete, and cost to complete? By tracking these values, we can export data to the project estimation software to get better estimates. I'll file a bug requesting these things tomorrow from the office. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Thu Jun 29 06:08:31 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 28 Jun 2006 23:08:31 -0700 Subject: UI module owner Message-ID: > >> I want the "most critical information" > >> available in that first screen. Users that want more than the most > >> critical information, can scroll down or select tabs depending on the > >> application. > > > > I agree, to an extent. Currently, they scroll down. You are proposing a > > switch to tabs. I suggest that the latter requires much more work to get > > a picture of the entire bug's state than the former. > > What about the Printable Version/Long Format? That continues to have > everything in one place. I agree that everything is in one place, but the place is too big. Currently, we separate out the activity log (with good reason) to prevent "clutter." My goal is to be able to give my users a very concise view of a bug within the first screen-ful in about an 800x600 size frame. Doing that at normal font size would require changes over what we have now. I'm referring to the single bug view. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Thu Jun 29 06:27:25 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Wed, 28 Jun 2006 23:27:25 -0700 Subject: UI module owner Message-ID: > timeless wrote: > > i don't have time to hunt for hundreds of wikis and > > thousands of talk pages and i certainly don't have time to fit my 20 > > or so people into your 4 personas. > > Received wisdom with personas is that if you have more than four focal > ones, then your product will be over-broadly targetted. I presume you > disagree? Right or wrong, timeless, I think that the persona models do add value to the requirements gathering process along with the rest of the development process. It helps us to consider the needs of a specific class of users (real or imagined) that are likely to use our product. It is certainly better than what we have now and until we have a better method, I see no reason not to use them. In fact, I think it's a great method to use in other software development projects. It's not a good end-all, but it does help developers consider use cases more thoroughly. Does adding sixteen additional personas add more to accuracy or precision? I don't want to waste time checking functionality against personas that don't add much in value. I do want a good list of corner cases, but I want the majority of what I'm trying to accomplish represented reasonably simply. If we say that pi is about 3, that's not very precise, but it's closer to accurate than saying pi is 6.135146248, which, while much more precise, is very inaccurate. I heard Steve Tockey say today, in a Construx Software Estimation class something to this effect (paraphrase): "An estimate doesn't need to match the actual result. What it needs to accomplish is getting an answer that's 'good enough' to lead the user to making the "right decision" based on that estimate." That's why I'm wondering if what we really need is more personas or a few well-developed models then corner cases to handle the "outliers". --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From jdevalk at opendarwin.org Thu Jun 29 06:30:18 2006 From: jdevalk at opendarwin.org (Joost 'AlthA' de Valk) Date: Thu, 29 Jun 2006 08:30:18 +0200 Subject: UI module owner In-Reply-To: <44A2FE48.3050901@mozilla.org> References: <449C2A87.9090509@mozilla.org> <449C3B46.7080504@bugzilla.org> <449C40D7.8010207@mozilla.org> <1151231997.90475.69.camel@D-MELENTYEV.HOME> <449F9D99.8020501@mozilla.org> <1151316452.90475.142.camel@D-MELENTYEV.HOME> <449FB685.5070305@mozilla.org> <1a75cc570606260413y5bd6d64bj96111e673dc80e37@mail.gmail.com> <449FC8B7.5030200@mozilla.org> <1a75cc570606260754u53ceff80md9c8ee3fce754e39@mail.gmail.com> <44A006AC.4050304@dberlin.org> <44A0585A.8040802@mozilla.org> <44A0FB93.10407@joostdevalk.nl> <44A2D0CD.1040708@mozilla.org> <287C0E59-1B99-434D-BF96-75B521D64050@joostdevalk.nl> <44A2FE48.3050901@mozilla.org> Message-ID: <19AC7A3F-EA4D-4B74-8023-FF75A86E4A34@opendarwin.org> On Jun 29, 2006, at 12:10 AM, Gervase Markham wrote: > And hey, opinions can change. That's the purpose of discussion. Don't > sound so surprised that you persuaded me of something :-) > Good, then at least this discussion is going somewhere ;-) From mkanat at bugzilla.org Thu Jun 29 11:55:56 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 29 Jun 2006 04:55:56 -0700 Subject: Working mod_perl installation In-Reply-To: <44A27D88.5040204@mozilla.org> References: <1151458440.4354.18.camel@es-lappy> <44A27D88.5040204@mozilla.org> Message-ID: <1151582157.2633.8.camel@localhost.localdomain> On Wed, 2006-06-28 at 14:00 +0100, Gervase Markham wrote: > The big thing about it is that it's faster, right? > > Perhaps there are caching issues, but a search for all bugs on this > installation returns the first result after 26 seconds, but on the tip > installation on the same box it takes 20. (Admittedly, these are very > rough results with no scientific rigour whatsoever.) > > Is there any test we can do to prove that mod_perl is making a > difference to something? There are a few problems: 1) I think the current install might have a memory leak, causing it to slow down once it's been up for a while. 2) mod_perl performance improvements will only be seen on the second page load in your httpd child, with the way that things are set up now. I could also have Apache pre-compile all CGIs on startup, which I may do if it doesn't take up too much RAM. That is, mod_perl compiles a CGI once and then never has to recompile it. But of course Apache runs as 8-10 processes, so it has to actually compile it once per-process. Trust me, it's extremely faster when things are working right. The best way to see the difference, at least for me, is to switch between index.cgi and query.cgi a few times. Remember that this *is* a testing installation, so even the performance might not be perfect yet. :-) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jun 29 13:38:10 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 29 Jun 2006 06:38:10 -0700 Subject: mod_perl: Modules should always be required by module name, not by file name Message-ID: <1151588291.3778.2.camel@localhost.localdomain> Another mod_perl note for everybody: Always require/use modules by their package name, not by their file name. That is, don't do: require "Bugzilla/Config/Common.pm"; Instead do: require "Bugzilla::Config::Common"; This allows mod_perl to always grab the module out of the correct location, by searching @INC. It also means that you don't have to worry about specifying the absolute path to the module, which you'd have to always do if you wanted to require it by name. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From mkanat at bugzilla.org Thu Jun 29 13:51:40 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 29 Jun 2006 06:51:40 -0700 Subject: mod_perl: Modules should always be required by module name, In-Reply-To: <1151588291.3778.2.camel@localhost.localdomain> References: <1151588291.3778.2.camel@localhost.localdomain> Message-ID: <1151589101.3778.8.camel@localhost.localdomain> On Thu, 2006-06-29 at 06:38 -0700, Max Kanat-Alexander wrote: > Instead do: > > require "Bugzilla::Config::Common"; Correction: If you have to do something like: require "Bugzilla/$module.pm" Instead do: eval("require Bugzilla::Config::$module") || die $@; That works. The reason is that normally if you use quotes in a require, perl assumes it's a path to a file. With the "|| die $@" it works exactly like a normal require. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From Guillaume.Rousse at inria.fr Thu Jun 29 14:45:41 2006 From: Guillaume.Rousse at inria.fr (Guillaume Rousse) Date: Thu, 29 Jun 2006 16:45:41 +0200 Subject: mod_perl: Modules should always be required by module name, not In-Reply-To: <1151588291.3778.2.camel@localhost.localdomain> References: <1151588291.3778.2.camel@localhost.localdomain> Message-ID: <44A3E795.3060102@inria.fr> Max Kanat-Alexander wrote: > Another mod_perl note for everybody: > > Always require/use modules by their package name, not by their file > name. > > That is, don't do: > > require "Bugzilla/Config/Common.pm"; > > Instead do: > > require "Bugzilla::Config::Common"; Why require (evaluated at runtime), instead of use (evaluated at compile time) ? And BTW, relationship with mod_perl is tedious: this is a general perl guideline. -- Guillaume Rousse Projet Estime, INRIA Domaine de Voluceau Rocquencourt - B.P. 105 78153 Le Chesnay Cedex - France From mkanat at bugzilla.org Thu Jun 29 15:02:37 2006 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Thu, 29 Jun 2006 08:02:37 -0700 Subject: mod_perl: Modules should always be required by module name, not In-Reply-To: <44A3E795.3060102@inria.fr> References: <1151588291.3778.2.camel@localhost.localdomain> <44A3E795.3060102@inria.fr> Message-ID: <1151593357.3778.11.camel@localhost.localdomain> On Thu, 2006-06-29 at 16:45 +0200, Guillaume Rousse wrote: > Why require (evaluated at runtime), instead of use (evaluated at compile > time) ? Usually we're doing this because we need to dynamically load a module, which can't be done at compile time. That is, we're loading some module that depends on a variable. Like "Bugzilla::DB::$db_driver" for example. Most of the time doing require Bugzilla "Bugzilla/DB/$db_driver.pm" would work fine, even in mod_perl, but it's probably just better to do it the other way. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From gerv at mozilla.org Thu Jun 29 22:19:22 2006 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 29 Jun 2006 23:19:22 +0100 Subject: Hospital visit Message-ID: <44A451EA.5090801@mozilla.org> Hi chaps, I know I have lots of your really interesting comments on the UI to read through, but I have to go back into hospital for a few days (see my blog) so it may be a while before I get to them or do more work on the personas. Don't think I'm ignoring you :-) Gerv From zach at zachlipton.com Thu Jun 29 22:34:14 2006 From: zach at zachlipton.com (Zach Lipton) Date: Thu, 29 Jun 2006 15:34:14 -0700 Subject: Hospital visit In-Reply-To: <44A451EA.5090801@mozilla.org> References: <44A451EA.5090801@mozilla.org> Message-ID: Best wishes Gerv. I'll be thinking good thoughts! --zach On Jun 29, 2006, at 3:19 PM, Gervase Markham wrote: > Hi chaps, > > I know I have lots of your really interesting comments on the UI to > read > through, but I have to go back into hospital for a few days (see my > blog) so it may be a while before I get to them or do more work on the > personas. Don't think I'm ignoring you :-) > > Gerv > - > To view or change your list settings, click here: > From kevin.benton at amd.com Thu Jun 29 23:43:10 2006 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 29 Jun 2006 16:43:10 -0700 Subject: UI module owner Message-ID: > Benton, Kevin wrote: > > In Vincent Flanders's book "Son Of Web Pages That Suck - Learning Good > > Design by Looking at Bad Design", he calls this "Mystery Meat > > Navigation." It's not intuitive and hides capabilities from users. > > Yeah, OK, OK. I've filed a bug on fixing it :-) > https://bugzilla.mozilla.org/show_bug.cgi?id=342740 :) > > In the US, we have a saying - "a picture is worth a thousand words." > > What I'd like to see in a lot of our help is just what timeless is > > talking about - examples with visual reference - screen shots or > > reproductions. > > Dave may be right - we should split the user manual out of the Bugzilla > Guide, and focus on it for a while. That sounds like a good idea to me. > Bugzilla is too complicated not to need a manual, even if we work hard > to make as many features as intuitive as possible. I don't know that I would say it's "too complicated not to need a manual", but I know that users would benefit from using a manual a lot more than not having one while wanting one. --- Kevin Benton Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator AMD - ECSD Software Validation and Tools The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication.