Hi everyone,
I wanted to get some idea of what y'all think of our existent bug tracker. I know there are mixed feelings about Bugzilla and works well for a lot of things we do and maybe we need to use it more effectively/upgrade it and find tools that integrate with it better. But I'd like to know whether there is any kind of consensus for sticking with it or switching away from it and what you would like to have that Bugzilla is missing now (we are a few versions behind on bugzilla.wikimedia.org)
Guillaume and Naoko have expressed a need for a Project Management Tool and I though it would be good to try use a tracker with some project management functionality or integrates easily with some project management tool.
I've started a page for gathering feedback and suggestions http://www.mediawiki.org/wiki/TrackerPMTool
Once we have a few good candidates I'll try to get a some test instances going for people to play with. -p
On Wed, Jan 6, 2010 at 6:25 PM, Priyanka Dhanda pdhanda@wikimedia.org wrote:
I wanted to get some idea of what y'all think of our existent bug tracker.
Bugzilla is obnoxious and hard to use, but people are familiar with it. From what I've seen of Trac, I'm not a big fan of that either (although I haven't used it much). My favorite issue tracker packages as a user are Launchpad and Google Issues. The latter isn't even distributed to third parties, let alone open-source. Launchpad, on the other hand, has been AGPL for several months now. It might not meet other requirements, but I like its UI a lot compared to most other packages I've used. (As a user, I mean, I've never administered any.)
The only software I've personally used that does stuff like time tracking is JIRA. It's free as in beer for open-source projects, but closed-source, and personally I think it's even more confusing to use than Bugzilla. Like Bugzilla's cluttered and cryptic UI except with ten times as many features, so it's that much worse. Plus the gibberish options tend to be enterprise-speak instead of hacker-speak, so I have a harder time understanding them.
On Thu, Jan 7, 2010 at 10:19 AM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
Bugzilla is obnoxious and hard to use, but people are familiar with it. From what I've seen of Trac, I'm not a big fan of that either (although I haven't used it much). My favorite issue tracker packages as a user are Launchpad and Google Issues. The latter isn't even distributed to third parties, let alone open-source. Launchpad, on the other hand, has been AGPL for several months now. It might not meet other requirements, but I like its UI a lot compared to most other packages I've used. (As a user, I mean, I've never administered any.)
The only software I've personally used that does stuff like time tracking is JIRA. It's free as in beer for open-source projects, but closed-source, and personally I think it's even more confusing to use than Bugzilla. Like Bugzilla's cluttered and cryptic UI except with ten times as many features, so it's that much worse. Plus the gibberish options tend to be enterprise-speak instead of hacker-speak, so I have a harder time understanding them.
That is apparently fixed in the newer versions, where you can set it up to hide the more advanced stuff on forms and stuff unless people want to use it and have forms that can only be touched if another one is. We do have a running testbed for the new version somewhere on the WMF servers, its address is in one of the bug reports requesting the upgrade.
-Peachey
On Wed, Jan 6, 2010 at 9:12 PM, K. Peachey p858snake@yahoo.com.au wrote:
That is apparently fixed in the newer versions, where you can set it up to hide the more advanced stuff on forms and stuff unless people want to use it and have forms that can only be touched if another one is. We do have a running testbed for the new version somewhere on the WMF servers, its address is in one of the bug reports requesting the upgrade.
New version of what? Bugzilla? I assume Mozilla's is roughly the latest version. That one is definitely better than ours, but still pretty confusing to normal people, compared to something like Launchpad or Google Issues.
On Wed, Jan 6, 2010 at 11:47 PM, Mike.lifeguard mike.lifeguard@gmail.com wrote:
Launchpad is (I think) still undergoing lots of changes. It may be opensourced now, but I'm not sure it is ready. I actually have UI complaints... since this request is at least in part coming from folks on the usability team, I wonder what they think of Launchpad. Maybe I'm hallucinating usability issues.
Well, workflow is just a lot smoother for common things. So for instance, to subscribe, just click "Subscribe" and it works immediately via AJAX. On Bugzilla you have to type in your e-mail address in the CC field, or scroll all the way to the bottom and check the box and hit Submit and hope you didn't change anything else by mistake at the same time, and hope that no one else changed anything at the same time so you avoid a mid-air collision. "Mark as duplicate" is similarly simple.
And it's just organized more intuitively. Compare:
https://bugs.launchpad.net/firefox/+bug/18305 https://bugzilla.mozilla.org/show_bug.cgi?id=235115
On Bugzilla you have to scroll through more than a page of mysterious fields (at my resolution) before you ever get to the actual bug description. Launchpad has most things neatly tucked away at the side. People are identified by names instead of e-mails. Status changes are noted inline in the comment that accompanies them instead of being hidden in a separate activity history. It's just . . . way better.
On Thu, Jan 7, 2010 at 2:17 AM, Robert Rohde rarohde@gmail.com wrote:
The historical position has been that absolutely nothing goes into the WMF software pool unless it is open source. As I recall, the only recognized exception was the closed source firmware running the routers at the server farm. By that standard, even a freebie is not good enough if the system is closed source.
Obviously this is not the current position, because the image servers run Solaris. The position was always to use open-source software *unless* no OSS met Wikimedia's needs. This was (is) the case for routers. It was also the case for Java before it was open-source, AFAIK just because Robert was more comfortable with Java Lucene than CLucene and you have to take volunteers where you can get them. Although the switch to Solaris wasn't discussed anywhere in public as far as I know, my impression is that it happened after we lost a whole bunch of images due to programming error, for the sake of being able to use ZFS snapshots.
I'm also not sure who would enforce such a policy with Brion no longer CTO. I note Priyanka's initial requirements just said "Free", and ^demon changed that to "Free (Beer and Speech)".
Personally, I would like to see Wikimedia stick to all OSS. Wikimedia's goal is to advance free knowledge, and supporting free software advances that goal, at least construed in a broad sense. Every high-profile user to any given open-source project helps that project and thereby OSS as a whole. But I'm not making the decisions here.
2010/1/7 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jan 7, 2010 at 2:17 AM, Robert Rohde rarohde@gmail.com wrote:
The historical position has been that absolutely nothing goes into the WMF software pool unless it is open source. As I recall, the only recognized exception was the closed source firmware running the routers at the server farm. By that standard, even a freebie is not good enough if the system is closed source.
Obviously this is not the current position, because the image servers run Solaris.
I understand they run OpenSolaris, which is free software.
- d.
On Thu, Jan 7, 2010 at 1:58 PM, David Gerard dgerard@gmail.com wrote:
I understand they run OpenSolaris, which is free software.
Well, either you're right or River is:
081128 13:01:12 <@yksinaisyyteni> we don't use opensolaris, we use solaris 10 ... 081128 13:02:08 <Simetrical> Wikimedia is using Solaris 10 to host Wikipedia/Commons/etc. stuff? 081128 13:02:15 <@yksinaisyyteni> the image server
(from #wikimedia-tech)
2010/1/7 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jan 7, 2010 at 1:58 PM, David Gerard dgerard@gmail.com wrote:
I understand they run OpenSolaris, which is free software.
Well, either you're right or River is:
River probably is then :-) However, I understood the ZFS bug manifested itself on OpenSolaris on the image server ...
- d.
David Gerard wrote:
2010/1/7 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jan 7, 2010 at 1:58 PM, David Gerard dgerard@gmail.com wrote:
I understand they run OpenSolaris, which is free software.
Well, either you're right or River is:
River probably is then :-) However, I understood the ZFS bug manifested itself on OpenSolaris on the image server ...
- d.
http://wikitech.wikimedia.org/view/Ms4 to Ms8 begin with "MsX is a Sun Fire X4540 running Solaris 10." Similar for Ms1 "This box is running Solaris 10 with zfs.".
So for now I will upgrade bugzilla to the latest version. -p
On 1/8/10 3:46 PM, Platonides wrote:
David Gerard wrote:
2010/1/7 Aryeh GregorSimetrical+wikilist@gmail.com:
On Thu, Jan 7, 2010 at 1:58 PM, David Gerarddgerard@gmail.com wrote:
I understand they run OpenSolaris, which is free software.
Well, either you're right or River is:
River probably is then :-) However, I understood the ZFS bug manifested itself on OpenSolaris on the image server ...
- d.
http://wikitech.wikimedia.org/view/Ms4 to Ms8 begin with "MsX is a Sun Fire X4540 running Solaris 10." Similar for Ms1 "This box is running Solaris 10 with zfs.".
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 37-01--10 03:59 PM, Priyanka Dhanda wrote:
Guillaume and Naoko have expressed a need for a Project Management Tool
What exactly does "Project Management Tool" encompass?
On 37-01--10 03:59 PM, Aryeh Gregor wrote:
From what I've seen of Trac, I'm not a big fan of that either (although I haven't used it much).
Trac is worse that bugzilla. Just say no.
My favorite issue tracker packages as a user are Launchpad ... Launchpad, on the other hand, has been AGPL for several months now. It might not meet other requirements, but I like its UI a lot compared to most other packages I've used. (As a user, I mean, I've never administered any.)
Launchpad is (I think) still undergoing lots of changes. It may be opensourced now, but I'm not sure it is ready. I actually have UI complaints... since this request is at least in part coming from folks on the usability team, I wonder what they think of Launchpad. Maybe I'm hallucinating usability issues.
- -Mike
Hi,
Mike.lifeguard a écrit :
On 37-01--10 03:59 PM, Priyanka Dhanda wrote:
Guillaume and Naoko have expressed a need for a Project Management Tool
What exactly does "Project Management Tool" encompass?
See the project management section of http://www.mediawiki.org/wiki/Tracker/PM_tool :)
-- Guillaume Paumier
On Thu, Jan 7, 2010 at 10:25 AM, Priyanka Dhanda pdhanda@wikimedia.orgwrote:
Guillaume and Naoko have expressed a need for a Project Management Tool and I though it would be good to try use a tracker with some project management functionality or integrates easily with some project management tool.
Anyone tried FogBugz, Joel Spolsky's baby? I'm so curious... although it's commercial software, who knows, you might get a discount or even a freebie.
Steve
On Wed, Jan 6, 2010 at 9:14 PM, Steve Bennett stevagewp@gmail.com wrote:
On Thu, Jan 7, 2010 at 10:25 AM, Priyanka Dhanda pdhanda@wikimedia.orgwrote:
Guillaume and Naoko have expressed a need for a Project Management Tool and I though it would be good to try use a tracker with some project management functionality or integrates easily with some project management tool.
Anyone tried FogBugz, Joel Spolsky's baby? I'm so curious... although it's commercial software, who knows, you might get a discount or even a freebie.
The historical position has been that absolutely nothing goes into the WMF software pool unless it is open source. As I recall, the only recognized exception was the closed source firmware running the routers at the server farm. By that standard, even a freebie is not good enough if the system is closed source.
However, my recollection is based on discussions years ago. On searching, I couldn't find any policy forbidding closed source software (is there one?). So, it is possible that closed source might be looked on as a more acceptable possibility for some functions now (though I wouldn't bet on it).
-Robert Rohde
On Thu, Jan 7, 2010 at 08:17, Robert Rohde rarohde@gmail.com wrote:
On Wed, Jan 6, 2010 at 9:14 PM, Steve Bennett stevagewp@gmail.com wrote:
Anyone tried FogBugz, Joel Spolsky's baby? I'm so curious... although it's commercial software, who knows, you might get a discount or even a freebie.
The historical position has been that absolutely nothing goes into the WMF software pool unless it is open source.
I deeply agree that.
However, my recollection is based on discussions years ago. On searching, I couldn't find any policy forbidding closed source software (is there one?). So, it is possible that closed source might be looked on as a more acceptable possibility for some functions now (though I wouldn't bet on it).
Wouldn't be nice. First, it's an attitude thing: we want (and have to) promote open stuff. Second, it isn't nice to show something to the users they cannot use themselves. It's kind of against or basic principle of "you can do what we do, you're free to do it, we just do it better" :-)
On Thu, Jan 7, 2010 at 8:39 AM, Peter Gervai grinapo@gmail.com wrote: ..
Wouldn't be nice. First, it's an attitude thing: we want (and have to) promote open stuff. Second, it isn't nice to show something to the users they cannot use themselves. It's kind of against or basic principle of "you can do what we do, you're free to do it, we just do it better" :-)
It will be a good idea to pass the memo to the guys that design the notability rules.
http://ioquake3.org/2009/02/20/ioquake3-entry-deleted-from-wikipedia/
Since most (all?) opensource proyects are webonly, and don't get in the press, are on some "obscure" area of the web where something can be wildly popular for these in-the-know, and invisible for these that edit and delete articles.
I mean, I can write a bot to nominate *all* opensource projects articles on wikipedia for speedy deletion, and few ones (maybe 6) will survive that.
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Ioquake3
<<<<<< Keep no matter how loud people and guidlines scream for reliable sources, many, many people use it and work on it and that makes it notable. If the press is not able to reliably represent this reality it's not a fault of the project and reality is a higher standard than reliable press. What do you need press for an Open Source project? Just looking at the SVN log proves more than any article could ever do. -- ioquake3 maintainer for the FreeBSD project
On 08.01.2010, 22:42 Tei wrote:
It will be a good idea to pass the memo to the guys that design the notability rules.
http://ioquake3.org/2009/02/20/ioquake3-entry-deleted-from-wikipedia/
Since most (all?) opensource proyects are webonly, and don't get in the press, are on some "obscure" area of the web where something can be wildly popular for these in-the-know, and invisible for these that edit and delete articles.
I mean, I can write a bot to nominate *all* opensource projects articles on wikipedia for speedy deletion, and few ones (maybe 6) will survive that.
<offtopic severity="Will not engage in further flamewar on-list"> FFS, how can one maintain an article without reliable sources? What such an article will look like? Enough article-count-stacking, emphasis on quality, even if that means systemic bias. Wikipedia is not a registry of open-source projects. And those projects that an average user might search for tend to have some sources, guess why?
As of counter examples of fancruft, there's one 100% recipe: remove all in-universe crap and slap {{db-empty}} if there's nothing left. </offtopic>
On Fri, Jan 8, 2010 at 8:42 PM, Tei oscar.vives@gmail.com wrote:
On Thu, Jan 7, 2010 at 8:39 AM, Peter Gervai grinapo@gmail.com wrote: ..
Wouldn't be nice. First, it's an attitude thing: we want (and have to) promote open stuff. Second, it isn't nice to show something to the users they cannot use themselves. It's kind of against or basic principle of "you can do what we do, you're free to do it, we just do it better" :-)
It will be a good idea to pass the memo to the guys that design the notability rules.
Right. Notability guidelines do not apply to the Wikimedia Servers, MediaWiki software or on which kind of bug tracker we are going to use, so please take complaining about that somewhere else.
Bryan
On Fri, Jan 8, 2010 at 2:42 PM, Tei oscar.vives@gmail.com wrote:
It will be a good idea to pass the memo to the guys that design the notability rules.
http://ioquake3.org/2009/02/20/ioquake3-entry-deleted-from-wikipedia/
Notability is decided by each wiki individually. The policies of the English Wikipedia are irrelevant to this list, which is about Wikimedia server administration and MediaWiki development. The correct list for this sort of comment would be wikien-l, or possibly foundation-l. Devs/sysadmins can't override wiki policies on things like notability, so there's no point in telling wikitech-l. Thanks.
Tei wrote:
It will be a good idea to pass the memo to the guys that design the notability rules.
http://ioquake3.org/2009/02/20/ioquake3-entry-deleted-from-wikipedia/
Since most (all?) opensource proyects are webonly, and don't get in the press, are on some "obscure" area of the web where something can be wildly popular for these in-the-know, and invisible for these that edit and delete articles.
I mean, I can write a bot to nominate *all* opensource projects articles on wikipedia for speedy deletion, and few ones (maybe 6) will survive that.
*Many* opensource projects are relevant, to cite a few: Apache, PHP, Python, Perl, Ruby, Postgresql, subversion, mercurial, git, bazaar... Those are more than 6... :) They are technologies widely known, there are books written about them... As opposed, this is the first time I hear about ioquake3. It may be relevant, it may be not.
Being in the web and free is not enough for warranting notability.
Even though script kiddies making its Linux ditro don't like it :)
http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Ioquake3
<<<<<< Keep no matter how loud people and guidlines scream for reliable sources, many, many people use it and work on it and that makes it notable. If the press is not able to reliably represent this reality it's not a fault of the project and reality is a higher standard than reliable press. What do you need press for an Open Source project? Just looking at the SVN log proves more than any article could ever do. -- ioquake3 maintainer for the FreeBSD project
If they are relevant, why bother if wikipedia doesn't acknowledge that? Suppose wikipedia didn't have an article about FreeBSD, would that make it a worse OS?
2010/1/7 Robert Rohde rarohde@gmail.com:
The historical position has been that absolutely nothing goes into the WMF software pool unless it is open source. As I recall, the only recognized exception was the closed source firmware running the routers at the server farm. By that standard, even a freebie is not good enough if the system is closed source. However, my recollection is based on discussions years ago. On searching, I couldn't find any policy forbidding closed source software (is there one?). So, it is possible that closed source might be looked on as a more acceptable possibility for some functions now (though I wouldn't bet on it).
The reasoning is that having the data be free content is not enough - the systems you need to use the data need to be free software as well.
Lucene is free software, but was out for a while as Java wasn't free software then. I believe we used a rewritten version in C# for a while, in fact. A Java version of Lucene started being used again when Java was in the process of being freed up, I think we were using it before there was an entirely free software Java.
(corrections welcomed!)
- d.
On Thu, Jan 7, 2010 at 6:59 AM, David Gerard dgerard@gmail.com wrote:
The reasoning is that having the data be free content is not enough - the systems you need to use the data need to be free software as well.
Strictly speaking though, the bug tracking software for Mediawiki isn't actually part of the chain of systems responsible for running Wikipedia. As far as I know no one has ever tried to duplicate Mediawiki's bugzilla or even wanted to. So, if one was going to make an exception, then this seems like an area that could be considered, but I don't know of any really strong arguments for why closed source would be necessary in this case.
-Robert Rohde
Robert Rohde wrote:
The historical position has been that absolutely nothing goes into the WMF software pool unless it is open source. As I recall, the only recognized exception was the closed source firmware running the routers at the server farm.
Also Solaris.
Lucene is free software, but was out for a while as Java wasn't free software then. I believe we used a rewritten version in C# for a while, in fact. A Java version of Lucene started being used again when Java was in the process of being freed up, I think we were using it before there was an entirely free software Java.
Well yeah, Brion took a strong stance against proprietary software and ported MediaWiki's interface to Lucene to C# to avoid having to use Java. But Lucene.NET was not very good and Robert Stojnic was keen to switch back to Java when he started working on it. Luckily by that time Sun had announced that they were making Java open source (although the source code wasn't actually published for a bit longer), so Brion could put aside his objections.
However, when we needed to scale up our file storage platform, and make backups more feasible, ZFS's snapshot feature became too attractive to resist. You can only favour idealism over pragmatism up to a point, beyond which it becomes irresponsible, and even Brion was won over. So Solaris was installed on the ms* servers.
I think the current policy is "use open source software unless you have a really good reason".
Jimmy Wales and Erik Moeller are also advocates of open source software.
-- Tim Starling
On Thu, Jan 7, 2010 at 10:35 PM, Tim Starling tstarling@wikimedia.org wrote:
However, when we needed to scale up our file storage platform, and make backups more feasible, ZFS's snapshot feature became too attractive to resist.
What was wrong with LVM snapshots? Performance?
What was wrong with LVM snapshots? Performance?
in zfs every write is 'copy on write', so snapshots have 'zero' cost, and multiple snapshots can use same data. in LVM every snapshot is standalone and has all the information it needs. also LVM doesn't have snapshot-based replication, and DRBD+ wasn't opensource/free at that time either ;-
Though reasons of OpenSolaris vs Solaris are different.
Domas
What were the reasons for replacing lighttpd with Sun Java System Web Server ?
On Sat, Jan 9, 2010 at 12:10 PM, Tim Starling tstarling@wikimedia.org wrote:
Platonides wrote:
What were the reasons for replacing lighttpd with Sun Java System Web Server ?
Probably the same reason that the toolserver uses Confluence instead of MediaWiki.
It only contains one page, which points to the MediaWiki wiki.
https://confluence.toolserver.org/pages/listpages-dirview.action?key=main
Are there plans to make greater use of the Confluence wiki?
https://wiki.toolserver.org/view/Domains#confluence.toolserver.org
-- John Vandenberg
John Vandenberg wrote:
On Sat, Jan 9, 2010 at 12:10 PM, Tim Starling tstarling@wikimedia.org wrote:
Platonides wrote:
What were the reasons for replacing lighttpd with Sun Java System Web Server ?
Probably the same reason that the toolserver uses Confluence instead of MediaWiki.
It only contains one page, which points to the MediaWiki wiki.
https://confluence.toolserver.org/pages/listpages-dirview.action?key=main
I count 65 pages.
https://confluence.toolserver.org/pages/listpages-dirview.action?key=tech
Maybe you were confused by the unfamiliar UI.
Are there plans to make greater use of the Confluence wiki?
Certainly not.
The reason for using SJWS on ms* was the same reason the toolserver uses Confluence: River installed them both. River's contribution is very much appreciated, but he does have his own way of doing things.
-- Tim Starling
On Sat, Jan 9, 2010 at 3:49 PM, Tim Starling tstarling@wikimedia.org wrote:
John Vandenberg wrote:
On Sat, Jan 9, 2010 at 12:10 PM, Tim Starling tstarling@wikimedia.org wrote:
Platonides wrote:
What were the reasons for replacing lighttpd with Sun Java System Web Server ?
Probably the same reason that the toolserver uses Confluence instead of MediaWiki.
It only contains one page, which points to the MediaWiki wiki.
https://confluence.toolserver.org/pages/listpages-dirview.action?key=main
I count 65 pages.
https://confluence.toolserver.org/pages/listpages-dirview.action?key=tech
Maybe you were confused by the unfamiliar UI.
Thanks Tim. I should know Confluence better; we "use" it at work. sigh.
Are there plans to make greater use of the Confluence wiki?
Certainly not.
Good to hear.
-- John Vandenberg
I would prefer something that would tightly integrate with CodeReview, but that probably means writing custom software, which is a lot of work.
Bryan
On Thu, Jan 7, 2010 at 11:22 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
I would prefer something that would tightly integrate with CodeReview, but that probably means writing custom software, which is a lot of work.
I think atlassian is happy to provide Jira as well as other tools for WMF, just like they do for other opensource projects.
On Thu, Jan 7, 2010 at 7:31 AM, Ryan Chan ryanchan404@gmail.com wrote:
On Thu, Jan 7, 2010 at 11:22 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
I would prefer something that would tightly integrate with CodeReview, but that probably means writing custom software, which is a lot of work.
I think atlassian is happy to provide Jira as well as other tools for WMF, just like they do for other opensource projects.
I would recommend reading the EULA as part of the evaluation process: http://www.atlassian.com/about/licensing/license.jsp
In particular, see section 10, which may affect the ability to get an honest opinion about the capabilities of the software from people with experience.
Rob
Bryan Tong Minh wrote:
I would prefer something that would tightly integrate with CodeReview, but that probably means writing custom software, which is a lot of work.
Bryan
Is it that hard? The basic features (add comments, dependencies, email notifications...) are quite straightforward.
A bugzilla extension would fix the skin issues and the not-really wikisyntax comments. It means recreating everything from the ground up, though.
Hi,
this is slightly off-topic, but I'll go ahead anyway:
Please don't make bugzilla (or any future bug tracker) look like MediaWiki (Monobook skin). What looks like a Wiki (but aren't) often gets confused with a Wiki. Buzgilla is not a Wiki. It's a bug tracker.
I know it's nice to have a familiar design on different pages, but this is just confusing for newbies. A distinguishable design prevents confusions.
Regards,
Church of emacs
On 1/7/10 10:55 AM, church.of.emacs.ml wrote:
Hi,
this is slightly off-topic, but I'll go ahead anyway:
Please don't make bugzilla (or any future bug tracker) look like MediaWiki (Monobook skin). What looks like a Wiki (but aren't) often gets confused with a Wiki. Buzgilla is not a Wiki. It's a bug tracker.
I know it's nice to have a familiar design on different pages, but this is just confusing for newbies. A distinguishable design prevents confusions.
Regards,
Church of emacs
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hmmm... Not being able to distinguish the difference between a bug tracker and a wiki based on the skins being similar is a point of view I have a hard time understanding. Having a consistent style across our tool-chain would by most people's thinking be an improvement in the way that each tool is more connected feeling...
Besides, we would be styling it with Vector not Monobook. Monobook is so last decade!
- Trevor
2010/1/7 Trevor Parscal tparscal@wikimedia.org:
Hmmm... Not being able to distinguish the difference between a bug tracker and a wiki based on the skins being similar is a point of view I have a hard time understanding.
Having read quite a few bug reports written in wikitext (which mostly doesn't work in Bugzilla, except for [[links]]), I would encourage a clearer distinction between the wikis and the bug tracker. I don't want to give people the impression that what they're reporting bugs on is really a quirky wiki variant: the bug tracker not only uses different syntax, but also has different policies, procedures and protocols.
I like the Launchpad design, its use of less jargon-like language and how it lists status changes amid the comments and provides a full activity log on a separate page.
Having a consistent style across our tool-chain would by most people's thinking be an improvement in the way that each tool is more connected feeling...
That's a nice idea in principle, but as outlined above I'd like to keep the similarities limited. Our bug tracker should actively communicate it's Wikimedia's (name and logo in prominent places) but shouldn't feel /too/ familiar to people that are used to wikis.
Besides, we would be styling it with Vector not Monobook. Monobook is so last decade!
I do agree that if we restyle anything, we should at least improve its looks :)
Roan Kattouw (Catrope)
Roan Kattouw wrote:
2010/1/7 Trevor Parscal tparscal@wikimedia.org:
Hmmm... Not being able to distinguish the difference between a bug tracker and a wiki based on the skins being similar is a point of view I have a hard time understanding.
Having read quite a few bug reports written in wikitext (which mostly doesn't work in Bugzilla, except for [[links]]), I would encourage a clearer distinction between the wikis and the bug tracker. I don't want to give people the impression that what they're reporting bugs on is really a quirky wiki variant: the bug tracker not only uses different syntax, but also has different policies, procedures and protocols.
It occurs to me that one option would be going the other way: the CodeReview extension already seems to have about 50% of the features a basic but functional bug tracker would need, including a couple of nice ones that our Bugzilla currently lacks (like, you know, comment preview, ability to use wiki markup and, well, code review). Yes, turning it into a full-featured issue tracker and project management tool would take some substantial work, but then, switching to a new project management tool and customizing it to fit our needs isn't quite a 15 minute job either. Just something to consider... :-)
wikitech-l@lists.wikimedia.org