Re: [Wikitech-l] MediaWiki to Latex Converter
On 12/11/2013 01:36 AM, C. Scott Ananian wrote: Could you take a look at the attached PDF, generated from https://ml.wikipedia.org/wiki/%E0%B4%AE%E0%B4%B2%E0%B4%AF%E0%B4%BE%E0%B4%B3%E0%B4%82 with our not-yet-deployed new software? Any Malayam-specific feedback you could provide would be very useful. The output is very good. Did not notice any issues. The hyphenation in some languages should use non-visible hyphen characters. XeTeX allows customizing it(hyphenchar). In the specific case of Malayalam, people normally use U+200C for causing line break without visible hyphen. Thanks Santhosh ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MacOS (OSX) developers / tech people with mac needed for huggle packaging
I will ask other successful huggle 3 Mac users (these who actually wrote the guide on wiki) what else they do so that it works to them On Tue, Dec 10, 2013 at 6:21 PM, Ori Livneh o...@wikimedia.org wrote: On Tue, Dec 10, 2013 at 8:14 AM, Petr Bena benap...@gmail.com wrote: Hi, Huggle 3 is slowly getting near to first release, and I have yet set up some built environment for early beta versions. 1 for windows on one of my own windows boxens (using NSIS and MinGW) which I use to release beta version packages on sourceforge, and other one for linux using launchpad. So that both Windows and Linux users can easily get and install huggle packages with no need to understand how compiling works or any need to resolve any dependencies themselves. [1] Unfortunately, we have no such thing for MacOS, not just because neither me or any other current huggle dev owns a Mac, but also because there is no free launchpad like service for mac's I know of. So, if someone of you has enough experience with packaging software for Macs and wants to help with huggle packaging for MacOS, let us know so that we can setup some build process for MacOS users as well. I hacked together a Homebrew formula: https://gist.github.com/atdt/7894375 But: brew install --HEAD huggle3 Warning: Your Xcode (4.6.3) is outdated Please update to Xcode 5.0.1. Xcode can be updated from the App Store. == Cloning https://github.com/huggle/huggle3-qt-lx.git Updating /Library/Caches/Homebrew/huggle3--git == ./configure --disable-silent-rules --prefix=/usr/local/Cellar/huggle3/HEAD == make exception.cpp: In instantiation of ‘std::basic_ostream_CharT, _Traits std::operator(std::basic_ostream_CharT, _Traits, const std::basic_string_CharT, _Traits, _Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]’: exception.cpp:17: instantiated from here exception.cpp:17: error: explicit instantiation of ‘std::basic_ostream_CharT, _Traits std::operator(std::basic_ostream_CharT, _Traits, const std::basic_string_CharT, _Traits, _Alloc) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]’ but no definition available make: *** [exception.o] Error 1 make: *** Waiting for unfinished jobs ___ 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] Patrolling on english wikipedia
The basic idea is to filter out * Suspicious edits (edits that looks like the vandalism but person who reviews them doesn't know for sure and needs more attention by others) * Good edits (edits that can be surely ignored by others so that people who deal with vandalism have less work and don't do double work reviewing same data) Using thank you feature doesn't really make it easy for others to figure out if edit was ever processed by that feature / flagged as good On Tue, Dec 10, 2013 at 7:05 PM, Isarra Yos zhoris...@gmail.com wrote: On 10/12/13 13:40, Petr Bena wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? What about using the thank feature for good edits? -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] Patrolling on english wikipedia
Can you even read them by api? I know these may be part of recent changes query, but huggle uses IRC feed for RC so the additional information about edits are retrieved using other api's. Is there any api that retrieve what tags are applied for an edit with certain RevID? On Tue, Dec 10, 2013 at 7:43 PM, Brian Wolff bawo...@gmail.com wrote: On 2013-12-10 11:05 AM, Isarra Yos zhoris...@gmail.com wrote: On 10/12/13 13:40, Petr Bena wrote: I was recently suggested by someone (and requested by someone else) to use patrolling on good edits in huggle, however after executing the patrol api query I receive this error: ?xml version=1.0?api servedby=mw1130error code=patroldisabled info=Patrolling is disabled on this wiki //api Is it true? Is patrolling really disabled on English wikipedia? It sounds to me very unlike, so is this a bug and different error message should have been displayed? What about using the thank feature for good edits? -L ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Really this seems the ideal use case for edit tags (the obvious problem is currently you can't set them by the api afaik) -bawolff ___ 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] API edit call in a maintenance script
El 10/12/13 00:33, Liangent ha escrit: On Tue, Dec 10, 2013 at 7:13 AM, Toni Hermoso Pulido toni...@cau.cat mailto:toni...@cau.cat wrote: Hello, I'm trying to perform an API edit call in a maintenance script using this example in MW 1.19.9 http://www.mediawiki.org/wiki/__API:Calling_internally http://www.mediawiki.org/wiki/API:Calling_internally $user = User::newFromId( 1 ); // Using WikiSysiop $page = WikiPage::newFromID( $id ); $titleText = $page-getTitle()-__getPrefixedText(); $text = ...; global $wgRequest; $req = new DerivativeRequest( $wgRequest, array( 'action' = 'edit', 'title' = $titleText, 'text' = $text, 'token' = $user-editToken(), ), true); $api = new ApiMain( $req, true ); $api-execute(); However, I get this problem: Unexpected non-MediaWiki exception encountered, of type UsageException badtoken: Invalid token Any idea what can be wrong? Token is not used to do user lookup. You need to call $api-getContext()-setUser( $user ); before $api-execute();. Hello Liangent, it does not seem to work. In the end, call seems to be performed as anonymous. In any case, I would continue sticked to doEdit, as Max pointed out. Thanks! -- Toni Hermoso Pulido http://www.cau.cat ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MacOS (OSX) developers / tech people with mac needed for huggle packaging
Le 10/12/13 18:21, Ori Livneh a écrit : I hacked together a Homebrew formula: https://gist.github.com/atdt/7894375 The make phase works for me using qt4. The make install phase bails out though: == make install ./build/install FATAL: You need to build huggle first make: *** [install] Error 1 == Configuration HOMEBREW_VERSION: 0.9.5 HEAD: 6429f350077250ae3a6565008a2bbb28bb3b8a1a CPU: quad-core 64-bit sandybridge OS X: 10.7.5-x86_64 Xcode: 4.6.3 CLT: 1.0.0.90.1.1249367152 X11: 2.6.5 = /usr/X11 ... Error: huggle3 did not build -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
Le 10/12/13 05:30, MZMcBride a écrit : I think adding an explicit HTML comment in the page source is a reasonable suggestion to consider. We already had an argument a few months ago regarding adding comments in the minified css/js and we said no. Who ever look at that source code will be able to find the unminified source. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MacOS (OSX) developers / tech people with mac needed for huggle packaging
Aye, I suppose I should implement some more options to configure script first, which are now missing, so some parameters are not passed to make install it seems to expect to run from directory where huggle was built On Wed, Dec 11, 2013 at 9:58 AM, Antoine Musso hashar+...@free.fr wrote: Le 10/12/13 18:21, Ori Livneh a écrit : I hacked together a Homebrew formula: https://gist.github.com/atdt/7894375 The make phase works for me using qt4. The make install phase bails out though: == make install ./build/install FATAL: You need to build huggle first make: *** [install] Error 1 == Configuration HOMEBREW_VERSION: 0.9.5 HEAD: 6429f350077250ae3a6565008a2bbb28bb3b8a1a CPU: quad-core 64-bit sandybridge OS X: 10.7.5-x86_64 Xcode: 4.6.3 CLT: 1.0.0.90.1.1249367152 X11: 2.6.5 = /usr/X11 ... Error: huggle3 did not build -- Antoine hashar Musso ___ 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] [Reminder] Language Engineering IRC Office Hour today December 11, 2013 at 1700 UTC
Hello, This is a reminder that the Wikimedia Language Engineering team will be hosting an IRC office hour from 1700 to 1800UTC later today on #wikimedia-office (FreeNode). Please see below for the event details. Thanks Runa === Event Details === What: WMF Language Engineering Office hour When: December 11, 2013 (Wednesday). 1700-1800 UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131211T1700 Where: IRC Channel #wikimedia-office on FreeNode -- Forwarded message -- From: Runa Bhattacharjee rbhattachar...@wikimedia.org Date: Fri, Dec 6, 2013 at 3:19 PM Subject: Language Engineering IRC Office Hour on December 11, 2013 (Wednesday) at 1700 UTC To: MediaWiki internationalisation mediawiki-i...@lists.wikimedia.org, Wikimedia Mailing List wikimedi...@lists.wikimedia.org, Wikimedia developers wikitech-l@lists.wikimedia.org, wikitech-ambassad...@lists.wikimedia.org [x-posted] Hello, The Wikimedia Language Engineering team will be hosting an IRC office hour on Wednesday, December 11, 2013 between 17:00 - 18:00 UTC on #wikimedia-office. (See below for timezone conversion and other details.) We will be talking about some of our recent and upcoming projects and then taking questions for the remaining time. Questions and any other concerns can also be sent to me directly before the event. See you there! Thanks Runa === Event Details === What: WMF Language Engineering Office hour When: December 11, 2013 (Wednesday). 1700-1800 UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131211T1700 Where: IRC Channel #wikimedia-office on FreeNode -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation -- Language Engineering - Outreach and QA Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth Devlopment Training
I'll probably try and attend, although it's during the day so there's no guarantee my boss won't randomly schedule a meeting or something. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Tue, Dec 10, 2013 at 11:43 PM, Aaron Halfaker ahalfa...@wikimedia.orgwrote: I'm bummed that I won't be able to join in since this overlaps substantially with the Analytics Research Data showcase that starts @ 11:30 AM PST. Would you be interested in recording the presentation for those of us who cannot attend? -Aaron On Tue, Dec 10, 2013 at 6:47 PM, Chris Steipp cste...@wikimedia.org wrote: Hi all, For any developers who have been thinking about connecting their application to MediaWiki, but haven't gotten around to diving in, I'm going to have a short training/workshop session next week. I'll give a brief intro to using the version of OAuth that we're running, and walk through some quick demos in php and go. After that, I'm happy to walk any developer through getting their app connected, if anyone is struggling with a particular issue. It will be Wed, Dec 18th at 11am PST (1900 UTC). Please let me know if you're interested. We'll probably use a hangout for the session, but if that's not an option for anyone we can use a voice call and etherpad. Either way I'll probably send out invites individually. ___ 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] Help needed with ParserCache::getKey() and ParserCache::getOptionsKey()
Am 10.12.2013 22:38, schrieb Brad Jorsch (Anomie): Looking at the code, ParserCache::getOptionsKey() is used to get the memc key which has a list of parser option names actually used when parsing the page. So for example, if a page uses only math and thumbsize while being parsed, the value would be array( 'math', 'thumbsize' ). Am 11.12.2013 02:35, schrieb Tim Starling: No, the set of options which fragment the cache is the same for all users. So if the user language is included in that set of options, then users with different languages will get different parser cache objects. Ah, right, thanks! Got myself confused there. The thing is: we are changing what's in the list of relevant options. Before the deployment, there was nothing in it, while with the new code, the user language should be there. I suppose that means we need to purge these pointers. Would bumping wgCacheEpoch be sufficient for that? Note that we don't care much about puring the actual parser cache entries, we want to purge the pointer entries in the cache. We just tried to enable the use of the parser cache for wikidata, and it failed, resulting in page content being shown in random languages. That's probably because you incorrectly used $wgLang or RequestContext::getLanguage(). The user language for the parser is the one you get from ParserOptions::getUserLangObj(). Oh, thanks for that hint! Seems our code is inconsistent about this, using the language from the parser options in some places, the one from the context in others. Need to fix that! It's not necessary to call ParserOutput::recordOption(). ParserOptions::getUserLangObj() will call it for you (via onAccessCallback). Oh great, magic hidden information flow :) Thanks for the info, I'll get hacking on it! -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Patrolling on english wikipedia
http://en.wikipedia.org/w/api.php?action=queryprop=revisionsrevids=585593930rvprop=tagsformat=jsonfm
Returns:
{
query: {
pages: {
12461: {
pageid: 12461,
ns: 0,
title: Gradient,
revisions: [
{
tags: [
Section blanking
]
}
]
}
}
}
}
On Wed, Dec 11, 2013 at 2:36 AM, Petr Bena benap...@gmail.com wrote:
Can you even read them by api? I know these may be part of recent
changes query, but huggle uses IRC feed for RC so the additional
information about edits are retrieved using other api's. Is there any
api that retrieve what tags are applied for an edit with certain
RevID?
On Tue, Dec 10, 2013 at 7:43 PM, Brian Wolff bawo...@gmail.com wrote:
On 2013-12-10 11:05 AM, Isarra Yos zhoris...@gmail.com wrote:
On 10/12/13 13:40, Petr Bena wrote:
I was recently suggested by someone (and requested by someone else) to
use patrolling on good edits in huggle, however after executing the
patrol api query I receive this error:
?xml version=1.0?api servedby=mw1130error
code=patroldisabled info=Patrolling is disabled on this wiki
//api
Is it true? Is patrolling really disabled on English wikipedia? It
sounds to me very unlike, so is this a bug and different error message
should have been displayed?
What about using the thank feature for good edits?
-L
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Really this seems the ideal use case for edit tags (the obvious problem
is
currently you can't set them by the api afaik)
-bawolff
___
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] Patrolling on english wikipedia
Ok, that is good, though it is lacking several features, including
ability to modify it (it's not possible to tag a page using these
api's) so we can use this to improve the scoring, but can't use it to
share some data with other users.
On Wed, Dec 11, 2013 at 3:09 PM, Aaron Halfaker ahalfa...@wikimedia.org wrote:
http://en.wikipedia.org/w/api.php?action=queryprop=revisionsrevids=585593930rvprop=tagsformat=jsonfm
Returns:
{
query: {
pages: {
12461: {
pageid: 12461,
ns: 0,
title: Gradient,
revisions: [
{
tags: [
Section blanking
]
}
]
}
}
}
}
On Wed, Dec 11, 2013 at 2:36 AM, Petr Bena benap...@gmail.com wrote:
Can you even read them by api? I know these may be part of recent
changes query, but huggle uses IRC feed for RC so the additional
information about edits are retrieved using other api's. Is there any
api that retrieve what tags are applied for an edit with certain
RevID?
On Tue, Dec 10, 2013 at 7:43 PM, Brian Wolff bawo...@gmail.com wrote:
On 2013-12-10 11:05 AM, Isarra Yos zhoris...@gmail.com wrote:
On 10/12/13 13:40, Petr Bena wrote:
I was recently suggested by someone (and requested by someone else) to
use patrolling on good edits in huggle, however after executing the
patrol api query I receive this error:
?xml version=1.0?api servedby=mw1130error
code=patroldisabled info=Patrolling is disabled on this wiki
//api
Is it true? Is patrolling really disabled on English wikipedia? It
sounds to me very unlike, so is this a bug and different error message
should have been displayed?
What about using the thank feature for good edits?
-L
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Really this seems the ideal use case for edit tags (the obvious problem
is
currently you can't set them by the api afaik)
-bawolff
___
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
2013/12/10 MZMcBride z...@mzmcbride.com * Minification reduces bandwidth usage. ** At the cost of making debugging more difficult. There is one thing that debug mode makes harder: Seeing how the page looks in an RTL language. That's because CSSJanus doesn't work in debug mode, and there were several objections in the past to changing that. That is the only thing that I'd love to see re-evaluated. As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. -- 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] Re-evaluating MediaWiki ResourceLoader's debug mode
As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. I'd actually disagree with the assertion that debug=true is easy to find, particularly for people who aren't active developers. Some random on the internet who just wants to see what our js looks like (out of curiosity or whatever) is not going to be able to find debug=true. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft for Bugzilla etiquette guidelines
Hi, On Mon, 2013-12-09 at 10:17 -0800, Jon Robson wrote: Would we be able to link to such a thing from within the Bugzilla interface to give it more visibility? Yes, in the footer, next to Privacy policy. I've filed https://bugzilla.wikimedia.org/show_bug.cgi?id=58332 so I don't forget. andre -- Andre Klapper | ak...@gmx.net 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] Re-evaluating MediaWiki ResourceLoader's debug mode
On 11.12.2013, 19:36 Brian wrote: As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. I'd actually disagree with the assertion that debug=true is easy to find, particularly for people who aren't active developers. Some random on the internet who just wants to see what our js looks like (out of curiosity or whatever) is not going to be able to find debug=true. If they look at the URL it will be pretty obvious because all of them have debug=false as first parameter. -- 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] Re-evaluating MediaWiki ResourceLoader's debug mode
On Wed, Dec 11, 2013 at 11:33 AM, Max Semenik maxsem.w...@gmail.com wrote: If they look at the URL it will be pretty obvious because all of them have debug=false as first parameter. As a proof of concept, this is how I found out about the debug parameter the first time I tried doing Javascript debugging in MediaWiki. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] chrome new version alway tips event.returnValue
when i open the chrome console,i always can get: event.returnValue is deprecated. Please use the standard event.preventDefault() instead. is any plan to fix this? Regrades Sen From SLboat(http://see.sl088.com) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] chrome new version alway tips event.returnValue
On Wed, Dec 11, 2013 at 9:59 AM, Sen kik...@gmail.com wrote: when i open the chrome console,i always can get: event.returnValue is deprecated. Please use the standard event.preventDefault() instead. is any plan to fix this? I don't know if there is currently a plan to fix it, but the warning is from jQuery and should be fixed by version 1.11 or greater [0]. As noted on the upstream bug this is just a warning and should have no effect on functionality. [0]: http://bugs.jquery.com/ticket/14282 Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia Commons Video Uploads waiting (Bug #58155)
Hi, I have a bunch of videos from our last conference waiting for an upload to Commons. For this I have filed a bug several days ago: * https://bugzilla.wikimedia.org/show_bug.cgi?id=58155 Can someone please take care of this in a timely manner? The conference is now three weeks ago and soon nobody will be interested in the videos anymore if we don't provide them near enough to the event. Thank you, Manuel -- Manuel Schneider - Chief Information Officer Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 340 66 22 - www.wikimedia.ch ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Linking gerrit project pages to gitweb
Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Re-evaluating MediaWiki ResourceLoader's debug mode
+1000 to what Max says. It really is kinda obvious to anyone who needs to know how to get into debug mode and if not there are wiki pages and if not it's easy enough to find out if you care enough. That said debug mode could definitely be improved and I'm glad you brought this topic up Max. A few things of the top of my head I'd like to see: * RTL working in debug mode * The code in ResourceLoader really could do with a good refactor - there are far too many different code paths and it would be good if we could simplify this to get them as close as possible. When I've worked with RL in the past to design my own modules which involves files I've had a lot of headaches trying to get things to work in both debug mode and non-debug mode (JavaScript templates [1] being one concrete example) - and even then the result wasn't quite was I was hoping for in that debug mode uses load.php urls to inject JavaScript before the file that needs it. [1] https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend.git/1f3c57137afae1d0f8ac602b62dccc741893d670/includes%2Fmodules%2FMFResourceLoaderModule.php On 11 Dec 2013 08:33, Max Semenik maxsem.w...@gmail.com wrote: On 11.12.2013, 19:36 Brian wrote: As everybody else already said, less bandwidth is a good thing for most people, obfuscation is OK when the source is available elsewhere, and debug=true is not hard for developers to find. I'd actually disagree with the assertion that debug=true is easy to find, particularly for people who aren't active developers. Some random on the internet who just wants to see what our js looks like (out of curiosity or whatever) is not going to be able to find debug=true. If they look at the URL it will be pretty obvious because all of them have debug=false as first parameter. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ 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] Linking gerrit project pages to gitweb
Every change has (gitblit) links. As does the project listing page. So does the branches page from an individual project. -Chad On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote: Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ 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] Linking gerrit project pages to gitweb
Perhaps I am a dumbass, but where is the gitblit link on: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend which the sort of link you get from the Projects list on gerrit? I cannot find it. -- brion On Wed, Dec 11, 2013 at 10:48 AM, Chad innocentkil...@gmail.com wrote: Every change has (gitblit) links. As does the project listing page. So does the branches page from an individual project. -Chad On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote: Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ 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] Linking gerrit project pages to gitweb
There isn't, you're not. This page has links: https://gerrit.wikimedia.org/r/#/admin/projects/ As does this: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend,branches And so would this, for example: https://gerrit.wikimedia.org/r/#/c/100811/ -Chad On Wed, Dec 11, 2013 at 10:52 AM, Brion Vibber bvib...@wikimedia.orgwrote: Perhaps I am a dumbass, but where is the gitblit link on: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend which the sort of link you get from the Projects list on gerrit? I cannot find it. -- brion On Wed, Dec 11, 2013 at 10:48 AM, Chad innocentkil...@gmail.com wrote: Every change has (gitblit) links. As does the project listing page. So does the branches page from an individual project. -Chad On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote: Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
I can see both sides of the argument here and just wanted to provide my thoughts on this matter. The short version is basically this: Keep gadgets for experiment, but ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience. As a developer the existence of Common.js and gadgets adds an extreme amount of unnecessary complexity to our code. In the early days of the mobile site, we missed an entire week of deployment due to certain global gadgets breaking on certain wikis that had not been designed for mobile that we had overlooked. We had to spend this week disabling all gadgets on mobile so we could actually continue work and remove this complexity. It seems extremely unreasonable to expect any engineer of MediaWiki to know exactly which gadgets are enabled on every single wiki using MediaWiki that exists and what actions they perform and under what circumstances. In addition to this, unless I am mistaken - and if I am this shows how much of a black hole Gadgets are for those not in the loop - gadgets do not tend to have tests, or any code review type process (editing a wiki page of a global gadget is like self merging your own code which we frown upon for core - so why do we encourage it here?). Wiki pages in my opinion are also not the best medium for code collaboration. There are various CSS rules in MediaWiki:Common.css that seem to only work on a small amount of pages thus the CSS is not optimal and we are hitting all our users badly in the performance (There are an extremely huge amount of rules for horizontal lists for example). Wiki pages can also be edited in isolation and unaware of each other so you end up generating lots of code that does the same thing rather than consolidating code as you would if it was under version control in a shared repository (FYI on the Barack Obama page according to Chrome web tools 90% of CSS rules we send go unused to a reader - although this a larger problem in that core doesn't even have a shared repository of styles that other extensions can use). All this said, I think gadgets are a great experimentation ground and create some extremely useful tools for editors and readers. However I do think various changes can be confusing for the average //reader// if enabled globally. I remember around the time of the Echo launch there was friction between developers of the feature and community members and the orange bar of death resurfaced promptly leaving an unacceptable very confusing fragmented experience for all readers who were not in that loop. I'd love us to get into a situation where Gadgets continue to be a platform for innovation but community and developers work hard to mature these gadgets into performant, test protected beasts that live in a single code repository. I do feel at times that we treat our users like dirt in terms of their experience... Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users deserve a certain standard of code. I'm aware using a code review process can slow things down but I feel this is really essential. I for one greatly benefit from having every single piece of my code scrutinized and perfected before being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process. Anyway that concludes my thoughts here... (braces himself for lions) On Mon, Dec 9, 2013 at 2:01 PM, Paul Selitskas p.selits...@gmail.com wrote: Yep, that's what I did too a year a two ago. Since some parts of front-end code work quite differently in Common.js and gadgets, it's bettet to put modular stuff (esp. ones that users would like to opt-out of) in gadgets. On Tue, Dec 10, 2013 at 12:38 AM, Liangent liang...@gmail.com wrote: MediaWiki:Common.js can also create disagreement and defaults change without notice. Actually what I did sometimes is to move code from MediaWiki:Common.js to default gadgets, so it can be disabled per user (for example, some users are using a too slow computer or network), and at the same time, this makes maintenance easier for developers, because gadgets can be made modularized, instead of using a big JavaScript and CSS file (Common.js/css). -Liangent On Tue, Dec 10, 2013 at 5:02 AM, K. Peachey p858sn...@gmail.com wrote: For wider discussion --- From: bugzilla-daemon at wikimedia.org Subject: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites http://news.gmane.org/find-root.php?message_id=%3cbug%2d58236%2d3%40https.bugzilla.wikimedia.org%2f%3e Newsgroups: gmane.org.wikimedia.mediawiki.bugs http://news.gmane.org/gmane.org.wikimedia.mediawiki.bugs Date: 2013-12-09 20:41:41 GMT (19 minutes ago)
Re: [Wikitech-l] Linking gerrit project pages to gitweb
So the pages that get you *to* the project page have links to the actual source browser, but the project detail page doesn't. Brilliant. I'll go file a bug report against gerrit. -- brion On Wed, Dec 11, 2013 at 10:56 AM, Chad innocentkil...@gmail.com wrote: There isn't, you're not. This page has links: https://gerrit.wikimedia.org/r/#/admin/projects/ As does this: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend,branches And so would this, for example: https://gerrit.wikimedia.org/r/#/c/100811/ -Chad On Wed, Dec 11, 2013 at 10:52 AM, Brion Vibber bvib...@wikimedia.org wrote: Perhaps I am a dumbass, but where is the gitblit link on: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend which the sort of link you get from the Projects list on gerrit? I cannot find it. -- brion On Wed, Dec 11, 2013 at 10:48 AM, Chad innocentkil...@gmail.com wrote: Every change has (gitblit) links. As does the project listing page. So does the branches page from an individual project. -Chad On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote: Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ 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 ___ 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] Linking gerrit project pages to gitweb
Filed as http://code.google.com/p/gerrit/issues/detail?id=2335 -- brion On Wed, Dec 11, 2013 at 11:15 AM, Brion Vibber bvib...@wikimedia.orgwrote: So the pages that get you *to* the project page have links to the actual source browser, but the project detail page doesn't. Brilliant. I'll go file a bug report against gerrit. -- brion On Wed, Dec 11, 2013 at 10:56 AM, Chad innocentkil...@gmail.com wrote: There isn't, you're not. This page has links: https://gerrit.wikimedia.org/r/#/admin/projects/ As does this: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend,branches And so would this, for example: https://gerrit.wikimedia.org/r/#/c/100811/ -Chad On Wed, Dec 11, 2013 at 10:52 AM, Brion Vibber bvib...@wikimedia.org wrote: Perhaps I am a dumbass, but where is the gitblit link on: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend which the sort of link you get from the Projects list on gerrit? I cannot find it. -- brion On Wed, Dec 11, 2013 at 10:48 AM, Chad innocentkil...@gmail.com wrote: Every change has (gitblit) links. As does the project listing page. So does the branches page from an individual project. -Chad On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote: Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ 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 ___ 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] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 11:04 AM, Jon Robson jdlrob...@gmail.com wrote: Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users deserve a certain standard of code. I'm aware using a code review process can slow things down but I feel this is really essential. I for one greatly benefit from having every single piece of my code scrutinized and perfected before being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process. Sending wiki edits to Gerrit for review? Absolutely not. I'm totally cool with the idea of code review for Gadgets so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Linking gerrit project pages to gitweb
A related feature request I just submitted -- links to review dashboards from all project pages: https://code.google.com/p/gerrit/issues/detail?id=2336 ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 11:20 AM, Brion Vibber bvib...@wikimedia.orgwrote: Filed as http://code.google.com/p/gerrit/issues/detail?id=2335 -- brion On Wed, Dec 11, 2013 at 11:15 AM, Brion Vibber bvib...@wikimedia.org wrote: So the pages that get you *to* the project page have links to the actual source browser, but the project detail page doesn't. Brilliant. I'll go file a bug report against gerrit. -- brion On Wed, Dec 11, 2013 at 10:56 AM, Chad innocentkil...@gmail.com wrote: There isn't, you're not. This page has links: https://gerrit.wikimedia.org/r/#/admin/projects/ As does this: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend,branches And so would this, for example: https://gerrit.wikimedia.org/r/#/c/100811/ -Chad On Wed, Dec 11, 2013 at 10:52 AM, Brion Vibber bvib...@wikimedia.org wrote: Perhaps I am a dumbass, but where is the gitblit link on: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend which the sort of link you get from the Projects list on gerrit? I cannot find it. -- brion On Wed, Dec 11, 2013 at 10:48 AM, Chad innocentkil...@gmail.com wrote: Every change has (gitblit) links. As does the project listing page. So does the branches page from an individual project. -Chad On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote: Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ 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 ___ 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] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 2:04 PM, Jon Robson jdlrob...@gmail.com wrote: Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users deserve a certain standard of code. I'm aware using a code review process can slow things down but I feel this is really essential. I for one greatly benefit from having every single piece of my code scrutinized and perfected before being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process. I can definitely understand the reasoning behind this. Right now with both Gadgets and common.js we are allowing non-reviewed code to be injected directly into every page. While there is a bit of trust to be had considering only administrators can edit those pages, it is still a security risk, and an unnecessary one at that. I like the idea of having gadgets (and any JS code for that matter) going through Gerrit for code review. The one issue is the question of where would Gadget code go? Would each gadget have its own code repository? Maybe we'd have just one repository for all gadgets as well as common.js (something like operations/common.js)? I don't think sending wiki edits to Gerrit is too feasible a solution, so if this were implemented it'd have to be entirely Gerrit-based. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
I'm totally cool with the idea of code review for Gadgets so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked. Chad, can you expand on that statement. I've been toying for some time with writing something that allows documentation to be synced both ways. E.g. for hooks and variables and what not. My simplistic toy example had a 1:1 link but I've been trying to figure out how to make it more complex. (Ideally this would also allow documentation to be linked to a branch and thus we then have versioned documentation) ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 11:21 AM, Chad innocentkil...@gmail.com wrote: On Wed, Dec 11, 2013 at 11:04 AM, Jon Robson jdlrob...@gmail.com wrote: Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users deserve a certain standard of code. I'm aware using a code review process can slow things down but I feel this is really essential. I for one greatly benefit from having every single piece of my code scrutinized and perfected before being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process. Sending wiki edits to Gerrit for review? Absolutely not. I'm totally cool with the idea of code review for Gadgets so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked. -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] Architecture Summit -- Gathering all relevant RfC's
On Wed, Nov 27, 2013 at 2:55 PM, Jon Robson jdlrob...@gmail.com wrote: One that I would like to discuss but still need to write up is JavaScript template support in ResourceLoader. Mobile has been using Hogan.js for some time and we would like to upstream this as a standard. I'll try and get this written in next 2 weeks but it would be good to capture this even in a stub like form (not sure if stubs are allowed on the RFC page) Hey Jon, If there's anything I can do to help you with this RfC then please let me know. Best, Diederik On Tue, Nov 26, 2013 at 6:27 PM, Diederik van Liere dvanli...@wikimedia.org wrote: Heya, The Architecture Summit will be upon us in less than two months. To make sure that this Summit is going to be productive it is important that we discuss the right RfC's. Before deciding which RfC's should be discussed at the Summit I want to make sure that https://www.mediawiki.org/wiki/Requests_for_comment contains all RfC's and that all important topics have an RfC. If you have a Mediawiki related RfC in a personal notepad, on your User Page, in your mind then this would be a great moment to write or move it under https://www.mediawiki.org/wiki/Requests_for_comment and add an entry to the table. If you don't have 'move' rights then please let me know and I can move it for you. If you know of a topic that *should* have an RfC but does not yet have an RfC then please reply to this list mentioning the topic. I will check with Tim/Brion to see how these topics can get an RfC. Once we have collected all relevant RfC's under https://www.mediawiki.org/wiki/Requests_for_comment then I will make a page where everybody can express their interest in which RfC's should be discussed at the Summit. Questions? Let me know! Best, Diederik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ 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] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwal...@wikimedia.org wrote: I'm totally cool with the idea of code review for Gadgets so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked. Chad, can you expand on that statement. I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 12:00 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwal...@wikimedia.org wrote: I'm totally cool with the idea of code review for Gadgets so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked. Chad, can you expand on that statement. I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks. That's a big part of it. The other part is that Gadgets and site CSS/JS stuff has always been a system that empowers wikis to make their own changes quickly. Gerrit may produce better reviewed code, but it's certainly not a rapid process. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
Ah; so it's actually slightly different use cases then. My thought is that it's on the developers to merge changes that come from the wiki. I've thought of two ways this could work: * For every new merge touching a documentation file; we reject changes via a jenkins job when there are still outstanding changes on the wiki (aka, we allow only fast forward merges for that source file). * Or have a script in jenkins that would automatically merge changes from the source branch into the wiki page (causing a failure if there was a merge conflict.) That way the wiki version remains as it is with new changes from source being automatically applied -- and selectively we accept changes into the source version. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 12:04 PM, Chad innocentkil...@gmail.com wrote: On Wed, Dec 11, 2013 at 12:00 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker mwal...@wikimedia.org wrote: I'm totally cool with the idea of code review for Gadgets so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked. Chad, can you expand on that statement. I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks. That's a big part of it. The other part is that Gadgets and site CSS/JS stuff has always been a system that empowers wikis to make their own changes quickly. Gerrit may produce better reviewed code, but it's certainly not a rapid process. -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] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On 11/12/13 19:21, Chad wrote: Sending wiki edits to Gerrit for review? Absolutely not. I'm totally cool with the idea of code review for Gadgets so forth, just not using Gerrit. We considered it for Scribunto (and heck, I wrote half of a proof of concept) but shot it down because the idea totally sucked. -Chad Thank you. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On 12/11/13, Tyler Romeo tylerro...@gmail.com wrote: On Wed, Dec 11, 2013 at 2:04 PM, Jon Robson jdlrob...@gmail.com wrote: Many a time I've talked about this I've hit the argument that gerrit is confusing to some users and is a barrier for development, but this is a terrible unacceptable attitude to have in my opinion. Our end users deserve a certain standard of code. I'm aware using a code review process can slow things down but I feel this is really essential. I for one greatly benefit from having every single piece of my code scrutinized and perfected before being consumed by a wider audience. If this is seen as a barrier, someone should investigate making it possible to send wiki edits to Gerrit to simplify that process. I can definitely understand the reasoning behind this. Right now with both Gadgets and common.js we are allowing non-reviewed code to be injected directly into every page. While there is a bit of trust to be had considering only administrators can edit those pages, it is still a security risk, and an unnecessary one at that. I like the idea of having gadgets (and any JS code for that matter) going through Gerrit for code review. The one issue is the question of where would Gadget code go? Would each gadget have its own code repository? Maybe we'd have just one repository for all gadgets as well as common.js (something like operations/common.js)? I don't think sending wiki edits to Gerrit is too feasible a solution, so if this were implemented it'd have to be entirely Gerrit-based. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l One of the primary reasons gadgets/local-js exist is because local wiki-admins feel that the mediawiki code review process is unavailable to them. I would expect any sort of code review requirement for gadgets to meet strong resistance, especially on the smaller wikis. I also think it would be unenforcable unless one plans to ban personal js in all forms. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
Hey, Has there been thought on how GitHub can potentially help here? I'm not sure it fits the workflow well, though can make the following observations: * People can click an edit button on GH to edit the code, much like on wiki. * If the GH web UI is used, people do not have to install git * They do not even need to understand git or know what it is * A workflow only involving code in actual source control can potentially be more streamlined and rely less on custom written solutions that also need to be maintained * Having such code in an easy to use (compared to git+gerrit) system that nevertheless provides a way to move to doing it more professionally might well have more people make the jump at some point Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 2:38 PM, Tyler Romeo tylerro...@gmail.com wrote: I can definitely understand the reasoning behind this. Right now with both Gadgets and common.js we are allowing non-reviewed code to be injected directly into every page. While there is a bit of trust to be had considering only administrators can edit those pages, it is still a security risk, and an unnecessary one at that. I like the idea of having gadgets (and any JS code for that matter) going through Gerrit for code review. The one issue is the question of where would Gadget code go? Would each gadget have its own code repository? Maybe we'd have just one repository for all gadgets as well as common.js (something like operations/common.js)? I don't think sending wiki edits to Gerrit is too feasible a solution, so if this were implemented it'd have to be entirely Gerrit-based. Could FlaggedRevs, perhaps with some modifications, be used to implement a review process? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff bawo...@gmail.com wrote: I would expect any sort of code review requirement for gadgets to meet strong resistance, especially on the smaller wikis. Unless it was the community doing code review on itself, maybe. To some extent this already happens on enwiki. I also think it would be unenforcable unless one plans to ban personal js in all forms. Not necessarily. Individual user JS applies only to the one user, while gadgets apply to potentially many and [[MediaWiki:Common.js]] to everyone. -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff bawo...@gmail.com wrote: One of the primary reasons gadgets/local-js exist is because local wiki-admins feel that the mediawiki code review process is unavailable to them. I would expect any sort of code review requirement for gadgets to meet strong resistance, especially on the smaller wikis. I also think it would be unenforcable unless one plans to ban personal In this case we should promptly work to fix this issue. To be honest, the only difficult part of our code review process is having to learn Git if you do not already know how to use it. If there were a way to submit patchsets without using Git somehow (maybe some kind of desktop application), it may make things easier. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 3:30 PM, Tyler Romeo tylerro...@gmail.com wrote: In this case we should promptly work to fix this issue. To be honest, the only difficult part of our code review process is having to learn Git if you do not already know how to use it. If there were a way to submit patchsets without using Git somehow (maybe some kind of desktop application), it may make things easier. I agree, it would make life a lot easier! Something like TortoiseSVN, but for Git, then? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] RFC deadline approaching for Arch Summit: December 20
Hi everyone, We're just over a week away from the Friday, December 20 deadline for RFCs as items to consider at the Architecture Summit.[1] That's not a hard and fast rule (we've never done this before), but we should definitely have a reasonable amount of time between the point an RFC is proposed and being discussed at the Architecture Summit. Ideally, we'll have taken care of everything that's reasonable to take care of via mailing list/IRC/other online meeting, and really be down the things that require face-to-face time to accomplish. It's my hope that we're not just nibbling at the edges, but that we're actually going to talk about things that will substantially modernize our architecture and reduce our technical debt. I believe there are RFCs in the list and in the works that do that, but I also know there are areas we've discussed informally in the past that we've never set to writing. Many of the RFCs cover important areas of incremental improvement, but not all of the changes we need to make have such small increments. Anyway, RFC submission page is here: https://www.mediawiki.org/wiki/Requests_for_comment Rob [1] https://www.mediawiki.org/wiki/Architecture_Summit_2014 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On 12/11/13, Tyler Romeo tylerro...@gmail.com wrote: On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff bawo...@gmail.com wrote: One of the primary reasons gadgets/local-js exist is because local wiki-admins feel that the mediawiki code review process is unavailable to them. I would expect any sort of code review requirement for gadgets to meet strong resistance, especially on the smaller wikis. I also think it would be unenforcable unless one plans to ban personal Not necessarily. Individual user JS applies only to the one user, while gadgets apply to potentially many and [[MediaWiki:Common.js]] to everyone. I guess I should have said without banning [[MediaWiki:Common.js]]. I was kind of assuming this proposal meant banning all site wide js (Since otherwise what's the point of banning default on gadgets? Default on gadgets is just a way to separate common.js into modules for easier maintainability) In this case we should promptly work to fix this issue. To be honest, the only difficult part of our code review process is having to learn Git if you do not already know how to use it. If there were a way to submit patchsets without using Git somehow (maybe some kind of desktop application), it may make things easier. Submitting patches is not the problem. Getting them reviewed in a timely fashion is a problem. Having power taken out of local wikis hands is a problem. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Architecture Summit -- Gathering all relevant RfC's
On Wed, Nov 27, 2013 at 12:55 PM, Jon Robson jdlrob...@gmail.com wrote: I'll try and get this written in next 2 weeks but it would be good to capture this even in a stub like form (not sure if stubs are allowed on the RFC page) There are plenty of RFCs there at this point that are stubs so I wouldn't let that stop you. :) Bryan -- Bryan Davis Wikimedia Foundationbd...@wikimedia.org [[m:User:BDavis_(WMF)]] Sr Software EngineerBoise, ID irc: bd808v:415.839.6885 x6855 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 3:21 PM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, Has there been thought on how GitHub can potentially help here? I'm not sure it fits the workflow well, though can make the following observations: Unless you're implying that github writes some code for us, I'm going to assume this is a troll from you and leave it at that. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Mailing list etiquette and trolling
Hey, In recent months I've come across a few mails on this list that only contained accusations of trolling. Those are very much not constructive and only serve to antagonize. I know some forums that have an explicit rule against this, which results in a ban on second violation. If there is a definition of the etiquette for this list somewhere, I suggest having a similar rule be added there. Thoughts? (I'm now half expecting someone to claim this mail is a troll. Perhaps we ought to make a contest out of making the accusation first, at least then it will have general amusement value :D) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailing list etiquette and trolling
On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote: In recent months I've come across a few mails on this list that only contained accusations of trolling. Those are very much not constructive and only serve to antagonize. I know some forums that have an explicit rule against this, which results in a ban on second violation. If there is a definition of the etiquette for this list somewhere, I suggest having a similar rule be added there. Thoughts? To be fair, you were proposing that we use a proprietary third party web site for editing wikimedia wiki pages, which would violate out privacy policy and break our principles of openness. How was I not to think you were trolling? My only alternative was to think you've simply lost your mind. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailing list etiquette and trolling
I think I've seen a couple of the times this has happened. It appears to me that it might be in reaction to a perceived misunderstanding of the topic on either party. If we assume good faith on both sides; then I think it's reasonable for the perceived 'trolling' party to gently restate their position. Ordinarily I would hold that we should simply be silent when we think we're being trolled -- but over a mailing list that can be perceived as if we're ignoring things. As we sometimes do in fact do this on purpose; I appreciate the feedback loop when a party perceives it so that we can correct and move on so that no one gets ignored unless we really do mean to ignore them. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 2:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, In recent months I've come across a few mails on this list that only contained accusations of trolling. Those are very much not constructive and only serve to antagonize. I know some forums that have an explicit rule against this, which results in a ban on second violation. If there is a definition of the etiquette for this list somewhere, I suggest having a similar rule be added there. Thoughts? (I'm now half expecting someone to claim this mail is a troll. Perhaps we ought to make a contest out of making the accusation first, at least then it will have general amusement value :D) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ 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] Wikimedia Commons Video Uploads waiting (Bug #58155)
Le 11/12/13 19:15, Manuel Schneider a écrit : Hi, I have a bunch of videos from our last conference waiting for an upload to Commons. For this I have filed a bug several days ago: * https://bugzilla.wikimedia.org/show_bug.cgi?id=58155 Can someone please take care of this in a timely manner? The conference is now three weeks ago and soon nobody will be interested in the videos anymore if we don't provide them near enough to the event. Hello, I have no idea which script should be used to upload those files. If anyone has a link to the step-by-step guide to achieve it, I will be more than happy to execute the commands and proceed with the uploads. cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
It's not a bad thought; but I don't think it'll work for a couple of reasons: * It causes people to leave the site * GItHub for various reasons requires an account (which most likely they wont have and it doesn't seem correct to require one given our editing philosophy) * The editing interface is completely different that of the MediaWiki interface * It would most likely complicate what's already going to be a fairly complicated merge / review process. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 12:21 PM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, Has there been thought on how GitHub can potentially help here? I'm not sure it fits the workflow well, though can make the following observations: * People can click an edit button on GH to edit the code, much like on wiki. * If the GH web UI is used, people do not have to install git * They do not even need to understand git or know what it is * A workflow only involving code in actual source control can potentially be more streamlined and rely less on custom written solutions that also need to be maintained * Having such code in an easy to use (compared to git+gerrit) system that nevertheless provides a way to move to doing it more professionally might well have more people make the jump at some point Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ 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] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks. I'm confused.. non-developers writing JS and CSS? This scares the bejesus outta me. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Linking gerrit project pages to gitweb
Thanks guys! On Wed, Dec 11, 2013 at 11:32 AM, Matthew Walker mwal...@wikimedia.org wrote: A related feature request I just submitted -- links to review dashboards from all project pages: https://code.google.com/p/gerrit/issues/detail?id=2336 ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 11:20 AM, Brion Vibber bvib...@wikimedia.orgwrote: Filed as http://code.google.com/p/gerrit/issues/detail?id=2335 -- brion On Wed, Dec 11, 2013 at 11:15 AM, Brion Vibber bvib...@wikimedia.org wrote: So the pages that get you *to* the project page have links to the actual source browser, but the project detail page doesn't. Brilliant. I'll go file a bug report against gerrit. -- brion On Wed, Dec 11, 2013 at 10:56 AM, Chad innocentkil...@gmail.com wrote: There isn't, you're not. This page has links: https://gerrit.wikimedia.org/r/#/admin/projects/ As does this: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend,branches And so would this, for example: https://gerrit.wikimedia.org/r/#/c/100811/ -Chad On Wed, Dec 11, 2013 at 10:52 AM, Brion Vibber bvib...@wikimedia.org wrote: Perhaps I am a dumbass, but where is the gitblit link on: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend which the sort of link you get from the Projects list on gerrit? I cannot find it. -- brion On Wed, Dec 11, 2013 at 10:48 AM, Chad innocentkil...@gmail.com wrote: Every change has (gitblit) links. As does the project listing page. So does the branches page from an individual project. -Chad On Wed, Dec 11, 2013 at 10:45 AM, Jon Robson jdlrob...@gmail.com wrote: Could we make it so: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MobileFrontend has a link to https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FMobileFrontend.git (and all other projects do the same) I swear I just spent 10 minutes searching through emails and google trying to find that link. I fear I'm not alone and it would be really good to provide better paths into the code. ___ 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 ___ 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 -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
Heh; wrong thread to discuss that in Jon -- this one is about non-developers helping out writing documentation for configuration variables and what not without having to modify the source file in gerrit. The OTHER thread, which I forked from, is the one about what we already allow (users to modify common.js and common.css) and how to get that code reviewed. ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Wed, Dec 11, 2013 at 2:35 PM, Jon Robson jdlrob...@gmail.com wrote: I'm not Chad, but one of the big issues is this: Consider the trouble that some of us as developers have using Git and Gerrit. Now think about trying to get non-developer JS and CSS coders to be able to use Git and Gerrit, much less to *want* to use Git and Gerrit rather than torches and pitchforks. I'm confused.. non-developers writing JS and CSS? This scares the bejesus outta me. ___ 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] Wikimedia Commons Video Uploads waiting (Bug #58155)
On 12/11/13, Antoine Musso hashar+...@free.fr wrote: Le 11/12/13 19:15, Manuel Schneider a écrit : Hi, I have a bunch of videos from our last conference waiting for an upload to Commons. For this I have filed a bug several days ago: * https://bugzilla.wikimedia.org/show_bug.cgi?id=58155 Can someone please take care of this in a timely manner? The conference is now three weeks ago and soon nobody will be interested in the videos anymore if we don't provide them near enough to the event. Hello, I have no idea which script should be used to upload those files. If anyone has a link to the step-by-step guide to achieve it, I will be more than happy to execute the commands and proceed with the uploads. cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Normally importImages.php is used I believe. I think you create a directory, use curl/wget to get all the files, then run importImages.php, making sure to specify the --comment-ext and --user option. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailing list etiquette and trolling
On 11/12/13 22:21, Ryan Lane wrote: On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote: In recent months I've come across a few mails on this list that only contained accusations of trolling. Those are very much not constructive and only serve to antagonize. I know some forums that have an explicit rule against this, which results in a ban on second violation. If there is a definition of the etiquette for this list somewhere, I suggest having a similar rule be added there. Thoughts? To be fair, you were proposing that we use a proprietary third party web site for editing wikimedia wiki pages, which would violate out privacy policy and break our principles of openness. How was I not to think you were trolling? My only alternative was to think you've simply lost your mind. - Ryan From a common (wiki) user standpoint, however, gerrit for instance might as well be a proprietary third party website as well - it's not easily accessible or directly connected to the wiki (different accounts, different interface, etc), so many of the same principles apply there too. This does support Matt's point, though - we all come into discussions with different perspectives, so if someone looks at it like a content editor and another looks at it like a platform developer, of course they might think the other is trolling because these perspectives can be so very different. We're not necessarily seeing or discussing the same things, and that's actually a good thing because it means we can cover the different sides of the problems better, but we do need to keep that in mind for it to work. -I ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailing list etiquette and trolling
Is this thread some trolling on its own? :P I think we need to use less rules and more common sense. All these etiquettes are just damaging your natural intelligence... On Wed, Dec 11, 2013 at 11:11 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, In recent months I've come across a few mails on this list that only contained accusations of trolling. Those are very much not constructive and only serve to antagonize. I know some forums that have an explicit rule against this, which results in a ban on second violation. If there is a definition of the etiquette for this list somewhere, I suggest having a similar rule be added there. Thoughts? (I'm now half expecting someone to claim this mail is a troll. Perhaps we ought to make a contest out of making the accusation first, at least then it will have general amusement value :D) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 -- ___ 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] Mailing list etiquette and trolling
On 11/12/13 23:28, Petr Bena wrote: I think we need to use less rules and more common sense. This. When you get right down to it, what even is trolling? And should it necessarily matter? Even if someone is trolling, that doesn't mean they may not have a real point to it, though perhaps they could be more polite. Thing is, the most effective trolling is generally effective precisely /because/ they have a point - a point which may be somehow uncomfortable, something neglected or ignored or that the target doesn't want to admit for whatever reason, but if the point is relevant it often should be brought up. Unfortunately with such points bringing them in any way, no matter how politely, can potentially be called trolling. -L ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailing list etiquette and trolling
On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.comwrote: (I'm now half expecting someone to claim this mail is a troll. Perhaps we ought to make a contest out of making the accusation first, at least then it will have general amusement value :D) This contest idea sounds exciting. ;) *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Commons Video Uploads waiting (Bug #58155)
:/ There are only ten videos. Is there some sort of special upload process that needs to be followed here? Because uploading ten things to Commons takes all of fifteen minutes. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Wed, Dec 11, 2013 at 5:53 PM, Brian Wolff bawo...@gmail.com wrote: On 12/11/13, Antoine Musso hashar+...@free.fr wrote: Le 11/12/13 19:15, Manuel Schneider a écrit : Hi, I have a bunch of videos from our last conference waiting for an upload to Commons. For this I have filed a bug several days ago: * https://bugzilla.wikimedia.org/show_bug.cgi?id=58155 Can someone please take care of this in a timely manner? The conference is now three weeks ago and soon nobody will be interested in the videos anymore if we don't provide them near enough to the event. Hello, I have no idea which script should be used to upload those files. If anyone has a link to the step-by-step guide to achieve it, I will be more than happy to execute the commands and proceed with the uploads. cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Normally importImages.php is used I believe. I think you create a directory, use curl/wget to get all the files, then run importImages.php, making sure to specify the --comment-ext and --user option. --bawolff ___ 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] Mailing list etiquette and trolling
On Wed, Dec 11, 2013 at 3:50 PM, Isarra Yos zhoris...@gmail.com wrote: On 11/12/13 23:28, Petr Bena wrote: I think we need to use less rules and more common sense. This. Rules are silly. Common sense for all :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 4:13 PM, Brian Wolff bawo...@gmail.com wrote: I guess I should have said without banning [[MediaWiki:Common.js]]. I was kind of assuming this proposal meant banning all site wide js (Since otherwise what's the point of banning default on gadgets? Default on gadgets is just a way to separate common.js into modules for easier maintainability) Yeah I think it's pretty much established that globally banning Gadgets is simply not going to work unless you also ban common.js. If anything it makes the problem worse, since at least Gadgets allow some organization for the chaos (and users can turn off gadgets). Submitting patches is not the problem. Getting them reviewed in a timely fashion is a problem. Having power taken out of local wikis hands is a problem. I'll be frank. I don't really care. If power is really the issue, then let people from the wikis have +2 on their wiki's Gerrit project. If the cost of increasing site-wide security and alleviating developers' pain is a few upset users who will get over it in a month or two, then so be it. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, 11 Dec 2013 21:30:15 +0100, Tyler Romeo tylerro...@gmail.com wrote: In this case we should promptly work to fix this issue. To be honest, the only difficult part of our code review process is having to learn Git if you do not already know how to use it. If there were a way to submit patchsets without using Git somehow (maybe some kind of desktop application), it may make things easier. There is also gerrit, which is widely considered a clusterfuck. You can actually submit patches almost without using git (apart from `git clone` and `git diff`) using http://tools.wmflabs.org/gerrit-patch-uploader/ (but they still have to be reviewed via gerrit). -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 3:58 PM, Tyler Romeo tylerro...@gmail.com wrote: On Wed, Dec 11, 2013 at 4:13 PM, Brian Wolff bawo...@gmail.com wrote: I guess I should have said without banning [[MediaWiki:Common.js]]. I was kind of assuming this proposal meant banning all site wide js (Since otherwise what's the point of banning default on gadgets? Default on gadgets is just a way to separate common.js into modules for easier maintainability) Yeah I think it's pretty much established that globally banning Gadgets is simply not going to work unless you also ban common.js. If anything it makes the problem worse, since at least Gadgets allow some organization for the chaos (and users can turn off gadgets). Submitting patches is not the problem. Getting them reviewed in a timely fashion is a problem. Having power taken out of local wikis hands is a problem. I'll be frank. I don't really care. If power is really the issue, then let people from the wikis have +2 on their wiki's Gerrit project. If the cost of increasing site-wide security and alleviating developers' pain is a few upset users who will get over it in a month or two, then so be it. I'm going to say this one final time, since I'm feeling like a broken record today... We are not going to use Gerrit for gadgets and so forth. It is the *wrong* tool for the job. Full stop. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 7:15 PM, Chad innocentkil...@gmail.com wrote: I'm going to say this one final time, since I'm feeling like a broken record today... We are not going to use Gerrit for gadgets and so forth. It is the *wrong* tool for the job. Full stop. Gerrit is a code review tool. Gadgets are code. It is the absolute *correct* tool for the job. At the very least it is a more proper tool than using wiki software. If Wikipedia wants to have any resemblance of proper software security, having gadgets stored on wiki should disappear very quickly. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, Dec 11, 2013 at 4:19 PM, Tyler Romeo tylerro...@gmail.com wrote: On Wed, Dec 11, 2013 at 7:15 PM, Chad innocentkil...@gmail.com wrote: I'm going to say this one final time, since I'm feeling like a broken record today... We are not going to use Gerrit for gadgets and so forth. It is the *wrong* tool for the job. Full stop. Gerrit is a code review tool. Gadgets are code. It is the absolute *correct* tool for the job. At the very least it is a more proper tool than using wiki software. If Wikipedia wants to have any resemblance of proper software security, having gadgets stored on wiki should disappear very quickly. Extension:CodeReview is also a code review tool. So is Reitveld. And Github. And Phabricator. And Gaereth. Doesn't mean they're the *right* tools ;-) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Commons Video Uploads waiting (Bug #58155)
The videos are (mostly) over 1 gb, which is our upload limit. Hence maintenance script needed. -bawolff On 2013-12-11 4:56 PM, Tyler Romeo tylerro...@gmail.com wrote: :/ There are only ten videos. Is there some sort of special upload process that needs to be followed here? Because uploading ten things to Commons takes all of fifteen minutes. *-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science On Wed, Dec 11, 2013 at 5:53 PM, Brian Wolff bawo...@gmail.com wrote: On 12/11/13, Antoine Musso hashar+...@free.fr wrote: Le 11/12/13 19:15, Manuel Schneider a écrit : Hi, I have a bunch of videos from our last conference waiting for an upload to Commons. For this I have filed a bug several days ago: * https://bugzilla.wikimedia.org/show_bug.cgi?id=58155 Can someone please take care of this in a timely manner? The conference is now three weeks ago and soon nobody will be interested in the videos anymore if we don't provide them near enough to the event. Hello, I have no idea which script should be used to upload those files. If anyone has a link to the step-by-step guide to achieve it, I will be more than happy to execute the commands and proceed with the uploads. cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Normally importImages.php is used I believe. I think you create a directory, use curl/wget to get all the files, then run importImages.php, making sure to specify the --comment-ext and --user option. --bawolff ___ 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] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
As both an active gadget writer (on pl.wikipedia) and a core developer, let me say that while I would *love* to have a somewhat formalized code-review process for gadgets, it is pretty much not possible, and the reason is twofold. First, code-review is, apart from spotting bugs, about getting the code to adhere to certain formal standards and code conventions. We have lots of such standards and conventions in core, for example, and while almost all of them are useful or (at least not troublesome) to a seasoned developer working in a team of a few dozen people, every single one is also *damned boring* – and if we make writing gadgets not enjoyable, people will stop writing them. When you're a single person working on a 200-line script, who the hell cares if you use == or ===, or if you use multiple `var` declarations in a function, or if you use `alert()` to notify the user that something went very wrong? In most cases this does not matter, and if the code works, that's all good. Unfortunately writing code for core is largely about petty things like this; if you're a biologist who learned to program for fun and wrote a tool in JS to scratch your own itch, code style matters very little, both for you and for other people who enjoy using your toy. Second, en.wp might be an exception, but most communities simply don't have enough active people. On pl.wp (ninth largest Wikipedia), I am currently the only active JavaScript person; who do I ask for review? Even if core developers or people from other wikis volunteered, they'd surely not be able to understand the domain, especially due to the language barrier. And my core experiences say that the slowest part of code-review is getting someone to do it (I have 30+ unreviewed or +1'd patches pending right now). And as Brad mentioned, informal code review happens; people watch gadgets' pages and look at the changes, non-admins have to ask admins to have their gadget code merged, admins are generally responsible people anyway, and even *if* something bad does happen (which I feel happens less often than with MW deployments, really), reverting or fixing the change takes one click instead of a multi-hour deployment process. I really liked what Jon said at the beginning, and what has apparently been lost in the discussions already – Keep gadgets for experiment, but ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience.. Proper global gadgets still don't exist, but when they finally happen, experienced coders who do this for a living should take them under their wings (to clean up existing code, to check new contributions – but a post-merge code-review might still be more appropriate); but local gadgets should stay the safe haven of innovation they are now. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson jdlrob...@gmail.com wrote: I'm confused.. non-developers writing JS and CSS? This scares the bejesus outta me. There's so many movements urging people to learn to code right now, I don't see how this is surprising anymore. Yes, physicians and economists can write JavaScript too, and if their JS isn't the ultimate prettiest code, but if it works for their purposes, then so what? That's a net gain. And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Andrew Russell Green joins Wikimedia as Features Engineering Contractor (and in SF this week)
Hello everyone, It’s with great pleasure that I’m announcing that Andrew Green[1] has joined the Wikimedia Foundation as a contractor in Features Engineering working in the Education Project. Before joining us, Andy worked at the Instituto Mora[2] creating free software for social science research that uses images as a primary sources. He received a B.A. in music composition from the Université de Montréal in 1995 and went on to study social anthropology at the National School of Anthropology and History in Mexico City. He’s done a lot of work with the semantic web[3][4] which helps him navigate a lot of the pre-WikiData Education Program[5] codebase. :-) As you probably guessed with my usual tardiness, his first official day was actually on October 7th, so he’s already done a lot of work[6] for us. However, you’ll see him in the office this week and next (as well as at the holiday party), so be sure to say hi! and introduce yourself (he’s the quiet guy with big ideas sitting on the north end of the 3rd floor). Andrew lives and works in Mexico City, Mexico with his wife and two children. He knows Spanish, French, and English and loves to talk about the philosophy of mathematics, cognitive linguistics, and politics[7]. Please join me in welcoming Andrew to the Wikimedia Foundation. :-) Take care, Terry [1]: [[User:AndyRussG]] [2]: http://www.mora.edu.mx/inicio.aspx [3]: http://ceur-ws.org/Vol-348 [4]: https://github.com/AndrewGreen/papersandtalks [5]: https://www.mediawiki.org/wiki/Wikipedia_Education_Program [6]: https://gerrit.wikimedia.org/r/#/q/owner:%22AndyRussG+%253Candrew.green.df%2540gmail.com%253E%22,n,z [7]: AndyRussG: “Politics? Yeah, sure politics is cool. Well maybe not. Hmmm.” ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki - Gerrit was Re: FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
On 2013-12-11 4:52 PM, Bartosz Dziewoński wrote: On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson jdlrob...@gmail.com wrote: And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users. That's not always true. There are a variety of scenarios where a Gadget author may do something relatively common and innocent, and through a bad practice mistake could inadvertently introduce a gaping XSS vector that could be used to attack any user for whom said gadget is merely enabled. For example take a gadget which runs unconditionally on a specific URL, like how the AJAX recent changes does, triggering a special view when on `Special:BlankPage?blankspecial=ajaxrc`. Now say the gadget happens to take user input from the URL, for example a page title, because the gadget wants per-page stuff and include a link inside the toolbox on every page that would link to the tool passing along the title of the page (title might be the most common, but there are plenty of other reasons to accept user input from the URL). If the gadget author decided to output this title into the page, they might accidentally do it in a way that amounted to raw html concatenation: Such as `+ userInput +`ing it into a block of html, passing it to a mw.message in a parameter that accepts raw html, using innerHTML in the wrong way, using some other interface that actually accepts HTML, etc... If this happened, a glaring XSS vector would suddenly become open. Anyone, anywhere on the internet could simply include an iframe pointed to the URL and use that parameter to inject any html and script they wanted creating a full-blown XSS attack. (And thanks to user scripts, etc... escalating any momentary XSS attack into a persistent on-site XSS attack is trivial) ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
Bartosz Dziewoński wrote: I really liked what Jon said at the beginning, and what has apparently been lost in the discussions already – Keep gadgets for experiment, but ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience.. Proper global gadgets still don't exist, but when they finally happen, experienced coders who do this for a living should take them under their wings (to clean up existing code, to check new contributions – but a post-merge code-review might still be more appropriate); but local gadgets should stay the safe haven of innovation they are now. Yep. We should obviously find ways to improve performance and reduce unnecessary code. Global (Wikimedia-wide) gadgets would be a good approach to take. Converting successful JavaScript gadgets into PHP MediaWiki extensions would be another good approach to take. There are others. The idea being proposed in bug 58236, as it was framed, was a non-starter. It simply riled people up and caused them to become defensive. (Its sibling bugs didn't help.) However, if we re-frame the issue, I think many people would agree that if there's a desire to enable a gadget for _all_ users, whatever functionality that is being provided by that gadget probably ought to be integrated into a MediaWiki extension. Brian Wolff wrote: Submitting patches is not the problem. Getting them reviewed in a timely fashion is a problem. Having power taken out of local wikis hands is a problem. Yep. Brian Wolff also wrote: I also think it would be unenforcable unless one plans to ban personal js in all forms. Quite: if you ban site-wide JavaScript (Common.js, Monobook.js, gadgets, etc.), people will simply revert to using per-user JavaScript (i.e., User:Foo/script.js) and importScript(), as they did for years. Tyler Romeo wrote: I'll be frank. I don't really care. If power is really the issue, then let people from the wikis have +2 on their wiki's Gerrit project. Currently you already have a +1/+2 model on the wiki. Any user can +1 while any local administrator can +2. Tyler Romeo also wrote: If the cost of increasing site-wide security and alleviating developers' pain is a few upset users who will get over it in a month or two, then so be it. With respect, your posts exhibit hints that you have not been a community member of a Wikimedia wiki, though perhaps I'm mistaken. I find it much easier to agree with Bartosz and Brian than with you. It's very important that wikis have sovereignty and freedom to experiment. Daniel Friesen wrote: Bartosz Dziewoński wrote: And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users. That's not always true. There are a variety of scenarios where a Gadget author may do something relatively common and innocent, and through a bad practice mistake could inadvertently introduce a gaping XSS vector that could be used to attack any user for whom said gadget is merely enabled. While it's probably impossible to accurately measure, anecdotal evidence suggests that XSS vulnerabilities are far more common in MediaWiki core and its extensions and than in JavaScript gadgets. :-) Jon Robson wrote: I'd love us to get into a situation where Gadgets continue to be a platform for innovation but community and developers work hard to mature these gadgets into performant, test protected beasts that live in a single code repository. I do feel at times that we treat our users like dirt in terms of their experience... Further anecdotal evidence: I hear a lot of users complain about MediaWiki extensions (UniversalLanguageSelector, ArticleFeedbackv5, FlaggedRevs) and even occasionally about MediaWiki core, all of which go through formal code review. I don't hear many complaints about JavaScript gadgets or CSS. In fact, in my experience certain actions (such as nominating a page for deletion) have become nearly impossible without the use of gadgets. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailing list etiquette and trolling
On Wed, Dec 11, 2013 at 2:21 PM, Ryan Lane rlan...@gmail.com wrote: On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw jeroended...@gmail.com wrote: In recent months I've come across a few mails on this list that only contained accusations of trolling. Those are very much not constructive and only serve to antagonize. I know some forums that have an explicit rule against this, which results in a ban on second violation. If there is a definition of the etiquette for this list somewhere, I suggest having a similar rule be added there. Thoughts? To be fair, you were proposing that we use a proprietary third party web site for editing wikimedia wiki pages, which would violate out privacy policy and break our principles of openness. How was I not to think you were trolling? My only alternative was to think you've simply lost your mind. Or perhaps he merely suggested something that you disagreed with (or didn't understand), without losing [his] mind or being a troll? I'm a little skeptical about Jeroen's GitHub suggestion, but it seems like something reasonable people can disagree about. Could we not accuse Jeroen or anyone else of being a troll or losing his/her mind for floating an honest proposal? Thanks Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mailing list etiquette and trolling
On Thu, Dec 12, 2013 at 12:03 AM, Rob Lanphier ro...@wikimedia.org wrote: Or perhaps he merely suggested something that you disagreed with (or didn't understand), without losing [his] mind or being a troll? I'm a little skeptical about Jeroen's GitHub suggestion, but it seems like something reasonable people can disagree about. Could we not accuse Jeroen or anyone else of being a troll or losing his/her mind for floating an honest proposal? From my experience on the Internet, I suspect that most of the times when people are accused of trolling, they are actually serious; and most of the times when people are trolling, they're taken seriously and no one expresses any suspicion that they were trolling. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FWD: [Bug 58236] New: No longer allow gadgets to be turned on by default for all users on Wikimedia sites
+1 to everything MZM said. Except the XSS in user/site/gadget JS vs core/extension XSS. Intuition tells me the former is much more common. We just think about core/extension XSS because it gets a security release and tons of attention. -Chad On Dec 11, 2013 8:01 PM, MZMcBride z...@mzmcbride.com wrote: Bartosz Dziewoński wrote: I really liked what Jon said at the beginning, and what has apparently been lost in the discussions already – Keep gadgets for experiment, but ensure global gadgets are held to a higher standard of quality and made more visible to a wider audience.. Proper global gadgets still don't exist, but when they finally happen, experienced coders who do this for a living should take them under their wings (to clean up existing code, to check new contributions – but a post-merge code-review might still be more appropriate); but local gadgets should stay the safe haven of innovation they are now. Yep. We should obviously find ways to improve performance and reduce unnecessary code. Global (Wikimedia-wide) gadgets would be a good approach to take. Converting successful JavaScript gadgets into PHP MediaWiki extensions would be another good approach to take. There are others. The idea being proposed in bug 58236, as it was framed, was a non-starter. It simply riled people up and caused them to become defensive. (Its sibling bugs didn't help.) However, if we re-frame the issue, I think many people would agree that if there's a desire to enable a gadget for _all_ users, whatever functionality that is being provided by that gadget probably ought to be integrated into a MediaWiki extension. Brian Wolff wrote: Submitting patches is not the problem. Getting them reviewed in a timely fashion is a problem. Having power taken out of local wikis hands is a problem. Yep. Brian Wolff also wrote: I also think it would be unenforcable unless one plans to ban personal js in all forms. Quite: if you ban site-wide JavaScript (Common.js, Monobook.js, gadgets, etc.), people will simply revert to using per-user JavaScript (i.e., User:Foo/script.js) and importScript(), as they did for years. Tyler Romeo wrote: I'll be frank. I don't really care. If power is really the issue, then let people from the wikis have +2 on their wiki's Gerrit project. Currently you already have a +1/+2 model on the wiki. Any user can +1 while any local administrator can +2. Tyler Romeo also wrote: If the cost of increasing site-wide security and alleviating developers' pain is a few upset users who will get over it in a month or two, then so be it. With respect, your posts exhibit hints that you have not been a community member of a Wikimedia wiki, though perhaps I'm mistaken. I find it much easier to agree with Bartosz and Brian than with you. It's very important that wikis have sovereignty and freedom to experiment. Daniel Friesen wrote: Bartosz Dziewoński wrote: And it's not very easy to cause a major security bug when writing code that runs client-side and usually only in response to user action. Most gadgets don't, say, parse untrusted input from *other* users. That's not always true. There are a variety of scenarios where a Gadget author may do something relatively common and innocent, and through a bad practice mistake could inadvertently introduce a gaping XSS vector that could be used to attack any user for whom said gadget is merely enabled. While it's probably impossible to accurately measure, anecdotal evidence suggests that XSS vulnerabilities are far more common in MediaWiki core and its extensions and than in JavaScript gadgets. :-) Jon Robson wrote: I'd love us to get into a situation where Gadgets continue to be a platform for innovation but community and developers work hard to mature these gadgets into performant, test protected beasts that live in a single code repository. I do feel at times that we treat our users like dirt in terms of their experience... Further anecdotal evidence: I hear a lot of users complain about MediaWiki extensions (UniversalLanguageSelector, ArticleFeedbackv5, FlaggedRevs) and even occasionally about MediaWiki core, all of which go through formal code review. I don't hear many complaints about JavaScript gadgets or CSS. In fact, in my experience certain actions (such as nominating a page for deletion) have become nearly impossible without the use of gadgets. MZMcBride ___ 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
