Re: [Wikitech-l] Data visualization for wiki

2016-02-04 Thread Yuri Astrakhan 
Ivo, there are two aspects of building graphs for Wiki:
* defining a "type" or "style" of a graph
* instantiating a graph with the specific data

Defining a new graph is a relatively complex programming task - one has to
program how graph would look like using Vega syntax. Instantiating is much
easier - one has to simply provide the needed data and a few parameters
controlling the graph.  Graph:Chart
  is a good example
which has been copied to many wikis.  The graph is generated via a complex
Lua script, but that complexity is hidden from all the graph users.

Frederic Bolduc (CCed) has done a good job building an experimental Visual
Editor plugin for graphs, but that plugin attempts to do both tasks -
define the new graph type and allow for users to instantiate it, and we do
not have enough resources to support both aspects well.  It would be ideal
if you helped with that extension to change it into a template editor +
galery picker. This way community may build the graphs it needs, and lists
them in a "gallery of good graphs". Visual Editor would than show a "list
of recommended graphs" as a set of icons. Editors will be able to quickly
insert a graph template and provide data for it.

On Fri, Feb 5, 2016 at 2:10 AM, Ivo Kruusamägi 
wrote:

> So, some questions:
>
> * how important could that in-wiki image editing capability be?
> * has anything been done so far?
>
> I'd like to find some topic suitable for university student to work on. So
> here it is: free workforce for wiki. Act now the get that! Offer some
> topics. PHP related tasks preferred.
>
> Ivo
>
> 2016-02-04 14:20 GMT+02:00 Ivo Kruusamägi :
>
> > OK, this Graph extension seems rather advanced and even though not
> exactly
> > what I had in mind, somewhat similar. So may I conclude it would be
> > pointless to go into that direction? Or are there some things, that may
> > need someone to work with them? Like (making random example): building
> very
> > simple Visual Editor add-on to enable fast creation of some more simple
> > graphs (like pie charts from the enormous variety of possibilities
> > )?
> >
> > Could I get more information about need for image editors? *I'd like to
> > find something that might be suitable topic for bachelor thesis* and
> > vandering around alone inside the topic not yet known to me may not prove
> > to be fruitful.
> >
> > As for this Commons topic. Yes, something similar to Wikidata Game, but
> > directed towards Commons and not Wikidata. More in line with Estonian
> sites
> > Ajapaik  (for adding geolocation information
> > to old images), sift.pics (for determining image types) and
> > postkaart.ajapaik.ee (for digitalizing text in old postcards).
> >
> > Ivo
> >
> > 2016-02-04 5:00 GMT+02:00 MZMcBride :
> >
> >> Ivo Kruusamägi wrote:
> >> >What I'd like to see is some development, that would make it possible
> for
> >> >user to create visualizations inside MediaWiki. Something so easy that
> a
> >> >child could do that. Like this . Workflow example:
> >> 1)
> >> >user selects sth like Create Data Visualization, 2) has some selections
> >> >about cart type, colors, etc, 3) place to write down text (title, axes,
> >> >description) and 4) a table to fill in with data (values + their text
> >> >labels). That could then be saved as one revision. After that every
> other
> >> >user could edit this graph with the same selections and data tables
> just
> >> >like users edit articles and edit history is saved and easy to compare.
> >> >
> >> >Image files like this
> >> > or that
> >> ><
> >>
> https://commons.wikimedia.org/wiki/File:Tree_map_exports_2010_Estonia.svg
> >> > are ridiculous and fixes like that
> >> > are not that
> >> flexible,
> >> >pretty and easy to use as what we need. So lets move forward.
> >>
> >> Are you familiar with the "Graph" MediaWiki extension? Here's a demo:
> >> . This MediaWiki
> >> extension is deployed to Wikimedia wikis, including all the Wikipedias.
> >>
> >> >There are plenty of GPL licensed solutions that could be integrated
> with
> >> >MediaWiki. But I can't be only one thinking about this.
> >>
> >> You're not. :-)
> >>
> >> >So what should I know about that topic so that this work could really
> be
> >> >useful? I.e. how to avoid reinventing the wheel (like building
> something
> >> >already in development) and how to be sure that it could be easily
> >> >incorporated later? Who would be the perfect people to talk about this
> >> >topic?
> >>
> >> This mailing list is great for general discussion. Or we have a
> >> Phabricator installation at  where
> we
> >> track bugs and feature requests. You can search around for Phabricator
> >> Maniphes

Re: [Wikitech-l] Data visualization for wiki

2016-02-04 Thread Ivo Kruusamägi 
So, some questions:

* how important could that in-wiki image editing capability be?
* has anything been done so far?

I'd like to find some topic suitable for university student to work on. So
here it is: free workforce for wiki. Act now the get that! Offer some
topics. PHP related tasks preferred.

Ivo

2016-02-04 14:20 GMT+02:00 Ivo Kruusamägi :

> OK, this Graph extension seems rather advanced and even though not exactly
> what I had in mind, somewhat similar. So may I conclude it would be
> pointless to go into that direction? Or are there some things, that may
> need someone to work with them? Like (making random example): building very
> simple Visual Editor add-on to enable fast creation of some more simple
> graphs (like pie charts from the enormous variety of possibilities
> )?
>
> Could I get more information about need for image editors? *I'd like to
> find something that might be suitable topic for bachelor thesis* and
> vandering around alone inside the topic not yet known to me may not prove
> to be fruitful.
>
> As for this Commons topic. Yes, something similar to Wikidata Game, but
> directed towards Commons and not Wikidata. More in line with Estonian sites
> Ajapaik  (for adding geolocation information
> to old images), sift.pics (for determining image types) and
> postkaart.ajapaik.ee (for digitalizing text in old postcards).
>
> Ivo
>
> 2016-02-04 5:00 GMT+02:00 MZMcBride :
>
>> Ivo Kruusamägi wrote:
>> >What I'd like to see is some development, that would make it possible for
>> >user to create visualizations inside MediaWiki. Something so easy that a
>> >child could do that. Like this . Workflow example:
>> 1)
>> >user selects sth like Create Data Visualization, 2) has some selections
>> >about cart type, colors, etc, 3) place to write down text (title, axes,
>> >description) and 4) a table to fill in with data (values + their text
>> >labels). That could then be saved as one revision. After that every other
>> >user could edit this graph with the same selections and data tables just
>> >like users edit articles and edit history is saved and easy to compare.
>> >
>> >Image files like this
>> > or that
>> ><
>> https://commons.wikimedia.org/wiki/File:Tree_map_exports_2010_Estonia.svg
>> > are ridiculous and fixes like that
>> > are not that
>> flexible,
>> >pretty and easy to use as what we need. So lets move forward.
>>
>> Are you familiar with the "Graph" MediaWiki extension? Here's a demo:
>> . This MediaWiki
>> extension is deployed to Wikimedia wikis, including all the Wikipedias.
>>
>> >There are plenty of GPL licensed solutions that could be integrated with
>> >MediaWiki. But I can't be only one thinking about this.
>>
>> You're not. :-)
>>
>> >So what should I know about that topic so that this work could really be
>> >useful? I.e. how to avoid reinventing the wheel (like building something
>> >already in development) and how to be sure that it could be easily
>> >incorporated later? Who would be the perfect people to talk about this
>> >topic?
>>
>> This mailing list is great for general discussion. Or we have a
>> Phabricator installation at  where we
>> track bugs and feature requests. You can search around for Phabricator
>> Maniphest task related to vectorized and rasterized image editors, such as
>> . You're welcome to discuss on
>> those tasks. Integrating a decent SVG editor and a decent PNG/JPG/GIF
>> editor would be amazing!
>>
>> >P.S: I also have some development plans for a web platform that will help
>> >to gamify organizing media files in Wikimedia Commons (coordinates,
>> >categories, descriptions, quality assessment, etc). Sort like adding an
>> >additional data layer and when everything works fine then migrating that
>> >information into Commons. Any great ideas there as well? (not so great
>> >ideas could be sent to list :P )
>>
>> Sure. Maybe poke around  if you
>> haven't already? It sounds similar to what you want to do.
>>
>> 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

Re: [Wikitech-l] Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)

2016-02-04 Thread Brad Jorsch (Anomie) 
On Thu, Feb 4, 2016 at 4:00 PM, Federico Leva (Nemo) 
wrote:

> No, this is not what I'm talking about. My problems span multiple weeks or
> months and I reiterate my need for a document outlining the expected
> behaviour.


Off the top of my head, it goes something like this on WMF wikis.

   1. You submit the login form on xxwiki. The response sets a bunch of
   cookies and redirects you to Special:CentralLogin/start on loginwiki.
   2. Loginwiki sets some cookies and redirects you to
   Special:CentralLogin/complete on xxwiki.
   3. xxwiki updates the cookies and redirects you to the returnto page.
   4. The returnto page will have a number of  tags for 1x1 images to
   try to log you in to the other domains in the cluster. It'll also have one
   to try to update the cookies on loginwiki.

The final set of cookies includes xxwikiSession, xxwikiUserID, and
xxwikiUserName locally, and centralauth_Session, centralauth_User, and (if
you checked "remember me") centralauth_Token set on the whole domain. For
most domains the whole domain is like ".wikipedia.org", while for stuff
under wikimedia.org it's the third level like "commons.wikimedia.org".

Even if nothing below works, you *should* be logged in on xxwiki and
loginwiki now.

The 1x1  tags work like this, when they work. They can fail if the
browser blocks 1x1 images or third-party cookies. If any step fails due to
not having the right cookies, it'll just stop there and serve the
transparent PNG.

   1. The  tag points to Special:CentralAutoLogin/start on the target
   wiki. This will redirect to Special:CentralAutoLogin/checkLoggedIn on
   loginwiki.
   2. Loginwiki will redirect back to
   Special:CentralAutoLogin/createSession on the target wiki. Unless it thinks
   you're logged out, of course.
   3. The target wiki will set a session cookie and redirect to
   Special:CentralAutoLogin/validateSession on loginwiki.
   4. Loginwiki will redirect back to Special:CentralAutoLogin/setCookies
   on the target wiki.
   5. The target wiki will set all the relevant cookies and serve a
   transparent 1x1 PNG. Now you should be logged in when you visit any wiki on
   the domain.

When you visit a wiki, aren't logged in, and don't have the "I already did
this" token set in local storage, it does something much like the 1x1 
flow except with a

[Wikitech-l] Help test SessionManager on WMF beta cluster

2016-02-04 Thread Bryan Davis 
One of the conclusions from the recent SessionManager rollout failure [0] was:

"we should have recruited and coordinated testing by developers and
users inside and outside of the WMF while the code was only on the
beta testing cluster"

SessionManager is back on the WMF beta cluster [1] now after being
briefly removed for the 1.27.0-wmf.12 release cycle, so an
announcement seems in order. The beta cluster implements a SUL
authenticated wiki farm that is completely separate from the Wikimedia
production SUL system. Helping test SessionManager there would involve
logging in, logging out, creating new user accounts and generally
wandering around the wikis doing things you would normally do in
production while keeping an eye out for session related issues.

If you spot something (or just think you spotted something) file a
Phabricator task with as many details as you can provide and tag it
with the #reading-infrastructure-team project. For session related
issues getting traces of the headers and cookies used in the requests
that are failing is most helpful. You can also poke around in the
logging interface [2] to try and find associated error messages.

If you find other bugs, report them in Phabricator too. :)

Also please remember NOT TO USE passwords in the beta cluster that
match the passwords you use anywhere else on the planet!


[0]: 
https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-SessionManagerRolloutFailure
[1]: http://deployment.wikimedia.beta.wmflabs.org/wiki/Main_Page
[2]: https://logstash-beta.wmflabs.org/#/dashboard/elasticsearch/default

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

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

Re: [Wikitech-l] restarting of stream.wikimedia.org backend servers in ~ 48hours

2016-02-04 Thread Daniel Zahn 
This has happened today, with about 24 hours delay. Sorry about that.

The maintenance is over and servers and service is back up.

We had to intervene a tiny bit with a manual fix to start redis, but i see
the service running and some connectings again.



On Mon, Feb 1, 2016 at 12:29 PM, Daniel Zahn  wrote:

> Hello,
>
> to anyone who is a client of stream.wikimedia.org
> (https://wikitech.wikimedia.org/wiki/RCStream), so people who run tools
> relying on the RC stream.
>
> In about 48 hours, on February 3rd at 20:00 UTC, we will have to reboot
> the backend servers of the stream.wm.org service, rcs1001 and 1002.
>
> This service is loadbalanced and we will only reboot the 2 servers one at
> a time,
> so there should be no service downtime.
>
> But nevertheless your clients will get disconnected and may need your
> intervention to reconnect.
>
> Please be prepared to do so if your client will not automatically
> reconnect.
>
> I will send another mail once this has happened.
>
> Best regards,
>
> Daniel
>
> --
> Daniel Zahn 
> Operations Engineer
>



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

Re: [Wikitech-l] Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)

2016-02-04 Thread Federico Leva (Nemo) 
No, this is not what I'm talking about. My problems span multiple weeks 
or months and I reiterate my need for a document outlining the expected 
behaviour.


Nemo

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

Re: [Wikitech-l] Using assignees for RFC shepherd

2016-02-04 Thread Rob Lanphier 
On Thu, Feb 4, 2016 at 7:08 AM, MZMcBride  wrote:
>
> I'm still not really sure what [the "shepherd" definition in the
> Governance RFC
> ] means.
> The biggest focus seems to be on speed and throughput for the RFC process
> itself, when the focus should actually be code quality, sustainability, and
> overall architecture.


Are code quality, sustainability, overall architecture, and
speed+throughput for the RFC process mutually exclusive?

I filed T125865: Assign RFCs to ArchCom shepherds
 which I think will be the most
organized place to discuss this further.

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

[Wikitech-l] Recent authentication session instability (was Re: Update from the Wikimedia Performance Team)

2016-02-04 Thread Bryan Davis 
On Thu, Feb 4, 2016 at 8:20 AM, MZMcBride  wrote:
> Federico Leva (Nemo) wrote:
>>Login pretty much never does what I expect nowadays, but I'm not sure my
>>expectations are correct so I can't identify actual bugs.
>
> There are various open tasks in Phabricator about user sessions currently,
> such as . Being unexpectedly
> logged out lately has been a bit annoying, though I don't know if it's
> related to the Performance team or some other team.

The origin of the unexpected logouts falls on the AuthManager project
and specifically the SessionManager component that rolled out in
1.27.0-wmf.11 [0]. We had various issues related to the session
handling changes including a bug that was overloading the storage
capacity of the Redis servers that store session data [1] and two
other issues which required rolling the wikis back to 1.27.0-wmf.10
[2][3].

Both rollbacks were accompanied by a run of the
"resetGlobalUserTokens.php" maintenance script which updates each
user's CentralAuth records in such a way that their authentication
session will be considered invalid the next time it is used on a wiki.
This was done from an abundance of caution point of view concerning
possible issues with sessions that had been issued by the
SessionManager software. The reset script is not fast [4], so session
invalidation has slowly worked its way across the CentralAuth user
table.

Part of the enhancements that are being applied in order to bring
SessionManager back to production with 1.27.0-wmf.13 is a new config
setting that can be used to give us a nearly instant switch to throw
to invalidate all active sessions. This setting is actually included
in 1.27.0-wmf.12, but the configuration on the Wikimedia cluster has
not been changed to make use of it yet. Invalidating all user sessions
is not something we plan to do for fun certainly, but there have been
in the past (and likely will be in the future) software and
configuration issues that necessitate the use of that heavy hammer
approach.


[0]: https://phabricator.wikimedia.org/T123451
[1]: https://phabricator.wikimedia.org/T125267
[2]: 
https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-SessionManagerRolloutFailure
[3]: https://tools.wmflabs.org/sal/log/AVKZtfQXW8txF7J0uNE2
[4]: https://phabricator.wikimedia.org/T124861

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

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

Re: [Wikitech-l] [WikimediaMobile] MobileFrontend+Wikibase security patch

2016-02-04 Thread Toby Negrin 
Thanks for the quick response everybody.

-Toby

On Thu, Feb 4, 2016 at 10:58 AM, Jon Robson  wrote:

> A security vulnerability has been discovered in MediaWiki setups which
> use both Wikibase and MobileFrontend.
>
> All projects in the Wikimedia cluster have been since patched but if
> you use these two extensions please be sure to apply the fix.
>
> Patch file and issue are documented on
> https://phabricator.wikimedia.org/T125684
>
> ___
> Mobile-l mailing list
> mobil...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MobileFrontend+Wikibase security patch

2016-02-04 Thread Jon Robson 
A security vulnerability has been discovered in MediaWiki setups which
use both Wikibase and MobileFrontend.

All projects in the Wikimedia cluster have been since patched but if
you use these two extensions please be sure to apply the fix.

Patch file and issue are documented on https://phabricator.wikimedia.org/T125684

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

Re: [Wikitech-l] Using assignees for RFC shepherd

2016-02-04 Thread Scott MacLeod 
Rob, MZMcBride and All,

And what's a shepherd in relation to the facilitator of any specific
committee (if this is relevant)?

Can someone please circulate a summary of RUST decision-making again? (Is
this relevant -
https://oqi.wisc.edu/resourcelibrary/uploads/resources/Project_Prioritization_Guide_v_1.pdf
?)

Thank you,
Scott



On Thu, Feb 4, 2016 at 7:08 AM, MZMcBride  wrote:

> Rob Lanphier wrote:
> >In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed
> >the way we handle RFC assignments in Phabricator.  Previously, the RFC
> >would frequently be assigned to person writing the RFC.  As we try out
> >the Rust model (per T123606 ),
> >and as we try to increase the speed by which RFCs move though the
> >process, we thought it would make sense to also assign RFCs to shepherds
> >on the ArchCom.
> >
> >We didn't discuss all of the implications of this in the meeting today,
> >but we think this might help us scale our RFC triage process.  What do
> >you all think?
>
> I guess 
> tries to answer the question "what's a shepherd?"
>
> ---
> * Nominate a shepherd from a (sub)team to guide an RFC through the process.
> ** Makes sure that stakeholders are informed.
> ** Guides the discussion.
> ** Once the discussion plateaus or stalls & in coordination with the RFC
>author(s), announces and widely publicizes a "Final Comment Period",
>which is one week.
> ---
>
> I'm still not really sure what any of this means. The biggest focus seems
> to be on speed and throughput for the RFC process itself, when the focus
> should actually be code quality, sustainability, and overall architecture.
>
> I found the recent RFC discussion about adding an expiration field to the
> watchlist table to be very disappointing. My impression was that people
> were more concerned with quickly pushing through a new feature (with
> unknown user interface implications) than with solving the deeper
> underlying problems we have with page lists.
>
> MZMcBride
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 

- Scott MacLeod - Founder & President
- 415 480 4577
- http://scottmacleod.com
- Please donate to tax-exempt 501 (c) (3)
- World University and School
- via PayPal, or credit card, here -
- http://worlduniversityandschool.org
- or send checks to
- PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516
- World University and School - like Wikipedia with best STEM-centric
OpenCourseWare - incorporated as a nonprofit university and school in
California, and is a U.S. 501 (c) (3) tax-exempt educational organization.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-l] InstantCommons - Images disappearing again

2016-02-04 Thread David Gerard 
On 4 February 2016 at 17:14, Brad Jorsch (Anomie)  wrote:

> No, it was a change in the underlying image handling code that broke API
> prop=imageinfo in 1.27.0-wmf.12. Tracked as
> https://phabricator.wikimedia.org/T125804, and now resolved.


yep, working for us now. Thanks!


- d.

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

Re: [Wikitech-l] [MediaWiki-l] InstantCommons - Images disappearing again

2016-02-04 Thread Brad Jorsch (Anomie) 
On Thu, Feb 4, 2016 at 11:39 AM, David Gerard  wrote:

> I came here to post about the same problem. It appears to have broken
> this morning. Did the API change again?
>

No, it was a change in the underlying image handling code that broke API
prop=imageinfo in 1.27.0-wmf.12. Tracked as
https://phabricator.wikimedia.org/T125804, and now resolved.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [MediaWiki-l] InstantCommons - Images disappearing again

2016-02-04 Thread David Gerard 
I came here to post about the same problem. It appears to have broken
this morning. Did the API change again?

On 4 February 2016 at 07:33, Dr. Michael Bonert
 wrote:
> In September 2014, I described an intermittent recurrent problem associated
> with the InstantCommons images.
>
> I hadn't seen the problem seen since April or May of 2015.
>
> It is now back -- after I upgraded to MediaWiki 1.26.2.
> Unlike in the past, it hasn't resolved with a server re-boot.
>
> I did have record traffic earlier in the week... but the problem --like in
> the past-- doesn't seem to be traffic related.
>
> I cannot find a relation to memory. I'm not running out of memory.
> The underlying LAMP (Debian Linux Apache MySQL PHP) stack hasn't changed.
>
> Product Versions
> Operating System: Debian (stable)
> MediaWiki   1.26.2 (f465524)
> PHP 5.6.13-0+deb8u1 (apache2handler)
> MySQL   5.5.44-0+deb8u1
>
> The details of what is installed is here:
> http://librepathology.org/wiki/index.php/Special:Version
>
> I do have git installed -- and am using it to upgrade.
>
> Like in the past-- the image that is local to the site, i.e.
> non-InstantCommons,
> (
> http://librepathology.org/wiki/index.php/File:Atypical_ductal_hyperplasia_-_very_high_mag.jpg
> )
> is still there-- and displays properly. At the same time, all the images
> from the InstantCommons are gone.
>
>
> A list of previous posts I did can be found here:
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043340.html
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043345.html
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043348.html
> https://lists.wikimedia.org/pipermail/mediawiki-l/2014-September/043349.html
>
> Help on this would be much appreciated...
>
> I have a testing site (pathologyprotocols.org) that is running the exact
> same set-up (behind a login).
> It is also failing suddenly in the same way; the InstantCommons images are
> gone.
>
> I wonder whether...
> - It is the InstantCommons server
> - There is "talk" between the InstantCommons server and a MediaWiki install
> (with the InstantCommons activated).
> I know this as images that are removed from the InstantCommons... are
> then removed on then
> MediaWiki install with InstantCommons activated.
>
> I think the communication is governed by 'descriptionCacheExpiry' and
> 'apiThumbCacheExpiry'
>   https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons
>   ? I wonder whether setting those to infinity would solve anything.
> - I suspect the thumb cache is purged... and then there is a bug preventing
> the image from being
> confirmed as being the same as on the InstantCommons... or there a
> processing bottle neck as the thumbnails have to be re-created.
>
> Thanks in Advance,
> Michael
>
>
> ___
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

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

Re: [Wikitech-l] Update from the Wikimedia Performance Team

2016-02-04 Thread MZMcBride 
Federico Leva (Nemo) wrote:
>Login pretty much never does what I expect nowadays, but I'm not sure my
>expectations are correct so I can't identify actual bugs.

There are various open tasks in Phabricator about user sessions currently,
such as . Being unexpectedly
logged out lately has been a bit annoying, though I don't know if it's
related to the Performance team or some other team.

MZMcBride



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

Re: [Wikitech-l] Using assignees for RFC shepherd

2016-02-04 Thread MZMcBride 
Rob Lanphier wrote:
>In the ArchCom meeting earlier today, Daniel, Timo, Tim and I discussed
>the way we handle RFC assignments in Phabricator.  Previously, the RFC
>would frequently be assigned to person writing the RFC.  As we try out
>the Rust model (per T123606 ),
>and as we try to increase the speed by which RFCs move though the
>process, we thought it would make sense to also assign RFCs to shepherds
>on the ArchCom.
>
>We didn't discuss all of the implications of this in the meeting today,
>but we think this might help us scale our RFC triage process.  What do
>you all think?

I guess 
tries to answer the question "what's a shepherd?"

---
* Nominate a shepherd from a (sub)team to guide an RFC through the process.
** Makes sure that stakeholders are informed.
** Guides the discussion.
** Once the discussion plateaus or stalls & in coordination with the RFC
   author(s), announces and widely publicizes a "Final Comment Period",
   which is one week.
---

I'm still not really sure what any of this means. The biggest focus seems
to be on speed and throughput for the RFC process itself, when the focus
should actually be code quality, sustainability, and overall architecture.

I found the recent RFC discussion about adding an expiration field to the
watchlist table to be very disappointing. My impression was that people
were more concerned with quickly pushing through a new feature (with
unknown user interface implications) than with solving the deeper
underlying problems we have with page lists.

MZMcBride



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

Re: [Wikitech-l] Data visualization for wiki

2016-02-04 Thread Ivo Kruusamägi 
OK, this Graph extension seems rather advanced and even though not exactly
what I had in mind, somewhat similar. So may I conclude it would be
pointless to go into that direction? Or are there some things, that may
need someone to work with them? Like (making random example): building very
simple Visual Editor add-on to enable fast creation of some more simple
graphs (like pie charts from the enormous variety of possibilities
)?

Could I get more information about need for image editors? *I'd like to
find something that might be suitable topic for bachelor thesis* and
vandering around alone inside the topic not yet known to me may not prove
to be fruitful.

As for this Commons topic. Yes, something similar to Wikidata Game, but
directed towards Commons and not Wikidata. More in line with Estonian sites
Ajapaik  (for adding geolocation information to
old images), sift.pics (for determining image types) and
postkaart.ajapaik.ee (for digitalizing text in old postcards).

Ivo

2016-02-04 5:00 GMT+02:00 MZMcBride :

> Ivo Kruusamägi wrote:
> >What I'd like to see is some development, that would make it possible for
> >user to create visualizations inside MediaWiki. Something so easy that a
> >child could do that. Like this . Workflow example: 1)
> >user selects sth like Create Data Visualization, 2) has some selections
> >about cart type, colors, etc, 3) place to write down text (title, axes,
> >description) and 4) a table to fill in with data (values + their text
> >labels). That could then be saved as one revision. After that every other
> >user could edit this graph with the same selections and data tables just
> >like users edit articles and edit history is saved and easy to compare.
> >
> >Image files like this
> > or that
> ><
> https://commons.wikimedia.org/wiki/File:Tree_map_exports_2010_Estonia.svg
> > are ridiculous and fixes like that
> > are not that flexible,
> >pretty and easy to use as what we need. So lets move forward.
>
> Are you familiar with the "Graph" MediaWiki extension? Here's a demo:
> . This MediaWiki
> extension is deployed to Wikimedia wikis, including all the Wikipedias.
>
> >There are plenty of GPL licensed solutions that could be integrated with
> >MediaWiki. But I can't be only one thinking about this.
>
> You're not. :-)
>
> >So what should I know about that topic so that this work could really be
> >useful? I.e. how to avoid reinventing the wheel (like building something
> >already in development) and how to be sure that it could be easily
> >incorporated later? Who would be the perfect people to talk about this
> >topic?
>
> This mailing list is great for general discussion. Or we have a
> Phabricator installation at  where we
> track bugs and feature requests. You can search around for Phabricator
> Maniphest task related to vectorized and rasterized image editors, such as
> . You're welcome to discuss on
> those tasks. Integrating a decent SVG editor and a decent PNG/JPG/GIF
> editor would be amazing!
>
> >P.S: I also have some development plans for a web platform that will help
> >to gamify organizing media files in Wikimedia Commons (coordinates,
> >categories, descriptions, quality assessment, etc). Sort like adding an
> >additional data layer and when everything works fine then migrating that
> >information into Commons. Any great ideas there as well? (not so great
> >ideas could be sent to list :P )
>
> Sure. Maybe poke around  if you
> haven't already? It sounds similar to what you want to do.
>
> 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