Re: [Wikitech-l] Reworking API help

[Max Semenik]

On 14.05.2012, 7:04 Kevin wrote:

> While considering adding syntax highlighting to the format=jsonfm output
> of the API, I noticed the hackishness of the current API help page
> system[1] and started working on a replacement that generates a "[...] a
> fully-HTML version of the help message"[2] while remaining
> fully compatible with existing extensions.

> I propose moving API help to a new special page Special:ApiHelp, which
> would run a few preg_replace operations and then the parser on
> individual portions of the documentation to format them as HTML. The
> combined output for all modules would be cached in memcached as in the
> old ApiHelp class.

https://en.wikipedia.org/wiki/Special:ApiSandbox

-- 
Best regards,
  Max Semenik ([[User:MaxSem]])


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Gerard Meijssen]

Hoi,
MantisBT is localised at translatewiki.net. Given that we are talking about
software to be used by the Wikimedia Foundation, it is a VERY important
consideration. It beats hands down other software like MathJax that is
considered to be usable and is not ieven internationalised.
Thanks,
 GerardM

On 12 May 2012 18:17, David Gerard  wrote:

> Discussion on Oliver Keyes' blog:
>
>http://quominus.org/archives/714
>
> He's coming from the perspective of liaison with newbies. Read the
> comments.
>
> (I will note that Antoine Musso was right in the previous discussion
> that Mantis has a nice, friendly interface. I myself was most
> displeased to discover that (a) the code itself is really horrible (b)
> it's all but unsupported even to free-software standards.)
>
>
> - d.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r115234]: New comment added

[MediaWiki Mail]

"Nikerabbit" posted a comment on MediaWiki.r115234.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115234#c32801

Commit summary for MediaWiki.r115234:

Localisation updates from http://translatewiki.net.

Nikerabbit's comment:

Why has '@author Njardarlogar' been in almost every commit but no content 
changes?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115364]: Revision status changed

[MediaWiki Mail]

"Nikerabbit" changed the status of MediaWiki.r115364 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115364

Old status:  new
New status: ok

Commit summary for MediaWiki.r115364:

Fixed constant session errors due to wrong token function usage

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] The bugtracker problem, again

[Krinkle]

On May 14, 2012, at 5:04 AM, K. Peachey wrote:

> On Mon, May 14, 2012 at 12:55 PM, Krinkle  wrote:
>> I'm convinced all other fields can be done without and removing them will
>> improve the workflow of the developers and the Bugmeister. Including, but not
>> limited to:
>> - Platform (Hardware/OS)
>> - See also
>> - Web browser
>> - URL
>> These are rarely used and can just be put in the comments. Maybe URL is a 
>> nice
>> one to have aggregated to the top of the bug view. But even then it is 
>> limited
>> to a single url only (and has no label). Should still have a comment, so 
>> might
> 
> URL is nice and used more on the Site request type bugs, I also find
> that it being limited to one url is =(, I know there is the See Also
> field, but for some reasons the BZ devs have decided this should be
> locked to support certain urls only (Unless they have changed their
> view since the last time I went diving in the BZ BZ)

Well, one doesn't need a URL field to link to the local discussion.
One can just put that in a comment. Which many do (even in Site requests).

-- Krinkle


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[K. Peachey]

On Mon, May 14, 2012 at 12:55 PM, Krinkle  wrote:
> I'm convinced all other fields can be done without and removing them will
> improve the workflow of the developers and the Bugmeister. Including, but not
> limited to:
> - Platform (Hardware/OS)
> - See also
> - Web browser
> - URL
> These are rarely used and can just be put in the comments. Maybe URL is a nice
> one to have aggregated to the top of the bug view. But even then it is limited
> to a single url only (and has no label). Should still have a comment, so might

URL is nice and used more on the Site request type bugs, I also find
that it being limited to one url is =(, I know there is the See Also
field, but for some reasons the BZ devs have decided this should be
locked to support certain urls only (Unless they have changed their
view since the last time I went diving in the BZ BZ)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Reworking API help

[Kevin Israel]

While considering adding syntax highlighting to the format=jsonfm output
of the API, I noticed the hackishness of the current API help page
system[1] and started working on a replacement that generates a "[...] a
fully-HTML version of the help message"[2] while remaining
fully compatible with existing extensions.

I propose moving API help to a new special page Special:ApiHelp, which
would run a few preg_replace operations and then the parser on
individual portions of the documentation to format them as HTML. The
combined output for all modules would be cached in memcached as in the
old ApiHelp class.

Here are a few questions about the best way to implement this:

1. Some members of ApiBase I need access to are marked "protected", yet
   special pages have to subclass SpecialPage, not ApiBase. Which of
   these possible solutions is least hackish?

   (a) Generating the help page in an API module and then making
   an internal API request to execute that module when accessing
   the special page. The special page would show the result.

   (b) Internally calling action=paraminfo, individually requesting
   information on each API module to avoid encountering API limits.
   This would avoid duplicating lines 183-200 and 223-227 of
   includes/api/ApiParamInfo.php .

   (c) Adding an "allmodules" option to action=paraminfo, which would
   only be allowed for internal requests because I am unsure of how
   to cache the result.[3]
   This would have the same advantage as option (b).

2. In bug 26681[1], Sam Reed suggested moving ApiHelp out of core.
   I disagree. One of the main uses of the API is for coding bots
   and user scripts, which are a quicker and more convenient way to
   automate wiki processes than extensions that a server admin must
   install. Having accurate, easy-to-read documentation specific to
   the MediaWiki version and set of extensions is extremely useful
   when coding a bot or user script. So does API help really not
   belong in core?

3. Special:ApiHelp would need about ten CSS rules to display properly.
   Is creating a separate ResourceLoader module the norm in
   this situation?

4. To fit as many parameters on screen as possible, Special:ApiHelp
   would use a tabular layout similar to the current text-based output
   format. Is there any advantage to using definition lists over tables
   (or vice-versa), keeping in mind that CSS can style the definition
   list to appear in two columns?

5. Certain "tags" can apply to modules (i.e. "Read", "Write",
   "Must POST", "Can generate"), which will go in the module's heading.
   Therefore, I need to reduce the tags' font size to that of the
   body text similar to .editsection. Is there a good alternative to
   copying the .editsection code for each skin (or just using the
   percentages for Vector), given the limitations of CSS?

I would greatly appreciate your input.

[1]: https://bugzilla.wikimedia.org/show_bug.cgi?id=26681
[2]: quoted from includes/api/ApiFormatBase.php
[3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=26680

-- 
Wikipedia user PleaseStand
http://en.wikipedia.org/wiki/User:PleaseStand

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bugzilla Weekly Report

[reporter]

MediaWiki Bugzilla Report for May 07, 2012 - May 14, 2012

Status changes this week

Bugs NEW   :  575 
Bugs ASSIGNED  :  32  
Bugs REOPENED  :  77  
Bugs RESOLVED  :  231 

Total bugs still open: 7778

Resolutions for the week:

Bugs marked FIXED  :  160 
Bugs marked REMIND :  0   
Bugs marked INVALID:  19  
Bugs marked DUPLICATE  :  35  
Bugs marked WONTFIX:  5   
Bugs marked WORKSFORME :  10  
Bugs marked LATER  :  2   
Bugs marked MOVED  :  0   

Specific Product/Component Resolutions & User Metrics 

New Bugs Per Component

ArticleFeedbackv5   13  
PageTriage  11  
Site requests   10  
Translate   9   
MobileFrontend  9   

New Bugs Per Product

MediaWiki   31  
Wikimedia   18  
MediaWiki extensions80  
Wikimedia Mobile3   
Wikimedia Labs  7   

Top 5 Bug Resolvers

sam [AT] reedyboy.net   37  
jrobson [AT] wikimedia.org  24  
reha [AT] omniti.com18  
krinklemail [AT] gmail.com  12  
s.mazeland [AT] xs4all.nl   9   


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Inline styles trouble on the mobile site

[Krinkle]

On May 11, 2012, at 11:17 AM, Tei wrote:

> On 11 May 2012 10:24, Ryan Kaldari  wrote:
>> What about this idea: We could introduce a new CSS class called 'nomobile'
>> that functioned similarly to 'noprint' — any element set to this class would
>> be hidden completely on mobile devices. If someone noticed a problem with a
>> specific template on mobile devices, they could either fix the template or
>> set it to 'nomobile'. This would make template creators aware of the problem
>> and give them an incentive to fix their inline styles.
> 
> 
> http://www.stuffandnonsense.co.uk/archives/images/specificitywars-05v2.jpg
> 
> I think theres a limitation to that,   ".nomobile  .darthvader
> .darthvader"   will not work as expected (I think)
> 

As far as CSS is concerned this will work just fine. Due to a logic error in 
the mobile site specifically it can fail sometimes. But CSS has no such bug or 
limitation, and in MediaWiki it will work just fine.

Not sure how that link is relevant..

-- Krinkle


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Krinkle]

TL;DR: Reduce number of fields in our BugZilla. Simplify access to search 
filters.

See also https://www.mediawiki.org/wiki/Bugzilla which covers a fair bit for
newbies. Doesn't make BugZilla better, but it does offer a guide for new users.

Regarding target audience. I think it is fair to say that our Bugzilla is
primarily intended for developers (be it staff developers, volunteer
contributors developing core and/or extensions, or other interested tech-savvy
users who are an editor on a MediaWiki-powered site or maybe own their own
MediaWiki site). Not readers or editors of MediaWiki sites themselves,
directly.

MediaWiki sites (e.g. English Wikipedia, or your-wiki.example.org) have a local
place for feedback. For Wikimedia wikis, this local place for feedback would be
the village pump. Or maybe a generic feedback tool. Not BugZilla.

I don't think the issue tracker that developers use should be designed so that a
reader can figure out that a spelling mistake should be reported/fixed on
translatewiki, or that a bug in the watchlist should be reported on "MediaWiki
core > Watchlist", or that a feature request for whatever aborted his edit
should be filed under "MediaWiki extensions > AbuseFilter". Readers are best
leaving comments in a discussion forum. And users can help each other figure out
whether there is a way already or maybe the user did something wrong.

Anyone participating in a local discussion environment who feels technically
responsible for the site (site-admins) or are tech-savvy community members
(basically anyone who would know what a MediaWiki extension is and understand
Special:Version's content).. those detect "bugs" and "feature request" when they
appear in local fora and they report them upstream to the software bug tracker.

Don't get me wrong though, I agree completely that BugZilla feels like a
complete hack in the front end. Even for those that are the primary intended
audience (anyone who knows which product/component may be relevant and what a
bug report should contain), it is still an unusable nightmare in many aspects.
And even for those that aren't the primary intended users of the bug tracker, to
outside users it should still be easy to follow and understand the progress,
without necessarily knowing how or wanting to participate. And currently neither
is easy in BugZilla.

For the developer/Bugzilla side of issue tracking, one of the main problem with
Bugzilla infrastructure is in my opinion its complexity and over-organization of
meta data[1]. I think the only fields we need as key/value pairs are:
- Component
- Title
- Assignee
- Target Milestone
- Keywords
- Dependency tree

And of course general timeline items like attachments, comments, overal
open/close status and CC. And considering the large scope of our Bugzilla
install, the component category ("Product") may also be justified. And the
voting system can be used to prevent the useless +1 comments.

Assignee should be empty by default, only set when going to be worked on.
Current "Default assignee" should in most cases be default CC. Then we won't
need status "ASSIGNED" anymore (which is currently often forgotten, but due to
the "default assignee" stuff, one can often not see whether it's really on
someone's list).

I'm convinced all other fields can be done without and removing them will
improve the workflow of the developers and the Bugmeister. Including, but not
limited to:
- Platform (Hardware/OS)
- See also
- Web browser
- URL
These are rarely used and can just be put in the comments. Maybe URL is a nice
one to have aggregated to the top of the bug view. But even then it is limited
to a single url only (and has no label). Should still have a comment, so might
as well not have that field.
- Priority
- Severity
Use milestones and keywords instead ("MediaWiki 1.20.0 release",
"code-update-regression", ..) Those are more descriptive and easy to track and
understand. The only useful key-value of those is "severity: enhancement" to
distinguish between a bug and an improvement, but we can just use a keyword for
that.
- Close values (RESOLVED, FIXED, WORKSFORME, VERIFIED, DUPLICATE, ...)
Close reason and addendums (like "verified") can be put in comments. Plain
Open/Close is all we need.

Check out this presentation by Zach Holman (from GitHub) "How GitHub uses
GithHub to build GitHub". It is about how they work internally at GitHub (and a
bit about how GitHub helps them to do that, but it could be "How Wikimedia uses
[Code review, MediaWiki.org, Mailing lists, Bugzilla] to build MediaWiki" :D). 
* Video: http://zachholman.com/talk/how-github-uses-github-to-build-github
Specifically the section about Issues (slide 55 and on):
*
https://speakerdeck.com/u/holman/p/how-github-uses-github-to-build-github?slide=55

Note that the navigation portal[2] I recently created for BugZilla (mostly for
my own use, but you may find it useful too), encourages the above workflow. All
that matters there is the product, milestone and wheth

Re: [Wikitech-l] Problem with CSS Janus License

[Stephen John Smoogen]

On 13 May 2012 06:36, Platonides  wrote:
> On 12/05/12 00:18, Stephen John Smoogen wrote:
>> While the license sounds like it is "Public Domain" that can cause
>> problems in various places. Also in trying to find the code that is
>> referenced.. (snook.ca) I could not find a copy to see what its
>> license was. The second site doesn't recommend that code anymore but
>> recommends a GPL2+ updated version.
>
> It looks more like WTFPL with attribution clause.
> I don't see why such license would be a problem.
>

As far as I know it is not a problem if it is clear. It is when the
license isn't clear that it can become a problem.. especially when the
author put one thing down and meant something else. It may only occur
in 100 times, but that become more problems than being clear in the
first place.



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me."  —James Stewart as Elwood P. Dowd

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visual watchlist

[Aaron Pramana]

Risker  gmail.com> writes:
> 
> Just to give our GSoC participant a bit of a heads up, a fairly routine
> change that was made to watchlists on Enwp a few days ago (and has been
> implemented fairly widely on other projects) created a disproportionate
> amount of confusion and reaction.[1]
> 
> It might be a good idea to mine the thread linked below and co-opt multiple
> users in that thread to act as beta testers for the proposed improvements.
> Oh, and it reminds us that changes to the common.css should be tested on
> multiple skins.
> 
> Looking forward to seeing the end result!
> 
> Risker/Anne
> 
> [1]  non-permanent link:  <
> 
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Watchlist_-
_bold_letter_article_titles.21
> >
> 

Thanks for the advice! I'm going to post a prioritized feature/fix list and put 
out a call for testers shortly.




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r115370]: New comment added, and revision status changed

[MediaWiki Mail]

"Krinkle" changed the status of MediaWiki.r115370 to "ok" and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115370#c32800

Old Status: new
New Status: ok

Commit summary for MediaWiki.r115370:

r115369: Ignore new key for Translatewiki.net

Krinkle's comment:

Thx

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r115369]: Revision status changed

[MediaWiki Mail]

"Krinkle" changed the status of MediaWiki.r115369 to "deferred"
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/115369

Old status:  new
New status: deferred

Commit summary for MediaWiki.r115369:

Mwsnapshots: i18n update

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Redirect rules & ShortURL deployment - need to make a decision

[Yuvi Panda]

The routing code has been merged in. Thanks Dantman!

On Tue, May 8, 2012 at 1:34 PM, Yuvi Panda  wrote:
> Update: Daniel's comments at
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36164 have been
> incorporated into the extension in
> https://gerrit.wikimedia.org/r/#/c/6728/, which is awaiting review.
> Hopefully someone can find a bit of time to review it and the
> deployment process can be started again! :)
>
> On Sat, Apr 21, 2012 at 12:04 AM, Asher Feldman  
> wrote:
>> On Fri, Apr 20, 2012 at 8:01 AM, Mark A. Hershberger 
>> wrote:
>>
>>> Sumana Harihareswara  writes:
>>>
>>> > Please leave your comments at bug 1450 so we can decide how to write
>>> > the rewrite rule.
>>>
>>> Since Gerrit makes review possible and the relevant Apache config
>>> (redirects.conf) is on noc and *should* be in git, I've gone ahead and
>>> (after discussing how to proceed with Ops) submitted a configuration to
>>> Gerrit: https://gerrit.wikimedia.org/r/5433
>>>
>>
>> I had to give this a -2 since the rewrite rule was broken and we don't
>> deploy application configs tied to mediawiki via puppet or currently plan
>> to do so.  For that reason, I don't want this stuff dumped ad-hoc in the
>> puppet repo (the reason for the -2.)  The change itself is straight
>> forward, I just have one follow-up question about scope which I'll ask over
>> at the ticket.
>>
>> -A
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Yuvi Panda T
> http://yuvi.in/blog



-- 
Yuvi Panda T
http://yuvi.in/blog

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visual watchlist

[Risker]

On 13 May 2012 11:38, Arun Ganesh  wrote:

> >
> >
> > From: Aaron Pramana 
> >
> To: wikitech-l@lists.wikimedia.org
> >
> Subject: Re: [Wikitech-l] Visual watchlist
> >
> Message-ID: 
> >
> Content-Type: text/plain; charset=utf-8
> >
> Thanks again for your feedback - my GSoC project page is available here and
> > I'd
> >
> appreciate any feedback you have:
> >
>
> http://www.mediawiki.org/wiki/User:Blackjack48/GSOC_proposal_for_watchlist_impro
> >
> vements
> >
>
> > I will incorporate your suggestions into my project within the next few
> > days.
> >
>
> Thanks Amir. Aaron, that is awesome, I'd be happy to help you out with the
> visual design and css.
>


Just to give our GSoC participant a bit of a heads up, a fairly routine
change that was made to watchlists on Enwp a few days ago (and has been
implemented fairly widely on other projects) created a disproportionate
amount of confusion and reaction.[1]

It might be a good idea to mine the thread linked below and co-opt multiple
users in that thread to act as beta testers for the proposed improvements.
Oh, and it reminds us that changes to the common.css should be tested on
multiple skins.

Looking forward to seeing the end result!

Risker/Anne




[1]  non-permanent link:  <
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Watchlist_-_bold_letter_article_titles.21
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Helder Wiki]

On Sun, May 13, 2012 at 2:23 PM, phoebe ayers  wrote:
> If there's any way to tie the login to SUL that would be cool, but
> just providing more explanatory messages would be helpful!
This would be
https://bugzilla.wikimedia.org/show_bug.cgi?id=29853
which is a duplicate of
https://bugzilla.wikimedia.org/show_bug.cgi?id=27852

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[phoebe ayers]

On Sun, May 13, 2012 at 9:26 AM, Platonides  wrote:
> On 12/05/12 18:17, David Gerard wrote:
>> Discussion on Oliver Keyes' blog:
>>
>>     http://quominus.org/archives/714
>>
>> He's coming from the perspective of liaison with newbies. Read the comments.
>
> I have to say it's the first time I met him.
>
> I'll try to summarise his points below with my comments:
>
> 1a) The steps are not clear.
>
> Solution: Make the "Enter a new bug report" link of
> https://bugzilla.wikimedia.org/ much bigger.
>
> The intermediate page asking you to login is not "cool", but I think
> that's a clear enough path.
>
>
> 1b) There's no indication that your login is your email.
>
> Granted. This can be confusing. Specially for the perspective of a
> mediawiki user.
> The only positive point might be that, if you have recently registered,
> you probably remember that your email is your login.
>
> The email sent by bugzilla does help, although it isn't explicit, either:
>> To use the wonders of Bugzilla, you can use the following:
>>
>>  E-mail address: platoni...@gmail.com
>>        Password: HPqd4NwIu
>
> Proposal: Add a message at the front page noting that you need a
> different login for bugzilla, that it is our email, and it'll be
> publicly visible.

+1. This is probably the biggest problem I have using bugzilla as an
occasional, non-technical user :)

If there's any way to tie the login to SUL that would be cool, but
just providing more explanatory messages would be helpful!

-- phoebe

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Platonides]

On 12/05/12 18:17, David Gerard wrote:
> Discussion on Oliver Keyes' blog:
> 
> http://quominus.org/archives/714
> 
> He's coming from the perspective of liaison with newbies. Read the comments.

I have to say it's the first time I met him.

I'll try to summarise his points below with my comments:

1a) The steps are not clear.

Solution: Make the "Enter a new bug report" link of
https://bugzilla.wikimedia.org/ much bigger.

The intermediate page asking you to login is not "cool", but I think
that's a clear enough path.


1b) There's no indication that your login is your email.

Granted. This can be confusing. Specially for the perspective of a
mediawiki user.
The only positive point might be that, if you have recently registered,
you probably remember that your email is your login.

The email sent by bugzilla does help, although it isn't explicit, either:
> To use the wonders of Bugzilla, you can use the following:
> 
>  E-mail address: platoni...@gmail.com
>Password: HPqd4NwIu

Proposal: Add a message at the front page noting that you need a
different login for bugzilla, that it is our email, and it'll be
publicly visible.


2) You need to know the components where to file the bug.
Yes, it can be confusing.
Add a Generic group from where they should be refiled into the
appropiate component?


3a) Bugzilla status keywords are confusing.
Indeed they are. Those closing the bug should provide a justification
message suitable for everyone, though.


3b) There's no threading in the bugs
Valid, although not too important for the common bug.

3c) It is in ascending order by date
NOTABUG :)
Top-posting is bad. It would be crazy to read the bug reports backwards.
I don't oppose to an option to show them in reverse order, though.

I also like how we have our bugzilla configured with the comment box in
the bottom, ie. where the new comment will be added, and just below the
last comment.


[4] He provided no step 4, so I'm adding another problem for naive
reporting not listed there: all bugzilla communication is in English.


5a) Bugzilla is not used to discuss fixing the bug but for discussing
where it appears.

The first step is always determining what needs to be fixed and how to
reproduce it. The how to do it is usually straightforward and doesn't
require discussion, although it is sometimes there (moreover, that
newbie reporter wouldn't understand them anyway, I expect him to think
"you're the developers, just fix it").


5b) watching these threads usually provides me with very little
information about what is happening with the bug, who is dealing with
it, what the proposed ETA is, whether it will be deployed now or rolled
into the next MediaWiki release, so on and so forth

Who says that anyone would do it? :)
Consider it won't be done until, someone says "fixed here".
Alternatively, if a developer is asking many quesitons about it, he may
be considering to fix it.
Time of deployment is usually on next deployment, which should be very
easy with the planned new two-week deployments.
https://blog.wikimedia.org/2012/04/12/mediawiki-1-20wmf1-deployment/

It used to be harder, like needing you to know the revision number and
the branch point of next release.

5c) real conversation happens elsewhere...
What makes you think there's any conversation at all?
I don't think there's much discussion needed on most bugs.

You should just wait until there's a message like "it's done here" in
bugzilla. Then there might be later objections at gerrit, though, which
may drift the conversation to a different site.


What may be harder and needing extra skills would be to actually bug the
right person convincing them to implement a fix for that little bug that
really annoys you.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[Helder Wiki]

On Sat, May 12, 2012 at 3:40 PM, MZMcBride  wrote:
> My notes on a better approach to this problem are here:
> . There are associated bugs
> scattered around as well.

For the record, the script
https://en.wikipedia.org/wiki/MediaWiki:Wikibugs.js
was updated on other wikis but still needs to be updated on enwiki:
https://en.wikipedia.org/w/index.php?diff=prev&oldid=479666994

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Visual watchlist

[Arun Ganesh]

>
>
> From: Aaron Pramana 
>
To: wikitech-l@lists.wikimedia.org
>
Subject: Re: [Wikitech-l] Visual watchlist
>
Message-ID: 
>
Content-Type: text/plain; charset=utf-8
>
Thanks again for your feedback - my GSoC project page is available here and
> I'd
>
appreciate any feedback you have:
>
http://www.mediawiki.org/wiki/User:Blackjack48/GSOC_proposal_for_watchlist_impro
>
vements
>

> I will incorporate your suggestions into my project within the next few
> days.
>

Thanks Amir. Aaron, that is awesome, I'd be happy to help you out with the
visual design and css.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] The bugtracker problem, again

[MZMcBride]

Steven Walling wrote:
> Moodbar was not built to be a general purpose issue reporting tool. And
> definitely not something that could or should replace an issue tracker. It
> is designed only for asking newcomers whether they are having a generally
> positive or negative experience and why, so that we could get an overall
> read on the mood of new editors. Either outcome could in fact be the
> product of totally normal experiences on Wikipedia.
> 
> As for the "colorful faces" you seem to dislike, well, it wasn't designed
> with your demographic in mind. To date hundreds of editors are not only
> successfully reporting issues, they're getting responses from other
> editors: https://toolserver.org/~dartar/fd/

I'm not following you (and I'm not sure you're following me). Wikimedia's
response to the "gather user feedback regarding the site" issue has been
MoodBar, which, regardless of the demographic I happen to sit in, looks
ridiculous. I can find a number of people from other demographics who agree.

You write that MoodBar wasn't built to be a general purpose issue reporting
tool. But you also write that hundreds of editors are successfully reporting
issues and receiving responses from other editors. Something isn't aligning
here.

As I said, a generic reusable feedback tool that doesn't treat our users
like retards would be cool. MoodBar _might_ be version 0.1 of this concept,
but it needs a lot of work.

MZMcBride



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Problem with CSS Janus License

[Platonides]

On 12/05/12 00:18, Stephen John Smoogen wrote:
> Also in trying to find the code that is
> referenced.. (snook.ca) I could not find a copy to see what its
> license was. The second site doesn't recommend that code anymore but
> recommends a GPL2+ updated version.

I see http://snook.ca/archives/javascript/your_favourite_1
and http://snook.ca/archives/quick_links/quick_link_the_1 refering to
Robert Nyman changes at
http://robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/

Then we added a number of changes ourselves.



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Problem with CSS Janus License

[Platonides]

On 12/05/12 00:18, Stephen John Smoogen wrote:
> While the license sounds like it is "Public Domain" that can cause
> problems in various places. Also in trying to find the code that is
> referenced.. (snook.ca) I could not find a copy to see what its
> license was. The second site doesn't recommend that code anymore but
> recommends a GPL2+ updated version.

It looks more like WTFPL with attribution clause.
I don't see why such license would be a problem.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [pywikipedia r10208]: Revision status changed

[MediaWiki Mail]

"Xqt" changed the status of pywikipedia.r10208 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10208

Old status:  new
New status: ok

Commit summary for pywikipedia.r10208:

bug #3526155: also support transliteration_target='None'

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [pywikipedia r10206]: Revision status changed

[MediaWiki Mail]

"Xqt" changed the status of pywikipedia.r10206 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10206

Old status:  new
New status: ok

Commit summary for pywikipedia.r10206:

If pywikibot.verbose is set, print full exception tracebacks on unexpected 
network Exceptions (e.g. UnicodeDecodeErrors)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [pywikipedia r10207]: Revision status changed

[MediaWiki Mail]

"Xqt" changed the status of pywikipedia.r10207 to "ok"
URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10207

Old status:  new
New status: ok

Commit summary for pywikipedia.r10207:

Localisation updates from http://translatewiki.net.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview