Re: [Wikitech-l] [WikimediaMobile] Mobile article preview gadget

2014-10-12 Thread Brion Vibber 
I've taken the liberty of adding this to the gadgets proposals page on
en.wikipedia:
https://en.wikipedia.org/wiki/Wikipedia:Gadget/proposals#Mobile_sidebar

If no objection I'll set it up tomorrow.

Also I put the .js and .css files on github for easier patching:
https://github.com/brion/MediaWiki-MobileSidebar

-- brion

On Sun, Oct 12, 2014 at 6:07 PM, Brion Vibber  wrote:

> Awesome! I've made some further updates, and there's now a toggle button
> on the tab bar, next to the watchlist star, so the mobile view can be
> turned on and off at will.
>
> Note that since it now uses an external stylesheet, to include the copies
> from  my meta page now takes two imports:
>
> // Mobile sidebar
> mw.loader.load('
> https://meta.wikimedia.org/w/index.php?action=raw&title=User:Brion_VIBBER/mobile-sidebar.js&ctype=text/javascript',
> 'text/javascript');
> mw.loader.load('
> https://meta.wikimedia.org/w/index.php?action=raw&title=User:Brion_VIBBER/mobile-sidebar.css&ctype=text/css',
> 'text/css');
>
> -- brion
>
> On Fri, Oct 10, 2014 at 10:33 PM, Prateek Saxena 
> wrote:
>
>> On Fri, Oct 10, 2014 at 1:15 PM, Brion Vibber 
>> wrote:
>> > This shows the currently viewed page on the mobile view in an 
>> > sidebar, and captures link navigation within the iframe to navigate on
>> the
>> > desktop window as well.
>>
>> I really like this :)
>>
>>
>> > Todo:
>> > * add an on/off switch
>> > * pretty it up
>>
>> I added just an off switch and prettied it up a little. I just refresh
>> the page to turn it back on for now. I have an idea for putting the
>> size selection UI which I'll add later.
>>
>> http://cl.ly/XzUa
>> https://meta.wikimedia.org/wiki/User:Prtksxna/common.js
>> https://meta.wikimedia.org/wiki/User:Prtksxna/common.css
>>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

2014-10-12 Thread Arlo Breault 
On Sunday, October 12, 2014 at 4:45 PM, Marc A. Pelletier wrote:
> On 10/12/2014 12:50 PM, Arlo Breault wrote:
> > The people on this list can best answer that.
>  
>  
> What the people on this list cannot answer is /whether/ and under what
> conditions it would desirable to allow proxy editing in the first place.
>  
The “that” I was referring to was whether the rate limiting,  
as I described it above, was technically feasible.

Sorry if that wasn’t clear.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bugzilla Weekly Report

2014-10-12 Thread reporter 
MediaWiki Bugzilla Report for October 06, 2014 - October 13, 2014

Status changes this week

Reports changed/set to UNCONFIRMED:  5 
Reports changed/set to NEW:  25
Reports changed/set to ASSIGNED   :  25
Reports changed/set to REOPENED   :  7 
Reports changed/set to PATCH_TO_RE:  70
Reports changed/set to RESOLVED   :  258   
Reports changed/set to VERIFIED   :  8 

Total reports still open  : 15755 
Total bugs still open : 9559  
Total non-lowest prio. bugs still open: 9231  
Total enhancements still open : 6196  

Reports created this week: 301   

Resolutions for the week:

Reports marked FIXED :  191   
Reports marked DUPLICATE :  22
Reports marked INVALID   :  7 
Reports marked WORKSFORME:  18
Reports marked WONTFIX   :  17

Specific Product/Component Resolutions & User Metrics 

Created reports per component

OCG   PDF renderer  22  
  
VisualEditor  Editing Tools 15  
  
MediaWiki extensions  Collection14  
  
MediaWiki extensions  WikidataRepo  13  
  
MediaWiki extensions  Flow  11  
  

Created reports per product

MediaWiki extensions  112   
Wikimedia 32
OCG   31
MediaWiki 29
VisualEditor  28

Top 5 bug report closers

jrobson [AT] wikimedia.org28
jforrester [AT] wikimedia.org 21
aklapper [AT] wikimedia.org   11
krinklemail [AT] gmail.com9 
roan.kattouw [AT] gmail.com   9 


Most urgent open issues

Product   | Component | BugID | Priority  | LastChange | Assignee   
  | Summary  
--
Analytics | Dashiki   | 70871 | Highest   | 2014-09-16 | 
wikibugs-l[AT]lists. | Update metric classification in Vital

Analytics | Dashiki   | 70887 | Immediate | 2014-10-03 | 
nuria[AT]wikimedia.o | Story: EEVSUser loads dashboard from 

Analytics | Refinery  | 68246 | Highest   | 2014-10-01 | 
wikibugs-l[AT]lists. | Story: AnalyticsEng has kafkatee on a

Analytics | Refinery  | 68139 | Highest   | 2014-10-01 | 
wikibugs-l[AT]lists. | Epic: AnalyticsEng has kafkatee runni

Analytics | Refinery  | 68247 | Highest   | 2014-10-01 | 
wikibugs-l[AT]lists. | Story: AnalyticsEng generates new dat

Analytics | Wikimetrics   | 69252 | Highest   | 2014-08-07 | 
wikibugs-l[AT]lists. | Epic: AnalyticsEng has robust code to

Analytics | Wikimetrics   | 69253 | Highest   | 2014-08-08 | 
wikibugs-l[AT]lists. | Story: AnalyticsEng uses TimeSeries s

Analytics | Wikimetrics   | 69145 | Highest   | 2014-08-08 | 
wikibugs-l[AT]lists. | Story: AnalyticsEng has editor_day ta

Analytics | Wikimetrics   | 69397 | Highest   | 2014-08-14 | 
wikibugs-l[AT]lists. | Wikimetrics backup has no monitoring 

MediaWiki ext | CentralAuth   | 71676 | Highest   | 2014-10-06 | 
legoktm.wikipedia[AT | GlobalRename: do user subpage moves i

MediaWiki ext | OAuth | 57336 | Highest   | 2014-09-10 | 
wikibugs-l[AT]lists. | Make metawiki the central OAuth wiki 

MediaWiki ext | WikibaseQuery | 67533 | Highest   | 2014-09-11 | 
csteipp[AT]wikimedia | security review of WikibaseQuery 

MediaWiki ext | WikibaseQuery | 67534 | Highest   | 2014-10-02 | 
aschulz4587[AT]gmail | performance review of WikibaseQuery  

MediaWiki ext | WikibaseQuery | 67536 | Highest   | 2014-09-11 | 
csteipp[AT]wikimedia | security review of WikibaseQueryEngin

MediaWiki ext | WikibaseQuery | 67535 | Highest   | 2014-10-03 | 
aschulz4587[AT]gmail | performance review of WikibaseQueryEn

MediaWiki ext | WikidataRepo  | 70398 | Highest   | 2014-10-02 | 
wikidata-bugs[AT]lis | UI broken for Julian calendar model d

MediaWiki ext | WikidataRepo  | 52385 | Highest   | 2014-10-03 | 
wikidata-bugs[AT]lis | Query by one property and one value (

MediaWiki ext | WikidataRepo  | 71667 | Highest   | 2014-10-06 | 
wikidata-bugs[AT]lis | unable to open items (InvalidArgument

OCG   | General/Unk

Re: [Wikitech-l] [WikimediaMobile] Mobile article preview gadget

2014-10-12 Thread Brion Vibber 
On Sat, Oct 11, 2014 at 2:27 AM, Prateek Saxena 
wrote:

> On Fri, Oct 10, 2014 at 1:15 PM, Brion Vibber 
> wrote:
> > Todo:
> > * make a couple common sizes selectable instead of just 320x480?
>
> The next size would be 480×800 which did not even fit on my screen.
> Even though I tested with some UI controls I don't think it makes
> sense put something that large on the screen. I instead added a link
> to the page that I could open in a new tab and then let the inspector
> resize it.
>

Note that mobile devices often have a scaling factor which needs to be
compensated for; 480x800 mobile screens usually have a density of 1.5x
which means they'd cover just 320x533 CSS pixels. And let's not even start
on the iPhone 6 Plus, which has a different physical resolution from the
rendering resolution (ag!)


> PS: Find the easter egg without looking at the code
>

A :D

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

Re: [Wikitech-l] [WikimediaMobile] Mobile article preview gadget

2014-10-12 Thread Brion Vibber 
Awesome! I've made some further updates, and there's now a toggle button on
the tab bar, next to the watchlist star, so the mobile view can be turned
on and off at will.

Note that since it now uses an external stylesheet, to include the copies
from  my meta page now takes two imports:

// Mobile sidebar
mw.loader.load('
https://meta.wikimedia.org/w/index.php?action=raw&title=User:Brion_VIBBER/mobile-sidebar.js&ctype=text/javascript',
'text/javascript');
mw.loader.load('
https://meta.wikimedia.org/w/index.php?action=raw&title=User:Brion_VIBBER/mobile-sidebar.css&ctype=text/css',
'text/css');

-- brion

On Fri, Oct 10, 2014 at 10:33 PM, Prateek Saxena 
wrote:

> On Fri, Oct 10, 2014 at 1:15 PM, Brion Vibber 
> wrote:
> > This shows the currently viewed page on the mobile view in an 
> > sidebar, and captures link navigation within the iframe to navigate on
> the
> > desktop window as well.
>
> I really like this :)
>
>
> > Todo:
> > * add an on/off switch
> > * pretty it up
>
> I added just an off switch and prettied it up a little. I just refresh
> the page to turn it back on for now. I have an idea for putting the
> size selection UI which I'll add later.
>
> http://cl.ly/XzUa
> https://meta.wikimedia.org/wiki/User:Prtksxna/common.js
> https://meta.wikimedia.org/wiki/User:Prtksxna/common.css
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

2014-10-12 Thread Marc A. Pelletier 
On 10/12/2014 12:50 PM, Arlo Breault wrote:
> The people on this list can best answer that.

What the people on this list cannot answer is /whether/ and under what
conditions it would desirable to allow proxy editing in the first place.

-- Marc


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

Re: [Wikitech-l] Php files under the test directory

2014-10-12 Thread Divyanshi Kathuria 
On 12-Oct-2014 9:35 PM, "Brian Wolff"  wrote:
> @dataProvider
> annotation needs to take the name of the function that is the provider not
> just "Provider"). I suggest you try looking at other code that uses
> @dataProvider to try to find an example, or read through the section of
the
> PHPUnit docs on data providers.
Thanks for pointing out the mistakes. :) I ll make the required changes.

Divyanshi Kathuria
divyanshikathuria27.wordpress.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

2014-10-12 Thread Arlo Breault 
> Unless there is further discussion to be had on a new *technical* solution
> to Tor users, this is the wrong mailing list to be making these proposals.
> At the very least take it to the main wikimedia list, or on-wiki, where
> this is a lot more relevant.

Thanks Tyler. I kept the discussion going here because it sounded above
like Derric may already be in the process of doing that and I wanted to keep
a unified voice there.

Although my suggestion is similar in kind to what had already been proposed,
the main object to it was that it would create too much work for our
already constrained resources. The addition of rate limiting is a technical
solution that may or may not be feasible.

The people on this list can best answer that.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Php files under the test directory

2014-10-12 Thread Brian Wolff 
On Oct 12, 2014 10:13 AM, "Divyanshi Kathuria" 
wrote:
>
> On Thu, Oct 09, 2014 at 09:54:03PM +0200, dan entous wrote:
>  this would be the best way to achieve what's needed. in any case, i
believe this is the general idea antoine is getting at.
>
> Thank You so much for your help. I have tried to incorporate data
providers according to the changes you mentioned.
> Here is the file :
https://gist.github.com/divyanshikathuria/e5a09b50f65779f92c69
> Please see if it is correct and suggest the necessary changes.
>
> --
> Divyanshi Kathuria
> divyanshikathuria27.wordpress.com
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

No, that's not quite right (indentation is wrong, the @dataProvider
annotation needs to take the name of the function that is the provider not
just "Provider"). I suggest you try looking at other code that uses
@dataProvider to try to find an example, or read through the section of the
PHPUnit docs on data providers.

For this type of review like question, its probably better to ask on the
bug instead of the mailing list unless noone is responding on the bug.

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

Re: [Wikitech-l] Introduction for OPW (Collaborative spelling dictionary building tool)

2014-10-12 Thread Brian Wolff 
On Oct 12, 2014 6:54 AM, "Quim Gil"  wrote:
>
> Hi Ankita,
>
> On Fri, Oct 10, 2014 at 11:06 PM, Ankita Shukla 
> wrote:
>
> > Hello everyone!
> >
> > I am Ankita Shukla and am a Computer Science and Engineering student
> > pursuing
> > the junior year of Bachelor of Technology.
> >
> > I am interested in working on the project: Collaborative spelling
> > dictionary
> > building tool, as given on the Featured Projects Section of MediaWiki
OPW
> > page.
> >
>
>
https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Collaborative_spelling_dictionary_building_tool
> is mentored by Kartik and Amir (explicitly CCed above). There should have
> been a link to a Bugzilla report where you and other candidates interested
> could ask questions directly and discuss the project. I have created that
> report now:
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=71973
>
> Please follow up there.
>
> Let me also paste the description of that project idea, just in case other
> contributors in this list want to help defining it:
>
> There are extensive spelling dictionaries for the major languages of the
> world: English, Italian, French and some others; at various degrees of
> coverage, Mozilla has over a hundred
> ,LibreOffice dozens
> .
They
> help make Wikipedia articles in these languages more readable and
> professional and provide an opportunity for participation in improving
> spelling. Many other languages, however, don’t have spelling dictionaries.
> One possible way to build good spelling dictionaries would be to employ
> crowdsourcing, and Wikipedia editors can be a good source for this, but
> this approach will also require a robust system in which language experts
> will be able to manage the submissions: accept, reject, filter and build
> new versions of the spelling dictionary upon them. This can be done as a
> MediaWiki extension integrated with VisualEditor, and possibly use
Wikidata
> as a backend.
>
>- Skills: PHP, Web frontend. Bonus: Familiarity with VisualEditor and
>Wikidata; experience in an existing dictionary-building community.
>- Mentors: Amir Aharoni
>, Kartik Mistry
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

How would such a thing interact with the wiktionary community. Would it
harvest data from them or be a sub project somehow, or is it planned to be
entirely separate?

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

Re: [Wikitech-l] Php files under the test directory

2014-10-12 Thread Divyanshi Kathuria 
On Thu, Oct 09, 2014 at 09:54:03PM +0200, dan entous wrote:
 this would be the best way to achieve what's needed. in any case, i believe 
this is the general idea antoine is getting at.

Thank You so much for your help. I have tried to incorporate data providers 
according to the changes you mentioned. 
Here is the file : 
https://gist.github.com/divyanshikathuria/e5a09b50f65779f92c69
Please see if it is correct and suggest the necessary changes. 

-- 
Divyanshi Kathuria
divyanshikathuria27.wordpress.com


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

Re: [Wikitech-l] Introduction for OPW (Collaborative spelling dictionary building tool)

2014-10-12 Thread Ankita Shukla 
Hi Quim and Pine,

Thanks for the response.
I'll keep everyone updated about the progress. :)
Also, I'll follow up on the bugzilla report now on.

Thanks a lot!
Ankita Shukla


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

Re: [Wikitech-l] Introduction for OPW (Collaborative spelling dictionary building tool)

2014-10-12 Thread Quim Gil 
Hi Ankita,

On Fri, Oct 10, 2014 at 11:06 PM, Ankita Shukla 
wrote:

> Hello everyone!
>
> I am Ankita Shukla and am a Computer Science and Engineering student
> pursuing
> the junior year of Bachelor of Technology.
>
> I am interested in working on the project: Collaborative spelling
> dictionary
> building tool, as given on the Featured Projects Section of MediaWiki OPW
> page.
>

https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9#Collaborative_spelling_dictionary_building_tool
is mentored by Kartik and Amir (explicitly CCed above). There should have
been a link to a Bugzilla report where you and other candidates interested
could ask questions directly and discuss the project. I have created that
report now:

https://bugzilla.wikimedia.org/show_bug.cgi?id=71973

Please follow up there.

Let me also paste the description of that project idea, just in case other
contributors in this list want to help defining it:

There are extensive spelling dictionaries for the major languages of the
world: English, Italian, French and some others; at various degrees of
coverage, Mozilla has over a hundred
,LibreOffice dozens
. They
help make Wikipedia articles in these languages more readable and
professional and provide an opportunity for participation in improving
spelling. Many other languages, however, don’t have spelling dictionaries.
One possible way to build good spelling dictionaries would be to employ
crowdsourcing, and Wikipedia editors can be a good source for this, but
this approach will also require a robust system in which language experts
will be able to manage the submissions: accept, reject, filter and build
new versions of the spelling dictionary upon them. This can be done as a
MediaWiki extension integrated with VisualEditor, and possibly use Wikidata
as a backend.

   - Skills: PHP, Web frontend. Bonus: Familiarity with VisualEditor and
   Wikidata; experience in an existing dictionary-building community.
   - Mentors: Amir Aharoni
   , Kartik Mistry
   
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Registration Open: MediaWiki Developer Summit 2015

2014-10-12 Thread Quim Gil 
On Sat, Oct 11, 2014 at 7:28 AM, Tony Thomas <01tonytho...@gmail.com> wrote:

> On Tue, Oct 7, 2014 at 5:00 AM, Rachel Farrand 
> wrote:
>
> >
> >- Scholarship registration opened on September 18th and will *close on
> >October 19th*.
>
>
> Its open ?
>
> https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Travel_sponsorship
> says coming soon.


Sorry, we forgot to update the wiki page. Please register by October 19;
the options to request travel sponsorship are included in the same form.

https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015#Registration



> Or should we request in meta.wikimedia.org/wiki/Grants:TPS?
>

No, in this case the decision will be made directly by us.

PS: you can even subscribe to https://phabricator.wikimedia.org/T567 to
follow progress.  :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

2014-10-12 Thread Tyler Romeo 
On Sun, Oct 12, 2014 at 3:24 AM, Arlo Breault 
wrote:

> Proposal:


Unless there is further discussion to be had on a new *technical* solution
to Tor users, this is the wrong mailing list to be making these proposals.
At the very least take it to the main wikimedia list, or on-wiki, where
this is a lot more relevant.

*-- *
*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] Tor and Anonymous Users (I know, we've had this discussion a million times)

2014-10-12 Thread Arlo Breault 
Thanks for initiating the conversation Derric. I've tried to put together a
proposal addressing the general problem of allowing edits from a proxy.
Feedback is appreciated.

Proposal:

* Require an account to edit via proxy.

* Allow creating accounts from proxies but globally rate limit account creations
  from all proxies (to once per five mins? or some data driven number that makes
  sense).

* Tag any edits made through a proxy as such and put them in a queue.

* Limit the amount of edits in that queue per account (to one? again, look at
  the data).

* Apply a first pass of abuse filtering on those edits before notifying a human
  of their presence to approve.

* Rate limit global proxy edits per second to something manageable (see data)

This limits the amount of backlog work a single user can create to how many
captchas they can solve / accounts they can create. But I think it's enough a
deterrent in that 1) their edits aren't immediately visible, 2) if they're
abusive, they won't show up on the site at all, and 3) it forces the act to
premeditated creation of accounts which can be associated at the time of an
attack and deleted together.

Rate limiting account creation seems to open a DOS vector but combining
that with the captcha hopefully helps.

Attribution / Licensing:

As a consequence of requiring an account to edit via proxy, we avoid the
issue of attributing edits to a shared IP.

Sybil attack:

Or, as it's called around here, sockpuppeting. CheckUser would presumably
provide less useful information but the edit history of the accounts would
still lend themselves to the same sorts of behavioural evidence gathering
that is undertaken at present.

Class system:

This makes a set of users concerned about their security and privacy trade off
some usability but that seems acceptable.

A reputation threshold for proxy users can be introduced. After a substantial
amount of edits and enough time has lapsed, the above edit restrictions can be
lifted from an account. Admins would still have recourse to block/suspend the
account if it becomes abusive.

Blacklisting:

Anonymous credential systems (like Nymble) are interesting research directions
but the appropriate collateral to use is still unsolved.

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