Last modified: 2014-04-17 10:06:35 UTC
It would be great to have a place withing WP that we can point users to for filing bugs instead of just dumping them in bugzilla. Since it might be relevant, attaching their recent click-trail (or similar) should be an option. Also useful, a way to see the status of bugs and perhaps comment on them.
There is http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports Though, unreviewed etc..
Mark, are you suggesting an alternative or simplified "new bug" form? Or an entirely parallel bug tracking system? (I would recommend against the latter, as this would splinter reporting & issue tracking further unless it's something really qualitatively different like the Firefox beta feedback system.)
(In reply to comment #2) I think he means wrapping it in a custom wiki page to make it easier.
not a new bug tracking system, just a way to make sure users of Wikipedia have an easy way to file bug reports using Bugzilla, but without having to deal with the "shock" of learning Yet Another Web app.
Integrating BZ into CentralAuth so people don't have to register another account, and making sure the new bug form isn't too horrid, would probably do the job pretty well. Main impediment to CentralAuth integration is probably that BZ's model of email privacy in inverse to ours: users' email addresses are exposed to all other users... Perhaps a one-click 'create your bugzilla account' though, that warns that your email address will be visible to other people on the bug tracker, might be a smaller hurdle to pass.
[Or -- complete madness perhaps -- a mapping of wiki usernames to fake email 'addresses' and a plugin to BZ to send mails indirectly. MWAHAHAHAHHA]
Switching Wkimedia's BugZilla to a "Vector" skin and the interwiki link to [[bugzilla:]] did a lot of good already to bridge the gap. A CentralAuth integration would make it even better. (In reply to comment #5) > Main impediment to CentralAuth integration is probably that BZ's model of email > privacy in inverse to ours: users' email addresses are exposed to all other > users... Is there a preference to hide the e-mailadres from public in BugZilla ? If not perhaps a mini plug-in could be created for this which would be set as default for accounts via CentralAuth.
(In reply to comment #7) > Is there a preference to hide the e-mailadres from public in BugZilla ? > If not perhaps a mini plug-in could be created for this which would be set as > default for accounts via CentralAuth. > Not in BZ 3.x. Maybe in 4? (In reply to comment #2) > Mark, are you suggesting an alternative or simplified "new bug" form? Or an > entirely parallel bug tracking system? (I would recommend against the latter, > as this would splinter reporting & issue tracking further unless it's something > really qualitatively different like the Firefox beta feedback system.) How about a SpecialPage, called Special:FeatureIdea or Special:BugRequest. We could have them be posted to BZ's API. I'd certainly like to have either UNCONFIRMED, or a keyword, or something to differentiate these outside bugs. Makes querying, duping, etc easier.
(In reply to comment #7) > Is there a preference to hide the e-mailadres from public in BugZilla ? > If not perhaps a mini plug-in could be created for this which would be set as > default for accounts via CentralAuth. That would make Bz unusable to anyone that wanted to do a simple search (eg: all bugs filed by X) or if they wanted to CC someone onto a bug. You need email addresses to be visible for Bz to be usable.
(In reply to comment #9) > That would make Bz unusable to anyone that wanted to do a simple search (eg: > all bugs filed by X) Why does it follow that this would be the inevitable result of hiding email addresses? If I only had "p858snake" I could search for all the bugs you filed: https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&emailreporter1=1&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&email1=p858snake&resolution=---&resolution=WONTFIX&resolution=LATER&emailtype1=substring
(In reply to comment #10) > (In reply to comment #9) > > That would make Bz unusable to anyone that wanted to do a simple search (eg: > > all bugs filed by X) > > Why does it follow that this would be the inevitable result of hiding email > addresses? If I only had "p858snake" I could search for all the bugs you > filed: That is assuming that the persons real name field (if they had it set) would match anywhere near their email.
In this particular case, yes, but AFAIK there is no reason to think that a similar search could not be added whenever CentralAuth was added.
*** Bug 27852 has been marked as a duplicate of this bug. ***
More discussion on the "vision thing" for this at Bug #27852 *** This bug has been marked as a duplicate of bug 27852 ***
Bug #27852 doesn't seem like the correct place to discuss centralauth for BZ but rather a much bigger integration. Wouldn't using a view (sorry I haven't actually looked at the db) allow you to map the users from centralauth in the short term pending some kind of huge proper integration?
Un-duping. Tying Bugzilla into a central-auth type thing would be useful to lots of people (I don't say CentralAuth necessarily, we might look at something like OpenID for this). Comment #15 is correct, bug 27852 is about a wider issue than just improving BZ auth.
(In reply to comment #2) > Mark, are you suggesting an alternative or simplified "new bug" form? There IS a guided form, however it needs lots of love first (see bug 36762). (In reply to comment #7) > Is there a preference to hide the e-mailadres from public in BugZilla ? No: https://bugzilla.mozilla.org/show_bug.cgi?id=218917
See https://github.com/LegNeato/mediawiki-bugzilla#mediawiki-extension-for-bugzilla http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Improve_the_mediawiki-bugzilla_extension_to_a_deployable_level
As a few things have been mentioned here: * Central Auth / SUL bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=14487 * Public email address in Bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=148
This enhancement request is really messy, which is surprising considering that we have all the Bugzilla experts here. ;) We are talking about different things: 1. Publishing Bugzilla data in MediaWiki pages. Indeed a useful feature for any project using Bugzilla and MediaWiki e.g. us. At least Andre and me used http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports years ago in another project. That was with MW 1.15 or so. Mozilla developed https://github.com/LegNeato/mediawiki-bugzilla#mediawiki-extension-for-bugzilla and is using it in MW 1.19.4 although it says it has open bugs. I think it's worth to complete and if one or two of you would volunteer as mentors I will push it to https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas to see if a qualified student is interested. 2. Reporting a bug to Bugzilla from a MediaWiki page. The argument is that Bugzilla scares users. If that is true we should try first a nice Bugzilla guided UI for filing bugs ---> Bug 36762 Andre says it takes work, but I guess less work than developing an extension that anyway should guide MediaWiki users to help them understand what are they doing. Otherwise be prepared to DUPE / Article Feedback / Twitter / Facebook style messages flooding Bugzilla. 3. Commenting on existing bug reports from a MediaWiki page. For this you need 1 and 2 in the first place. However, once the user is at this point, I wonder how less scary is to see this page here with 20 comments or the equivalent exported to a Wiki page. And how less scary would be to find a textarea with a "Save changes" vs "Comment" button at the end. If this is a concern then we can simply work on a good custom CSS/skin for our Bugzilla, instead of creating a new MW extension. 4. Unified login between MediaWiki and Bugzilla. Discussion should go ---> Bug 14487 5. Hiding email addresses. Discussion should go ---> Bug 148
I have contacted Brandon Savage from Mozilla to see what needs to be done to consider their MediaWiki - Bugzilla extesion ready for production. https://twitter.com/quimgil/status/315526551762505728 + email with more details. I also found this, which is probably the last update from the main developer at the time: http://christian.legnitto.com/blog/2012/04/18/new-mediawiki-bugzilla-feature/
Can someone please install https://github.com/mozilla/mediawiki-bugzilla somewhere to test how that works with a plain, up-to-date MediaWiki and our Bugzilla? I'm happy starting to test in order to find potential bugs and feature requests. See also the wiki.moz component at bugzilla.mozilla.org: http://tinyurl.com/d2wsy47 Mozilla considers the linked code repository and bug reporting site 'upstream' for this project, which is good. They are committed to maintain it but they have many other things in their plate. They are happy to collaborate in a co-mentored GSOC/OPW project. They are defining what would be the appropriate project scope. Anybody volunteering to co-mentor with a Bugzilla/Mozilla co-mentor, to cover the MediaWiki specific side? With two mentors for one project I wouldn't expect much work for each, and especially the MW side looks rather uncomplicated (?). In a way or another we should keep pushing this forward!
(In reply to comment #22) > Can someone please install https://github.com/mozilla/mediawiki-bugzilla > somewhere to test how that works with a plain, up-to-date MediaWiki and our > Bugzilla? It can probably be put in labs somewhere?
(In reply to comment #23) > (In reply to comment #22) > > Can someone please install https://github.com/mozilla/mediawiki-bugzilla > > somewhere to test how that works with a plain, up-to-date MediaWiki and our > > Bugzilla? > > It can probably be put in labs somewhere? Isn't there already a bugzilla project in labs? Having said that, it would seem as this is all MW/client side, anyone should be able to install it on their own wiki without too much of an issue. https://wiki.mozilla.org/Special:Version - 1.19.4. I'm guessing that means we can drop anicent MW compatibility. JS needs overhauling (manual inclusion of own resources etc) Do we know if there is any sort of Semantic extension dependancy/usage? I do note it hasn't been touched in 4 months. Certainly a first pass to normalise their own style usage and fixing up a few icky things (?> among others) would be nice. File storage of generated charts needs FileBackend/swift-ifying (In reply to comment #22) > See also the wiki.moz component at bugzilla.mozilla.org: > http://tinyurl.com/d2wsy47 > As well as https://github.com/mozilla/mediawiki-bugzilla/issues And open pull requests at https://github.com/mozilla/mediawiki-bugzilla/pulls 2 of which are Hexmode I'll probably set it up on my dev wiki tomorrow and see how well it plays ball
(In reply to comment #24) > > It can probably be put in labs somewhere? > Isn't there already a bugzilla project in labs? I am aware of the unfinished https://labsconsole.wikimedia.org/wiki/Nova_Resource:Bugtracker and http://kubo.wmflabs.org//bugzilla/
(In reply to comment #24) > Having said that, it would seem as this is all MW/client side, anyone should > be able to install it on their own wiki without too much of an issue. As a super-amateru sysadmin I was deterred by these requirements that I don't understand and I was too busy / lazy to find out this week with all the GSOC stuff: > Requires HTTP_Request2 from PEAR > For charting, requires gd https://github.com/mozilla/mediawiki-bugzilla
(In reply to comment #26) > (In reply to comment #24) > > Having said that, it would seem as this is all MW/client side, anyone should > > be able to install it on their own wiki without too much of an issue. > > As a super-amateru sysadmin I was deterred by these requirements that I don't > understand and I was too busy / lazy to find out this week with all the GSOC > stuff: > > > > Requires HTTP_Request2 from PEAR > > For charting, requires gd > > https://github.com/mozilla/mediawiki-bugzilla For the first one: pear install HTTP_Request2 And for the second (on Ubuntu at least) apt-get install php5-gd
And the HTTP_Request2 one can likely be replaced by the Http classes in MediaWiki itself..
(In reply to comment #26) > (In reply to comment #24) > > Having said that, it would seem as this is all MW/client side, anyone should > > be able to install it on their own wiki without too much of an issue. > > As a super-amateru sysadmin I was deterred by these requirements that I don't > understand and I was too busy / lazy to find out this week with all the GSOC > stuff: > > > > Requires HTTP_Request2 from PEAR > > For charting, requires gd > > https://github.com/mozilla/mediawiki-bugzilla Yup, after installing those, with the default requires using: <bugzilla> { "product": "Bugzilla", "priority":"P1" } </bugzilla> I get results working fine! 3 pull requests already https://github.com/mozilla/mediawiki-bugzilla/pull/19 and https://github.com/mozilla/mediawiki-bugzilla/pull/20 and https://github.com/mozilla/mediawiki-bugzilla/pull/21 For our usage: require_once( "$IP/extensions/mediawiki-bugzilla/Bugzilla.php" ); $wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi"; $wgBugzillaURL = "https://bugzilla.wikimedia.org"; then <bugzilla> { "product": "MediaWiki", "status": "NEW" } </bugzilla> (well, I think it's working. It's taking a long time to save the page ;)) (note, its slow due to a lot of results!)
require_once( "$IP/extensions/mediawiki-bugzilla/Bugzilla.php" ); $wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi"; $wgBugzillaURL = "https://bugzilla.wikimedia.org"; $wgBugzillaMethod = 'xml-rpc'; Not actually sure where our rest api (needs confirming), but the xml-rpc one works fine
Thank you for testing and for the patches! Question: is the extension supporting lists of bugs related to a specific keyword? For instance, imagine that we want to show all the open reports marked as EASY.
(In reply to comment #31) > Thank you for testing and for the patches! > > Question: is the extension supporting lists of bugs related to a specific > keyword? For instance, imagine that we want to show all the open reports > marked > as EASY. Presumably something like the following should be enough: <bugzilla> { "keyword": "easy" } </bugzilla>
(In reply to comment #21) > I have contacted Brandon Savage from Mozilla to see what needs to be done to > consider their MediaWiki - Bugzilla extesion ready for production. Mozilla is excited about co-mentoring with us this activity as a Google Summer of Code / Outreach Program for Women project. Brandon Savage (current maintainer) will be co-mentor. Anybody from our side willing to co-mentor to assist with MediaWiki knowledge? It shouldn't be much work. Brandon also say that this week he will go through the open issues and pull requests in GitHub.
(In reply to comment #33) > (In reply to comment #21) > > I have contacted Brandon Savage from Mozilla to see what needs to be done to > > consider their MediaWiki - Bugzilla extesion ready for production. > > Mozilla is excited about co-mentoring with us this activity as a Google > Summer > of Code / Outreach Program for Women project. Brandon Savage (current > maintainer) will be co-mentor. Anybody from our side willing to co-mentor to > assist with MediaWiki knowledge? It shouldn't be much work. > > Brandon also say that this week he will go through the open issues and pull > requests in GitHub. Is there enough work to be potentially done to make it a decent GSoC/similar project?
Brandon from Mozilla said: We have a short list of our open issues here: http://tinyurl.com/d2wsy47 Of course, this is by no means a complete or comprehensive list. Charting is nascent; we support limited charts for our users. There's also limited support for more complex queries of the Bugzilla API, and the JSON you're expected to compose for the API largely requires an already-working knowledge of the REST API for Bugzilla. Not to mention the fact that there's little to no documentation. Here's my punch list of things I think would be great mentoring bugs and could keep a developer busy for a couple of months working on this project: *Fully implement charting. * Identify and implement a creative solution to the JSON-must-follow-Bugzilla's-API problem. * Make mediawiki-bugzilla compatible with the latest versions of medawiki (right now I do not think that it is) * Some kind of sane pagination (Bugzilla's API doesn't implement one so this is challenging) * Making the plugin overall less fragile, and more robust. We could use some error handling for unavailability of the Bugzilla API, for example. * Write unit tests or functional tests for this plugin (we have none) Then Christian Legnitto, former main developer added: As for the open issues, I believe there are patches in the tree that just need to be deployed for https://bugzilla.mozilla.org/show_bug.cgi?id=845471, as I added (and brandon fixed) support for that in https://bugzilla.mozilla.org/show_bug.cgi?id=743987. You can configure the defaults install-wide or do it by each query. Why use the rest API format? No need to change some middleware mapping library whenever features are added to the bugzilla API, a lot comes "for free". I could see a decent UI being built on top to be a good project, though for Mozilla it isn't that useful as most people are technical or can dive into technical docs (or copy and paste + tweak something working). One thing I wasn't happy about was moving pcharts into the repo...I think its license is GPL3 which I didn't want in there (was doing the default mozilla tri-license). But, I didn't see the need to protest much. Another decent project might be to just output in data labels and have client-side JS render the charts rather than creating images server-side. And I added: What about having a page documenting / advertising the extension under https://www.mediawiki.org/wiki/Extensions ? We are meeting tomorrow at 9:30am Pacific over Skype. I also have sent an invitation to Sam just in case he can join and help with MediaWiki technical assessment. It would be very useful if you could make it! And to Andre, of course. If anybody else wants to join just send me an email.
(In reply to comment #30 by Reedy) > $wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi"; > Not actually sure where our rest api (needs confirming), but the xml-rpc one > works fine There is no REST API by default. There is https://bugzilla.wikimedia.org/jsonrpc.cgi and https://bugzilla.wikimedia.org/xmlrpc.cgi
(In reply to comment #36) > (In reply to comment #30 by Reedy) > > $wgBugzillaRESTURL = "https://bugzilla.wikimedia.org/bzapi"; > > Not actually sure where our rest api (needs confirming), but the xml-rpc one > > works fine > > There is no REST API by default. There is > https://bugzilla.wikimedia.org/jsonrpc.cgi and > https://bugzilla.wikimedia.org/xmlrpc.cgi Isn't that great? gj on the documentation, Mozilla. $wgBugzillaRESTURL = 'https://api-dev.bugzilla.mozilla.org/latest'; // The URL for your Bugzilla API installation $wgBugzillaURL = 'https://bugzilla.mozilla.org'; // The URL for your Bugzilla installation $wgBugzillaTagName = 'bugzilla'; // The tag name for your Bugzilla installation (default: 'bugzilla') $wgBugzillaMethod = 'REST'; // XML-RPC and JSON-RPC may be supported later Considering they've got xml-rpc in the code already, and a instantiation of a json-rpc class that doesn't exist... Ugh.
Brandon Savage (Mozilla), Andre Klapper and me had a chat today and defined the scope for this project in a broad sense. Brandon and Reedy have volunteered co-mentoring this project, which has been now featured for Google Summer of Code and Outreach Program for Women: http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Productize_the_Bugzilla-MediaWiki_extension If a student / intern is interested we will develop the project upstream at https://github.com/mozilla/mediawiki-bugzilla In the meantime, I wonder... couldn't we install this extension already in mediawiki.org or Wikitech? If it's good enough for Mozilla's Wiki it may be good enough for us, to get us started and have a better idea of bugs / missing features.
(In reply to comment #38) > In the meantime, I wonder... couldn't we install this extension already in > mediawiki.org or Wikitech? If it's good enough for Mozilla's Wiki it may be > good enough for us, to get us started and have a better idea of bugs / > missing features. It'll need a full security review. I'm not sure if such a review would be the subject of this bug or a separate "Review and deploy extension blah to blargh" bug.
Bug 46908 - Please enable MediaWiki-Bugzilla extension in Wikitech
There is an ongoing revision of our project management tools, which includes Bugzilla. https://www.mediawiki.org/wiki/Requests_for_comment/Project_management_tools_review Setting Lowest priority for now. This will change in a direction or another when we have a decision.
(Also see [[mw:Extension:IssueTracker]] which is not about integration but about doing issue tracking itself in MediaWiki...)
