Re: [Wikitech-l] Turkey ban

2017-05-02 Thread Steinsplitter Wiki
I suspect if this will work, they also created on a own OS which... isn't 
popular at all.


Von: Wikitech-l  im Auftrag von 
Jonathan Morgan 
Gesendet: Dienstag, 2. Mai 2017 18:00
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Turkey ban

And now, this:
https://arstechnica.com/tech-policy/2017/05/2-chinese-writers-will-create-their-own-wikipedia-competitor/

On Sun, Apr 30, 2017 at 1:39 AM, Amir Ladsgroup  wrote:

> The Iranian government by blocking several major websites (youtube,
> facebook, twitter) actually made people aware of anonymizers and people
> were able to use a wide range of them.
> Most popular ones that people in Turkey can use is: 1- Psiphon (a little
> bit slow, has an android app) 2- Hotspot shield (great, also andriod app)
> 3- Lantern (the only one that supports linux)
> Tor is good too but we have editing problems with that.
>
> Best
>
> On Sun, Apr 30, 2017 at 12:57 PM Bináris  wrote:
>
> > When I was in Iran, I could reach all the blocked sites (such as
> Facebook)
> > with Psiphon.
> > https://en.wikipedia.org/wiki/Psiphon
> > And so do the local people.
> > Citizens of dictatorships are very efficient in using client-side
> > solutions.
> > ___
> > 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
>



--
Jonathan T. Morgan
Senior Design Researcher
Wikimedia Foundation
User:Jmorgan (WMF) 
___
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] Code of Conduct

2016-09-29 Thread Steinsplitter Wiki


>>To reach more people like you, what would be the best place to post
messages so you'd see them?




Positing it at the village pumpes of the local project (similar to the tech 
news notifications), for example :-)
Or using limited CN banners (similar to the community survey banners).



--Steinsplitter

Von: Wikitech-l <wikitech-l-boun...@lists.wikimedia.org> im Auftrag von Andre 
Klapper <aklap...@wikimedia.org>
Gesendet: Donnerstag, 29. September 2016 15:58
An: wikitech-l@lists.wikimedia.org
Betreff: Re: [Wikitech-l] Code of Conduct
    
On Wed, 2016-09-28 at 11:07 +0000, Steinsplitter Wiki wrote:
> I noticed that a Code of Conduct for Phabricator is getting
> developed. Cool to see that people are creating such a policy, it is
> standard yet in big other projects. :-)

A Code of Conduct for Wikimedia's technical spaces is being developed;
Phabricator is one of those technical spaces.

> Unfortunately, the whole Code of Conduct Voting hasn't been widely
> announced (just on phabricator). [...] Such a important decision
> should be widely announced imho. 

To reach more people like you, what would be the best place to post
messages so you'd see them?

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/

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

[Wikitech-l] Code of Conduct

2016-09-28 Thread Steinsplitter Wiki
Hello,

I am not sure where to ask, thus i write here. Sorry if this is the wrong place!
I noticed that a Code of Conduct for Phabricator is getting developed. Cool to 
see that people are creating such a policy, it is standard yet in big other 
projects. :-)

Just a few thoughts:
Unfortunately, the whole Code of Conduct Voting hasn't been widely announced 
(just on phabricator). There are a lot users which are using phab just once at 
year. Such a important decision should be widely announced imho. I mainly see 
participation just from  a very closed group.

Last but not least: I am not happy at all that me comment has been strike from  
https://www.mediawiki.org/w/index.php?title=Talk:Code_of_Conduct/Draft=2247995=2247822
 by Matt Flaschen (WMF). Looks like it is no longer allowed to comment over 
there, thus i write here.

:-)

Regards,
Steinsplitter



http://meta.wikimedia.org/wiki/User:Steinsplitter

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

Re: [Wikitech-l] FW: File with an unknown copyright status on MediaWiki.org

2016-05-25 Thread Steinsplitter Wiki
There are hundreds of files in 
https://www.mediawiki.org/wiki/Category:Files_with_unknown_copyright_status

Likely they schould be nominated after one week or moor automatically for 
deletion (using parser function).  Then a human can review it and press delete.

Likely Template:Information schould be preloaded at Special:Upload (similar to 
commons), so we would also have machine readable data for files.


Best,
--Steinspliter

> From: p858sn...@gmail.com
> Date: Wed, 25 May 2016 21:11:13 +1000
> To: wikitech-l@lists.wikimedia.org
> Subject: Re: [Wikitech-l] FW: File with an unknown copyright status on
> MediaWiki.org
> 
> On 25 May 2016 at 20:40, Ricordisamoa  wrote:
> > , while on mediawiki.org no one cares.
> 
> That's not true, It's a project I plan to work on shortly (just need
> to finish a few other things first).
> 
> And it's not a simple case of just hitting delete on everything.
> 
> ___
> 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] FW: File with an unknown copyright status on MediaWiki.org

2016-05-25 Thread Steinsplitter Wiki




Hello,

I hope this is the right place to ask, if not please excuse.

All files uploaded to MediaWiki.org must be available under a free license (no 
"fair use" or "noncommercial").
What we do with files with unclear copyright status (no license, no author, 
etc.) such as:

* https://www.mediawiki.org/wiki/File:Scott_profile_pic.jpeg
* 
https://www.mediawiki.org/wiki/File:EMWCon_Spring_2016_Mediawiki_in_the_Enterprise.pdf
* https://www.mediawiki.org/wiki/File:3d_extension_screenshot.png
* a lot of other

Nominating for deletion? Per the intro at 
https://www.mediawiki.org/wiki/Special:Upload such files must be deleted.

We have {{Unknown copyright}} template, but it seems that nobody is working on 
it?


Best,
--Steinsplitter

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

Re: [Wikitech-l] New [[Main Page]] for Wikitech

2016-01-29 Thread Steinsplitter Wiki

Well done! :-)

> Date: Fri, 29 Jan 2016 12:55:40 +0100
> From: puro...@blissenbach.org
> To: wikitech-l@lists.wikimedia.org
> Subject: Re: [Wikitech-l] New [[Main Page]] for Wikitech
> 
> Well done!
> Purodha
> 
> On 29.01.2016 07:25, MZMcBride wrote:
> > Bryan Davis wrote:
> >>I've been working on a little redesign project for the Main Page on
> >>wikitech [0] and three key sub pages it points to since 2016-01-01 in
> >>my User space. Tonight I decided that although it is far from perfect
> >>it is better enough. I hope that some of you like it better than the
> >>old page and that none of you hate it with a fiery passion that
> >>compels you to revert it rather than helping me make it better.
> >>
> >>[0]: https://wikitech.wikimedia.org/wiki/Main_Page
> >
> > Very nice! Thank you for doing this.
> >
> > 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
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] UploadWizard long term problems

2015-09-14 Thread Steinsplitter Wiki
Hi,

UploadWizard has a lot of bugs and is sometimes defacto unusable.

See error reports here: 
https://commons.wikimedia.org/wiki/Commons:Upload_Wizard_feedback

See also reports on phabricator.

It is a huge problem that the UploadWizard is not fixed for years now. 
Especially during WLM we have a lot of error reports.


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

Re: [Wikitech-l] [Engineering] Code of conduct

2015-08-23 Thread Steinsplitter Wiki
Why we need a committee?

I think admins can enforce if necessary.

 Date: Sun, 23 Aug 2015 00:30:40 -0600
 From: bawo...@gmail.com
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] [Engineering] Code of conduct
 
 On 8/22/15, Risker risker...@gmail.com wrote:
  David, thanks for this find.
 
  THIS is why the Code of Conduct is needed.  I recognized myself in this
  blog.  I remembered avoiding any aspect of socialization at conferences I
  had to attend for work, and simply didn't even consider attending
  conferences for any other purpose.  I remembered how readily the guys
  assumed that any woman there was there for more than just networking and
  learning.  I remembered having my butt pinched, my breasts accidentally
  touched, my questions ignored or laughed at. I remember how the buzz of
  background conversation is always much louder when the speaker is a woman
  than when the speaker is a man.
 
  It's changed for me. Not because there's any less of all of this going on.
  No, it's because my hair is grey and I'm now old enough to be the mom of
  half the people in the room at any male-dominated conferences I attend; and
  outside of Wikimedia events, the conferences I go to are usually full of
  conservative businesswomen, and alcohol is rarely involved.
 
  So yeah...you need a code of conduct. Because if I was even 15 years
  younger, I'd never go to a Wikimedia conference.
 
  Risker/Anne
 
 
 Thank you for writing this. I really appreciate you sharing your experiences.
 
 Your comments have convinced me that I should support the proposal,
 where previously I had mixed feelings. The types of behaviours you
 describe are absolutely unacceptable.
 
 --
 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] Code of conduct committee

2015-08-21 Thread Steinsplitter Wiki
Some thoughts about 
https://www.mediawiki.org/wiki/Code_of_conduct_for_technical_spaces/Draft
* I can't see community consensus (RFC) for this.
* I see a lot (maybe 70%) staffer edits there.
* It is complicated to understand the policy.

I have the feeling that only a few staffer building this.
Please don't forget to involve the community!

How you like to enforce this policy on irc?

What is the committee? A WMF super arbcom?

Moor transparency would be great, and to write it in simple english so that non 
native speakers can get involved.

Best and with concerns,
Steinsplitter

 Date: Fri, 21 Aug 2015 00:27:22 -0400
 From: mflasc...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 Subject: [Wikitech-l] Code of conduct committee
 
 There is some discussion now about how the Code of Conduct Committee 
 should be formed.  See:
 
 
 * 
 https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft#Membership_of_the_committee_and_ECT.27s_role
 
 and
 
 * 
 https://www.mediawiki.org/wiki/Talk:Code_of_conduct_for_technical_spaces/Draft#Another_membership_proposal
  
 .
 
 Thanks,
 
 Matt Flaschen
 
 ___
 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] Geohack tools

2015-08-07 Thread Steinsplitter Wiki
You can integrate it in templates.

 Date: Thu, 6 Aug 2015 23:01:46 -0700
 From: wiki.p...@gmail.com
 To: wikitech-l@lists.wikimedia.org
 Subject: [Wikitech-l] Geohack tools
 
 I just now realized how powerful these tools are when I started clicking
 around.
 
 https://tools.wmflabs.org/geohack/geohack.php?pagename=File%3AWhite-cheeked_Starling_perching_on_a_rock.jpgparams=34.610576_N_135.540542_E_globe:Earth_class:object_language=en
 
 Is there any chance of integrating some of these tools more directly onto
 Wikipedia pages, and into mobile web/mobile apps?
 
 Pine
 ___
 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] Slides from Lila's presentation at Wikimania

2015-07-19 Thread Steinsplitter Wiki
Nice .pdf ... but why it was necessary to post this to x-lists? Seems offtopic 
here. 

 Date: Sat, 18 Jul 2015 16:31:22 -0700
 From: wiki.p...@gmail.com
 To: wikimani...@lists.wikimedia.org; wikimedi...@lists.wikimedia.org; 
 wikitech-l@lists.wikimedia.org
 Subject: [Wikitech-l] Slides from Lila's presentation at Wikimania
 
 Courtesy of WMF Comms:
 https://commons.wikimedia.org/wiki/File:Wikimania_2015_presentation_by_Lila_Tretikov.pdf
 
 Pine
 ___
 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] Provide a well-performing API to rotate an image

2015-07-17 Thread Steinsplitter Wiki
 Apologies if I'm missing something but is there any reason why we can't do
 image rotation on the client using the canvas JavaScript api?

Client side rotation takes ages, especially with big files.

 Agreed! Most of that probably should be non-destructive editing that keeps
 the original and applies crop/rotate/filters along with thumbnailing as
 necessary.

I suggest that we keep status quo. It has worked perfect for years. Just fixing 
thumbs does not fix the file itself and we want to have the file itself fixed.

 Date: Fri, 17 Jul 2015 19:30:44 +0800
 From: jdlrob...@gmail.com
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] Provide a well-performing API to rotate an image
 
 Apologies if I'm missing something but is there any reason why we can't do
 image rotation on the client using the canvas JavaScript api?
 
 On Thu, Jul 16, 2015 at 3:45 PM, MZMcBride z...@mzmcbride.com wrote:
 
  Brion Vibber wrote:
  Allowing override of the thumb rotation would provide you real time
  rotation...
  
  I'm not sure about the need to rotate the original file; ideally original
  files should be left as-is and kept archival.
 
  In my opinion, we need to solve image rotation as part of a larger project
  to support in-browser rasterized image manipulation. A bot shouldn't be
  necessary here. We should have the ability, in a Web browser, to crop,
  rotate, and make other basic manipulations to rasterized images. The fact
  that we have a media repository using software called MediaWiki that
  doesn't include an in-browser basic photo editor is pretty silly.
 
 
 Agreed! Most of that probably should be non-destructive editing that keeps
 the original and applies crop/rotate/filters along with thumbnailing as
 necessary. That'll take some more infrastructure work though.
 
 Of course if you're going to draw on a picture that'll require uploading a
 new version.
 
 -- brion
 ___
 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] Provide a well-performing API to rotate an image

2015-07-16 Thread Steinsplitter Wiki
 You would still need to rewrite the bot though, even if there was a
 rotation API, wouldn't you?

No need to rewrite then because Rillke will fix the rotate link java-script. :-)

 Date: Thu, 16 Jul 2015 12:21:10 -0500
 From: gti...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] Provide a well-performing API to rotate an image
 
 You would still need to rewrite the bot though, even if there was a
 rotation API, wouldn't you?
 
 On Thu, Jul 16, 2015 at 11:19 AM, YiFei zhuyifei1...@gmail.com wrote:
 
   That doesn't really answer Brion's question. What would prevent it from
   continuing to run while it is being rewritten?
   lack of time.
  (commenting on this as I tried to debug the code previously)
  The code currently:
  * is independent from any maintained mw api libraries
  * use self defined api parameters
  * uses php's curl, which has quite weird https support
  * has doc strings in de, which I can't read
  * generates tons of php warnings
  * and does not check whether upload / page save is successfully done or not
 
  The bot have failed when:
  * a few weeks ago from the https switch
  * currently from session / token-related issue (not entirely sure)
 
  Rewrite attempts have been made, but:
  * the code barely make any sense (not OOP, reduced indentation, tons of
  bugs, etc.)
  * lack of time to do complete rewrite
 
  
   Date: Thu, 16 Jul 2015 09:05:11 -0500
   From: dga...@wikimedia.org
   To: wikitech-l@lists.wikimedia.org
   Subject: Re: [Wikitech-l] Provide a well-performing API to rotate an
  image
  
   Hi Steinsplitter,
  
   On 16 July 2015 at 09:00, Steinsplitter Wiki 
  steinsplitter-w...@live.com
   wrote:
  
   Out of curiosity what is the problem with the bot that prevents it
  from
   working?
   It is very old and bad written and needs a complete rewrite.
  
   That doesn't really answer Brion's question. What would prevent it from
   continuing to run while it is being rewritten?
  
   Dan
  
   --
   Dan Garry
   Lead Product Manager, Discovery
   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
 
  ___
  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] Provide a well-performing API to rotate an image

2015-07-16 Thread Steinsplitter Wiki
Hi,

I am not sure if this is the correct mailinglist to write.

Every week on commons a bot is rotating hunderts of files, however this bot 
will stop working soon. In the last years tens of thousands files has been 
rotated.

Rotating files is a vital feature on commons and therefore indispensable. The 
bugreport [1] on phabricator is open since three years, but, unfortunately no 
dev is working on it. The bug has also a lot of +1 (tokens).

I am wonder if it is possible to enable and code review this feature asap.

:-)

Best,
Steinsplitter

[1] https://phabricator.wikimedia.org/T35186
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Provide a well-performing API to rotate an image

2015-07-16 Thread Steinsplitter Wiki
 Out of curiosity what is the problem with the bot that prevents it from
 working?
It is very old and bad written and needs a complete rewrite.

 It's entirely possible that fixing the bot is easier than hacking an
 internal rotate and reupload feature that runs on the image scalers.
It would be the best solution to fix that function in mediawiki. This would 
also allow real time rotation.

 Or... Just making it possible to mark images as needing to be rotated
 correctly on output (given we already rotate on thumbnail generation)...
The thumb rotation is not always perfect and the file itself is not rotatet at 
all.

:-)

 Date: Thu, 16 Jul 2015 08:51:47 -0500
 From: bvib...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] Provide a well-performing API to rotate an image
 
 Out of curiosity what is the problem with the bot that prevents it from
 working?
 
 It's entirely possible that fixing the bot is easier than hacking an
 internal rotate and reupload feature that runs on the image scalers.
 
 Or... Just making it possible to mark images as needing to be rotated
 correctly on output (given we already rotate on thumbnail generation)...
 
 -- brion
 On Jul 16, 2015 8:27 AM, Steinsplitter Wiki steinsplitter-w...@live.com
 wrote:
 
  Hi,
 
  I am not sure if this is the correct mailinglist to write.
 
  Every week on commons a bot is rotating hunderts of files, however this
  bot will stop working soon. In the last years tens of thousands files has
  been rotated.
 
  Rotating files is a vital feature on commons and therefore indispensable.
  The bugreport [1] on phabricator is open since three years, but,
  unfortunately no dev is working on it. The bug has also a lot of +1
  (tokens).
 
  I am wonder if it is possible to enable and code review this feature asap.
 
  :-)
 
  Best,
  Steinsplitter
 
  [1] https://phabricator.wikimedia.org/T35186
 
  ___
  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] Provide a well-performing API to rotate an image

2015-07-16 Thread Steinsplitter Wiki
 That doesn't really answer Brion's question. What would prevent it from
 continuing to run while it is being rewritten?
lack of time.

 Date: Thu, 16 Jul 2015 09:05:11 -0500
 From: dga...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] Provide a well-performing API to rotate an image
 
 Hi Steinsplitter,
 
 On 16 July 2015 at 09:00, Steinsplitter Wiki steinsplitter-w...@live.com
 wrote:
 
   Out of curiosity what is the problem with the bot that prevents it from
   working?
  It is very old and bad written and needs a complete rewrite.
 
 
 That doesn't really answer Brion's question. What would prevent it from
 continuing to run while it is being rewritten?
 
 Dan
 
 -- 
 Dan Garry
 Lead Product Manager, Discovery
 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] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

2015-07-08 Thread Steinsplitter Wiki
All this unnecessary changes is just making wikicoders live hard. *sigh*

 From: mai...@live.de
 To: wikitech-l@lists.wikimedia.org
 Date: Wed, 8 Jul 2015 08:17:41 +0200
 Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for 
 action=query will change at the end of this month
 
 
 
 
  Date: Tue, 7 Jul 2015 10:20:33 -0400
  From: bjor...@wikimedia.org
  
  On Mon, Jul 6, 2015 at 9:02 PM, John Mark Vandenberg jay...@gmail.com
  wrote:
  
   Did the change go live?
  
  
  Yes!
  
  
   Did the wikis fall over?
  
  
  If they did, no one told me about it or complained about it in any of the
  places I looked. Not that I personally looked in extremely many places, but
  I'd have expected it to make it to this mailing list or Phabricator if
  something important broke.
  
 
 
 You can't expect the average user to go to Phabricator or post on this 
 mailing list. If you are lucky, they complain on the respective talk pages 
 like [1] or some other place.
 
 I think, there is be quite a substantial amount of programs around which 
 still use the old interface and are broken now. Waiting for someone to notice 
 and fix...
 
 Marco
 
 [1] 
 https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk%3AGadget-Cat-a-lot.jstype=revisiondiff=165244124oldid=165227754#Not_working_2
 
 
 
  
   Is there any ongoing analysis of the number of user agents (bots /
   gadgets / etc) still not specifying continue method?
  
  
  The log warnings I used before the change were removed as part of the
  change, since it doesn't seem particularly interesting anymore: we can't
  tell server-side whether a client is actually broken or just isn't using
  continuation at all.
  
  I can tell you that the gzip-compressed api-feature-usage log files were
  around 2.5G on June 1 (just before the final communication push), 1.1G on
  July 1 (just before the change), and only 46M on July 4 (after the change
  with the logging for this removed).
  
  Is there a common approach for gadgets to identify themselves to the
   API - e.g. setting a custom user-agent?
  
  
  Clients that cannot set the User-Agent header (such as gadgets and other
  scripts running in a browser) may use the Api-User-Agent header instead. If
  present, this header is prepended to the standard User-Agent header for
  purposes such as the api-feature-usage log and Special:ApiFeatureUsage.
  
  
  -- 
  Brad Jorsch (Anomie)
  Software Engineer
  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
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

2015-06-19 Thread Steinsplitter Wiki
Before playing around with api serious bugs should be fixed...  I see xxXx 
unresolved bugs on pahricator.   It is frustrating

 Date: Thu, 18 Jun 2015 14:56:25 -0700
 From: sp...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for 
 action=query will change at the end of this month
 
 On Thu, Jun 18, 2015 at 9:26 AM, Brian Gerstle bgers...@wikimedia.org
 wrote:
 
  I guess it comes down to is this: if we're going to continue supporting
  old behavior, they should be accessible via the same old requests.  *This
  removes the need for existing clients to be updated in the first place*.
  If we eventually want to delete the old code keeping the old behavior
  separated from the new will make it clear  explicit what's being dropped
  and what to use instead. ...
 
  Lastly, changing the default behavior to make things sane for new
  developers is, IMO, a bad trade-off
 
 
 That seems the crux of it. Because the MediaWiki API isn't versioned (and
 there are good reasons for it), the recommended best practices form of an
 API request evolves, something like
 
 api.php?continue= formatversion=2 utf8= *your_actual_params*
 
 and over time the best practices boilerplate at the front gets longer
 unless we change a default and break old clients. Examples and
 documentation should show best practices; T103015 is to use formatversion=2
 and https in all example API requests. (We should have used continue= in
 examples for the last year, it's too late now.)
 
 The above is actually a real URL and shows three different approaches:
 1. As the e-mail subject says we're going to make continue= the default in
 a few weeks so you won't need to add it (but clients MUST add rawcontinue=
 to get the old behavior).
 2. formatversion=2 is the future but won't be the default for a while.
 3. If you request formatversion=2 then results default to utf8, so you
 don't need to specify utf8.  (Note formatversion=2 only applies to
 format=json or php.)
 
 Which approach to take is a judgement call, I'm interject-opinion-reluctant
 :)
 
 
 
  because they'll eventually get tripped by us pulling the rug out from
  under their feet by *breaking backwards compatibility stable APIs*.
 
 
 Or, over time the best practices boilerplate endlessly expands:
 responselayout=clean reporterrors=schema facebookoverlordmode= ... Does
 that make our API user-hostile? IMO it just makes it wordy.
 
 
 
  Those sorts of changes should be reserved for experimental or even beta
  APIs.  Continuing queries seems like a stable—and pervasive—part of the API.
 
 
 Cheers,
 -- 
 =S Page  WMF Tech writer
 ___
 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 BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

2015-06-09 Thread Steinsplitter Wiki
Maybe someone with enough time and knowledge can fork compat and keep it 
alive...

 Date: Tue, 9 Jun 2015 13:03:03 +1000
 From: jay...@gmail.com
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for 
 action=query will change at the end of this month
 
 On Tue, Jun 9, 2015 at 6:04 AM, Ilya Korniyko intra...@gmail.com wrote:
  It would be nice if MediaWiki API  _AND_ pywikipedia bot do not deprecate
  at once.
 
  Now it looks as
  API:  we are deprecating what we promised to deprecated long ago - ok
  pywikipedia compat:  did not handle the deprecation of API before, and are
  not going to fix copy-pasted in tens of places (not one place, it's never
  that simple) query builders to support rawcontinue, we announce compat as
  discontinued together with the old style API.
  API deprecation was not coordinated with client library deprecation - not ok
 
  If there is one year gap between two deprecations - ok,  bot writers can
  choose either compat or core, and their bots can still work.
  Most users don't use APi directly so it should be the problem of
  coordination between API and clients developers.
 
 On the pywikipedia side, it has been unofficially deprecated for a
 while, and the intention was to decommission compat as gracefully as
 possible, with Wikimania as the final killing ground.
 
 The pywikibot developers roughly hashed out a decommissioning plan at
 the Lyon hackathon, and worked with WMF staff to start doing impact
 analysis.
 https://phabricator.wikimedia.org/T101214
 
 Then the MW API continuation breakage was announced post Lyon. Hmm.
 
 The continuation problem in pywikipedia / compat is not so much those
 50 or so occurrences where continuation bugs appear to exist, but
 1. testing those 50 or so occurrences
 2. finding the other less obvious occurrences
 3. scripts people have written using compat's query.GetData may also
 be broken, as it doesnt do continuation.
 
 With a lot of wasted effort, 1  2 might be resolved so that 'compat'
 code works, and someone could create a hack on query.GetData which
 adds continuation for scripts not yet adapted to do continuation.
 However the active pywikibot developers (approx. 5 people?) are
 focused on making core better , including about 10 complex patches
 under review that improve its query continuation algorithms, and
 making core more compatible with 'compat' to ease the pain of
 switching to core.
 
 If anyone submits patches for compat continuation bugs affecting them,
 they will be reviewed (usually by people familiar with compat) with
 the presumption that the patch author has tested it, and merged if
 there are no major problems.
 
 --
 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] old-bugzilla.wikimedia.org to be switched off in favor of static-bugzilla

2015-06-08 Thread Steinsplitter Wiki
 I'd like to thank John  Daniel for all their work creating static-bz!

+1

 From: aklap...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 Date: Mon, 8 Jun 2015 17:13:08 +0200
 Subject: [Wikitech-l] old-bugzilla.wikimedia.org to be switched off in favor 
 of static-bugzilla
 
 Hi everybody!
 
 More than six months ago, Wikimedia migrated its bug report management
 from Bugzilla to Phabricator.
 At the same time, Bugzilla was turned read-only (but still allowed
 users to log in to access and manually migrate votes or saved searches)
 and moved to the address old-bugzilla.wikimedia.org.
 
 Before that migration, users were asked to join Phabricator and were
 made aware of required steps and limitations [1].
 This was done via a banner on top of Bugzilla, emails on wikitech-l@,
 announcements on en.wp Village Pump, and two emails to all Bugzilla
 users who had logged in since October 2013 [2].
 
 Now after everybody had more than six months to switch to Phabricator,
 old-bugzilla.wikimedia.org is planned to get switched off on June 22nd
 [3] (as keeping Bugzilla running requires maintenance like applying
 security updates).
 
 Thanks to John and Daniel, a static HTML version of old-bugzilla exists
 at 
 https://static-bugzilla.wikimedia.org [4].
 It allows to still access those historical Bugzilla reports and the
 related history/activity.
 
 Please note that you can still claim the activity of your Bugzilla
 account imported into Phabricator [5] after switching off old-bugzilla,
 as this functionality does not rely on old-bugzilla being available. 
 
 I'd like to thank John  Daniel for all their work creating static-bz!
 
 Cheers,
 andre
 
 [1] https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla#Missing_data
 [2] https://phabricator.wikimedia.org/T618
 [3] https://phabricator.wikimedia.org/T95184#1327072
 [4] https://phabricator.wikimedia.org/T85140
 [5] 
 https://www.mediawiki.org/wiki/Phabricator/Help#Claiming_your_previous_Bugzilla_and_RT_accounts
 
 -- 
 Andre Klapper | Wikimedia Bugwrangler
 http://blogs.gnome.org/aklapper/
 
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

2015-06-03 Thread Steinsplitter Wiki
I haven't followed this discussion, however i am wondering why api is not keep 
backward compatible. This will break a lot of stuff and i am wondering why we 
need such changes in the app---

Best :-)
Steinsplitter 

 Date: Tue, 2 Jun 2015 16:42:47 -0400
 From: bjor...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org; mediawiki-api-annou...@lists.wikimedia.org
 Subject: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for 
 action=query will change at the end of this month
 
 As has been announced several times (most recently at
 https://lists.wikimedia.org/pipermail/wikitech-l/2015-April/081559.html),
 the default continuation mode for action=query requests to api.php will be
 changing to be easier for new coders to use correctly.
 
 *The date is now set:* we intend to merge the change to ride the deployment
 train at the end of June. That should be 1.26wmf12, to be deployed to test
 wikis on June 30, non-Wikipedias on July 1, and Wikipedias on July 2.
 
 If your bot or script is receiving the warning about this upcoming change
 (as seen here
 https://www.mediawiki.org/w/api.php?action=querylist=allpages, for
 example), it's time to fix your code!
 
- The simple solution is to simply include the rawcontinue parameter
with your request to continue receiving the raw continuation data (
example

 https://www.mediawiki.org/w/api.php?action=querylist=allpagesrawcontinue=1).
No other code changes should be necessary.
- Or you could update your code to use the simplified continuation
documented at https://www.mediawiki.org/wiki/API:Query#Continuing_queries
(example

 https://www.mediawiki.org/w/api.php?action=querylist=allpagescontinue=),
which is much easier for clients to implement correctly.
 
 Either of the above solutions may be tested immediately, you'll know it
 works because you stop seeing the warning.
 
 I've compiled a list of bots that have hit the deprecation warning more
 than 1 times over the course of the week May 23–29. If you are
 responsible for any of these bots, please fix them. If you know who is,
 please make sure they've seen this notification. Thanks.
 
 AAlertBot
 AboHeidiBot
 AbshirBot
 Acebot
 Ameenbot
 ArnauBot
 Beau.bot
 Begemot-Bot
 BeneBot*
 BeriBot
 BOT-Superzerocool
 CalakBot
 CamelBot
 CandalBot
 CategorizationBot
 CatWatchBot
 ClueBot_III
 ClueBot_NG
 CobainBot
 CorenSearchBot
 Cyberbot_I
 Cyberbot_II
 DanmicholoBot
 DeltaQuadBot
 Dexbot
 Dibot
 EdinBot
 ElphiBot
 ErfgoedBot
 Faebot
 Fatemibot
 FawikiPatroller
 HAL
 HasteurBot
 HerculeBot
 Hexabot
 HRoestBot
 IluvatarBot
 Invadibot
 Irclogbot
 Irfan-bot
 Jimmy-abot
 JYBot
 Krdbot
 Legobot
 Lowercase_sigmabot_III
 MahdiBot
 MalarzBOT
 MastiBot
 Merge_bot
 NaggoBot
 NasirkhanBot
 NirvanaBot
 Obaid-bot
 PatruBOT
 PBot
 Phe-bot
 Rezabot
 RMCD_bot
 Shuaib-bot
 SineBot
 SteinsplitterBot
 SvickBOT
 TaxonBot
 Theo's_Little_Bot
 W2Bot
 WLE-SpainBot
 Xqbot
 YaCBot
 ZedlikBot
 ZkBot
 
 
 -- 
 Brad Jorsch (Anomie)
 Software Engineer
 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] API BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

2015-06-03 Thread Steinsplitter Wiki
yes.

 Date: Wed, 3 Jun 2015 04:25:10 -0700
 From: ab...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for 
 action=query will change at the end of this month
 
 Steinsplitter, just to be clear, you meant API, not app, correct?
 
 On Wed, Jun 3, 2015 at 3:49 AM, Steinsplitter Wiki 
 steinsplitter-w...@live.com wrote:
 
  I haven't followed this discussion, however i am wondering why api is not
  keep backward compatible. This will break a lot of stuff and i am wondering
  why we need such changes in the app---
 
  Best :-)
  Steinsplitter
 
   Date: Tue, 2 Jun 2015 16:42:47 -0400
   From: bjor...@wikimedia.org
   To: wikitech-l@lists.wikimedia.org;
  mediawiki-api-annou...@lists.wikimedia.org
   Subject: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for
  action=query will change at the end of this month
  
   As has been announced several times (most recently at
   https://lists.wikimedia.org/pipermail/wikitech-l/2015-April/081559.html
  ),
   the default continuation mode for action=query requests to api.php will
  be
   changing to be easier for new coders to use correctly.
  
   *The date is now set:* we intend to merge the change to ride the
  deployment
   train at the end of June. That should be 1.26wmf12, to be deployed to
  test
   wikis on June 30, non-Wikipedias on July 1, and Wikipedias on July 2.
  
   If your bot or script is receiving the warning about this upcoming change
   (as seen here
   https://www.mediawiki.org/w/api.php?action=querylist=allpages, for
   example), it's time to fix your code!
  
  - The simple solution is to simply include the rawcontinue parameter
  with your request to continue receiving the raw continuation data (
  example
  
  https://www.mediawiki.org/w/api.php?action=querylist=allpagesrawcontinue=1
  ).
  No other code changes should be necessary.
  - Or you could update your code to use the simplified continuation
  documented at
  https://www.mediawiki.org/wiki/API:Query#Continuing_queries
  (example
  
  https://www.mediawiki.org/w/api.php?action=querylist=allpagescontinue=
  ),
  which is much easier for clients to implement correctly.
  
   Either of the above solutions may be tested immediately, you'll know it
   works because you stop seeing the warning.
  
   I've compiled a list of bots that have hit the deprecation warning more
   than 1 times over the course of the week May 23–29. If you are
   responsible for any of these bots, please fix them. If you know who is,
   please make sure they've seen this notification. Thanks.
  
   AAlertBot
   AboHeidiBot
   AbshirBot
   Acebot
   Ameenbot
   ArnauBot
   Beau.bot
   Begemot-Bot
   BeneBot*
   BeriBot
   BOT-Superzerocool
   CalakBot
   CamelBot
   CandalBot
   CategorizationBot
   CatWatchBot
   ClueBot_III
   ClueBot_NG
   CobainBot
   CorenSearchBot
   Cyberbot_I
   Cyberbot_II
   DanmicholoBot
   DeltaQuadBot
   Dexbot
   Dibot
   EdinBot
   ElphiBot
   ErfgoedBot
   Faebot
   Fatemibot
   FawikiPatroller
   HAL
   HasteurBot
   HerculeBot
   Hexabot
   HRoestBot
   IluvatarBot
   Invadibot
   Irclogbot
   Irfan-bot
   Jimmy-abot
   JYBot
   Krdbot
   Legobot
   Lowercase_sigmabot_III
   MahdiBot
   MalarzBOT
   MastiBot
   Merge_bot
   NaggoBot
   NasirkhanBot
   NirvanaBot
   Obaid-bot
   PatruBOT
   PBot
   Phe-bot
   Rezabot
   RMCD_bot
   Shuaib-bot
   SineBot
   SteinsplitterBot
   SvickBOT
   TaxonBot
   Theo's_Little_Bot
   W2Bot
   WLE-SpainBot
   Xqbot
   YaCBot
   ZedlikBot
   ZkBot
  
  
   --
   Brad Jorsch (Anomie)
   Software Engineer
   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
 
 ___
 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 BREAKING CHANGE: Default continuation mode for action=query will change at the end of this month

2015-06-03 Thread Steinsplitter Wiki
Most operator are volunteers and don't have time to change the code every month 
because there is a change in the api. Because of this devs should keep the api 
backward-compatible. 
Also wondering why wee need this new api. The old one was imho perfectly.

Was the new api coded by WMF or by volunteers?

 I feel that bot operators should actively pay attention to the technical
 aspects of the community and the mailing lists.
Sorry, i disagree. Bot operators are volunteers and not payed staffers. Most of 
them having a job and real live.

-- Steinsplitter

 Date: Wed, 3 Jun 2015 14:50:48 +0300
 From: yastrak...@wikimedia.org
 To: wikitech-l@lists.wikimedia.org
 CC: mediawiki-api-annou...@lists.wikimedia.org
 Subject: Re: [Wikitech-l] API BREAKING CHANGE: Default continuation mode for 
 action=query will change at the end of this month
 
 I feel that bot operators should actively pay attention to the technical
 aspects of the community and the mailing lists. So, the bot operator who
 never updates their software, doesn't pay attention to the announcements,
 and ignores api warnings should be blocked after the deadline.  Bot
 operators do not operate in a vacuum, and should never run bots just for
 the sake of running them.
 Community should always be able to find and communicate with the bot
 operators.
 Obviously we should not make sudden changes (except in the
 security/breaking matters), and try to make the process as easy as
 possible. The rawcontinue param is exactly that, simply adding it will keep
 the logic as before.
 
 Lastly, I again would like to promote the idea discussed at the hackathon
 -- a client side minimalistic library that bigger frameworks like pywikibot
 rely on, and that is designed in part by the core developers. See the
 proposal at
 https://www.mediawiki.org/wiki/Requests_for_comment/Minimalistic_MW_API_Client_Lib_Specification
 On Jun 3, 2015 2:29 PM, John Mark Vandenberg jay...@gmail.com wrote:
 
  On Wed, Jun 3, 2015 at 3:42 AM, Brad Jorsch (Anomie)
  bjor...@wikimedia.org wrote:
   ...
   I've compiled a list of bots that have hit the deprecation warning more
   than 1 times over the course of the week May 23–29. If you are
   responsible for any of these bots, please fix them. If you know who is,
   please make sure they've seen this notification. Thanks.
 
  Thank you Brad for doing impact analysis and providing a list of the
  71 bots with more than 10,000 problems per week.  We can try to solve
  those by working with the bot operators.
 
  If possible, could you compile a list of bots affected at a lower
  threshold - maybe 1,000.  That will give us a better idea of the scale
  of bots operators that will be affected when this lands - currently in
  one months time.
 
  Will the deploy date be moved back if the impact doesnt diminish by
  bots being fixed?
 
  --
  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
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Anonymous editing impact on mobile

2015-04-29 Thread Steinsplitter Wiki
It would be helpful to see how much mobile acconts getting indf. blocked (and 
how much have all edits in main ns and file ns deleted)

Best

 Date: Tue, 28 Apr 2015 23:13:32 -0400
 From: risker...@gmail.com
 To: wikitech-l@lists.wikimedia.org
 Subject: Re: [Wikitech-l] Anonymous editing impact on mobile
 
 How can edits from logged-in users be down 152%?  The maximum decrease
 should be 100% - and that would mean no edits from logged-in users.  Same
 for first edits by logged-in users.
 
 I seriously wonder about the number of accounts created on mobile - are
 we really adding 0.05% of all of the current existing accounts every single
 month just on mobile?  Or does that include accounts that already existed
 on a WMF site?
 
 Risker/Anne
 
 
 
 On 28 April 2015 at 20:00, Jon Robson jrob...@wikimedia.org wrote:
 
  Anonymous editing was enabled on mobile web on 30th March 2015 to all users
  (previous it was available in an experimental mode of the site). Now we
  have almost a month's worth of data I thought it would be a good time to
  check the impact... it's a little disappointing to be honest... but it
  depends what we are optimising and consider the most important.
 
  Quick summary:
  * All edits up 154%
  * Edits from logged in users down 152%
  * Errors up 600%
  * No noticeable impact on the new active editor graph [0] (editors that hit
  5 edits in the month period)
  * First edits by logged in users down 176% (although this could arguably be
  said to  be compensated by anonymous edits)
  * New account creation up by 192%
 
  Follow ups
  * Aaron H, it would be great if you could report back with some findings on
  the quality of the edits during this same period.
  * Can anyone provide theories why registrations jumped so much? This might
  be related to the change or because of something else
 
  Details on the queries I ran:
  In March for a 26 day period before the change:
  * 170,948 total edits [1]
  * 169,845 non-anonymous edits [6]
  ** by 40,658 distinct users [7]
  * 26,617 users completely their first ever edit [11]
  * 9,528 errors [8]
  * 219,012 accounts created on mobile [12]
 
  For a similar 26 day period in April
  * 263,986 total edits [2]
  * 136,079 non-anonymous edits [4]
  ** by 26,823 distinct users [5]
  * 15,109 users completely their first ever edit [10]
  * 58,394 errors [9]
  * 419,976 accounts created on mobile [13]
 
  [0]  http://mobile-reportcard.wmflabs.org/
  [1] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015030100 and timestamp  2015032700
  [2] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015040100 and timestamp  2015042700
  [3] https://phabricator.wikimedia.org/T97494
  [4] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015040100 and timestamp  2015042700 and
  event_username is NOT NULL
  [5] select count(distinct event_username) from MobileWebEditing_8599025
  where event_action = 'success' and timestamp  2015040100 and timestamp
   2015042700 and event_username is NOT NULL
  [6] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015030100 and timestamp  2015032700 and
  event_username is NOT NULL
  [7] select count(distinct event_username) from MobileWebEditing_8599025
  where event_action = 'success' and timestamp  2015030100 and timestamp
   2015032700 and event_username is NOT NULL
  [8] select count(*) from MobileWebEditing_8599025 where event_action =
  'error' and timestamp  2015030100 and timestamp  2015032700
  [9] select count(*) from MobileWebEditing_8599025 where event_action =
  'error' and timestamp  2015040100 and timestamp  2015042700
  [10] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015040100 and timestamp  2015042700 and
  event_userEditCount = 0
  [11] select count(*) from MobileWebEditing_8599025 where event_action =
  'success' and timestamp  2015030100 and timestamp  2015032700 and
  event_userEditCount = 0
  [12] select count(*) from ServerSideAccountCreation_5487345 where
  event_displayMobile = 1 and timestamp  2015030100 and timestamp 
  2015032700
  [13] select count(*) from ServerSideAccountCreation_5487345 where
  event_displayMobile = 1 and timestamp  2015040100 and timestamp 
  2015042700
  ___
  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

[Wikitech-l] Too much open bugs (Wikimedia Commons, Media storage)

2014-05-14 Thread Steinsplitter Wiki
Hi,
I wanted to bring to your attention a few critical issues that are negatively 
affecting the workof the Commons community and the wider Wikimedia projects.
First, there are about 36 unresolved bugs [0] in the Media storage component. 
Swift is a vitalcomponent of the projects' ability to show images and other 
media, and it having so manyopen bugs causes serious ongoing issues, not only 
on Commons, but everywhere.
Some of these bugs are high priority, and have been open since 2012. The 
community of adminsare straining under the load, and it's not getting any 
better now that additional paths into theupload pipeline are becoming available.
UploadWizard, too, is fundamentally broken. There are a *lot* of open bugs [1] 
[2] and the interfaceis in need of design love.
It would be awesome to see these issues addressed in the coming months. In 
particular, becauseWiki Loves Monuments will start in September, it would be 
great to have these issues fixedon or before August 13th, giving Commons about 
two weeks to test the fixes and changesbefore the contest starts, and plenty of 
room for backporting urgent fixes.
Regards,Steinsplitter
https://commons.wikimedia.org/wiki/User:Steinsplitter

[0] 
https://bugzilla.wikimedia.org/buglist.cgi?component=Media%20storageproduct=Wikimediaresolution=---[1]
 
https://commons.wikimedia.org/wiki/Special:PrefixIndex/Commons:Upload_help/Archive[2]
 
https://bugzilla.wikimedia.org/buglist.cgi?component=UploadWizardproduct=MediaWiki%20extensionsresolution=---
  
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l