Re: [Wikimedia-l] Disabe Media Viewer for non-logged-in users and logged-in users on Wikimedia Commons

[Gilles Dubuc]

Steinsplitter, if you're interested in reviving this, please have the
intellectual honesty of running the RfC again and publicizing it widely. As
others already pointed out, the context of that RfC is nothing like today.
Not only Media Viewer itself changed a lot, with many fixes based on direct
community feedback, but the very people who expressed their opinion in 2014
might have changed their views.

If anything, if you still get the same outcome now, you'll have a much
stronger case for what you're asking for.

On Tue, Mar 15, 2016 at 9:16 AM, rupert THURNER 
wrote:

> On Mar 14, 2016 23:47, "Fæ"  wrote:
> >
> > On 14 March 2016 at 22:12, Marc A. Pelletier  wrote:
> > > On 16-03-14 05:01 PM, Vi to wrote:
> > >> Ignoring a wide community
> > >> consensus is *always* a mistake.
> > >
> > > It is.  I never advocated otherwise.
> > >
> > > That old RfC, however, does not show a wide community consensus, let
> > > alone a consensus of the actually impacted community.
> > >
> > > -- Coren / Marc
> >
> > You could walk in the shoes of others, as Jimbo advocates, and you
> > could create an RFC to show whether users prefer it, rather than
> > putting the burden of proof onto a community that has already
> > established what it wanted.
>
> Marc just look at the German Wikipedia which recently voted for the switch
> on of visual editor. It was community driven and caused no stir.
>
> I really fail to understand that you guys always go down a confrontational
> path instead of inventing a solution so all users have the option to
> choose. Maybe a media tab or similar.
>
> Rupert
>
> Rupert
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] IRC office hours: Shared hosting

[Gilles Dubuc]

As part of T113210 [1], which is a broader discussion on track for the
developer summit, I am hosting two IRC office hours back to back [2] on
December 21st from 20:00 UTC to 22:00 UTC.

The previous office hour [3] focused on ways to reconnect to the shared
hosting community. This time two very different topics will be discussed.

*The open questions in the descriptions below are by no means meant to be
exhaustive, nor are they expected to be fully answered by the end of those
office hours. They are just examples to clarify the context of the titles.*

*Shared hosting technical alternatives*

During the last office hour on the topic of non-technical mediawiki
installs, people seemed very eager to discuss new technical solutions that
could offer a viable alternative to shared hosting.

Could new technologies like containers allow for performance/cost ratios
comparable to shared hosting? If not, how big would the penalty be? How
much maintenance would we have to do to keep deployment on such platforms
up to date?

Shared hosting has always suffered from the fact that it's not used at the
WMF and therefore only maintained on a volunteer basis. How would things be
different with new tech?

*Shared hosting support definition*

Shared hosting usage is already a reality and we should do a better job
accounting for it. Currently mediawiki contributors have no visibility in
what should be supported and to what degree. Our browser support is graded
and very clear, meanwhile our server-side support is not:
https://www.mediawiki.org/wiki/Compatibility

Should we model our server-side compatibility guidelines on the graded
system we have for browsers? If so, what would that look like? How could we
break down "shared hosting support" into more discreet server-side
capabilities?


[1] https://phabricator.wikimedia.org/T113210
[2] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
[3]
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-11-19-19.00.html
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Update from the Wikimedia Performance Team

[Gilles Dubuc]

Hello,

This is the monthly report from the Wikimedia Performance team.

## Our progress ##

* Availability. We've done a major overhaul of the ObjectCache interfaces. Many
factory methods were deprecated or removed, reducing it to just four simple
entry points. New docs at
https://doc.wikimedia.org/mediawiki-core/master/php/classObjectCache.html#details

We've written a new IExpiringStore interface for convenient TTL constants,
e.g. $cache::TTL_WEEK. See
https://doc.wikimedia.org/mediawiki-core/master/php/interfaceIExpiringStore.html

We've migrated most use of wfGetMainCache() to WANObjectCache. Work
continued on the librarization of BagOStuff, Memcached, and other object
cache classes.

* Performance testing infrastructure. We've created dedicated dashboards
for portals:

https://grafana.wikimedia.org/dashboard/db/webpagetest-portals

And for mobile:

https://grafana.wikimedia.org/dashboard/db/mobile-webpagetest

We now test one page using real 3G connections (from San Francisco and
Bangalore) and test other pages using the following physical devices:
iPhone 6, iPad mini 2 and Moto G.

* Media stack. We've extended Thumbor with 12 small plugins to meet our
needs and match our existing thumbnailing feature set. This includes
support for all the file formats in use on Commons. The Thumbor Vagrant
stack is now very close to having all the moving parts needed in
production, with basic Vagrant roles for Varnish and Swift having been
written to that end. Our objective is to finish the work on VM by the
holidays and have it ready to be showcased and discussed collectively at
the developer summit in a breakout session.

* ResourceLoader. We've written a new mw.requestIdleCallback API for
scheduling deferred tasks. We've removed usage of the  msg_resource_links
DB table. We now use message config from the module registry directly.
We've migrated MessageBlobStore msg_resource DB table to an object cache
(to be deployed in January 2016): https://phabricator.wikimedia.org/T113092

## How are we doing? ##

Client-side performance has remained stable over the past month. Save Timing
has also remained stable, around the 1s median mark.

The job queue's health improved greatly after adding a new server to the
pool, with the job queue size dropping drastically and the 99th percentile
job processing time going from one day to one hour:

* https://grafana.wikimedia.org/dashboard/db/job-queue-health

There was a small scare about a sudden increase of the SpeedIndex value
across the board:

https://grafana.wikimedia.org/dashboard/db/webpagetest

But it was entirely explained by the fundraising banner, which doesn't
appear immediately on pageload. SpeedIndex measures the time it takes for
the above-the-fold area to "settle" visually. The banner appears late and
pushes the content down, which delays the time when visual changes stop
happening for the above-the-fold area.

Until next time,
Aaron, Gilles, Peter, Timo, and Ori.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] IRC office hour this Thursday: reconnecting with the shared hosting community

[Gilles Dubuc]

As part of T113210 [1], which is a broader discussion on track for the
developer summit, I am hosting an IRC office hour [2] this Thursday at
19:00 UTC.

Since shared hosting is a broad topic, this session will focus specifically
on brainstorming ways to reconnect with the shared hosting community.
Shared hosting mediawiki users are currently underrepresented in the
greater mediawiki community. We rarely run into them in phabricator, on
gerrit or on the mailing lists. Which means that people often have to think
on their behalf about their use cases and issues, instead of getting direct
input.

There must be practical ways to bring those thousands of mediawiki users
back into the fold, so to speak. Hopefully we can come up with interesting
ideas to achieve that.

And if you happen to be a shared hosting user, by all means, please join
this IRC office hour :)

[1] https://phabricator.wikimedia.org/T113210
[2] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] Net neutrality: since when has it had anything to do with price?

[Gilles Dubuc]

To me Josh's point in the other thread settles this argument. I can't
presume to know better than the people this service is made for what is
good for them. People in other cultures have values as well. They might be
different than ours, but more importantly, they have to be pitted against
constraints that are completely different than ours. It's perfectly normal
that the result of the moral equation people have to solve can be different
than ours. It's also logical for it to evolve over time, as the constraints
change. Let people in the countries where Wikipedia Zero operates decide
whether it fits their vision of the movement or not. I'm sure that if users
in a given country find it contrary to their beliefs or what they think to
be the movement's values, they'll campaign against it on their own accord.

On Wed, Apr 1, 2015 at 8:34 PM, Jens Best best.j...@gmail.com wrote:

 Hi Nathan and everybody,

 Last time I checked my mail (containing my repsonse to Gerard) wasn't
 published and as I sent it yesterday morning I'm suprised that it took that
 long to arrive.

 Also, I would like you to stop your wrong assumptions about off-topic -
 As Gerard made a statement to Wikipedia Zero my answer to him isn't surely
 off topic. I didn't decide to discuss the pros/cons of WP0 in the
 Welcome-Mail to Kourosh.
 In my welcoming response I just pointed out to Kourosh that one of his new
 responsibilities (highlighted by Lila) is a big problem for the global
 community which cares about an open and free web, inculding several NGOs of
 the Global South who spoke out clearly against Wikipedia Zero e.g. at the
 Internet Governance Forum (IGF) 2014 in Istanbul (where net neutrality was
 a main subject of discussion). As this subject was subsequentially
 discussed in the threat my answer to Gerard's input was not off-topic at
 all.

 Right now I don't feel any open-mindedness towards even the possibilitiy
 that The Great WMF could have made a mistake by going to bed with the
 telecoms to get zero-rated. As long as there isn't even the slightest
 willingness to acknowledge the possibility that WP0 was a mistake it
 becomes more and more senseless to talk with official and inofficial
 representatives of the WMF-system.

 Maybe WMF and with it Wikipedia has to learn the consequences of its
 mistakes the hard way. But the ignorance towards facts which was presented
 over the last months when it comes to the glorious Wikipedia Zero and the
 fact that it is a violation of core principle of the free and open web is
 enourmous and without any excuse for an organisation carrying that amount
 of responsibility when it comes to stand for an open web which made
 Wikipedia possible in the first.

 Hopefully with Kourosh the organisation will get somebody who has the
 outside-world experience and the professional courage to stop mistakes like
 Wikipedia Zero. We'll see. Apart from that I rest my case, all the
 recurring participants in the ongoing discussion exchanged their arguments
 already. I don't see new faces in the discussion and therefore I'm actually
 not interested to repeat my arguments over and over.

 Just, because I promised him, two main answer to James:

 - Of course net neutrality has a monetary aspect. Read the
 definition[1]: …treat
 all data on the Internet https://en.wikipedia.org/wiki/Internet equally,
 not discriminating or *charging differentially* by content, site, platform,
 application, type of attached equipment, or mode of communication. If you
 have to pay different prices for different data it is a basic violation of
 net neutrality. net neutrality isn't about techy aspects, it is about power
 and structural equality in the web.

 - Wikipedia Zero can't offer the promised grow because by definition it is
 a *Walled Wikipedia*. WP0 will always be just a marketing tool for telecoms
 to lure new customers in and train them that different data has different
 price tag. Their teachings are: When you wanna leave Wikipedia, wanna
 follow the links to really enrich your knowledge by using all the other
 free content in the web - you have to pay. So therefore Wikipedia Zero is
 not about the free knowledge of the world, it is a Wikipedia which has
 chosen the wrong side of the play about a free and open web for the
 self-involved purpose of being the one and only source for knowledge.
 Welcome to world of first-world-owned telecoms teaching their new Global
 South-customers an internet far away from what the internet was supposed
 to be.


 cheers

 Jens

 [1] https://en.wikipedia.org/wiki/Net_neutrality

 PS: @Marc No Marc, no bits of my message were accidentally elided. When I
 write in a mailinglist I, of course, express my opinion and my points of
 view, but your nit-picking and pseudo-kind cynical remarks additionally
 prove how biased the whole discussion is at the moment in the WMF-universe.
 Critics are not welcome. Message recieved, continue with your holy mission.
 Hail Wikipedia, the mother of all 

Re: [Wikimedia-l] Next steps regarding WMF-community disputes about deployments

[Gilles Dubuc]

 from my own experience, the Flow and Multimedia folks track bugs somewhere
 else where I can't even view or comment


Bugs and tasks are public for the Multimedia team. If you mean bugs in
the bastardized sense of the term which is things filed in bugzilla, then
yes, the Multimedia team doesn't usually file building/refactoring tasks in
bugzilla, we use mingle instead, which is public and can be commented on by
everyone: http://ur1.ca/i1x3g We regularly link to our mingle cards on our
mailing list updates, it's never been a secret area. I find that the
mailing list is a better place for discussion, though, and we summarize in
regular threads what tasks we're working on or planning to work on. In
practice that's what's always happened anyway, people interested in what
we're up to will reply to the detailed mailing list updates rather than
comment on Mingle. Probably because Mingle's comment support is terrible.

As for actual bugs (defects) on products the Multimedia team is responsible
for, they are currently tracked on bugzilla like everything else. It can
happen ocassionally that we fix a bug and forget to file it in bugzilla,
but generally speaking a bug/defect tracked in Mingle has a bugzilla
counterpart. The existing disconnect and the fact that we sometimes forget
to file a counterpart is one of the reasons we want to have a unified tool
to do all the things people currently use bugzilla, mingle and trello for.

Our team will be one of the first to migrate to phabricator when the
migration starts, because it will allow us to treat tasks, workload and
defects in a single place. It will also give a much clearer view of what's
going on to casual observers. The only reason why our team uses Mingle
instead of Bugzilla for building tasks and triage is that Bugzilla offers
no workload management and is often a poor fit for things that aren't
defects. We're definitely not using Mingle to get things out of view (since
it's public and regularly linked to), it's just that in the status quo
Bugzilla alone didn't offer what we needed. I'm sure other teams use Trello
and other tools for similar reasons. This is all coming from needs not
covered by Bugzilla and we know very well how much that sucks in various
ways, including the introduction of signup hurdles for people who want to
interact with us, and the lack of discoverability, despite linking to
Mingle every time we can. We certainly hope that the move to phabricator
will make help people see and comment on what we're doing. Feeling like
we're the only ones active on a particular tool is unhealthy for our
projects, that's definitely not what we're looking for with phabricator, on
the contrary.


On Mon, Aug 25, 2014 at 6:19 AM, svetlana svetl...@fastmail.com.au wrote:

 On Mon, 25 Aug 2014, at 13:19, Pine W wrote:
  I have heard very few people say don't ever change the interface. I
 have
  heard people say don't force an interface change on me that I don't
 think
  is an improvement.
 
  VE was a good example. The sentiment of the community wasn't that VE''s
  concept is wrong, it's that the implementation and rollout had major
  deficiencies.
 
  The MV issue is larger than than the usual editor-focused interface
 change
  because it impacts readers as well as editors, and there were issues with
  the display of licenses to readers. Personally I feel that the MV issues
  are fixable but the rollout should have been handled differently, and I
 am
  glad that the community and WMF both want to avoid repeating rollout
  problems again and again.
 
  Pine


 This instance is not new;
 https://meta.wikimedia.org/wiki/Limits_to_configuration_changes is a
 historical list of similar pattern in the relationship.

 They already told you that they are doing this to not lose readers, so
 that fundraising keeps working. Tops you can do is, like the WMF folks
 remarked earlier, is have community work on what it needs from the bottom
 up grassroots etc.

 A first step here, I believe, is have the Teams track bugs in the open;
 from my own experience, the Flow and Multimedia folks track bugs somewhere
 else where I can't even view or comment (and even if I could, it being
 different from Bugzilla would make things harder). I'm not sure what about
 migration to Phabricator, but I think it's an operations style of thing
 (I'm yet to figure out how to get involved, but it'd make it easier for
 anyone to work on the new features - they are really documented on-wiki
 (thankfully they only internalise only bug tracking atm), although so far
 only in English mostly).

 svetlana

 ___
 Wikimedia-l mailing list, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

___
Wikimedia-l mailing list,