Re: [Wikitech-l] [Wikimedia-l] Subject for Wikimedia Hackathon(s) 2014-2015: CoSyne

[Rachel Farrand]

Yep, if you look at the Hackathon schedule you should see that it has been
scheduled for Thursday afternoon at 2pm. Hope you can make it!


On Wed, Aug 6, 2014 at 3:03 AM, Emeric Vallespi 
wrote:

> Hello,
>
> Does anyone have planned a meeting during Wikimania about next Hackathon's
> organization ?
> I believe it would be useful to know who of us still want to organize,
> after informations which was forwarded by former organizers, and how we
> could collaborate to choose the next (co-)organizer.
>
> I will be around the Wikimania Hackathon this afternoon and tomorrow, let
> me know if you're interested with this discussion.
> (Jean-Frederic & Sylvain are also available)
>
> --
> Emeric Vallespi
> Vice-treasurer
> Wikimedia France
>
> emeric.valle...@wikimedia.fr
> Twitter: @evallespi
>
>
>
> On 16 juil. 2014, at 21:00, Emeric Vallespi 
> wrote:
>
> > Hi,
> >
> > WMFr is still thinking about organizing Wikimedia Hackathon in 2015. We
> are currently identifying the technical, financial and especially human
> resources needed to make it a success.
> >
> > Frans, could you provide me/us your documentation or the link (Meta ?) ?
> It would be very useful.
> >
> > Wikimedia France really wants to organize an international event in 2015.
> >
> > Anyway, we believe that if another chapter wants to organize Hackathon
> it could be a waste of time for one of us to position our proposals against
> until the result.
> >
> > So if a sister entity positions herself clearly and seriously to
> organize Wikimedia Hackathon we can discuss it.
> >
> > Best regards,
> > --
> > Emeric Vallespi
> > Vice-Treasurer
> > Wikimedia France
> >
> > emeric.valle...@wikimedia.fr
> > Twitter: @evallespi | Mob. +33 (0)6 61151312
> >
> > On 14 juil. 2014, at 20:38, Frans Grijzenhout 
> wrote:
> >
> >> Hi Balázs, WMNL hosted the international hackaton in 2013.
> Documentation is
> >> archived and thus still available and we are more than willing to help
> you
> >> in preparing the international hackaton in 2015.
> >> Regards, Frans
> >>
> >>
> >>
> >> *Frans Grijzenhout*, voorzitter / chair
> >> fr...@wikimedia.nl
> >> +31 6 5333 9499
> >> http://www.wikimedia.nl/
> >>
> >> *Vereniging Wikimedia Nederland*
> >> *Postadres*: *Bezoekadres:*
> >> Postbus 167   Mariaplaats 3
> >> 3500 AD  Utrecht3511 LH Utrecht
> >>
> >> ABNAMRO NL33 ABNA 0497164833 - Kamer van Koophandel 17189036
> >>
> >>
> >>
> >>
> >> 2014-07-14 16:56 GMT+02:00 Balázs Viczián  >:
> >>
> >>> Hi,
> >>>
> >>> WMHU would be interested in *hosting *a Hackathon in Hungary
> (anywhere) but
> >>> we would need a couple of international volunteers to help filling the
> core
> >>> of event (finding topics and speakers or building up the content in
> >>> general). In exchange, the rest (from side events to the smallest
> details)
> >>> can be left with us :)
> >>>
> >>> Balazs
> >>>
> >>>
> >>> 2014-07-14 14:53 GMT+02:00 Frans Grijzenhout :
> >>>
>  Hi Romaine, this is to remind you that the CoSyne project was a
> research
>  project, sponsored by the EU and conducted by different partners. The
>  research has been concluded and the results have been reported early
>  2013..The technical infrastructure has sinds then been dismantled, so
> it
>  will not be that easy to restart CoSyne. Regards, Frans
> 
> 
>  *Frans Grijzenhout*, voorzitter / chair
>  fr...@wikimedia.nl
>  +31 6 5333 9499
>  http://www.wikimedia.nl/
> 
>  *Vereniging Wikimedia Nederland*
>  *Postadres*: *Bezoekadres:*
>  Postbus 167   Mariaplaats 3
>  3500 AD  Utrecht3511 LH Utrecht
> 
>  ABNAMRO NL33 ABNA 0497164833 - Kamer van Koophandel 17189036
> 
> 
> 
> 
>  2014-07-09 23:44 GMT+02:00 Romaine Wiki :
> 
> > I doubt if these tools are similar. But I do think they can benefit
> >>> from
> > each other.
> >
> > Romaine
> >
> >
> > 2014-07-09 16:03 GMT+02:00 Antoine Musso :
> >
> >> Le 09/07/2014 14:33, Romaine Wiki a écrit :
> >>> As a subject of one/more hackathons I would like to recommend
> >>> CoSyne
> > [1].
> >>> CoSyne is translation and multilingual synchronisation tool. The
> > project
> >>> was set up by Wikimedia Netherlands together with several
>  universities
> >> and
> >>> other partners, including the EU. The tool makes it possible to
> > translate
> >>> much more easier from one Wikipedia (etc) to another with much
> >>> better
> >>> quality translations than existing translating tools. It does not
> > matter
> >> if
> >>> an article is already written, it is possible with this tool to
>  expand
> >>> existing articles and to update articles with a new section when on
>  one
> >>> Wikipedia this was added. It makes it possible to exchange
>  information
> > in
> >>> more languages and helps 

Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords

[Andre Klapper]

On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote:
> After reading this [1] I am wondering if Wikimedia should start taking
> steps to reduce reliance on usernames and passwords.

What "steps" do you refer to, or is this intentionally vague?
Disallowing usernames and logins?
Two-step authentication/verification?
Something else?

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

Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords

[svetlana]

On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote:
> On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote:
> > After reading this [1] I am wondering if Wikimedia should start taking
> > steps to reduce reliance on usernames and passwords.
> 
> What "steps" do you refer to, or is this intentionally vague?
> Disallowing usernames and logins?
> Two-step authentication/verification?
> Something else?
> 
> andre

from what i could read and parse:
use less of external things like skype and google accounts
so that there is only 1 username for everything

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

Re: [Wikitech-l] [Wikimedia-l] "let's elect people to serve on the wikimedia engineering "community" team!" (brainstorming)

[Andre Klapper]

Hi,

On Wed, 2014-08-06 at 12:01 +1000, svetlana wrote:
> On Wed, 6 Aug 2014, at 06:58, Quim Gil wrote:
> > > - encourage feedback by absolutely /anyone/ about the next features they'd
> > > like,
> > >
> > 
> > Betas and Bugzilla today. Phabricator should make it easier to provide
> > feedback in a wider range of topics, not only "bugs".
> 
> 99% of users of Wikimedia projects don't /know/ about these tools.
> That's the problem, and your response is not reflecting it.

I've seen people on Village Pumps etc. complaining about certain
software changes introduced. After I provided links to five [sic!]
previous announcements, their reply was basically "I didn't see them!
Wrong place, you should have put them $here and $there instead".

What is your proposal to _successfully_ make more people aware of such
tools, if that's the problem?

There are also enough (note to myself: [citation needed]) Wikipedia
readers who don't know that you can edit an article yourself. Everybody
has the personal freedom to not be interested in $stuff. Personally I'm
fine with driving a car while having no clue why and how a car works.

Cheers,
andre

PS: Obviously this is all my personal opinion.
-- 
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] Fellow ticket discount for the SEMANTiCS conference Leipzig

[Sebastian Hellmann]

Dear colleagues and fellow enthusiast of the semantic web,

we are pleased to announce that the SEMANTiCS conference on Sep 4-5, 
2014 in Leipzig, will become a major industry conference on semantic web 
and linked data applications in Europe.


With partners such as PoolParty, STI2, Eccenca, IntraFind, LOD2 Project, 
MarkLogic, Ontos and Wolters Kluwer as well as more than 50% of our 
currently registered attendees being from the industry sector, SEMANTiCS 
has lifted the primarily academic topic of semantic web to the next 
level of business application.
From our keynote speakers Sofia Angeletou (BBC), Thomas Kelly 
(Cognizant), Phil Archer (W3C) and Orri Erling (OpenLink) to 40+ 
speakers on 5 parallel tracks and special events like the vocabulary 
carnival, H2020 networking event and conference dinner, SEMANTiCS offers 
a wide variety of industry insights and networking chances. You can see 
our programm here: http://www.semantics.cc/programme/


Hence, this year's SEMANTiCS conference is your chance to get in touch 
with potential business clients and industry partners to push your own 
projects and developments in the semantic web sector.


You can still submit to the Vocabulary Carnival: 
http://www.semantics.cc/vocarnival/ as well as the H2020 networking 
session. Furthermore, we will collect and print your H2020 organisation 
profile description in the program guide, so you can be approached at 
the conference for potential projects.


Being a fellow enthusiast in this future-defining field, we'd like to 
offer you a special discount of 20% on your ticket to the conference. 
Simply go to www.semantics.cc/registration/discount and claim your 
discount with the following promo code: “semantic-web-fellow”

This offer is valid until 15th of August.

For further information on the programme and our keynote speaker, please 
visit www.semantics.cc

Feel free to forward this email to any interested fellow.

See you in Leipzig,

Sebastian Hellmann
on behalf of the all conference committee members


--
Sebastian Hellmann
AKSW/NLP2RDF research group
Insitute for Applied Informatics (InfAI) and DBpedia Association
Events:
* *Sept. 1-5, 2014* Conference Week in Leipzig, including
** *Sept 2nd*, MLODE 2014 
** *Sept 3rd*, 2nd DBpedia Community Meeting 


** *Sept 4th-5th*, SEMANTiCS (formerly i-SEMANTICS) 
Venha para a Alemanha como PhD: http://bis.informatik.uni-leipzig.de/csf
Projects: http://dbpedia.org, http://nlp2rdf.org, 
http://linguistics.okfn.org, https://www.w3.org/community/ld4lt 


Homepage: http://aksw.org/SebastianHellmann
Research Group: http://aksw.org
Thesis:
http://tinyurl.com/sh-thesis-summary
http://tinyurl.com/sh-thesis
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bikeshedding a good name for "the api.php API"

[Brad Jorsch (Anomie)]

When api.php was basically the only API in MediaWiki, calling it "the API"
worked well. But now we've got a Parsoid API, Gabriel's work on a REST
content API, Gabriel's work on an internal storage API, and more on the
way. So just saying "the API" is getting confusing.

So let's bikeshed a reasonably short name for it that isn't something awful
like "the api.php API". I'm horrible at naming.


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

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[Bartosz Dziewoński]

How about just "the MediaWiki API"? That's the only proper external API  
core MediaWiki has, as far as I'm aware.


If anybody is planning to tack on something new, they should be the ones  
thinking about what to name that thing ;)


--
Matma Rex

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

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[Tim Starling]

On 06/08/14 14:32, Brad Jorsch (Anomie) wrote:
> When api.php was basically the only API in MediaWiki, calling it "the
> API" worked well. But now we've got a Parsoid API, Gabriel's work on a
> REST content API, Gabriel's work on an internal storage API, and more
> on the way. So just saying "the API" is getting confusing.
> 
> So let's bikeshed a reasonably short name for it that isn't something
> awful like "the api.php API". I'm horrible at naming.

How about "the action API"? The fact that it is organised in a
hierarchy of actions distinguishes it from REST, which is organised as
a hierarchy of objects. The term "action" also distinguishes it from RPC.

-- Tim Starling


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

Re: [Wikitech-l] Policy on browser support

[Erik Moeller]

On Mon, Aug 4, 2014 at 5:36 PM, Derric Atzrott
 wrote:
>>> I would like to make a case for moving more browsers into the grade C
>>> category.

>> Yes please. As a project that must live the test of time I think we should
>> be focusing our energy on building for future browsers. Our main goal is to
>> provide people knowledge which can be done without JavaScript. Older
>> browsers hold us back in my opinion.

> I would also support this, for similar, but slightly different reasons.  I
> agree that we need to make sure that the project stands the test of time, and
> for that reason I think we need to make Grade C a first class citizen.

OK. I've submitted a change to do this for MSIE6 for now. [1] It got
merged quickly, but please update if I missed anything (I'll add
release notes now). Provided there are no concerns with this, I'll
send a note to wikitech-ambassadors@ soon, drafted here:

https://www.mediawiki.org/wiki/User:Eloquence/MSIE6

This case seems very obvious given the unpatched vulnerabilities and
lack of official support; let's discuss additional browsers/categories
of browsers on a case by case basis.

Timo, I also noticed that the definition of "grade C" in startup.js
was inconsistent with what's on the mediawiki.org page so I updated it
accordingly.

Thanks,
Erik

[1] https://gerrit.wikimedia.org/r/#/c/152072/
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[Tyler Romeo]

Definitely agree with this. It’s the only API that is part of core, so 
“MediaWiki API” makes sense.
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: Bartosz Dziewoński 
Reply: Wikimedia developers >
Date: August 6, 2014 at 9:52:34
To: Wikimedia developers >
Subject:  Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"  

How about just "the MediaWiki API"? That's the only proper external API 
core MediaWiki has, as far as I'm aware.

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

Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords

[Tyler Romeo]

In terms of external authentication, we need Extension:OpenID to catch up to 
the OpenID standard in order to do that.

In terms of two-factor, I have like eight patches for Extension:OATHAuth 
attempting to make it production-worthy.

https://gerrit.wikimedia.org/r/132783
-- 
Tyler Romeo
0x405D34A7C86B42DF

From: svetlana 
Reply: Wikimedia developers >
Date: August 6, 2014 at 7:57:12
To: wikitech-l@lists.wikimedia.org >
Subject:  Re: [Wikitech-l] News about stolen Internet credentials; reducing 
Wikimedia reliance on usernames and passwords  

On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote:
> On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote:
> > After reading this [1] I am wondering if Wikimedia should start taking
> > steps to reduce reliance on usernames and passwords.
>  
> What "steps" do you refer to, or is this intentionally vague?
> Disallowing usernames and logins?
> Two-step authentication/verification?
> Something else?
>  
> andre

from what i could read and parse:
use less of external things like skype and google accounts
so that there is only 1 username for everything

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

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

Re: [Wikitech-l] Policy on browser support

[Jon Robson]

\o/ what terrific news to wake up to!
Derric I think we are in agreement on the way forward! You are not saying
anything I disagree with :)
On 6 Aug 2014 07:33, "Erik Moeller"  wrote:

> On Mon, Aug 4, 2014 at 5:36 PM, Derric Atzrott
>  wrote:
> >>> I would like to make a case for moving more browsers into the grade C
> >>> category.
>
> >> Yes please. As a project that must live the test of time I think we
> should
> >> be focusing our energy on building for future browsers. Our main goal
> is to
> >> provide people knowledge which can be done without JavaScript. Older
> >> browsers hold us back in my opinion.
>
> > I would also support this, for similar, but slightly different reasons.
>  I
> > agree that we need to make sure that the project stands the test of
> time, and
> > for that reason I think we need to make Grade C a first class citizen.
>
> OK. I've submitted a change to do this for MSIE6 for now. [1] It got
> merged quickly, but please update if I missed anything (I'll add
> release notes now). Provided there are no concerns with this, I'll
> send a note to wikitech-ambassadors@ soon, drafted here:
>
> https://www.mediawiki.org/wiki/User:Eloquence/MSIE6
>
> This case seems very obvious given the unpatched vulnerabilities and
> lack of official support; let's discuss additional browsers/categories
> of browsers on a case by case basis.
>
> Timo, I also noticed that the definition of "grade C" in startup.js
> was inconsistent with what's on the mediawiki.org page so I updated it
> accordingly.
>
> Thanks,
> Erik
>
> [1] https://gerrit.wikimedia.org/r/#/c/152072/
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[Petr Bena]

The Chosen One's API. In short: Tchopi :P

Do we really need to call it somehow? When you will say "api" 99% of
people who know mediawiki a bit will go for api.php. Special naming
should be used just for the other weird api's that nobody is ever
going to use anyway.

Btw, why do we need to have them in secondary php files / entry points?

On Wed, Aug 6, 2014 at 5:23 PM, Tyler Romeo  wrote:
> Definitely agree with this. It’s the only API that is part of core, so 
> “MediaWiki API” makes sense.
> --
> Tyler Romeo
> 0x405D34A7C86B42DF
>
> From: Bartosz Dziewoński 
> Reply: Wikimedia developers >
> Date: August 6, 2014 at 9:52:34
> To: Wikimedia developers >
> Subject:  Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"
>
> How about just "the MediaWiki API"? That's the only proper external API
> core MediaWiki has, as far as I'm aware.
>
> ___
> 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] Bikeshedding a good name for "the api.php API"

[Yuri Astrakhan]

API vs REST/CONTENT API? If we end up exposing rest API via the same entry
point, no reason of even calling it anything else. If we have a separate
entry point (why?), we could call it REST API or CONTENT API, specifying
that it is mostly for the rendered content as opposed to internal database
data.
On Aug 6, 2014 1:04 PM, "Petr Bena"  wrote:

> The Chosen One's API. In short: Tchopi :P
>
> Do we really need to call it somehow? When you will say "api" 99% of
> people who know mediawiki a bit will go for api.php. Special naming
> should be used just for the other weird api's that nobody is ever
> going to use anyway.
>
> Btw, why do we need to have them in secondary php files / entry points?
>
> On Wed, Aug 6, 2014 at 5:23 PM, Tyler Romeo  wrote:
> > Definitely agree with this. It’s the only API that is part of core, so
> “MediaWiki API” makes sense.
> > --
> > Tyler Romeo
> > 0x405D34A7C86B42DF
> >
> > From: Bartosz Dziewoński 
> > Reply: Wikimedia developers >
> > Date: August 6, 2014 at 9:52:34
> > To: Wikimedia developers >
> > Subject:  Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"
> >
> > How about just "the MediaWiki API"? That's the only proper external API
> > core MediaWiki has, as far as I'm aware.
> >
> > ___
> > 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] Disabling JS support in additional browsers

[Erik Moeller]

Following up on disabling JavaScript support for IE6 [1], here is some
additional research on other browsers. I'd appreciate if people with
experience testing/developing for/with these browsers would jump in
with additional observations. I think we should wait with adding other
browsers to the blacklist until the IE6 change has been rolled out,
which may expose unanticipated consequences (it already exposed that
Common.js causes errors in blacklisted browsers, which should be fixed
once [2] is reviewed and merged).

As a reminder, the current blacklist is in .

As a quick test, I tested basic browsing/editing operation on English
Wikipedia with various browsers. Negative results don't necessarily
indicate that we should disable JS support for these browsers, but
they do indicate the quality of testing that currently occurs for
those browsers. Based on a combination of test results, unpatched
vulnerabilities and usage share, an initial recommendation for each
browser follows.

Note that due to the heavy customization through gadgets/site scripts,
there are often site-specific issues which may not be uncovered
through naive testing.

== Microsoft Internet Explorer 7.x ==

Last release in series: April 2009

- Browsing: Most pages work fine (some styling issues), but pages with
audio files cause JavaScript errors (problem in TMH).
- Editing: Throws JS error immediately (problem in RefToolbar)

Both of these errors don't occur in IE8.

Security vulnerabilities:

Secunia reports 15 out of 87 vulnerabilities as unpatched, with the
most serious one being rated as "moderately critical" (which is the
same as IE6, while the most serious IE8 vulnerability is rated "less
critical").

Usage: <1%

Recommendation: Add to blacklist

== Opera 8.x ==

Last release in series: September 2005

Browsing/editing: Works fine, but all JS fails due to a script
execution error (which at least doesn't cause a pop-up).

Security: Secunia reports 0 unpatched vulnerabilities (out of 26).

Usage: <0.25%

Recommendation: Add to blacklist

== Opera 10.x-12.x ==

Last release in series: April 2014

Browsing/editing: Works fine, including advanced features like
MediaViewer (except for 10.x)

Security: No unpatched vulnerabilities in 12.x series according to
Secunia, 2 unpatched vulnerabilities in 11.x ("less critical") and 1
unpatched vulnerability in 10.x ("moderately critical")

Usage: <1%

Recommendation: Maintain basic JS support, but monitor situation re:
10.x and add that series to blacklist if maintenance cost too high

== Firefox 3.6.* ==

Last release in series: March 2012

Browsing/editing: Works fine (MediaViewer disables itself)

Security: 0 unpatched vulnerabilities according to Secunia

Recommendation: Maintain basic JS support

== Firefox 3.5.* ==

Last release in series: April 2011

Browsing/editing: Works fine (MediaViewer disables itself)

Security: 0 unpatched vulnerabilities according to Secunia

Recommendation: Maintain basic JS support

== Safari 4.x ==

Last release in series: November 2010

Browsing/editing: Works fine

Security: 1 unpatched "highly critical" vulnerability according to
Secunia ("exposure of sensitive information")

Recommendation: Maintain basic JS support, but monitor

== Safari 3.x ==

Last release in series: May 2009

Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all

Security: 2 unpatched vulnerabilities, "highly critical"

Usage share: Usage reports for Safari in [3] are broken, all Safari
versions are reported as "0.0". However, [4] suggests that Safari 3
usage is negligible/non-existent.

Recommendation: Styling issue may be worth investigating in case it
affects other browsers and/or is JS-caused. Otherwise probably can be
safely ignored.

[1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html
[2] https://gerrit.wikimedia.org/r/#/c/152122/
[3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
[4] 
http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-version-which-is-used-so-far-by-users
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[James Forrester]

On 6 August 2014 14:53, Tim Starling  wrote:

> On 06/08/14 14:32, Brad Jorsch (Anomie) wrote:
> > When api.php was basically the only API in MediaWiki, calling it "the
> > API" worked well. But now we've got a Parsoid API, Gabriel's work on a
> > REST content API, Gabriel's work on an internal storage API, and more
> > on the way. So just saying "the API" is getting confusing.
> >
> > So let's bikeshed a reasonably short name for it that isn't something
> > awful like "the api.php API". I'm horrible at naming.
>
> How about "the action API"? The fact that it is organised in a
> hierarchy of actions distinguishes it from REST, which is organised as
> a hierarchy of objects. The term "action" also distinguishes it from RPC.
>

[Relaying conversations at Wikimania.]

Yes, this is sensible. Let's certainly not call it "the MediaWiki API"
given how many are planned.

J.
-- 
James D. Forrester
jdforres...@gmail.com
[[Wikipedia:User:Jdforrester|James F.]] (speaking purely in a personal
capacity)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

[Bartosz Dziewoński]

On Tue, 29 Jul 2014 13:00:37 +0200, Krinkle  wrote:

(…) I personally do not see any use in having mediawiki/skins/* in  
Gerrit as separate structure for repositories that are extensions in  
every way. An extension can provide hooks, messages, config variables,  
special pages, skins, api modules, resource modules and more. A skin  
repo would typically provide at least three of these (messages, skin,  
resource modules) and possibly hooks and config variables as well.  
What's the point in having a separate scheme for repos that provide some  
arbitrary subset of these features?


In the Glorious Future, there might come a day when skins will no longer  
need to provide any PHP code; they'd just define some configuration, HTML  
templates and CSS+JS. One can dream, eh?


mediawiki/skins/* is already the de-facto accepted hierarchy for skins in  
Gerrit, with about 20 repositories there (and most of them indeed  
functional) [1]; I am not aware of any skins in mediawiki/extensions/  
other than Nostalgia (which has been migrated to skins/ too).


The naming has been discussed on this list in the past, and the result is  
summarized at [2].


[1]  
https://gerrit.wikimedia.org/r/#/admin/projects/?filter=mediawiki%252Fskins%252F

[2] http://www.gossamer-threads.com/lists/wiki/wikitech/465428#465428



But more important than the naming scheme in Gerrit (which I could care  
less about) is the local development workflow which affects developer  
productivity and understandability of our eco system. Let's aim to keep  
be as simple as possible without compromising on important benefits.


I don't think using skins/ in this way is as problematic as you're making  
it seem:




We have an mediawiki/extensions.git meta repository. To avoid conflicts  
with MediaWiki core's extensions directory (…)
I always advocate people set up an extensions directory on their disk  
elsewhere (e.g. next to mediawiki-core, not inside), either as the meta  
repo clone or as your own container directory with git clones of  
individual extensions inside of it. Then simply configure  
$wgExtensionAssetsPath to point at localhost/git/extensions or whatever  
and require_once in LocalSettings from ../extensions instead.


This is possible with skins in exactly the same way, but instead of  
$wgExtensionAssetsPath you configure $wgStylePath.


The 'common' directory might be a bit problematic here. I think we should  
just get rid of it once and for all and put the assets in resources/ where  
they belong.




This could be set up for skins as well, but it's tricky. Aside from  
having two systems then, it's still tricky. At least for a while to come  
(working with current wmf branches, and release branches) we can't  
guarantee skins/ to be empty. (…)


It is possible to get it right but it comes at the cost of several  
months / up to 2-3 years of inconvenience locally for everyone. (…)


There will be no 'two systems'. We're removing skins from core and moving  
them to separate repositories. That will be the only way from now on. With  
the exception of the aforementioned 'common' that we need to kill, the  
skins/ directory will be empty.


The transition period will of course require some additional care, but I  
don't see how it could take years. The WMF will need to care about it for  
a total of about two weeks while the deployments roll by (less if we  
backport the changes, which might be a lot easier with our submodules  
setup). The people who backport changes would have to deal with it for  
longer, were it not for the fact that the new way is backwards-compatible  
with older MediaWikis (set up the skins/ directory the way you described,  
and it should work back to MW 1.19 at least) and the fact that we rarely  
need to backport changes to skins anyway.




We haven't committed to this new structure yet, and instead of taking  
this opportunity to create a mess for years to come, I'd rather take  
this opportunity to get rid of the mess that is mediawiki/skins  
altogether and just fold it all back into extensions.


To get the ball rolling: What's the downside of going that route? We  
have quite a lot to gain in terms of simplicity and compatibility.


Breaking things can be good, but I haven't seen any short or long term  
benefits so far that would justify it.


I'm really not convinced how it creates more of a mess than what you  
propose. This structure is consistent with user expectations (of skin  
developers and sysadmins), already established practices in the MediaWiki  
community and other projects like CMS-es and forums (again, see [2] and  
earlier discussion). I think that is a big win.


[2] http://www.gossamer-threads.com/lists/wiki/wikitech/465428#465428


--
Matma Rex

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

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[MZMcBride]

Brad Jorsch (Anomie) wrote:
>When api.php was basically the only API in MediaWiki, calling it "the API"
>worked well. But now we've got a Parsoid API, Gabriel's work on a REST
>content API, Gabriel's work on an internal storage API, and more on the
>way. So just saying "the API" is getting confusing.
>
>So let's bikeshed a reasonably short name for it that isn't something
>awful like "the api.php API". I'm horrible at naming.

For what it's worth, 
uses "Web API", as does .

Tim Starling wrote:
>How about "the action API"? The fact that it is organised in a
>hierarchy of actions distinguishes it from REST, which is organised as
>a hierarchy of objects. The term "action" also distinguishes it from RPC.

A quick count at  says that there are
currently 52 &list=foo entries and 83 &action=foo entries. While these
numbers are inflated due to installed extensions, I'm hesitant to present
the MediaWiki Web API as an action API. Though you could perhaps argue
that listing is just another action.

I tend to agree with the view of others in this thread that simply saying
"the [{MediaWiki (core), Web}] API" is usually sufficiently clear.

MZMcBride



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

Re: [Wikitech-l] Bikeshedding a good name for "the api.php API"

[Daniel Friesen]

On 2014-08-06, 6:37 PM, MZMcBride wrote:
> Tim Starling wrote:
>> How about "the action API"? The fact that it is organised in a
>> hierarchy of actions distinguishes it from REST, which is organised as
>> a hierarchy of objects. The term "action" also distinguishes it from RPC.
> A quick count at  says that there are
> currently 52 &list=foo entries and 83 &action=foo entries. While these
> numbers are inflated due to installed extensions, I'm hesitant to present
> the MediaWiki Web API as an action API. Though you could perhaps argue
> that listing is just another action.
;) ?action=query&list=*
Technically speaking, listing *is* an action.

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] News about stolen Internet credentials; reducing Wikimedia reliance on usernames and passwords

[Brian Wolff]

On Aug 6, 2014 8:57 AM, "svetlana"  wrote:
>
> On Wed, 6 Aug 2014, at 21:49, Andre Klapper wrote:
> > On Tue, 2014-08-05 at 22:05 -0700, Pine W wrote:
> > > After reading this [1] I am wondering if Wikimedia should start taking
> > > steps to reduce reliance on usernames and passwords.
> >
> > What "steps" do you refer to, or is this intentionally vague?
> > Disallowing usernames and logins?
> > Two-step authentication/verification?
> > Something else?
> >
> > andre
>
> from what i could read and parse:
> use less of external things like skype and google accounts
> so that there is only 1 username for everything
>
>

The solution to stolen credentials is to combine all credentials so that a
single credential can control everything?

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