date:20131211

Re: [Wikitech-l] MediaWiki to Latex Converter

2013-12-11 Thread Santhosh Thottingal


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

2013-12-11 Thread Petr Bena

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  wrote:
> On Tue, Dec 10, 2013 at 8:14 AM, Petr Bena  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: 
>
> 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_traits, _Alloc = std::allocator]’:
> 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_traits, _Alloc = std::allocator]’ 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

2013-12-11 Thread Petr Bena

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  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:
>>
>> > code="patroldisabled" info="Patrolling is disabled on this wiki"
>> />
>>
>> 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

2013-12-11 Thread Petr Bena

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  wrote:
> On 2013-12-10 11:05 AM, "Isarra Yos"  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:
>>>
>>> >> code="patroldisabled" info="Patrolling is disabled on this wiki"
>>> />
>>>
>>> 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

2013-12-11 Thread Toni Hermoso Pulido


El 10/12/13 00:33, Liangent ha escrit:


On Tue, Dec 10, 2013 at 7:13 AM, Toni Hermoso Pulido 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



$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

2013-12-11 Thread Antoine Musso

Le 10/12/13 18:21, Ori Livneh a écrit :
> I hacked together a Homebrew formula: 

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

2013-12-11 Thread Antoine Musso

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

2013-12-11 Thread Petr Bena

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  wrote:
> Le 10/12/13 18:21, Ori Livneh a écrit :
>> I hacked together a Homebrew formula: 
>
> 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

2013-12-11 Thread Runa Bhattacharjee

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 
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
, Wikimedia Mailing List
, Wikimedia developers
,
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

2013-12-11 Thread Tyler Romeo

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 wrote:

> 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 
> 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()

2013-12-11 Thread Daniel Kinzler

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

2013-12-11 Thread Aaron Halfaker

http://en.wikipedia.org/w/api.php?action=query&prop=revisions&revids=585593930&rvprop=tags&format=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  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  wrote:
> > On 2013-12-10 11:05 AM, "Isarra Yos"  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:
> >>>
> >>>  >>> code="patroldisabled" info="Patrolling is disabled on this wiki"
> >>> />
> >>>
> >>> 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

2013-12-11 Thread Petr Bena

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  wrote:
> http://en.wikipedia.org/w/api.php?action=query&prop=revisions&revids=585593930&rvprop=tags&format=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  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  wrote:
>> > On 2013-12-10 11:05 AM, "Isarra Yos"  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:
>> >>>
>> >>> > >>> code="patroldisabled" info="Patrolling is disabled on this wiki"
>> >>> />
>> >>>
>> >>> 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-11 Thread Amir E. Aharoni

2013/12/10 MZMcBride 

> * 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

2013-12-11 Thread Brian Wolff

>
> 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

2013-12-11 Thread Andre Klapper

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

2013-12-11 Thread Max Semenik

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

2013-12-11 Thread Tyler Romeo

On Wed, Dec 11, 2013 at 11:33 AM, Max Semenik  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

2013-12-11 Thread Sen

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

2013-12-11 Thread Bryan Davis

On Wed, Dec 11, 2013 at 9:59 AM, Sen  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 Foundation
[[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)

2013-12-11 Thread Manuel Schneider

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

2013-12-11 Thread Jon Robson

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

2013-12-11 Thread Jon Robson

+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"  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

2013-12-11 Thread Chad

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  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

2013-12-11 Thread Brion Vibber

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  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  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

2013-12-11 Thread Chad

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 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  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 
> 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

2013-12-11 Thread Jon Robson

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 
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  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  wrote:
>>
>> > For wider discussion
>> >
>> > ---
>> > From:  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)
>> >
>> > https://bugzilla.wikimedia.org/sho

Re: [Wikitech-l] Linking gerrit project pages to gitweb

2013-12-11 Thread Brion Vibber

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  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  >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  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 
> > 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

2013-12-11 Thread Brion Vibber

Filed as http://code.google.com/p/gerrit/issues/detail?id=2335

-- brion


On Wed, Dec 11, 2013 at 11:15 AM, Brion Vibber 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  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 > >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 
>> 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 
>> > 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

2013-12-11 Thread Chad

On Wed, Dec 11, 2013 at 11:04 AM, Jon Robson  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

2013-12-11 Thread Matthew Walker

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 wrote:

> Filed as http://code.google.com/p/gerrit/issues/detail?id=2335
>
> -- brion
>
>
> On Wed, Dec 11, 2013 at 11:15 AM, Brion Vibber  >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  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  >> >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 
> >> 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 
> >> > 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

2013-12-11 Thread Tyler Romeo

On Wed, Dec 11, 2013 at 2:04 PM, Jon Robson  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

2013-12-11 Thread Matthew Walker

"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  wrote:

> On Wed, Dec 11, 2013 at 11:04 AM, Jon Robson  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

2013-12-11 Thread Diederik van Liere

On Wed, Nov 27, 2013 at 2:55 PM, Jon Robson  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
>  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

2013-12-11 Thread Brad Jorsch (Anomie)

On Wed, Dec 11, 2013 at 2:54 PM, Matthew Walker  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

2013-12-11 Thread Chad

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 
> 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

2013-12-11 Thread Matthew Walker

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  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 
> > 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

2013-12-11 Thread Isarra Yos


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

2013-12-11 Thread Brian Wolff

On 12/11/13, Tyler Romeo  wrote:
> On Wed, Dec 11, 2013 at 2:04 PM, Jon Robson  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

2013-12-11 Thread Jeroen De Dauw

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

2013-12-11 Thread Nathan Larson

On Wed, Dec 11, 2013 at 2:38 PM, Tyler Romeo  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

2013-12-11 Thread Brad Jorsch (Anomie)

On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff  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

2013-12-11 Thread Tyler Romeo

On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff  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

2013-12-11 Thread Nathan Larson

On Wed, Dec 11, 2013 at 3:30 PM, Tyler Romeo  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

2013-12-11 Thread Rob Lanphier

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

2013-12-11 Thread Brian Wolff

On 12/11/13, Tyler Romeo  wrote:
> On Wed, Dec 11, 2013 at 3:19 PM, Brian Wolff  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

2013-12-11 Thread Bryan Davis

On Wed, Nov 27, 2013 at 12:55 PM, Jon Robson  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 Foundation
[[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

2013-12-11 Thread Ryan Lane

On Wed, Dec 11, 2013 at 3:21 PM, Jeroen De Dauw wrote:

> 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

2013-12-11 Thread Jeroen De Dauw

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

2013-12-11 Thread Ryan Lane

On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw 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.

- 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

2013-12-11 Thread Matthew Walker

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 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] Wikimedia Commons Video Uploads waiting (Bug #58155)

2013-12-11 Thread Antoine Musso

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

2013-12-11 Thread Matthew Walker

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 wrote:

> 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

2013-12-11 Thread Jon Robson

> 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

2013-12-11 Thread Jon Robson

Thanks guys!


On Wed, Dec 11, 2013 at 11:32 AM, Matthew Walker  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 wrote:
>
>> Filed as http://code.google.com/p/gerrit/issues/detail?id=2335
>>
>> -- brion
>>
>>
>> On Wed, Dec 11, 2013 at 11:15 AM, Brion Vibber > >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  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 > >> >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 
>> >> 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 
>> >> > 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

2013-12-11 Thread Matthew Walker

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  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)

2013-12-11 Thread Brian Wolff

On 12/11/13, Antoine Musso  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

2013-12-11 Thread Isarra Yos


On 11/12/13 22:21, Ryan Lane wrote:

On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw 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.

- 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

2013-12-11 Thread Petr Bena

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  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

2013-12-11 Thread Isarra Yos


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

2013-12-11 Thread Tyler Romeo

On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw wrote:

> (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)

2013-12-11 Thread Tyler Romeo

:/ 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  wrote:

> On 12/11/13, Antoine Musso  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

2013-12-11 Thread Chad

On Wed, Dec 11, 2013 at 3:50 PM, Isarra Yos  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

2013-12-11 Thread Tyler Romeo

On Wed, Dec 11, 2013 at 4:13 PM, Brian Wolff  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

2013-12-11 Thread Bartosz Dziewoński


On Wed, 11 Dec 2013 21:30:15 +0100, Tyler Romeo  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

2013-12-11 Thread Chad

On Wed, Dec 11, 2013 at 3:58 PM, Tyler Romeo  wrote:

> On Wed, Dec 11, 2013 at 4:13 PM, Brian Wolff  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

2013-12-11 Thread Tyler Romeo

On Wed, Dec 11, 2013 at 7:15 PM, Chad  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

2013-12-11 Thread Chad

On Wed, Dec 11, 2013 at 4:19 PM, Tyler Romeo  wrote:

> On Wed, Dec 11, 2013 at 7:15 PM, Chad  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)

2013-12-11 Thread Brian Wolff

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"  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  wrote:
>
> > On 12/11/13, Antoine Musso  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

2013-12-11 Thread Bartosz Dziewoński


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

2013-12-11 Thread Bartosz Dziewoński


On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson  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)

2013-12-11 Thread Terry Chay

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

2013-12-11 Thread Daniel Friesen

On 2013-12-11 4:52 PM, Bartosz Dziewoński wrote:
> On Wed, 11 Dec 2013 23:35:43 +0100, Jon Robson 
> 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

2013-12-11 Thread MZMcBride

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

2013-12-11 Thread Rob Lanphier

On Wed, Dec 11, 2013 at 2:21 PM, Ryan Lane  wrote:

> On Wed, Dec 11, 2013 at 5:11 PM, Jeroen De Dauw  >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

2013-12-11 Thread Nathan Larson

On Thu, Dec 12, 2013 at 12:03 AM, Rob Lanphier  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

2013-12-11 Thread Chad

+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"  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

77 matches

Mail list logo