[Wikitech-l] IRC web client for Wikipedia help

[Pine W]

Hi,

Following up on a conversation on the gendergap email list, I am discussing
with Freenode the possibility of changing the default web client to one
that is friendlier and has a less technical feel, primarily for the benefit
of new users who access #wikipedia-en-help by clicking on a link. The
likely candidate for a new IRC client is Kiwi. If Freenode wants to
maintain their current default web client we can still use Kiwi if we run
it on Wikimedia pages. Would WMF or the volunteer dev community be willing
to implement this? If so, is filing a Bugzilla bug the best way to get the
wheels of progress to turn?

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

Re: [Wikitech-l] DB deadlock on Mediawiki 1.23.2 with VisualEditor and Parsoid

[C. Scott Ananian]

What seems like a deadlock may in fact be parsoid timing out while
trying to connect to your local wiki's API end point.  We have had
some users report problems of this sort which were caused by their
firewall or access control setup.  You might want to verify that the
API end point for your local wiki is configured correctly, and that
you can successfully connect to it from the machine Parsoid is running
on.
  --scott

On Sun, Aug 10, 2014 at 11:56 PM, Bjoern Kahl  wrote:
>
> Am 10.08.14 um 20:52 schrieb Gabriel Wicke:
>> On 08/10/2014 04:10 PM, Bjoern Kahl wrote:
>>>  What could cause this behavior and how should I configure my system to
>>>  prevent the deadlocks?  If this is a Bug in either MediWiki or the
>>>  VisualEditor or Parsoid, how to further investigate and fix it?
>>
>> In case this is a private wiki:
>>
>> Did you set $wgSessionsInObjectCache = true;
>>
>> following the instructions at
>> https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis
>> ?
>
>  Yes, I have (and had) "$wgSessionsInObjectCache = true;" in my
>  LocalSettings.php
>
>  I have just disabled it (set to false) to counter-check, and it does
>  produce a different sequence of activities.  On a first glance, it
>  seems to stop earlier, but in the end process and answer three calls
>  from Parsoid instead of zero.
>
>  I'll have a closer look tomorrow, for today it's to late (1 in the
>  morning (1 CEST / 23 UTC))
>
>
>  Thanks
>
> Björn
>
> --
> | Bjoern Kahl   +++   Siegburg   +++Germany |
> | "googlelogin@-my-domain-"   +++   www.bjoern-kahl.de  |
> | Languages: German, English, Ancient Latin (a bit :-)) |
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
(http://cscott.net)

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

[Wikitech-l] Bugzilla Weekly Report

[reporter]

MediaWiki Bugzilla Report for August 04, 2014 - August 11, 2014

Status changes this week

Reports changed/set to UNCONFIRMED:  1 
Reports changed/set to NEW:  23
Reports changed/set to ASSIGNED   :  10
Reports changed/set to REOPENED   :  5 
Reports changed/set to PATCH_TO_RE:  76
Reports changed/set to RESOLVED   :  239   
Reports changed/set to VERIFIED   :  12

Total reports still open  : 15468 
Total bugs still open : 9381  
Total non-lowest prio. bugs still open: 9105  
Total enhancements still open : 6087  

Reports created this week: 296   

Resolutions for the week:

Reports marked FIXED :  155   
Reports marked DUPLICATE :  14
Reports marked INVALID   :  14
Reports marked WORKSFORME:  25
Reports marked WONTFIX   :  23

Specific Product/Component Resolutions & User Metrics 

Created reports per component

MediaWiki extensions  Translate 16  
  
Analytics Quarry11  
  
Pywikibot General   10  
  
VisualEditor  Editing Tools 9   
  
Analytics Wikimetrics   8   
  

Created reports per product

MediaWiki extensions  84
MediaWiki 39
Wikimedia 38
Analytics 25
VisualEditor  24

Top 5 bug report closers

aklapper [AT] wikimedia.org   21
twkozlowski [AT] gmail.com17
hashar [AT] free.fr   14
dbrant [AT] wikimedia.org 12
jforrester [AT] wikimedia.org 11


Most urgent open issues

Product   | Component | BugID | Priority  | LastChange | Assignee   
  | Summary  
--
Analytics | EventLogging  | 68931 | Highest   | 2014-08-08 | 
christian[AT]quellte | Cleaning up of some (?) EventLogging 

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

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

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

Analytics | Visualization | 68351 | Highest   | 2014-08-07 | 
wikibugs-l[AT]lists. | Story: AnalyticsEng has website for E

Analytics | Wikimetrics   | 68445 | Highest   | 2014-07-29 | 
wikibugs-l[AT]lists. | Story: EEVSUser downloads report with

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   | 68731 | Highest   | 2014-08-08 | 
wikibugs-l[AT]lists. | Backing up wikimetrics data fails if 

Analytics | Wikimetrics   | 68833 | Highest   | 2014-08-08 | 
wikibugs-l[AT]lists. | session management   

Analytics | Wikimetrics   | 68840 | Highest   | 2014-08-08 | 
wikibugs-l[AT]lists. | Wikimetrics can't run a lot of recurr

MediaWiki | Skin and page | 66608 | Highest   | 2014-07-31 | 
wikibugs-l[AT]lists. | XSS in mediawiki.page.image.paginatio

MediaWiki ext | ContentTransl | 68214 | Highest   | 2014-07-18 | 
wikibugs-l[AT]lists. | Translations don't give attribution p

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

MediaWiki ext | WikibaseQuery | 67534 | Highest   | 2014-07-28 | 
ori[AT]wikimedia.org | performance review of WikibaseQuery  

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

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

MediaWiki ext | WikibaseQuery

Re: [Wikitech-l] Recommended way to change a lot of absolute links at wiki

[Benjamin Lees]

If you simply remove the timestamp from a revision in a dump, the importer
appears to happily insert it with the current time as the timestamp.  This
may also cause cancer, summon Cthulhu, etc.

In addition to pywikibot, there's the Replace Text extension[0], which
ought to be able to handle what you want to do.

[0] https://www.mediawiki.org/wiki/Extension:Replace_Text
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[James HK]

Hi,

> etc. These are important capabilities of the wiki that have been used
> for many clearly beneficial purposes. In the long run, we will want to
> apply a code review process to these changes as with any other
> deployed code, but for now the system works as it is and we have no
> intent to remove this capability.

I first thought when witnessing the explicit removal of some lines of
code from the German MediaWiki:Common.js [0] followed by the
alteration of permission (meaning the assignment of the newly created
 right) to the same page was a coincidence.

Now, having observed that not only user Eloquence (aka Erik Moeller)
himself engaged in the enforcement of   right on de.wp
[1] but soon after a workaround was published a change was deployed
[2, 3] as counter measurement to block any possible interference can
no longer be interpret as acting in good faith but rather strikes me
as a form of oppression (or worst as censorship).

> This protection level provides an additional path to manage these
> situations by preventing edits to the relevant pages (we're happy to
> help apply any urgent edits) until a particular situation has calmed
> down.

What situation did emerge that such drastic measures were/are necessary?

[0] 
https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=prev&oldid=132946422

[1] 
https://de.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&action=historysubmit&diff=132951396&oldid=132951390

[2] https://gerrit.wikimedia.org/r/#/c/153345/ +
https://gerrit.wikimedia.org/r/#/c/153351/

[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=69380

Cheers

On 8/10/14, Erik Moeller  wrote:
> Hi folks,
>
> Admins are currently given broad leeway to customize the user
> experience for all users, including addition of site-wide JS, CSS,
> etc. These are important capabilities of the wiki that have been used
> for many clearly beneficial purposes. In the long run, we will want to
> apply a code review process to these changes as with any other
> deployed code, but for now the system works as it is and we have no
> intent to remove this capability.
>
> However, we've clarified in a number of venues that use of the
> MediaWiki: namespace to disable site features is unacceptable. If such
> a conflict arises, we're prepared to revoke permissions if required.
> This protection level provides an additional path to manage these
> situations by preventing edits to the relevant pages (we're happy to
> help apply any urgent edits) until a particular situation has calmed
> down.
>
> Thanks,
> Erik
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> 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] [Translators-l] Thank you for Tech News & see you soon

[svetlana]

On Mon, 11 Aug 2014, at 04:07, Tomasz W. Kozłowski wrote:
> Philippe,
> the patch is not for the MediaWiki software but for the configuration
> of Wikimedia wikis (it's in the operations/mediawiki-config repository
> on Gerrit).
> 
> It has been merged and deployed on the production cluster. The user
> right has been added to the global staff user group, and it has
> already been used to protect the MediaWiki:Common.js page on the
> German Wikipedia so that no one can edit it except Wikimedia
> Foundation employees.
> 
> Wikimedia Foundation is using this user right to actively fight its
> community of volunteers.
> 
> This is something I cannot and will not support.
> 
> Tomasz
> 

completely agree with 100% of the above
cc'ing 2 more lists

ftr, the change discussed is: 

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

Re: [Wikitech-l] DB deadlock on Mediawiki 1.23.2 with VisualEditor and Parsoid

[Bjoern Kahl]

Am 10.08.14 um 20:52 schrieb Gabriel Wicke:
> On 08/10/2014 04:10 PM, Bjoern Kahl wrote:
>>  What could cause this behavior and how should I configure my system to
>>  prevent the deadlocks?  If this is a Bug in either MediWiki or the
>>  VisualEditor or Parsoid, how to further investigate and fix it?
> 
> In case this is a private wiki:
> 
> Did you set $wgSessionsInObjectCache = true;
> 
> following the instructions at
> https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis
> ?

 Yes, I have (and had) "$wgSessionsInObjectCache = true;" in my
 LocalSettings.php

 I have just disabled it (set to false) to counter-check, and it does
 produce a different sequence of activities.  On a first glance, it
 seems to stop earlier, but in the end process and answer three calls
 from Parsoid instead of zero.

 I'll have a closer look tomorrow, for today it's to late (1 in the
 morning (1 CEST / 23 UTC))


 Thanks

Björn

-- 
| Bjoern Kahl   +++   Siegburg   +++Germany |
| "googlelogin@-my-domain-"   +++   www.bjoern-kahl.de  |
| Languages: German, English, Ancient Latin (a bit :-)) |



signature.asc
Description: OpenPGP digital signature
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Vito]

After VE fiasco I would had expected to see a less full of itself 
Wikimedia. I was wrong.


The Roman Empire strength was its ability to make Romans out of other peoples.
The wiki strenght is making editors and develepers out of netizens.
Rome felt before losing its ability.
Is wiki losing its one? Will it survive becoming a weird socialnetwork ran 
by a bunch of employee with no actual experience of daily editing?


Vito

Inviato con AquaMail per Android
http://www.aqua-mail.com


Il 10 agosto 2014 22:31:55 Tyler Romeo  ha scritto:


Wow this is pretty depressing, although in today's age I cannot say I'm
surprised. Corporations have always been about controlling their consumers,
and it was really only a matter of time before the WMF fell into that as
well. I wonder whether there's any legitimate justification for all of
this, or whether it's just a repeat of the VisualEditor fiasco, aka, "the
WMF knows best" kind of thing.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science


On Sun, Aug 10, 2014 at 3:19 PM, Siebrand Mazeland 
wrote:

>
> > Op 10 aug. 2014 om 20:12 heeft Ricordisamoa <
> ricordisa...@openmailbox.org> het volgende geschreven:
> >
> > I'd really like to hear Jimbo's opinion on the
> matter
>
> You should really watch Jimmy's speech at the Wikimania closing session.
> You might be surprised.
>
> Cheers!
>
> --
> Siebrand
> ___
> 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] Superprotect user right, Comming to a wiki near you

[Tyler Romeo]

Wow this is pretty depressing, although in today's age I cannot say I'm
surprised. Corporations have always been about controlling their consumers,
and it was really only a matter of time before the WMF fell into that as
well. I wonder whether there's any legitimate justification for all of
this, or whether it's just a repeat of the VisualEditor fiasco, aka, "the
WMF knows best" kind of thing.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science


On Sun, Aug 10, 2014 at 3:19 PM, Siebrand Mazeland 
wrote:

>
> > Op 10 aug. 2014 om 20:12 heeft Ricordisamoa <
> ricordisa...@openmailbox.org> het volgende geschreven:
> >
> > I'd really like to hear Jimbo's opinion on the
> matter
>
> You should really watch Jimmy's speech at the Wikimania closing session.
> You might be surprised.
>
> Cheers!
>
> --
> Siebrand
> ___
> 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] Superprotect user right, Comming to a wiki near you

[Siebrand Mazeland]

> Op 10 aug. 2014 om 20:12 heeft Ricordisamoa  
> het volgende geschreven:
> 
> I'd really like to hear Jimbo's opinion on the matter

You should really watch Jimmy's speech at the Wikimania closing session. You 
might be surprised.

Cheers!

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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Vito]

Superprotect is a feature, the way it will be used must be determined by 
consensus, on a theoretical basis there are different possible good uses. 
But, anyway, anyone using this feature should be accountable to the 
community, like anyone holding any advanced rights.


Vito

Inviato con AquaMail per Android
http://www.aqua-mail.com


Il 10 agosto 2014 20:01:19 Erwin Dokter  ha scritto:


On 10-08-2014 15:35, svetlana wrote:
>
> This change solves a problem that does not exist.
> We either trust sysops, or we don't.

I concur. There are enough admins available to revert bad code
additions. Also, this measure is completely without effect.

*Suppose* I were a rogue admin wanting to add some bad code to common.js
that disables some WMF feature; I will be reverted by staff and
common.js is superprotected.

Oh well, I'll just create a hidden default gadget... Happy hunting!

Regards,
--
Erwin Dokter


___
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] Superprotect user right, Comming to a wiki near you

[Ricordisamoa]

I'd really like to hear Jimbo's opinion on the matter

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

Re: [Wikitech-l] [Wikimedia-l] Superprotect user right, Comming to a wiki near you

[Tomasz W . Kozłowski]

This is, by far, the most disgusting and disrespectful action
undertaken by the Foundation that I have ever witnessed. The 2012 mass
desysopping of volunteer administrators on the WMF wiki and the past
threats of desysopping users re: VisualEditor and MediaViewer do not
even come close to this.

It is clear to me that the Foundation has agreed on this sneaky change
behind closed doors while some of the most outspoken Wikimedia
volunteers were (and still are) gathered in London. This is not the
first time that we're seeing this happpen, and it is clear to me that
the Foundation has lost all remaining moral authority to talk about
transparency and involving volunteers in the decision-making process.

Erik has forced his employees, including a so-called community
advocacy liaison, to use this opportunity to actively fight the
volunteer community of the German Wikipedia. He himself has engaged in
a wheel war over this, and continues to shove MediaViewer down the
German Wikipedia's community throat.

I'm not sure what was the purpose of this change, but if its aim was
to escalate the already tense situation between the WMF and its
volunteer communities regarding MediaViewer, protecting the
MediaWiki:Common.js page so that no one can edit it was the perfect
choice.

This action will cause a huge shitstorm, and Erik deserves every bit
of shit and mud that will be thrown his way.

You can force anything you like on your employees, but you cannot
force the volunteer community to do what you want, not in a manner
like this.

Remember that in the end, the community can exist without the WMF, but
there is no WMF without the community.

-- 
Tomasz

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

Re: [Wikitech-l] DB deadlock on Mediawiki 1.23.2 with VisualEditor and Parsoid

[Gabriel Wicke]

On 08/10/2014 04:10 PM, Bjoern Kahl wrote:
>  What could cause this behavior and how should I configure my system to
>  prevent the deadlocks?  If this is a Bug in either MediWiki or the
>  VisualEditor or Parsoid, how to further investigate and fix it?

In case this is a private wiki:

Did you set $wgSessionsInObjectCache = true;

following the instructions at
https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis
?

Gabriel

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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[MZMcBride]

Erwin Dokter wrote:
>On 10-08-2014 15:35, svetlana wrote:
>> This change solves a problem that does not exist.
>> We either trust sysops, or we don't.
>
>I concur. There are enough admins available to revert bad code
>additions. Also, this measure is completely without effect.
>
>*Suppose* I were a rogue admin wanting to add some bad code to common.js
>that disables some WMF feature; I will be reverted by staff and
>common.js is superprotected.
>
>Oh well, I'll just create a hidden default gadget... Happy hunting!

Page protection doesn't persist if you delete and restore the page, as a
German Wikipedia admin has now pointed out with "MediaWiki:Common.js".

I agree with svetlana as well: the security of the entire MediaWiki
infrastructure, which in turn is the security of a large portion of
Wikimedia wikis, relies on the idea that local administrators can be
trusted. Erik has now personally re-super-protected "MediaWiki:Common.js"
and he continues to stoke the fires of war with the German Wikipedia.

MZMcBride



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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Benjamin Lees]

This seems like an unfortunate escalation on the WMF's part.  Both sides
have a responsibility to try to work together, but as a practical matter,
the community does not answer to a single person, and the WMF staff do:
it's likely that the first olive branch is going to need to come from the
WMF side.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Erwin Dokter]

On 10-08-2014 15:35, svetlana wrote:


This change solves a problem that does not exist.
We either trust sysops, or we don't.


I concur. There are enough admins available to revert bad code 
additions. Also, this measure is completely without effect.


*Suppose* I were a rogue admin wanting to add some bad code to common.js 
that disables some WMF feature; I will be reverted by staff and 
common.js is superprotected.


Oh well, I'll just create a hidden default gadget... Happy hunting!

Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Ricordisamoa]

Il 10/08/2014 19:33, Ricordisamoa ha scritto:

Il 10/08/2014 15:27, Erik Moeller ha scritto:

Hi folks,

Admins are currently given broad leeway to customize the user
experience for all users, including addition of site-wide JS, CSS,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove this capability.

However, we've clarified in a number of venues that use of the
MediaWiki: namespace to disable site features is unacceptable. If such
a conflict arises, we're prepared to revoke permissions if required.
This protection level provides an additional path to manage these
situations by preventing edits to the relevant pages (we're happy to
help apply any urgent edits) until a particular situation has calmed
down.

Thanks,
Erik
https://meta.wikimedia.org/w/index.php?title=Special:Log&dir=prev&offset=20140810134614&limit=1&type=gblrights 



WMF vs. community?
https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotection
Updated link: 
https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotect_rights


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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Ricordisamoa]

Il 10/08/2014 15:27, Erik Moeller ha scritto:

Hi folks,

Admins are currently given broad leeway to customize the user
experience for all users, including addition of site-wide JS, CSS,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove this capability.

However, we've clarified in a number of venues that use of the
MediaWiki: namespace to disable site features is unacceptable. If such
a conflict arises, we're prepared to revoke permissions if required.
This protection level provides an additional path to manage these
situations by preventing edits to the relevant pages (we're happy to
help apply any urgent edits) until a particular situation has calmed
down.

Thanks,
Erik

https://meta.wikimedia.org/w/index.php?title=Special:Log&dir=prev&offset=20140810134614&limit=1&type=gblrights

WMF vs. community?
https://meta.wikimedia.org/wiki/Requests_for_comment/Superprotection

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

[Wikitech-l] DB deadlock on Mediawiki 1.23.2 with VisualEditor and Parsoid

[Bjoern Kahl]

 Dear All,

 I need some help tracking down a DB deadlock on a single-server,
 "private" Wiki installation running latest MediaWiki download
 from http://www.mediawiki.org/wiki/Download

 I have been referred to this mailing list from #mediawiki at
 irc.freenode.org, thanks for the pointer!


 Installed versions:
 ---

 - MediaWiki: 1.23.2

 - VisualEditor from Git, branch REL1_23, ID 9883566

 - Parsoid from Git, branch REL1_23, ID 8da3673

 - parsoid service from Git, branch master, ID df35443

 - mysql: 5.5.35, Debian wheezy package

 - apache:  2.2.22, Debian wheezy package

 - PHP: 5.4.4, Debian wheezy package

 - OS: Linux  3.2.0-4-686-pae #1 SMP Debian 3.2.57-3 i686 GNU/Linux

 MediaWiki, Parsoid (nodejs) service and mysql database are all on the
 same server.  Setup followed the instructions on
 https://www.mediawiki.org/wiki/Parsoid/Setup


 Problem description:
 

 Logging in, reading and editing using the standard (not visual) edit
 works fine.

 Clicking "Edit", which starts the visual editor, results in no
 reaction at all for approx 5 seconds, then the page goes dim and a
 progress indicator appears at the top right corner.

 After another approx. 100 seconds, the page returns to normal state
 as if opened or reading.


 Directly accessing the Parsoid service, here running on port 8000,
 promptly delivers the page.


 Preliminary investigation:
 --

 Enabling debugging in LocalSettings.php and tweaking wfDebugTimer()
 to get absolute millisecond timestamps and client address/port info
 in the log file showed the following sequences of activities
 (anonymized log files available if needed):

 Summarized:

 - client request page by calling
   "GET /wiki/api.php?format=json&action=visualeditor&paction=parse..."

 - MediaWiki starts processing and class the Parsoid service with
   "GET /testwiki/TestPage?oldid=4053 HTTP/1.0"

 - Parsoid service calls
   "GET /wiki/api.php?format=json&action=query&prop=revisions&..."

 - call from Parsoid server into MediaWiki API deadlocks with
   client call into API.

 The question is why is it deadlocking and how to prevent the deadlock.


 Detailed activities analysis:

 - (1) client accesses
   "GET /wiki/api.php?format=json&action=visualeditor&paction=parse..."

 - (2) MediaWiki starts some session bookkeeping, including opening a
   DB transaction with "BEGIN" and performing several queries in
   the transaction.

 - (3) MediaWiki/1.23.2 calls the parsoid service with
   "GET /testwiki/TestPage?oldid=4053 HTTP/1.0"

 - (4) Parsoid/0.1 calls
   "GET /wiki/api.php?format=json&action=query&prop=revisions&..."

 - (5) MediaWiki starts processing (in a new apache/PHP slave) and opens
   a new DB transaction with "BEGIN" performing the same initial
   "UPDATE `wiki_user` SET user_touched ..." query as first query in
   the transaction as in step (2).

 - (6) approx. 40 seconds pass

 - (7) Parsoid service drops connection from (4) to MediaWiki
   (TCP FIN packet observed by tcpdump while capturing the on-wire
   conversation between MediaWiki and the client / the Parsiod service)

 - (8) Parsoid/0.1 calls again
   "GET /wiki/api.php?format=json&action=query&prop=revisions&..."
   from a new connection (client port number changed)

 - (9) MediaWiki starts processing (in a new apache/PHP slave) and opens
   a new DB transaction with "BEGIN" performing the same initial
   "UPDATE `wiki_user` SET user_touched ..." query as first query in
   the transaction as in step (2) and (5).

 - (10) approx. 10 seconds pass

 - (11) MediaWiki receives a
   "SQL ERROR: Lock wait timeout exceeded; try restarting transaction"
   relating to transaction from step (5)

 - (12) MediaWiki attempts a ROLLBACK of (5) and tries to send a
   "HTTP 500" (content captured by tcpdump) but the connection is
   already dead.

 - (13) approx. 30 seconds pass

 - (14) Parsoid service drops connection from (8) to MediaWiki
   (TCP FIN packet observed by tcpdump while capturing the on-wire
   conversation between MediaWiki and the client / the Parsiod service)

 - (15) Parsoid/0.1 calls again
   "GET /wiki/api.php?format=json&action=query&prop=revisions&..."
   from a new connection (client port number changed)

 - (16) MediaWiki starts processing (in a new apache/PHP slave) and
   opens a new DB transaction with "BEGIN" performing the same initial
   "UPDATE `wiki_user` SET user_touched ..." query as first query in
   the transaction as in step (2), (5) and (9).

 - (17) approx. 10 seconds pass

 - (18) MediaWiki receives a
   "SQL ERROR: Lock wait timeout exceeded; try restarting transaction"
   relating to transaction from step (9)

 - (19) MediaWiki attempts a ROLLBACK of (9) and tries to send a
   "HTTP 500" (content captured by tcpdump) but the connection is
   already dead.

 - (20) approx. 10 seconds pass

 - (21) MediaWiki closes the connection to the Parsoid service from
   step (3), without any data exchange after receiving th

Re: [Wikitech-l] Engineers in residence

[Joel Sahleen]

+1 Scott

As a new hire at WMF, I consider it to be a privilege to be doing work that 
supports the efforts of the community and the movement, but I am also proud of 
the fact that what I am doing allows me to support my family without 
compromising my personal values. Doing good and making a living are not 
mutually exclusive and not everyone has the luxury of coding purely as a hobby.

From what I have seen, most of the engineers who work at the foundation could 
easily get higher paying jobs elsewhere, but they choose to work at WMF because 
they believe in the movement and its mission. To imply that these people's 
contributions are somehow less ethical or meaningful because they get paid 
seems to be rather uninformed and frankly a little offensive. Furthermore, as 
someone who has been working in the localization field for over five years, I 
can validate Scott’s point that how much attention a given coder gives to 
localization has more to do with his or her personal integrity and commitment 
to that end than anything about his or her employment status. This holds 
generally for other aspects of software development, I would argue.

With the proper legal structures in place, I see no reason why an “Engineer in 
Residence” program at WMF could not succeed. Having such a program would not 
only provide an influx of engineering talent (without adding more WMF 
employees), it might also allow us to positively influence the culture of 
several corporate entities, which would seem to be a good thing.

Joel

On Aug 10, 2014, at 2:32 PM, C. Scott Ananian  wrote:

> On Sun, Aug 10, 2014 at 9:27 AM, svetlana  wrote:
>> I feel that having development carried out by "employees" hinders 
>> programming the same software as a hobby: for instance, they work in a 
>> single language, and don't need localised documentation
> 
> Good localized software is a commitment of the
> project/community/coders, irrespective of coder's employment statuses.
> 
> I have certainly worked on software which was localized *only because*
> a company paid people to do the localization.  And, of course, I'm
> sure the converse occurs as well.
> 
> As a software engineer who enjoys his work, I'm rather put off by the
> idea that it is somehow wrong for me to make a living using my skills
> to further a cause I believe in.  Are all employees of non-profits
> somehow polluting the non-profit's ideals?
> 
> I contributed code to mediawiki as a volunteer before I became an
> employee.  I did not have any problems doing so.  It is true that some
> "community" projects have trouble accepting contributions from
> non-employees, but this is not the case for WMF in my experience.  But
> again, this is due to the values and commitment of the
> community/organization, not who is (or is not) being paid.
>  --scott
> 
> -- 
> (http://cscott.net)
> 
> ___
> 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] Engineers in residence

[Chris McMahon]

On Sun, Aug 10, 2014 at 2:47 PM, Gilles Dubuc  wrote:

> >
> > personally i really liked your comparison, when we were chatting the
> other
> > day, to an artist in residence -- imo, programmers are the artists of our
> > time and this matches well.
> >
>


> To me the point
> is to have our engineering more open and collaborative, which in my opinion
> would also increase pure volunteer contributions as a side effect. This is
> very hard to do in anything other than a non-profit open source project, I
> think we're in a position to make very interesting things happen through
> such efforts.


Such good timing. As a direct result of meeting at Wikimania (thanks Nik
Everett), here is an expert from Expedia who would like to contribute to
our security efforts.  He has posted to the QA mail list:
http://lists.wikimedia.org/pipermail/qa/2014-August/001847.html
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you

[Isarra Yos]

On 08/08/14 14:24, Jon Robson wrote:

On 8 Aug 2014 04:23, "Antoine Musso"  wrote:

Le 07/08/2014 22:05, Erwin Dokter a écrit :

I now have to submit two patches and hope they both get merged at the
exact same time.

The world we should be working towards is one where you'd only have to
update the skin. Moving this code out of core I believe will help drive
that. Submitting two patches _is_ annoying and this is why I think it will
drive improvements to the skin API. :)


This. If it takes two patches, one in the skin, one in core, this seems 
like a good thing - because then it means the added support will then be 
available to all the other skins too, including mobile and the skins of 
various other projects. This is important, because it also means that it 
should become easier to not just focus on a single skin and ignore 
everything else (which has long been the case with vector).


While this should be great for third-party projects, even around here, 
users of monobook who've seen new features released that simply not work 
on their skin should also benefit, as well as potentially everyone else 
as well should the time come for a new default skin for Wikimedia, 
something that will have to happen sooner or later.


-I

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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Nicolas Vervelle]

Le 10 août 2014 17:06, "James HK"  a écrit :
>
> Hi,
>
> > It could mean that, but of course it is actually introduced to prevent
> > the German community from deactivating the Media Viewer.
>
> User JEissfeldt, removed `mw.config.set("wgMediaViewerOnClick",
> false);` from Common.js [0] and is the same person who sets
> ``.
>
> I have no idea what the German community wants or doesn't want but
> using `protect-level-superprotect` to block potential edits is rather
> questionable.
>
> [0]
https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=prev&oldid=132946422
>

Thanks for the diff... That shows what this super protect power is really
for: WMF forcing something against community wishes/discussion. My fear
wasn't unfounded. Clearly a huge step backwards for the wiki philosophy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[James HK]

Hi,

> It could mean that, but of course it is actually introduced to prevent
> the German community from deactivating the Media Viewer.

User JEissfeldt, removed `mw.config.set("wgMediaViewerOnClick",
false);` from Common.js [0] and is the same person who sets
``.

I have no idea what the German community wants or doesn't want but
using `protect-level-superprotect` to block potential edits is rather
questionable.

[0] 
https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=prev&oldid=132946422

Cheers

On 8/10/14, John Mark Vandenberg  wrote:
> On Sun, Aug 10, 2014 at 9:00 PM, Michał Łazowik  wrote:
>> Wiadomość napisana przez Nicolas Vervelle  w dniu 10
>> sie 2014, o godz. 15:45:
>>
>>> I hope it's not an other step from WMF to prevent the application of
>>> community decisions when they not agree with it. I fear that they will
>>> use
>>> this to bypass community decisions. For example like forcing again VE on
>>> everyone on enwki: last year, sysop were able to apply community decision
>>> against Erik wishes only because they had access to site wide js or CSS.
>>
>> I'd like to believe that code-reviewing would mean improving code quality,
>> security
>> and performance (applies to javascript).
>
> It could mean that, but of course it is actually introduced to prevent
> the German community from deactivating the Media Viewer.
>
> https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&action=history
>
> I remember when we used to beg for the WMF to deploy extensions.
> Now we really need to beg for the WMF to not deploy extensions ...
>
> --
> John Vandenberg
>
> ___
> 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] Superprotect user right, Comming to a wiki near you

[John Mark Vandenberg]

On Sun, Aug 10, 2014 at 9:00 PM, Michał Łazowik  wrote:
> Wiadomość napisana przez Nicolas Vervelle  w dniu 10 sie 
> 2014, o godz. 15:45:
>
>> I hope it's not an other step from WMF to prevent the application of
>> community decisions when they not agree with it. I fear that they will use
>> this to bypass community decisions. For example like forcing again VE on
>> everyone on enwki: last year, sysop were able to apply community decision
>> against Erik wishes only because they had access to site wide js or CSS.
>
> I'd like to believe that code-reviewing would mean improving code quality, 
> security
> and performance (applies to javascript).

It could mean that, but of course it is actually introduced to prevent
the German community from deactivating the Media Viewer.

https://de.wikipedia.org/w/index.php?title=MediaWiki:Common.js&action=history

I remember when we used to beg for the WMF to deploy extensions.
Now we really need to beg for the WMF to not deploy extensions ...

--
John Vandenberg

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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Maarten Dammers]

Hi Erik,

I understand you reasoning, but you couldn't have communicated and timed 
this in a worse way. You might be doing the right thing, but because of 
this ill communication and timing, this will be completely overshadowed. 
That saddens me. Good luck with the shit storm :-(


Maarten

Erik Moeller schreef op 10-8-2014 14:27:

Hi folks,

Admins are currently given broad leeway to customize the user
experience for all users, including addition of site-wide JS, CSS,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove this capability.

However, we've clarified in a number of venues that use of the
MediaWiki: namespace to disable site features is unacceptable. If such
a conflict arises, we're prepared to revoke permissions if required.
This protection level provides an additional path to manage these
situations by preventing edits to the relevant pages (we're happy to
help apply any urgent edits) until a particular situation has calmed
down.

Thanks,
Erik



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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[hoo]

Totally agree with that, dirty common.js hacks aren't really beneficial
for anyone.

Cheers,

Marius


On Sun, 2014-08-10 at 14:56 +0100, Derk-Jan Hartman wrote:
> On 10 aug. 2014, at 14:27, Erik Moeller  wrote:
> 
> > However, we've clarified in a number of venues that use of the
> > MediaWiki: namespace to disable site features is unacceptable. If such
> > a conflict arises, we're prepared to revoke permissions if required.
> > This protection level provides an additional path to manage these
> > situations by preventing edits to the relevant pages (we're happy to
> > help apply any urgent edits) until a particular situation has calmed
> > down.
> 
> I agree that the current situation is basically something that grew 
> historically that is no longer sustainable. For a long time this was not 
> really a problem and good faith made it work regardless of how broken it was, 
> but when it is used for manipulation, then action is required.
> 
> This is not a new thing, but perhaps a clarification that was long over due 
> (and one we perhaps we shied away from too long). We need to collaborate to 
> iterate and improve the software for our movement. I'm the first to support 
> the fact that we have not been able to do that in the past for many reasons. 
> We are now becoming more capable, but we will also still be making a lot of 
> mistakes from various roles, while building the actual feedback loop required 
> to perfect this process. BUT that is a separate issue and there are different 
> venues for that, which are not Common.js -like methodologies.
> 
> DJ ,
> Volunteer developer
> 
> ___
> 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] Superprotect user right, Comming to a wiki near you

[Michał Łazowik]

Wiadomość napisana przez Nicolas Vervelle  w dniu 10 sie 
2014, o godz. 15:45:

> I hope it's not an other step from WMF to prevent the application of
> community decisions when they not agree with it. I fear that they will use
> this to bypass community decisions. For example like forcing again VE on
> everyone on enwki: last year, sysop were able to apply community decision
> against Erik wishes only because they had access to site wide js or CSS.

I'd like to believe that code-reviewing would mean improving code quality, 
security
and performance (applies to javascript).

Michał


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Recommended way to change a lot of absolute links at wiki

[Dmitriy Sintsov]

Hi!
I made a XML dump with --current option, then replaced some of external
domain links [http://somedomain.org] in it. When I import the dump back,
these pages aren't updated. I think that's because text processors /
editors do not update sha1 / timestamp fields. Why doesn't
maintenance/importDump.php recalculate and compare sha1 of actual page
content? How should I touch timestamp / sha1 xml field text in the modified
dump? Is there any ready solution? Or, shall I use pywikibot instead (that
will be longer and slower)?
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Derk-Jan Hartman]

On 10 aug. 2014, at 14:27, Erik Moeller  wrote:

> However, we've clarified in a number of venues that use of the
> MediaWiki: namespace to disable site features is unacceptable. If such
> a conflict arises, we're prepared to revoke permissions if required.
> This protection level provides an additional path to manage these
> situations by preventing edits to the relevant pages (we're happy to
> help apply any urgent edits) until a particular situation has calmed
> down.

I agree that the current situation is basically something that grew 
historically that is no longer sustainable. For a long time this was not really 
a problem and good faith made it work regardless of how broken it was, but when 
it is used for manipulation, then action is required.

This is not a new thing, but perhaps a clarification that was long over due 
(and one we perhaps we shied away from too long). We need to collaborate to 
iterate and improve the software for our movement. I'm the first to support the 
fact that we have not been able to do that in the past for many reasons. We are 
now becoming more capable, but we will also still be making a lot of mistakes 
from various roles, while building the actual feedback loop required to perfect 
this process. BUT that is a separate issue and there are different venues for 
that, which are not Common.js -like methodologies.

DJ ,
Volunteer developer



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Engineers in residence

[Gilles Dubuc]

>
> personally i really liked your comparison, when we were chatting the other
> day, to an artist in residence -- imo, programmers are the artists of our
> time and this matches well.
>

Absolutely, I also like that idea of doing something similar to artist
residencies. This could take many forms. The one I described in the opening
of this thread is just one take on many angles that can be explored. I
guess the most generic way to express the idea is setting up ways to remove
the economical barriers preventing willing engineers from contributing (or
contributing more) to our projects. It can be more than one scheme
targeting people in very different situations. Some would cost the
foundation/chapters money, some wouldn't, etc.

Also, I want to stress than I was talking about organizations in general,
and that includes other non-profits that align with our ideals.
Organizations like Mozilla, Creative Commons, FSF, etc. There are plenty of
them, with employees of their own, and for those non-profits it could take
the form of exchanges, for example (someone from the WMF spending X months
contributing to Mozilla projects while someone from Mozilla contributes to
Mediawiki projects, etc.). That's yet another take on this. To me the point
is to have our engineering more open and collaborative, which in my opinion
would also increase pure volunteer contributions as a side effect. This is
very hard to do in anything other than a non-profit open source project, I
think we're in a position to make very interesting things happen through
such efforts.


On Sat, Aug 9, 2014 at 5:22 PM, dan-nl 
wrote:

> this is an excellent idea and i don't think it needs to be focused only on
> large corporations or only on corporate individuals who want to volunteer.
> i would suggest opening the idea to any developer with a skill set that's
> needed or who wants to learn. and make it available in any Foundation
> office or chapter office in the world. depending on the skill set or
> learning situation might determine if the person was paid for their time or
> volunteered it.
>
> personally i really liked your comparison, when we were chatting the other
> day, to an artist in residence -- imo, programmers are the artists of our
> time and this matches well.
>
> offering housing and a stipend for food would be a good thing to include
> when the person volunteers their time.
>
> o dan
>
> On Aug 9, 2014, at 15:44 , Gilles Dubuc  wrote:
>
> > It doesn't exclude the community, the community already contributes to
> the
> > software. That's the point of open source. In fact I would expect that
> > people who already contribute to mediawiki as hobby who are also software
> > engineers as a day job would enjoy being given the freedom to work on
> what
> > they're passionate about even more. The community as you describe it and
> > people who work for corporations in order to pay their bills has a big
> > overlap.
> >
> > It would also be an opportunity to get valuable contributions from
> > experienced people whose life constraints may not allow them to do this
> as
> > a hobby. There's also a big difference in the nature of what you can
> > contribute in your free time compared to a full-time basis.
> >
> >
> > On Sat, Aug 9, 2014 at 3:23 PM, svetlana 
> wrote:
> >
> >> utter and complete rubbish as it excludes the community and leaves all
> >> development within corporate hands; All against free software philosophy
> >> and/or community involvement
> >>
> >> programming should be a hobby, like editing articles
> >>
> >> svetlana
> >>
> >> On Sat, 9 Aug 2014, at 23:27, Gilles Dubuc wrote:
> >>> This is an idea I've had for a while, and I'd like to see if there's
> any
> >>> interest, or on the contrary concerns, about it. I would like to
> explore
> >>> (and if I have official blessing, champion) the idea of asking
> >> corporations
> >>> with software engineering staff if they would be willing to let their
> >>> employees volunteer their expertise and time to mediawiki while ideally
> >>> still being on their employer's payroll. I mean engineering in the wide
> >>> sense of the term, including Ops, QA, etc. and maybe even UX.
> >>>
> >>> This would allow engineers to take a break for a predetermined duration
> >>> from their usual work duties and contribute in a very productive manner
> >> to
> >>> our open source projects. And maybe to other open source projects than
> >>> mediawiki, but I think our project in particular is a great starting
> >> point.
> >>> I see this as a flexible scheme. It doesn't really matter if people can
> >> do
> >>> it for a day, a month, or a year, I believe that these
> inter-organization
> >>> exchanges could have great value.
> >>>
> >>> *Background*
> >>>
> >>> Earlier this year the WMF's Multimedia team, which I'm a part of, had a
> >>> volunteer working full-time with us, Aaron Arcos. Aaron used to work at
> >>> Google and left to spend a year offering his software engineering
> skills
> >> to
> >>> sev

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Nicolas Vervelle]

Le 10 août 2014 15:35, "svetlana"  a écrit :
>
> On Sun, 10 Aug 2014, at 23:19, K. Peachey wrote:
> > Lets all welcome the new overlord Erik.
> >
> > Add a new protection level called "superprotect"
> > Assigned to nobody by default. Requested by Erik Möller for the purposes
> > of protecting pages such that sysop permissions are not sufficient to
> > edit them.
> > Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e
> > <
https://gerrit.wikimedia.org/r/#q,Idfa211257dbacc7623d42393257de1525ff01e9e,n,z
>
> >
> > https://gerrit.wikimedia.org/r/#/c/153302/
>
> This change solves a problem that does not exist.
> We either trust sysops, or we don't.
>
> Erik Moeller wrote:
> > In the long run, we will want to
> > apply a code review process to these
> > changes as with any other deployed code
>
> I hope such things will not need to go through the WMF. Or is that what
you'd like?

I hope it's not an other step from WMF to prevent the application of
community decisions when they not agree with it. I fear that they will use
this to bypass community decisions. For example like forcing again VE on
everyone on enwki: last year, sysop were able to apply community decision
against Erik wishes only because they had access to site wide js or CSS.

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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[svetlana]

On Sun, 10 Aug 2014, at 23:19, K. Peachey wrote:
> Lets all welcome the new overlord Erik.
> 
> Add a new protection level called "superprotect"
> Assigned to nobody by default. Requested by Erik Möller for the purposes
> of protecting pages such that sysop permissions are not sufficient to
> edit them.
> Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e
> 
> 
> https://gerrit.wikimedia.org/r/#/c/153302/

This change solves a problem that does not exist.
We either trust sysops, or we don't.

Erik Moeller wrote:
> In the long run, we will want to
> apply a code review process to these 
> changes as with any other deployed code

I hope such things will not need to go through the WMF. Or is that what you'd 
like?

svetlana.

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

Re: [Wikitech-l] Engineers in residence

[C. Scott Ananian]

On Sun, Aug 10, 2014 at 9:27 AM, svetlana  wrote:
> I feel that having development carried out by "employees" hinders programming 
> the same software as a hobby: for instance, they work in a single language, 
> and don't need localised documentation

Good localized software is a commitment of the
project/community/coders, irrespective of coder's employment statuses.

I have certainly worked on software which was localized *only because*
a company paid people to do the localization.  And, of course, I'm
sure the converse occurs as well.

As a software engineer who enjoys his work, I'm rather put off by the
idea that it is somehow wrong for me to make a living using my skills
to further a cause I believe in.  Are all employees of non-profits
somehow polluting the non-profit's ideals?

I contributed code to mediawiki as a volunteer before I became an
employee.  I did not have any problems doing so.  It is true that some
"community" projects have trouble accepting contributions from
non-employees, but this is not the case for WMF in my experience.  But
again, this is due to the values and commitment of the
community/organization, not who is (or is not) being paid.
  --scott

-- 
(http://cscott.net)

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

Re: [Wikitech-l] Superprotect user right, Comming to a wiki near you

[Erik Moeller]

Hi folks,

Admins are currently given broad leeway to customize the user
experience for all users, including addition of site-wide JS, CSS,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove this capability.

However, we've clarified in a number of venues that use of the
MediaWiki: namespace to disable site features is unacceptable. If such
a conflict arises, we're prepared to revoke permissions if required.
This protection level provides an additional path to manage these
situations by preventing edits to the relevant pages (we're happy to
help apply any urgent edits) until a particular situation has calmed
down.

Thanks,
Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

[Wikitech-l] Superprotect user right, Comming to a wiki near you

[K. Peachey]

Lets all welcome the new overlord Erik.

Add a new protection level called "superprotect"
Assigned to nobody by default. Requested by Erik Möller for the purposes
of protecting pages such that sysop permissions are not sufficient to


edit them.
Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e


https://gerrit.wikimedia.org/r/#/c/153302/



Someone clearly can't take criticism of their projects well.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Engineers in residence

[Dan Garry]

On 10 August 2014 13:57, Chris McMahon  wrote:
>
> Actually, I think we should consider serious limits to any such proposal,
> such as (as Gilles suggested) working only with reputable employees (or
> ex-employees, like Aaron Arcos) of reputable companies.  Otherwise I
> suspect "any developer" will game the system for their own benefit, for
> example to get free training or to pad their resume.


I would ordinarily be vary wary about limiting or restricting who we
collaborate with, but given that our code base is open source and we
welcome patches from everyone, making such a limitation seems workable for
the very practical purpose of making sure the relationships are as
productive as possible.

Thanks,
Dan

-- 
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Engineers in residence

[Chris McMahon]

On Sat, Aug 9, 2014 at 5:22 PM, dan-nl 
wrote:

> this is an excellent idea and i don't think it needs to be focused only on
> large corporations or only on corporate individuals who want to volunteer.
> i would suggest opening the idea to any developer with a skill set that's
> needed or who wants to learn.


Actually, I think we should consider serious limits to any such proposal,
such as (as Gilles suggested) working only with reputable employees (or
ex-employees, like Aaron Arcos) of reputable companies.  Otherwise I
suspect "any developer" will game the system for their own benefit, for
example to get free training or to pad their resume.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] URGENT! Documentation is out of date!

[Legoktm]

In honor of bug 1's 10th birthday today, take the time to fix some out
of date documentation or write some missing ones :)

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

-- Legoktm

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

[Wikitech-l] more thoughts on project types; what is reusable?

[svetlana]

For very small abandoned projects, nobody is around to do anything, even to 
review a patch.

For a slightly bigger project, someone is around to review a patch and explain 
you how to write one, and where to get started. The process of you writing it 
is slow, and the process of them reviewing it may also be slow.

For a next bigger project, 2-3 volunteer maintainers are around. They hear 
every word from feedback and prioritise them based on how easy they are to work 
around, and how well they fit a project scope. (Usually a lot of things fit 
project scope as long as it's designed and coded well.)

As a project goes bigger, more time is dedicated to unit tests. A volunteer 
would read feedback and review patches, but more effort would be spent into 
making the project not fall apart. Code review, unit tests, issue tracker, and 
again everything people request eventually gets in somewhere. Again someone is 
around who can explain you where to get started if you'd like to pick up your 
own request or someone else's.

As a project goes even bigger, it usually remains modular. It is relatively 
easy for you to get started by reading a very small module and coding your 
thing in. Again someone is around who sees you as a new potential volunteer, 
and is happy to explain you how things work.

...

When a project has an employee (or a GSOC student) coming in, something needs 
to prioritise their work. What issues to hand over to them to get them complete 
in no time?

...

Answer to this question may vary. It is hard to answer it right - there is more 
than one way to do it.

Some things come to my head about what should not be done:
1/ Miss community feedback. [For bigger projects, you /will/ have to 
consciously skip (note: this does not mean miss, it is a different word) some, 
to not make the thing a features mess. Simplicity is the key of success.]
2/ Come up with big non-modular projects.
3/ Lose consistency by working on big enhancements out of the blue, leaving the 
rest of functionality or interface behind.
4/ Write code which fails to be reusable.
5/ Fail to write documentation.
6/ Fail to showcase, reveal, and expose the features the employee added, which 
are reusable.
7/ Fail to support community work.
8/ Fail to meet original project mission.

Could someone please point me specifically to where (4) and (6) are not failing 
within Wikimedia Engineering?

In other words:
- What reusable things come out of each Wikimedia Engineering project?
- Where can I find out about them easily without asking you to find them for me 
by hand?

svetlana

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

Re: [Wikitech-l] Engineers in residence

[svetlana]

On Sun, 10 Aug 2014, at 04:04, Andre Klapper wrote:
> > programming should be a hobby, like editing articles
> 
> Free Software definitions don't imply that you shall not take money for
> your work, or eventually even make a living on it. It's part of the
> personal freedom that everybody has. However, nobody stops you from
> living your ideals of keeping programming a "hobby only". :)
> 
> Cheers,
> andre
> -- 
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/

I feel that having development carried out by "employees" hinders programming 
the same software as a hobby: for instance, they work in a single language, and 
don't need localised documentation

there are other (which i haven't shaped properly yet) differences of 
architecture of comminity-run tech projects and tech projects run by employees, 
which make getting involved as a hobby harder

for instance, i could not make a difference to a big linux distro run by a 
corporation (or using one as an upstream)

which is why I'm not very supportive of any plans that involve more employees 
at WMF Engineering either

I hope this way to put it is slightly more clear than it was before

svetlana

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