Re: [Wikitech-l] Preparing concise, readable release notes for 1.21
Robla wrote:
I'm sure all of those hooks have a corresponding extension that needs
the new hook.
Right! (Kudos to iAlex for creating all those pages.)
However, most extension pages don't have updated lists of used hooks, so
WhatLinksHere doesn't help.
I suspect it might be easier (!) to check the MediaWiki release
requirement in the extension infobox: maybe {{Extension}} could be
changed so that it autocategorizes by required release?
Maybe if there's a central updated location where to look for such
information users will start using it and devs will think it's worth
spending a few minutes to update the docs.
A for hooks, I've seen people removing them (as well as |parameters= and
|rights= ) from extension pages because it's too tedious to update them,
they change too much and devs can already find them easily in the code.
I think they're all registered in a standard way, so a bot could be
written to update extension pages regularly; it would be very useful.
Nemo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Creating custom skin based on Vector in MediaWiki 1.20
Hi!
Some year ago, I used to create Vector-based skin with redesigned layout (very
different positions of sidebar and action links) in MW 1.17 from scratch, via
copying all of Vector subtree and modifying it, then adding my skin resources
into Resources.php. It worked, but was a lot of work, including core patching.
Now I work with 1.20 and there's an article written by Daniel Friesen on how to
create Vector-derived skins without modifying Resources.php and using Vector
classes and styles as a base. So I do not have to modify the core and to copy
the whole skin subtree:
http://blog.redwerks.org/2012/02/28/mediawiki-subskin-tutorial/
I mostly followed the instructions in the guide. However my skin also changes
skin execute() method, because not just css and quite a lot of layout is
changed. execute() works fine.
I need to override a lot of Vector's css, located in 'skins.vector' resource
module.
But the following code:
/**
* @param $out OutputPage object
*/
function setupSkinUserCss( OutputPage $out ){
parent::setupSkinUserCss( $out );
$out-addModuleStyles( skins.artmuseum );
}
causes 'skins.vector' styles to be loaded after my 'skins.artmuseum' styles.
So, the Vector styles are not overwritten by my skin styles.
Changing the order does not help:
function setupSkinUserCss( OutputPage $out ){
$out-addModuleStyles( skins.artmuseum );
parent::setupSkinUserCss( $out );
}
ResourceLoader has 'dependencies' key to make resource automatically be
dependent on another resource:
$wgResourceModules['skins.artmuseum'] = array(
'styles' = array(
'artmuseum/screen.css' = array( 'media' = 'screen' ),
),
'remoteBasePath' = $GLOBALS['wgStylePath'],
'localBasePath' = $GLOBALS['wgStyleDirectory'],
'dependencies' = 'skin.vector'
);
However, 'skin.vector' module includes both styles and scripts. And
setupSkinUserCss() adds styles only. So 'dependencies' did not help, vector
styles are loaded later, anyway. What can I do with that?
Also, I need to load remote google webfonts. Does ResourceLoader support this
or I have to use old-fashionated methods of OutputPage() ?
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] editing channels - How was this edit made?
Hi, In the Bangalore DevCamp I spoke a bit with Brion about a way to measure various ways of editing MediaWiki pages. The original idea was to measure how much the mobile editing, when it becomes widely available, is actually used. A simplistic solution would be add a boolean rev_mobile field to the revision table, but this can apply to a lot of other things, for example: * Visual Editor vs. the current wiki-syntax editor * A usual browser vs. AutoWikiBrowser vs. direct API calls * bots vs. non-bots * for file uploads, Special:Upload vs. Special:UploadWizard Things get even more complicated, because several such flags may apply at once: for example, I can imagine a human editor using a mobile editing interface with a bot flag, because he makes a lot of tiny edits and the community doesn't want them to appear in RecentChanges. And of course, there may be privacy and performance implications, too. Nevertheless, some kind of metrics of the various contributions channels would be useful. Any more ideas? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Release notes updating
Hi, At https://gerrit.wikimedia.org/r/#/c/33163/ TheDJ commented that I should have updated the release notes. At another commit I made once (forgot which one) somebody commented that I shouldn't have updated the release notes and that this should only be done by the release manager, because this helps avoid merge conflicts and because the release manager has better judgment about which issues are important enough to be mentioned there. So should I or shouldn't I update them? I remember a couple of attempts to discuss it, but I don't remember a decision. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Mon, 2012-11-05 at 14:25 -0800, Quim Gil wrote: What about removing the LATER resolution from our Bugzilla? Picking this up again. Reading the postings again I mostly see support for dropping RESOLVED LATER. Daniel uses this for tickets whose solution is out of our control. As mentioned they could be marked via using the upstream keyword (preferably with an upstream tracking URL in the See Also field) in combination with the upstream keyword. Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets. * we need to actively discourage the use of RESOLVED LATER for tickets recently marked as such, and point to this thread. Help welcome. * we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome. Once no RESOLVED LATER tickets remain, I can remove the resolution. Silence means approval. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Enable Page View Statistic
Hi All I found that on Gujarati Wikipedia there is no page view statistic. So please enable that features and also give us data of How many hits per day or per month on Gujarati Wikipedia. Thanks in advance Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] a source repo for Extension:MathJax
Hi, In the Bangalore DevCamp I worked with Aditya Ravi Shankar on resolving Bug 35038 - Make MathJax menus translatable. It was mostly a success, but where should we commit the changes? Somewhat surprisingly, most of the changes will be needed in the MediaWiki extension code and not in the upstream library's repo. But apparently, the MathJax extension is not in Gerrit - its files must be downloaded from an obscure external site. Is there any reason not to setup a Gerrit extension for it? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Release notes updating
On Tue, Nov 13, 2012 at 3:26 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: At another commit I made once (forgot which one) somebody commented that I shouldn't have updated the release notes and that this should only be done by the release manager, because this helps avoid merge conflicts and because the release manager has better judgment about which issues are important enough to be mentioned there. You *should* update release notes. This statement about having the release manager do all release notes is incorrect. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Enable Page View Statistic
On Tue, Nov 13, 2012 at 4:21 AM, Harsh Kothari harshkothari...@gmail.com wrote: Hi All I found that on Gujarati Wikipedia there is no page view statistic. So please enable that features and also give us data of How many hits per day or per month on Gujarati Wikipedia. We do not use the built-in MediaWiki page view statistics because they do not work when you've got Squid or other caching in front of MediaWiki. For statistics on this and other topics, please see http://stats.wikimedia.org/ -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Enable Page View Statistic
Hi Chad Thanks for sharing this info. Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. On 13-Nov-2012, at 7:43 PM, Chad wrote: On Tue, Nov 13, 2012 at 4:21 AM, Harsh Kothari harshkothari...@gmail.com wrote: Hi All I found that on Gujarati Wikipedia there is no page view statistic. So please enable that features and also give us data of How many hits per day or per month on Gujarati Wikipedia. We do not use the built-in MediaWiki page view statistics because they do not work when you've got Squid or other caching in front of MediaWiki. For statistics on this and other topics, please see http://stats.wikimedia.org/ -Chad ___ 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
Re: [Wikitech-l] a source repo for Extension:MathJax
On Tue, Nov 13, 2012 at 6:03 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Somewhat surprisingly, most of the changes will be needed in the MediaWiki extension code and not in the upstream library's repo. But apparently, the MathJax extension is not in Gerrit - its files must be downloaded from an obscure external site. I'm not entirely sure I understand. If it's customization for the extension, shouldn't it go in the Math[0] extension? If it's actual changes to MathJax, it should be contributed upstream (which isn't a random site really, it's on Github[1]). -Chad [0] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Math.git [1] https://github.com/mathjax/MathJax ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] a source repo for Extension:MathJax
2012/11/13 Chad innocentkil...@gmail.com: On Tue, Nov 13, 2012 at 6:03 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Somewhat surprisingly, most of the changes will be needed in the MediaWiki extension code and not in the upstream library's repo. But apparently, the MathJax extension is not in Gerrit - its files must be downloaded from an obscure external site. I'm not entirely sure I understand. If it's customization for the extension, shouldn't it go in the Math[0] extension? Maybe, although I'm not completely sure what is the dependency between the Math MW extension and the MathJax MW extension. If I understand correctly, Math must be installed for the MathJax preference to work, but I don't know what other dependencies are there. If it's actual changes to MathJax, it should be contributed upstream (which isn't a random site really, it's on Github[1]). GitHub hosts the JavaScript code for core MathJax JS library. I am referring to the PHP code of the MW extension at http://people.cs.kuleuven.be/~dirk.nuyens/Extension_MathJax/ -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] editing channels - How was this edit made?
Dario has been proposing RevTagging to exactly address this need, see: http://www.mediawiki.org/wiki/Revtagging I really think we should put this on the roadmap for 2013 for Mediawiki, we definitely need this more granular level of instrumentation for determining the source of an edit. Best Diederik On Tue, Nov 13, 2012 at 6:19 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: Hi, In the Bangalore DevCamp I spoke a bit with Brion about a way to measure various ways of editing MediaWiki pages. The original idea was to measure how much the mobile editing, when it becomes widely available, is actually used. A simplistic solution would be add a boolean rev_mobile field to the revision table, but this can apply to a lot of other things, for example: * Visual Editor vs. the current wiki-syntax editor * A usual browser vs. AutoWikiBrowser vs. direct API calls * bots vs. non-bots * for file uploads, Special:Upload vs. Special:UploadWizard Things get even more complicated, because several such flags may apply at once: for example, I can imagine a human editor using a mobile editing interface with a bot flag, because he makes a lot of tiny edits and the community doesn't want them to appear in RecentChanges. And of course, there may be privacy and performance implications, too. Nevertheless, some kind of metrics of the various contributions channels would be useful. Any more ideas? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ 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
Re: [Wikitech-l] a source repo for Extension:MathJax
On 13 November 2012 15:47, Chad innocentkil...@gmail.com wrote: I'm not entirely sure I understand. If it's customization for the extension, shouldn't it go in the Math[0] extension? Note that the Math extension and the MathJax extension are two completely (?) unrelated MediaWiki extensions. See https://www.mediawiki.org/wiki/Extension:MathJax -- [[cs:User:Mormegil | Petr Kadlec]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] a source repo for Extension:MathJax
On Tue, Nov 13, 2012 at 7:00 AM, Petr Kadlec petr.kad...@gmail.com wrote: On 13 November 2012 15:47, Chad innocentkil...@gmail.com wrote: I'm not entirely sure I understand. If it's customization for the extension, shouldn't it go in the Math[0] extension? Note that the Math extension and the MathJax extension are two completely (?) unrelated MediaWiki extensions. See https://www.mediawiki.org/wiki/Extension:MathJax Indeed. We are not using [[Extension:MathJax]] at all. We use MathJax within [[Extension:Math]]. There is no relation between the two. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] a source repo for Extension:MathJax
2012/11/13 Chad innocentkil...@gmail.com: On Tue, Nov 13, 2012 at 7:00 AM, Petr Kadlec petr.kad...@gmail.com wrote: On 13 November 2012 15:47, Chad innocentkil...@gmail.com wrote: I'm not entirely sure I understand. If it's customization for the extension, shouldn't it go in the Math[0] extension? Note that the Math extension and the MathJax extension are two completely (?) unrelated MediaWiki extensions. See https://www.mediawiki.org/wiki/Extension:MathJax Indeed. We are not using [[Extension:MathJax]] at all. We use MathJax within [[Extension:Math]]. There is no relation between the two. That's the weird part - they are related, even though they are not related. The rendering engines are completely unrelated - E:Math has its own and E:MathJax loads the MathJax JS library from a CDN. The MW preferences seem to be related somehow - you need E:Math installed for the MathJax preference to work. But E:MathJax is not a part of the E:Math Gerrit repo. And I am trying to understand how to clear this up. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] a source repo for Extension:MathJax
On Tue, Nov 13, 2012 at 7:07 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: That's the weird part - they are related, even though they are not related. The rendering engines are completely unrelated - E:Math has its own and E:MathJax loads the MathJax JS library from a CDN. The MW preferences seem to be related somehow - you need E:Math installed for the MathJax preference to work. But E:MathJax is not a part of the E:Math Gerrit repo. And I am trying to understand how to clear this up. Easiest way to clear it up is pretend that [[Extension:MathJax]] doesn't even exist. We don't use it, and they're unrelated. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Release notes updating
On Tue, Nov 13, 2012 at 6:11 AM, Chad innocentkil...@gmail.com wrote: On Tue, Nov 13, 2012 at 3:26 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: At another commit I made once (forgot which one) somebody commented that I shouldn't have updated the release notes and that this should only be done by the release manager, because this helps avoid merge conflicts and because the release manager has better judgment about which issues are important enough to be mentioned there. You *should* update release notes. This statement about having the release manager do all release notes is incorrect. I've never heard that release manager claim either. The current word on release notes seems to be at https://www.mediawiki.org/wiki/CC#Release_notes, which says All significant changes to the core software which might affect wiki users, server administrators, or extension authors, must be documented in the RELEASE-NOTES file. I've been interpreting that as including pretty much any bug that was reported by a wiki user. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Release notes updating
On Tue, Nov 13, 2012 at 7:21 AM, Brad Jorsch bjor...@wikimedia.org wrote: On Tue, Nov 13, 2012 at 6:11 AM, Chad innocentkil...@gmail.com wrote: On Tue, Nov 13, 2012 at 3:26 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il wrote: At another commit I made once (forgot which one) somebody commented that I shouldn't have updated the release notes and that this should only be done by the release manager, because this helps avoid merge conflicts and because the release manager has better judgment about which issues are important enough to be mentioned there. You *should* update release notes. This statement about having the release manager do all release notes is incorrect. I've never heard that release manager claim either. The current word on release notes seems to be at https://www.mediawiki.org/wiki/CC#Release_notes, which says All significant changes to the core software which might affect wiki users, server administrators, or extension authors, must be documented in the RELEASE-NOTES file. I've been interpreting that as including pretty much any bug that was reported by a wiki user. Indeed. That's always been the case. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Nov 13, 2012 1:05 PM, Andre Klapper aklap...@wikimedia.org wrote: On Mon, 2012-11-05 at 14:25 -0800, Quim Gil wrote: What about removing the LATER resolution from our Bugzilla? Picking this up again. Reading the postings again I mostly see support for dropping RESOLVED LATER. Daniel uses this for tickets whose solution is out of our control. As mentioned they could be marked via using the upstream keyword (preferably with an upstream tracking URL in the See Also field) in combination with the upstream keyword. Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets. * we need to actively discourage the use of RESOLVED LATER for tickets recently marked as such, and point to this thread. Help welcome. * we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome. Once no RESOLVED LATER tickets remain, I can remove the resolution. Silence means approval. No it doesn't. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ 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
Re: [Wikitech-l] About RESOLVED LATER
Hi, trying to find the simplest path: On 11/13/2012 04:04 AM, Andre Klapper wrote: Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets. They will find out those queries return no results anymore. No harm done. * we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome. Since free time is a luxury, what about simply a bulk change TO NEW / LOWEST. I know it's not a perfect solution, but is a big improvement done fast. Then active teams and contributors (many of them receiving notifications for the changes) will fine tune each one of them. Or not, but this would mean that such reports would have been ignored anyway in your eventual call for volunteers. What I mean is that by doing a bulk change there is a potential for saving time, and no potential for wasting more time. * we need to actively discourage the use of RESOLVED LATER for tickets recently marked as such, and point to this thread. Help welcome. This can be easily implemented after the bulk change, by removing LATER altogether. Once no RESOLVED LATER tickets remain, I can remove the resolution. Another benefit of the bulk change is that quick transitions are better than long transitions. One alternative is to give people a week to change manually the resolution of LATER report, and then do the bulk change with the remaining ones. -- Quim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
2012/11/13 Quim Gil quim...@gmail.com: * we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome. Since free time is a luxury, what about simply a bulk change TO NEW / LOWEST. I know it's not a perfect solution, but is a big improvement done fast. Then active teams and contributors (many of them receiving notifications for the changes) will fine tune each one of them. Or not, but this would mean that such reports would have been ignored anyway in your eventual call for volunteers. I think somebody (or possibly a few somebodies with knowledge of different parts of the code) should at least quickly scan these lists, since some of the things marked as LATER might have been fixed in the meantime (and nobody found the bug to close, since it was RESOLVED) or have been made irrelevant (such as https://bugzilla.wikimedia.org/show_bug.cgi?id=34329 which I found skimming the list a few days ago). -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
* we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome. Since free time is a luxury, what about simply a bulk change TO NEW / LOWEST. I know it's not a perfect solution, but is a big improvement done fast. Then active teams and contributors (many of them receiving notifications for the changes) will fine tune each one of them. Or not, but this would mean that such reports would have been ignored anyway in your eventual call for volunteers. I think somebody (or possibly a few somebodies with knowledge of different parts of the code) should at least quickly scan these lists, since some of the things marked as LATER might have been fixed in the meantime (and nobody found the bug to close, since it was RESOLVED) or have been made irrelevant (such as https://bugzilla.wikimedia.org/show_bug.cgi?id=34329 which I found skimming the list a few days ago). A week provides ample time to do that. Although, I'm sure if there are disagreements on that length of time, another could easily be decided upon. Thank you, Derric Atzrott ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Tue, Nov 13, 2012 at 9:24 AM, Quim Gil quim...@gmail.com wrote: On 11/13/2012 04:04 AM, Andre Klapper wrote: Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets. They will find out those queries return no results anymore. No harm done. I apparently read this entirely differently than you: as written, that sounds more like community members need to adjust their Bugzilla queries to exclude LOWEST/UPSTREAM. At which point, why are we removing RESOLVED/LATER again? You're moving things from one bucket to another bucket, but doesn't actually raise visibility or alter how we think about the bugs. Nabil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On 11/13/2012 10:05 AM, Nabil Maynard wrote: On Tue, Nov 13, 2012 at 9:24 AM, Quim Gil quim...@gmail.com wrote: On 11/13/2012 04:04 AM, Andre Klapper wrote: Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets. They will find out those queries return no results anymore. No harm done. I apparently read this entirely differently than you: as written, that sounds more like community members need to adjust their Bugzilla queries to exclude LOWEST/UPSTREAM. At which point, why are we removing RESOLVED/LATER again? As explained: for clarity and for all those not doing specific queries to RESOLVED reports. NEW reports appear in search result s by default, RESOLVED reports not. You're moving things from one bucket to another bucket, but doesn't actually raise visibility or alter how we think about the bugs. As you see, it does raise visibility. Specially among newcomers, externals and casual contributors, who are good candidates to actually help pushing those bugs. -- Quim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On 11/13/2012 11:54 AM, Martijn Hoekstra wrote: Once no RESOLVED LATER tickets remain, I can remove the resolution. Silence means approval. No it doesn't. The above exchange really confuses me. I'm not sure what else silence could mean when someone explicitly tells you (as Andre has) If no one voices any objections, I'm going to do this. Could you clarify? And, if you think silence doesn't mean approval, wouldn't you be better served by speaking up an voicing your concerns? It certainly seems like you'd be better served by clearly stating your objection than by a terse reply such as you've given. Mark. -- http://hexmode.com/ Any time you have one overriding idea, and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Tue, Nov 13, 2012 at 2:01 PM, Mark A. Hershberger m...@everybody.orgwrote: On 11/13/2012 11:54 AM, Martijn Hoekstra wrote: Once no RESOLVED LATER tickets remain, I can remove the resolution. Silence means approval. No it doesn't. The above exchange really confuses me. I'm not sure what else silence could mean when someone explicitly tells you (as Andre has) If no one voices any objections, I'm going to do this. Could you clarify? And, if you think silence doesn't mean approval, wouldn't you be better served by speaking up an voicing your concerns? It certainly seems like you'd be better served by clearly stating your objection than by a terse reply such as you've given. Mark. Perhaps it should've been silence means acquiescence? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On 11/13/2012 02:07 PM, Nathan Larson wrote: On Tue, Nov 13, 2012 at 2:01 PM, Mark A. Hershberger m...@everybody.orgwrote: On 11/13/2012 11:54 AM, Martijn Hoekstra wrote: Silence means approval. No it doesn't. The above exchange really confuses me. Perhaps it should've been silence means acquiescence? Good point. It still has some negative connotations, though. Stick to single syllable words: If no one says anything, this is what I will do. -- http://hexmode.com/ Any time you have one overriding idea, and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Enable Page View Statistic
I'm working on this. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Tue, Nov 13, 2012 at 9:41 AM, Harsh Kothari harshkothari...@gmail.comwrote: Hi Chad Thanks for sharing this info. Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. On 13-Nov-2012, at 7:43 PM, Chad wrote: On Tue, Nov 13, 2012 at 4:21 AM, Harsh Kothari harshkothari...@gmail.com wrote: Hi All I found that on Gujarati Wikipedia there is no page view statistic. So please enable that features and also give us data of How many hits per day or per month on Gujarati Wikipedia. We do not use the built-in MediaWiki page view statistics because they do not work when you've got Squid or other caching in front of MediaWiki. For statistics on this and other topics, please see http://stats.wikimedia.org/ -Chad ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Tue, 2012-11-13 at 14:16 -0500, Mark A. Hershberger wrote: Good point. It still has some negative connotations, though. Stick to single syllable words: If no one says anything, this is what I will do. That's definitely a better wording of what I wanted to express, thanks. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Tue, 2012-11-13 at 14:16 -0500, Mark A. Hershberger wrote: Good point. It still has some negative connotations, though. Stick to single syllable words: If no one says anything, this is what I will do. That's definitely a better wording for what I wanted to express. Thanks. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Welcome Quim Gil to Engineering Community Team!
I am very happy to announce that tomorrow is Quim Gil's first day in the Engineering Community Team of the Wikimedia Foundation. His title is Technical Contributor Coordinator (IT Communications Manager) which means that he'll be reaching out to and nurturing our testers, coders, documenters, product managers, sysadmins, and other contributors to Wikimedia technologies like MediaWiki. His blog entry about coming to WMF: https://flors.wordpress.com/2012/08/27/moving-up-in-the-freedom-stack/ Quim is a contributor to Catalan Wikisource Wikipedia and English Wikipedia (User:Qgil), and has helped Wikimedia's mobile team as a volunteer. Most recently he's dug into statistical analysis of MediaWiki's coder community and the philosophical conundrum of RESOLVED:LATER. You might also know him from his activity in the worlds of GNOME, Qt, and Maemo -- he's coming to us from Nokia. If I try to detail all the consulting, event-running, volunteer recruiting, open source community management, writing, and projects he's done, I'll hit some kind of mailman limit so I won't try. :-) Quim lives in the Bay Area and will be working out of the San Francisco office while reporting to me remotely, which is kind of hilarious. In the near future he'll be encouraging volunteer testers and running our Outreach Program for Women. And tomorrow is Quim's birthday! So, happy birthday and welcome, Quim! -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Release notes updating
On Wed, Nov 14, 2012 at 1:21 AM, Brad Jorsch bjor...@wikimedia.org wrote: On Tue, Nov 13, 2012 at 6:11 AM, Chad innocentkil...@gmail.com wrote: You *should* update release notes. This statement about having the release manager do all release notes is incorrect. I've never heard that release manager claim either. It was from a discussion about the release notes after our change to git because it was conflicting too much or something of the likes, AFAIK that is what was decided but no one stuck to it and we reverted to where everyone does their own. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] editing channels - How was this edit made?
Diederik van Liere wrote: Dario has been proposing RevTagging to exactly address this need, see: https://www.mediawiki.org/wiki/Revtagging I really think we should put this on the roadmap for 2013 for Mediawiki, we definitely need this more granular level of instrumentation for determining the source of an edit. Please stop top-posting. If you don't understand what that means, please read https://wiki.toolserver.org/view/Mailing_list_etiquette. As I posted at https://www.mediawiki.org/wiki/Talk:Revtagging, it's not clear to me why the built-in revision tagging system in MediaWiki is insufficient for your needs. It _feels_ like wheel-reinvention, but perhaps there's some key component I'm missing. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Run a local tech training event - I can help you start
TL;DR: I'm encouraging volunteers and chapters to run local tech events -- I can help you get started. On 11/11/2012 12:42 AM, Erik Moeller wrote: Hi all, a reminder to chapters and volunteers around the world -- if you're planning a hackathon, please let us know beforehand by adding it to this page: https://www.mediawiki.org/wiki/MediaWiki_developer_meetings Consistent with Sue's recommendations to the Board, Wikimedia Foundation will spend less time organizing events on its own, and will more frequently send smaller groups to events organized around the world by the movement at large. But to do so we need to know what's coming up. :) Hackathons/DevCamps are a great way to help the movement. They can engage the existing volunteer developer commmunity, help expand it, bring together engineers with other Wikimedia practitioners, and create a focused space. We hope more folks around the world will take a role in hosting such developer events. If you would like WMF's thoughts and input, please feel free to ping Sumana (sumanah at wikimedia.org). All the best, Erik Thanks for starting this conversation, Erik. Yes, if you run a local tech training event, you can make the site better for your community -- including improving bots, templates and gadgets. And I can write and find tutorial resources for you, and likely get experienced developers to your event to teach. Noopur wrote: I know of two volunteers, Harsh and Sheel from India who have been keen to organize hackathons and help with localization. Sumana had offered to help us out and we realized that only links or information doesn't really help. So, we thought doing a Skype call where someone can walk people through the little details or answer specific questions would be great. Another thought, webcasting some such developer meets could also be great learning. Just thought I'd put this out because I am sure there are more Indian editors who would love to join in if there's such a call. Hope to see more hackathons and tech events soon :) I just had that call with Harsh and Sheel yesterday and they're on their way to planning initial devdays in their areas! Thanks, Noopur! Broadcasting these kinds of calls or having them more regularly is something I'd be interested in doing if volunteers tell me they want that. Live-streaming audio from hackathons is pretty difficult and costly to do well, so I've generally opted to concentrate on videotaping for later viewing and live notetaking/IRC participation instead. Here's how we're trying to be more effective at tech outreach and inreach events: Outreach: We have a regular engineering meetup night at headquarters (next one: January 17th), and we're continuing to encourage technologists to go to other meetups and conferences, like FOSDEM and JSConf, to learn, teach, and recruit. WMF staff can often get WMF to pay for their travel; volunteers can often get subsidies via https://meta.wikimedia.org/wiki/Participation:Support . And we're encouraging chapters and volunteers to organize hackdays for new volunteers, like Yuvi's been doing in south India, and as Harsh and Sheel are about to do! Inreach (meeting people who already contribute, helping them improve and hacking with them): WMF will continue to send staffers to the two big yearly Wikimedia tech meetings, one in the spring in Europe and one attached to Wikimania. In some cases we can sponsor volunteers to travel to those events; we sponsored a lot of volunteers to go to Berlin this past spring. We're also sending handfuls of staffers to smaller events organized by chapters, like the Wikimedia Netherlands hackathon last weekend, to collaborate with local Wikimedians. And the weekly online tech videochat is good for inreach - you can participate live or watch later. The next one is Thursday: https://www.mediawiki.org/wiki/Meetings/2012-11-15 Quim Gil (the new technical contributor coordinator at WMF) and I are encouraging chapters to run small regional events or trying to partner with existing events and groups. Here are the subjects, demographics, and geographies I particularly want to encourage via small events: Subjects: * Learning to write user scripts and gadgets * Moving bots to Labs * Commons curation and display tools, especially on mobile * Security training * Testing Echo * Testing usability on tablets * Rewriting templates in Lua Demographics: * Front-end developers (including gadgets user scripts) * Template writers maintainers * Women * Bot authors Locations: * Brazil (catalyst) * India (catalyst) * SF Bay Area (easy for staffers to get to) * Middle East North Africa (engineering talent, underrepresented in current tech community) * Hong Kong (underrepresented in current tech community, pre- and post-Wikimania opportunities) But please don't limit yourself to these ideas -- wherever you are and whatever you want to concentrate on, I'm happy to answer questions about this or to point you
Re: [Wikitech-l] Enable Page View Statistic
On Tue, Nov 13, 2012 at 4:21 AM, Harsh Kothari harshkothari...@gmail.com wrote: Hi All I found that on Gujarati Wikipedia there is no page view statistic. So please enable that features and also give us data of How many hits per day or per month on Gujarati Wikipedia. Also you may be interested in http://stats.grok.se/gu/top and http://stats.grok.se/gu/201012/%E0%AA%AE%E0%AB%81%E0%AA%96%E0%AA%AA%E0%AB%83%E0%AA%B7%E0%AB%8D%E0%AA%A0 (The interface doesn't work well in non-popular languages, so you have to make the urls by hand http://stats.grok.se/gu/yearmonth/pagename (with gu being the language code). Additionally a couple clicks in to the link Chad gave you gets to this page: http://stats.wikimedia.org/EN/SummaryGU.htm which has a graph of page views over time near the bottom. There are raw page view stats available at http://dumps.wikimedia.org/other/pagecounts-raw/ which one can filter/visualize/etc in whatever form is convenient (If you're into statistical stuff - requires some effort to get usable information). Hope that helps, -Bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Welcome Quim Gil to Engineering Community Team!
Welcome and Happy Birthday! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Open Tech Chat for Thursday, November 15
Hi everyone, Time once again for our weekly tech chat. Rather, Thursday is the time, because this week, I'm giving you *two whole days*[1] instead of the whopping hour notice that I gave you all last week. Full details here: https://www.mediawiki.org/wiki/Meetings/2012-11-15 For those too lazy to click, here are the essentials: * When: Thursday, 12:30pm PST (20:30 UTC) * Where: 6th floor + #wikimedia-dev + Google Hangout + YouTube This week, we have Saper presenting about Git and Gerrit tricks. Hope to see you there! Rob [1] Alright, technically, it's a little less than 44 hours, but that's still a lot better than last week, right? right?!? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Engineering] Welcome Quim Gil to Engineering Community Team!
Quim Gil's first day in the Engineering Community Team of the Wikimedia Foundation. Welcome and happy birthday, Quim! -- Gabriel Wicke Senior Software Developer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] On GitHub, rename wikimedia/mediawiki-core - wikimedia/mediawiki
The fact that mediawiki's repository is named mediawiki-core doesn't make sense to me. The chief benefit provided by GitHub is its popularity and visibility. We don't manage our code review or release process in GitHub anyway, so I see no reason not to give the most weight to aesthetic / populistic considerations. Let's make it github.com/wikimedia/mediawiki. Visibility helps! -- Ori Livneh o...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] On GitHub, rename wikimedia/mediawiki-core - wikimedia/mediawiki
On Tue, Nov 13, 2012 at 9:39 PM, Ori Livneh o...@wikimedia.org wrote: The fact that mediawiki's repository is named mediawiki-core doesn't make sense to me. The chief benefit provided by GitHub is its popularity and visibility. We don't manage our code review or release process in GitHub anyway, so I see no reason not to give the most weight to aesthetic / populistic considerations. Let's make it github.com/wikimedia/mediawiki. Visibility helps! This is not possible. Repos are the same name on the source and destination. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
