Last modified: 2014-03-09 18:04:51 UTC
The default Bugzilla page is so unhelpful. Having to construct an advanced query to find product/component-specific bugs is annoying. Would be great if the front page could have links to pre-defined searches for a selection of popular/user-centric products/components. Like: Also, "recently filed bugs". (Would love to see the Bugzilla equivalent of "recent changes") Also, a selection of keywords, like: * tracking * accessibility * easy * bugday * need-review * i18n
FYI https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=runnamed&namedcmd=New%20bugs%20in%20last%2024%20hours https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Changed%20in%20last%2024%20hours Some saved searches do the RC/newpages type of thing :) There is also a https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Created%20This%20Week&sharer_id=9183
Might need https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Changed%20in%20last%2024%20hours&sharer_id=6045 https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=New%20bugs%20in%20last%2024%20hours&sharer_id=6045 To get them to work properly
Even better if you didn't need to be logged in to use them.
Bugmeister is the new Bugzilla maintainer and default assignee.
Reset assignee per bug 37789
Agree with this - also let's have the bug, if it must be there, saying something far more welcoming and less in-jokey.
Created attachment 11439 [details] Initial proposal (screenshot) I agree that the current frontpage isn't too helpful. To tackle this I would start with making the most important basic functions more visible (side effect: We are closer to the upstream Bugzilla interface). As a second future step, anything specific (e.g. queries for something etc) could go to the bottom of the page. This part has high bikeshedding potential, so I prefer high-level structural proposals for a potential "queries" section at the bottom instead of "I want to query for this specific thingy, please put it on the front page so I don't need to use query.cgi or saved searches anymore, the rest I really don't care". ;)
I'm 100% in favor of the basic proposal Andre made and suggest we change to that immediately.
I'd like to upgrade to Bugzilla 4.2 first (as the screenshot is from 4.2.4 and I haven't tested with 4.0.9), but after that we can review and deploy.
Created attachment 11443 [details] Quick'n'dirty codedump so it doesn't get lost. Once cleaned up it can go to Gerrit.
Created attachment 11444 [details] Quick'n'dirty codedump so it doesn't get lost, part 2 (image file)
In Gerrit now: https://gerrit.wikimedia.org/r/#/c/42089/
Created attachment 11822 [details] Layout issue for logged-out users
Big big thanks for testing! Krinkle: Which browser is that?
(In reply to comment #14) > Big big thanks for testing! Krinkle: Which browser is that? Chrome 24, Chrome 25
(In reply to comment #13) > Created attachment 11822 [details] > Layout issue for logged-out users Should be fixed in patch set 4. Change is live on http://kubo.wmflabs.org/bugzilla .
I had a vision of a page similar to www.google.com or www.wikipedia.org. That is, a search input would be the focus of the Bugzilla landing page. This would be instead of the five large icons and probably without the global sidebar (copied from Vector). The proposed redesign currently has two search inputs on the main page (one in the body area and one global search input at the top of the page). I think this is a little awkward, though it'd be more awkward to remove either (both are expected by users now). Unless... you changed the overall design of the page more dramatically (again, think of www.wikipedia.org vs. en.wikipedia.org). Plus making a simple search input with "What is your problem?" and requiring people to search before filing a new bug would be nice (to presumably reduce the number of duplicate bugs). On the other hand, Bugzilla search isn't terribly great and the redesign at <http://kubo.wmflabs.org/bugzilla/> has grown on me a little, with the exception of the really sad search icon (<https://bugzilla.wikimedia.org/skins/standard/index/search.png>).
Apart from IE6 (which has other rendering issues too), http://kubo.wmflabs.org/bugzilla/ looks good on all other "older" browsers in browserstack.com (tested with 800x600px to check the CSS when not all five items are in a row). I've created patchset #5 to fix the three issues brought up by reviewers about patchset #4.
Bugzilla has a new frontpage since today with the main tasks easier accessible. This was the first and most important step. (In reply to comment #0) > Would be great if the front page could have links to pre-defined searches > for a selection of popular/user-centric products/components. Like: > Also, "recently filed bugs". Also, a selection of keywords, like: > tracking, accessibility, easy, bugday, need-review, i18n For the rest of the proposals I'm afraid that everybody has a different opinion about what's important or not, and it might be hard to find the most interesting stuff that fits everybody without getting too crowded. This needs some thoughts (especially layout-wise); they are welcome.
Created attachment 12542 [details] Redesigned Bugzilla front page with outdated CSS (In reply to comment #19) > Bugzilla has a new frontpage since today with the main tasks easier accessible. Including a screenshot of what can happen with the new HTML and old CSS, just for reference.
(In reply to comment #20) > Including a screenshot of what can happen with the new HTML and old CSS That's probably bug 49474. Not sure if there's anything that can be done.
(In reply to comment #21) > (In reply to comment #20) > > Including a screenshot of what can happen with the new HTML and old CSS > > That's probably bug 49474. Looks different, that's defined by Liangent as intermittent. I only had to hard refresh... thanks MZ.
(In reply to comment #21) > (In reply to comment #20) >> Including a screenshot of what can happen with the new HTML and old CSS > > That's probably bug 49474. Not sure if there's anything that can be done. I think the Bugzilla template allows for directly editing the relevant <link> tag. In a situation like this, you generally can just append a string (such as the date) to the end of the href attribute. For example: <link rel="stylesheet" href="skins/contrib/Wikimedia/vector.css" media="screen" /> might become... <link rel="stylesheet" href="skins/contrib/Wikimedia/vector.css?2013-06-15" media="screen" /> In any case, it's not a big deal and there are a lot of stylesheets included in a Bugzilla page (more than I expected, frankly), so this probably isn't worth the hassle. I just found the situation curious and noteworthy. (In reply to comment #22) > Looks different, that's defined by Liangent as intermittent. I only had to > hard refresh... Truth be told, I'm still not sure how those streaks of color got in there. In my browser, they aligned under three of the links very neatly. I saw screenshots from other browsers where they were not aligned. Very strange.
Backporting the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=390955 might fix this.
(In reply to comment #24) > https://bugzilla.mozilla.org/show_bug.cgi?id=390955 That patch works on boogs.wmflabs.org so we could backport it after upgrading to 4.4 (bug 49597). We don't need the requestee_count part in index.cgi though as we use Gerrit and not Bugzilla flags. There is one design issue at the bottom due to global.css:149 which defines #footer { clear: both; Setting this to clear:right or clear:none seems to work, but not sure if that's a good idea (I miss enough knowledge of CSS to judge).
Defining common queries has bikeshed potential, but I'll give it a shot: * General ** Open tickets reported by me (456) ** All tickets reported in the last 24 hours | last 7 days ** All tickets changed in the last 24 hours | last 7 days * Actionability ** Open tickets assigned to me (123) ** Open tickets with PATCH_TO_REVIEW status ** Open tickets which need more information (not implemented yet, see bug 36064) ** Open tickets with no changes for: 6 months | 1 year | 2 years * Planning ** Target Milestone: MediaWiki: MW-1.23.x | MW-1.22.x ** Target Milestone: MediaWiki extensions: MW 1.23 version | MW 1.22 version ** Open tickets with immediate/highest priority: All | MediaWiki | MediaWiki extensions | Wikimedia ** Open tickets with high priority: All | MediaWiki | MediaWiki extensions | Wikimedia * Popularity: ** >=20 votes: All | MediaWiki | MediaWiki extensions | Wikimedia ** High number of duplicates - link to duplicates.cgi ** High number of CCs (not implemented yet)
Created attachment 14103 [details] Preliminary patch Quick'n'dirty attaching some "what to do on a lazy Sunday afternoon" work here (will put patch into Gerrit at some point after playing more with it). Can be seen on http://boogs.wmflabs.org/index.cgi (but more awesome when being logged in). Won't deploy before fixing bug 49597 (4.4 upgrade) but you can expect this to hit the production server around Jan-Feb 2014. Link underlining for RSS feed icons still ugly; seems to get fixed by changing padding-left from 16px to 11px. Note to myself: Patch also requires copying https://bug390955.bugzilla.mozilla.org/attachment.cgi?id=818803 into /images.
Created attachment 14104 [details] Obligatory screenshot from boogs.wmflabs.org (For the records: Screenshot made after applying https://gerrit.wikimedia.org/r/#/c/101655/ which isn't on production yet.)
Note to myself: Next version of patch should sync "in X status" vs "with X status", and replace "closed bugs" by "closed tickets". (Just because I hate the term "bugs" when we also refer to enhancement requests here.)
(In reply to comment #27) > Created attachment 14103 [details] > Preliminary patch To do: Need to replace [ and ] by %5B and %5D for "[Bug%20creation]"
Change 106650 had a related patch set uploaded by Aklapper: Display useful links on Bugzilla front page https://gerrit.wikimedia.org/r/106650
We deployed this change today. Closing as FIXED.