Re: [Wikimedia-l] Not all pixels are created equals: introducing brand new Wikimedia France's metrics

2015-04-02 Thread Seb35

Le Thu, 02 Apr 2015 01:26:07 +0200, Pine W a écrit:

Dear Pierre-Selim,

I look forward to discussing this new metric at the Wikimedia Conference.

I might even take photographs of the deliberations and upload them to
Commons in order to improve my personal pixel metric.

Have you figured out a way to translate pixels into multiple languages?

Just walk accross streets or countries and show the pixels to different  
native speakers: you have translated the pixels. Be aware not to lost some  
pixels during the translation.

~ Seb35

I hope you will document the new pixel metric, and the methods for
measuring it, in the Learning Patterns Library.

On Apr 1, 2015 12:59 PM, Pierre-Selim wrote:

Dear movement fellows,

Impact is crucial for our movement, and although metrics will always be
imperfect, we must strive to reinvent ourselves and always come up with  
innovative ways of  measuring what we bring to the Wikimedia projects,  

free knowledge, and to human society.

Measuring impact regarding collections of media holds its own challenges
and although we have been focusing on this for a while now, much work  

lies ahead.

We were inspired by the “bytes added” metric, one of the pinnacles of
written content expansion measurement, which goes beyond mere edit  

The same reasoning holds true for media:a puny upload count cannot come
close to the real awesomeness.

This is why, as we appreciate that size matters, Wikimedia France  

commitee is proud to introduce its brand new set of metrics: the pixel
count and the quality pixel count − since quality is of firstmost

You may query the Pixel count metric for your FDC reports as part of our
wm-metrics webapp [1]

Furthermore, an implementation of these new metrics will also ship with  

new new (teasing!) product [2]

As of April 1st 2015 Wikimedia France has supported the upload on  

Commons of:

   - 1 229 694 933 639 pixels [3]

   - among those pixels, 22 407 932 851 are quality pixels (18,223512%)  

This is only the beginning: next step is the measurement of cute pixels,
encyclopedic pixels and amazing pixels.

Confident in the relevance of these new indicators, we would be  

and honored to see the Pixel count integrated in the Global Metrics.

As always we welcome feedback, hugs and pull requests.

For the quality committee of Wikimedia France
Caroline, Jean-Fred, Pierre-Selim and Petit Tigre


Wikimedia-l mailing list, guidelines at:

Wikimedia-l mailing list, guidelines at:

Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] Fwd: Accounting software for thematic orgs

2014-08-20 Thread Seb35

Forwarding to the to-be-revived treasurers mailing list. ~ Seb35

--- Message réexpédié---
De: Pine W
A: Wikimedia Mailing List
Sujet: [Wikimedia-l] Accounting software for thematic orgs
Date: Wed, 20 Aug 2014 06:54:41 +0200

Hi all,

There are online small business accounting software packages. Do any
thematic orgs have experience with them? Any recommendations? I am thinking
about proposing Quickbooks Online for the Cascadia user group, but as this
Forbes article says, there are competitors:


Wikimedia-l mailing list, guidelines at:

Wikimedia-l mailing list, guidelines at:

[Wikimedia-l] Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)

2014-08-14 Thread Seb35


I propose some constructive ideas to improve the deployment of new features:

* granular deployments: create user profiles where the users can choose
  if they want an overall appearance:
  * never ever change my interface: some experienced authors do not like
 when one change every month their workflow if they are happy with it,
  * experienced editor: some experienced editors want new features or see
 what the newbies see,
  * newbie: the newbies/editors-to-be could expect an editing environment
 possibly different than the reader environment,
  * reader: the readers have their own expectations for easy reading,
  * etc.
  The features could be deployed only for some groups, giving more flexibility
  to deploy reader features for readers, etc. Obviously there are
  preferences, but the newbies have no experience about it, and the
  experienced editors have to be discover new preferences on a case-by-case
  basis, making it difficult to everybody to track the preferences.

* implement global preferences (and the possibility to change locally or
  globally, like in Mailman) [bug 14950][]

* when a new feature is introduced, propose to users (not in never ever
  change my interface) if they want the new feature, locally or globally,
  possibly using the Notifications bar, or with some message in the prefs
  page and highlighting it on the prefs page

* work on a better organisation of the preferences, e.g. add an exhaustive
  preference panel similarly to Firefox’s about:config to permit the
  developers to add more preferences and hence offering more customisation
  possibilities for advanced users, by nullifying the argument the
  preferences page is too complicated for new users

* as it was proposed, add a review process for the gadgets+JS pages to avoid
  performance, security, usability issues, possibly with the help of the tech
  staff, and possibly with the general MediaWiki code review
  (gerrit/Phabricator) with some gateway between it and the MediaWiki
  websites [bug 69445][] [bug 20153][]

In other words, improve the deployment targets and give easy choices to users
to opt-in/opt-out/etc the new features depending on their willingness to
change their environment.

And although I’m neither a loudly people neither the community, I vote to
remove the superprotect right and any other enforcement of this type in the
future. It’s like an edit war where one party has the power to silence the
other, and like all edit wars there are at least two wrong versions.

[bug 69445]:
[bug 14950]:
[bug 20153]:

~ Seb35

Wikimedia-l mailing list, guidelines at:

Re: [Wikimedia-l] Chapters and GLAM tooling

2014-06-28 Thread Seb35
Similarly to what you are describing, Micru, BeWelcome has a process to  
identify issues and resolve them in a community discussion. It’s a sort of  
communal product specification/design.

The process looks like: [1]
1/ firstly, community members can submit issues or product ideas,
2/ secondly, there is a discussion with proposed resolutions,
3/ thirdly, a vote between the various proposed resolutions,
4/ lastly, the development phase itself.

Although we have some sort of such process (Idea lab, RFC, mailing lists,  
bug tracker,, it’s not as easy to find where are the ideas  
of products, where are the development of these ideas, and where and how  
you can give your voice to influence the path of the development.

Personally I like a lot the BeWelcome process (and it’s a non-technical  
member who presented me that), and I find you could reuse it in Wikimedia,  
probably in a customized form, and with short and intuitive product ideas  
and resolutions (avoid too long pages at first sight).


~ Seb35

Le mardi 26 juin 2014 15:12:03 (CEST), David Cuenca a écrit :
Erik (and others), is there any coordination page where groups could  
take, or discuss requests for development or requests for  

I saw often that sometimes the hard-to-achieve consensus is found, but
there is no way to evaluate the idea further. What now happens is:
- several development proposals materialize through different channels
(community, user groups, idea lab, RFCs, etc)
- there is a general consensus about project A
- limbo or an IEG, but as Ilario says, that doesn't guarantee its
future viability or integration with current or planned workflows, or
availability of resources for maintenance

It would be more rational to have a further step in the pipeline where
development ideas could be commented, shot down, or approved for  

commitment by the ones who actually can understand how they fit in the
broader product management/life-cycle context (engineering? PMs?
There are often community ideas that on first sight look great, but when
you think about the potential problems, implications, costs, or stepping  
the toes of other developments, that it is more rational not to start  
or delay them until certain conditions are met. But no voice is heard,  
that causes frustration and a sense of disconnection in the community,  

just a single statement this shouldn't be done because X, would make
everyone more aware of the limits.
And the opposite too, when some idea gather community support and is
green-lighted for further commitment, that would make chapters or other
organizations more confident about what is wanted and how.


On Thu, Jun 26, 2014 at 5:54 AM, Erik Moeller wrote:

Hi folks,

At the Zurich Hackathon, I met with a couple of folks from WM-CH who
were interested in talking about ways that chapters can get involved
in engineering/product development, similar to WM-DE's work on

My recommendation to them was to consider working on GLAM-related
tooling. This includes helping improve some of the reporting tools
currently running in Labs (primarily developed by the illustrious and
wonderful Magnus Manske in his spare time), but also meeting other
requirements identified by the GLAM community [1] and potentially
helping with the development of more complex MediaWiki-integrated
tools like the GLAMWiki-Toolset.

There's work that only WMF is well positioned to do (like feeding all
media view data into Hadoop and providing generalized reports and
APIs), but a lot of work in the aforementioned categories could be
done by any chapter and could easily be scaled up from 1 to 2 to 3
FTEs and beyond as warranted. That's because a lot of the tools are
separate from MediaWiki, so code review and integration requirements
are lower, and it's easier for technically proficient folks to help.

In short, I think this could provide a nice on-ramp for a chapter or
chapters to support the work of volunteers in the cultural sector with
appropriate technology. This availability of appropriate technology is
clearly increasingly a distinguishing factor for Wikimedia relative to
more commercial offerings in its appeal to the cultural sector.

At the same time, WMF itself doesn't currently prioritize work with
the cultural sector very highly, which I think is appropriate given
all the other problems we have to solve. So if this kind of work has
to compete for attention with much more basic improvements to say the
uploading pipeline or the editing tools, it's going to lose. Therefore
I think having a cultural tooling team or teams in the larger
movement would be appropriate.

I've not heard back from WM-CH yet on this, but I also don't think
it's an exclusive suggestion, so wanted to put the idea in people's
heads in case other organizations in the movement want to help with
it. I do want WMF

Re: [Wikimedia-l] How Wikimedia could help languages to survive

2014-04-26 Thread Seb35


As a supporter of language diversity, I’m a bit sad of this thread because
some people find we should not engage in language revitalisation because:
1/ it’s not explicitely in our scope (and I don’t fully aggree: sum of
all knowledge also includes minority cultures expressed in their
languages, as shown by Hubert Laska with the Kneip),
2/ it’s too difficult/expansive to save most languages.

Although there are obviously great difficulties, I find it shouldn’t stop
us to support or partnership with local languages institutions,
particularly if there are interested people or volunteers: we are not
obliged to select the 3000 more spoken languages and set up parterships to
save these 3000 languages, but we can support institutions or volunteers
_interested_ in saving some small language on a case-by-case basis (Rapa
Nui, Chickasaw, Skolt Sami, Kibushi, whatever) if minimum requirements are
met (writing system and ISO 639 code for a website, financial ressources
for a project), i.e. crowdsourcing the language preservation between
Wikimedia, volunteers, speakers, and institutions.

When multilinguism in the cyberspace is discussed by linguists, Wikipedia
is almost every time shown as *the* better successful example. As
discussed in this thread, perhaps some projects (Wikisource, Wiktionary,
Wikidata) are easier to set up in these languages and this could be a
first step, but these will only preserve these as non-living objects of
interest, at the contrary of a Wikibook/Wikipedia/Wikinews/Wikiversity
where speakers could practice the language, invent neologisms and
terminology, create corpora for linguists, and show the language to other
interested people in the world (I’m sure there are).

As an example in France, Wikimédia France has quite good relationships
with the DGLFLF (Delegation for the French language and languages of
France), and this institution census 75 languages in France, whose 2/3 are
overseas [1]. The DGLFLF contributed ressources on some small languages
and multilinguism on Wikibooks [2] and Commons [3].

[1] (fr)
[2] (fr)États_généraux_du_multilinguisme_dans_les_outre-mer
[3] (fr)(mul)États_généraux_du_multilinguisme_dans_les_outre-mer

~ Seb35

20.04.2014 05:46:47 (CEST), Milos Rancic kirjoitti:

There are ~6000 languages in the world and around 3000 of them have
more than 10,000 speakers.

That approximation has some issues, but they are compensated by the
ambiguity of the opposition. Ethnologue is not the best place to find
precise data about the languages and it could count as languages just
close varieties of one language, but it also doesn't count some other
languages. Not all of the languages with 10,000 or more speakers have
positive attitude toward their languages, but there are languages with
smaller number of speakers with very positive attitude toward their
own language.

So, that number is what we could count as the realistic final number
of the language editions of Wikimedia projects. At the moment, we have
less than 300 language editions.

* * *

There is the question: Why should we do that? The answer is clear to
me: Because we can.

Yes, there are maybe more specific organizations which could do that,
but it's not about expertise, but about ability. Fortunately, we don't
need to search for historical examples for comparisons; the Internet
is good enough.

I still remember infographic of the time while all of us thought that
Flickr is the place for images. It turned out that the biggest
repository of images is actually Facebook, which had hundred times
more of them than the Twitpic at the second place, which, in turn, had
hundred times more of images than Flickr.

In other words, the purpose of something and general perception of its
purpose is not enough for doing good job. As well as comparisons
between mismanaged internet projects and mismanaged traditional
scientific and educational organizations are numerous.

At this point of time Wikimedia all necessary capacities -- and even a
will to take that job. So, we should start doing that, finally :)

* * *

There is also the question: How can we do that? In short, because of  

I announced Microgrants project of Wikimedia Serbia yesterday. To be
honest, we have very low expectations. When I said to Filip that I
want to have 10 active community members after the project, he said
that I am overambitious. Yes, I am.

But ten hours later I've got the first response and I was very
positively surprised by a lot of things. The most relevant for this
story is that a person from a city in Serbia proper is very
enthusiastic about Wikipedia and contributing to it (and organizing
contributors in the area). I didn't hear that for years! (Maybe I was
just too pessimistic because of my obsession with statistics.)

Keeping in mind her position (she said that she

Re: [Wikimedia-l] [feature suggestion] Be able to include/exclude certain page fragments based on the geographic area

2014-03-13 Thread Seb35

Le lundi 10 mars 2014 21:03:20 (CET), Yuri a écrit :

On 03/10/2014 11:30, Seb35 wrote:
Another point of view is that the knowledge doesn’t (shouldn’t) depend  
in any way of the local government -- possibly it can be viewed  
differently from a culture to another but that’s a cultural question  
not related to censorship.

Moreover it would be a censorship practice close to the Ministry of  
Truth in 1984 where the newspapers are re-printed afterwards to modify  
the past History.

This is exactly the point: when local governments attempt to twist the  
truth, they are currently able to do this for all readers, regardless of  
the location. This feature would allow to explicitly twist the truth in  
specific areas where this twisting is legally required, while preserving  
the real version for everyone else. In a way, it will also keep the  
registry of altered information, while now there is no such way and  
alterations are just swallowed.

I’m not convinced by this method (quite difficult technically as said on  
the bug) because of the abuse ti could lead: if a government doesn’t like  
a version of an article (example given by Austin Hair), it would be too  
easy to find a random volunteer in the country to hide the unwanted parts.  
As a real example in the DCRI affair last year, if such a feature would  
have existed I guess the affair would have received a smaller attention  
from the international movement and the censorship would have worked  

I understand your intention with this system, but I find it’s not a good  
response to the problem; I find a better response is to encourage and help  
the free speech associations, like what was done during SOPA/PIPA.

~ Seb35

Wikimedia-l mailing list

Re: [Wikimedia-l] [feature suggestion] Be able to include/exclude certain page fragments based on the geographic area

2014-03-10 Thread Seb35
Another point of view is that the knowledge doesn’t (shouldn’t) depend in  
any way of the local government -- possibly it can be viewed differently  
from a culture to another but that’s a cultural question not related to  

Moreover it would be a censorship practice close to the Ministry of Truth  
in 1984 where the newspapers are re-printed afterwards to modify the past  

~ Seb35

Le mercredi 5 mars 2014 05:37:25 (CET), Todd Allen
a écrit :

Exactly this.

If the government of any given country wants to redirect certain  
or all of Wikipedia, to a page saying This content blocked by the  

of Knowledge, people will know they're being censored. If instead they
reach a sanitized version of the article reflecting the government's
preferred spin, we're putting that government's spin in our voice. That's
not at all acceptable.

Let them censor, let them make it obvious, and let them deal with the
fallout. But we should absolutely not help them in any way whatsoever.

On Tue, Mar 4, 2014 at 9:30 PM, Austin Hair wrote:

I think that if you stop to think about it another way, you'll find
that this would do the opposite of what you intend, to wit: allowing
various courts to impose editorial control.

Imagine Circletine, once a popular childhood beverage but now the
issue of some controversy regarding its tendency to cause tooth loss.
Although banned from sale in Europe and the United States, an
aggressive marketing campaign has made it the best-selling soft drink
in the nation of Elbonia. Equally aggressive lobbying in the Elbonian
parliament has resulted it in being a crime to disparage Circletine in
any way, or even to mention the controversy in print.

And so we have our article:

'''Circletine''' is a bannedin
country=elboniacontroversial/bannedin milk flavoring product made
from malt extract, curds, and whey, bannedin
country=elboniaonce/bannedin extremely popular worldwide

bannedin country=elboniaAlthough it enjoyed several decades of
success as an inexpensive beverage marketed mostly for children,
concerns over an increased risk of tooth loss led to its withdrawal
from sale in most western countries./bannedin

(I think you can see where this is going.)

Censorship is awful, but partial censorship is worse than simply
saying I'm not allowed to talk about it. Ask your government why.


On Tue, Mar 4, 2014 at 9:50 PM, Yuri wrote:
 I submitted the proposal to be able to eliminate certain parts of the
 articles in certain countries, where the local governments find those
 But it got rejected, and I am not sure I am clear why.

 The problem is that there are countries that lack the freedom of  

 (most of the countries), and some of them get very aggressive about
 materials that most reasonable people wouldn't find objectionable. The
 recent example, provided in the bug report above, is banning of any
 references of Adolf Hitler's book Mein Kampf in Russia. While this  

 may seem not as important, but I don't see why users outside Russia
 be affected by such decision, when they may not even support any
 or values of the said government. Yet, everybody's version of  

 is affected, and materials are hidden.

 My suggestion, if implemented, would allow to hide certain parts of  

 articles in the country (or area) of jurisdiction of the corresponding
 court, while allowing users not living there to still see the original

 If such governments get their way in banning materials globally, this
 effectively make wikipedia biased, and reflecting various POVs of  

 courts, which has never been intended by wikipedia.


 Wikimedia-l mailing list

Wikimedia-l mailing list

Wikimedia-l mailing list

Wikimedia-l mailing list

Re: [Wikimedia-l] [WMBD] Bengali Wikipedia program with Grameen Phone (A Telenor group company)

2014-02-16 Thread Seb35

Great program! Happy to see Wikipedia Zero in Grameen Phone!

For the video you ask, you can browse  
with many video tutorials and some Wikipedia introductory videos like and, both of them  
have bengali subtitles also.

~ Seb35

Le samedi 15 février 2014 12:42:23 (CET), Nurunnaby Chowdhury a écrit :

Dear All,

I am happy to inform you Wikimedia Bangladesh (WMBD) has arranged a two  

(February 16  17, 2014) Wikipedia program with Grameen Phone (A Telenor
concern). Grameen Phone is the largest telecommunication company based in
Bangladesh. Besides, in Bangladesh Grameen Phone  Banglalink (A Orascom
Telecom and VimpelCom Ltd concern) now provide, which is completely free of cost.

In this two-day program we will arrange different types of Workshops.  

president Munir Hasan will conduct two seminars on wikipedia. Me  our
another Sysop of Bengali Wikipedia Nasir Khan will jointly run 2/3
workshops. Our target audience 70+ I-Genious student. This all I-Genious
students selected by a year-long program arranged by Grameen Phone  The
Daily Prothom Alo all over the country [1]. On the first day 35  on the
second day 35 students will join this program. During the program we will
deliver hands on presentations, How to edit, how to contribute, How to
donate photo to commons. Moreover, we will enrich some articles those  


After the successful completion of the program all i-Genious students  

receive certificates from WMBD  Grameen Phone.

In this program we are interested to show a video about wikipedia. It  

be great if anyone can give me a link where i may find the video.


*​Nurunnaby Chowdhury Hasive* | User: nhasive
Sysop of *Bengali Wikipedia​*

Bangladesh Ambassador of *Open Knowledge Foundation Network​*

Wikimedia-l mailing list

Re: [Wikimedia-l] Statement for the police about the fundraising?

2014-02-07 Thread Seb35
It’s incredible that some governments think they own the language(s)  
mainly spoken in their country: is in Finnish but not  
related to Finland (non-Finnish people could visit, and  
Finnish people could visit other language Wikipedias). And it’s sad if  
they attack volunteers for a technical work, that would sound like the  
DGSE affair.

~ Seb35

Le Fri, 07 Feb 2014 23:00:40 +0100, Alex Monk a écrit:

Has anyone translated the email into English? Would be interesting to see
what it says...

Alex Monk

On 7 February 2014 21:33, Leinonen Teemu wrote:


I just got a message that the Finnish Police have asked the  

by sending an email to the, to give a
written statement about their possible violation of the laws that  
fundraising in Finland. There is a little news about this already  
online in

English. Here:

I chat about this with a lawyer friend and he was afraid that the police
msy go after the volunteers that have participated in the fundraising,  

by translating the fundraising messages.

Is there any equivalent cases from other countries?

In Finland one needs a pre-given permission to do fundraising.

- Teemu

Teemu Leinonen
+358 50 351 6796
Media Lab
Aalto University
School of Arts, Design and Architecture

Wikimedia-l mailing list

Wikimedia-l mailing list

Wikimedia-l mailing list

[Wikimedia-l] Basic income Wikimedians

2014-01-09 Thread Seb35


I would like to speak on this list about the basic income.

For a TL;DR about the concept, the idea of an (unconditionnal) basic
income is to give each citizen of a country a sum of money in order to
fullfill their basic needs: lodging, eat, be healthy. To give an idea of
the amount, one hears often 800-1000 € in France and I heard 2500 CHF in
Switzerland. If people want to earn more, their work income will be in
addition of this basic income. You can read more on the Wikipedia articles
([1] and other languages). Be aware, this idea is as strange as Wikipedia
when one discovers it.

As a Wikipmedian, I dream of such a basic income: it would empower the
people to edit the Wikimedia projects by giving them libre time (libre as
free speech). I don’t think Wikimedia itself should support this to avoid
being involved in politics, but probably many Wikipmedians could be
interested in this idea.

For the European citizens, there is currently an official call (an ECI
[2]) to support this idea at the European level, see [3] ; this call ends
in one week (yes, the 200,000 signatures is a bit far of the million
signatures needed). In Switzerland, a popular legislative initiative
collected more than the 100,000 needed signatures in September 2013, and
this will lead to a nationwide referendum about the basic income there.

Any thoughts about that?


~ Seb35 [^_^]

Wikimedia-l mailing list

Re: [Wikimedia-l] Basic income Wikimedians

2014-01-09 Thread Seb35
If a basic income is implemented somewhere in the world, people will have  
more time for themselves in mean (probably more partial-time work), so  
they will have more time to edit the Wikimedia projects, among other  
possible activities. ~S

Le Thu, 09 Jan 2014 13:55:39 +0100, Fæ a écrit:

Thanks. I don't see how this relates to Wikimedia projects, by definition
it is not.

On 9 January 2014 12:40, Emmanuel Engelhart wrote:

Le 09/01/2014 13:36, Fæ a écrit :
 ​The WMF has recently clarified that they frown upon paid editing.
 Presumably offering basic wage for people to edit Wikipedia is still  


The answer is no, because the basic income is *unconditional*.
This is an income, not at wage.

Definition from Wikipedia:
A basic income (also called basic income guarantee, unconditional basic
income, universal basic income, universal demogrant,[1] or citizen’s
income) is a proposed system[2] of social security in which citizens or
residents of a country regularly receive a sum of money unconditionally,
either from a government or some other institution able to ensure an
equitable distribution of common wealth.


Kiwix - Wikipedia Offline  more
* Web:
* Twitter:
* more:

Wikimedia-l mailing list

Wikimedia-l mailing list

Re: [Wikimedia-l] First Wikimedia-related contributor Kickstarter?

2013-11-02 Thread Seb35
Le Sat, 02 Nov 2013 02:56:30 +0100, Steven Walling a écrit:

On Fri, Nov 1, 2013 at 3:34 PM, Nathan wrote:

A post is live on Gizmodo today about a Commons contributor (Evan-Amos)  

takes high quality photos of video game systems and hardware.[1] Towards
the end it mentions that Evan started a Kickstarter to fund his efforts  

buy and photograph more systems as part of an online museum.[2]

Anyone know if this is the first Wikimedia-related Kickstarter  
campaign, or
has it happened before? What do people think about someone raising  
~$13k to

contribute photos to Commons? How does that fit in the debate about paid
editing? To me it has a very different feel than, say, Wiki-PR. But...


This guy is a free culture badass. :-)

I wish more Commons contributors could promote and support their work  

this. This project makes me think about other high quality photo
collections, such as the many featured pictures of vintage computers or
rocks and minerals. The list goes on and on.

Like others have hinted at, both chapters and the WMF can potentially  
out grants to support photography projects like this. I wonder if Evan  
that or considered it? I'd love to hear feedback from him about why he  

Kickstarter was fruitful, and how it compares to our large grants
infrastructure in the Wikimedia movement.

A small point about possible explanation for using Kickstarter is to reach  
other communities/public than the traditional Wikimedia communities and  
framework. In this sense it is also an outreach channel.

I find this type of funding is original in our movement, and moreover the  
project appears to be conducted with a good quality, so why not?

~ Seb35

Wikimedia-l mailing list

Re: [Wikimedia-l] Wikimedia and the politics of encryption

2013-09-05 Thread Seb35

I don’t see precisely how mandatory HTTPS could help spread the knowledge;
accordingly if users feel themselves spied and it prevent them to
contribute, yes, HTTPS helps; but if others feel cluttered by HTTPS (time
load, unfriendly firewalls, various problems), it could also lower the
number of editors.

On another side HTTPS is quite useless if users click-through any warning
(You are spied.: Ok/close me that ad → privacy education); anyway
encryption and code breaking is always a cat-and-mouse play, and we sould
have to carefully monitor state of the art if we really want to protect
the users; but imho it’s not our vision.

For HTTPS, I would like to see the users opt-in to the security they want:
e.g. if they write about intelligence, they probably know the dangers
about being spied and want minimize it as part of other means; if they
write about butterflies, perhaps they don’t matter about being spied. For
specific-rights editors security could be enforced, but possibly with
other means than encryption; e.g. if an oversight has to hide an article,
it is primarly needed to be sure the user has oversight rights
(authorisation), and it is not really useful to hide what article it is
(it was public). Accordingly for checkusers, we want the IPs stay private
(encrypted during the transport). This point is: HTTPS is not the solution
to all problems.

For HTTPS I see some security levels chosed by the users: no HTTPS at all
(Chinese users), equal HTTP/HTTPS (butterflies editor), prefered HTTPS
(privacy-conscious editor, but travelling to China regularly), always
HTTPS or nothing (intelligence editor). And this could be also implemented
for readers during their session. This option is politically neutral, it
just let the user choose.


Le Tue, 03 Sep 2013 21:38:36 +0200, Terry Chay a
This part of the discussion has strayed a bit far from the politics of  
encryption. ;-)

Not that it doesn't have value, but if I can bring it back on-topic for  
a moment…

The gist of the HTTPS issues is that it's simply not an engineering  
discussion, it's a political one. The abuses recently revealed in the  
United States is either orthogonal to the issue of the politics of  
encryption (in that HTTPS encryption in China, Iran, and the future is  
in discussion), or is the direct salient (in that it is a prime  
motivator for accelerating HTTPS rollout which has triggered this issue).

I, for one, would like to see the discussion of what to do. I'm of the  
believe that there is no simple engineering decision without introducing  
practical, political, legal, and moral complications. I suspect that  
even the more clever or complex ones also introduce these issues. It's  
important to outline what our choices are and the consequences of those  
choices, and derive consensus on what the right choice is going forward,  
as it is clear what we have now[1] is a temporary band-aid.[2]

I'm less sanguine about Erik's suggestion that creating a deadline to  
HTTP-canonical will actually get us to an adequate resolution. The  
reason is simply—whatever I think of Google personally—I feel Google has  
a highly-capable, highly-motivated, engineering-driven staff, and they  
were unable to come up with a workable solution. Unlike Google, we have  
a clear sense about what motivates us[3], so we need to figure out how  
best to get there/interpret it.

[2]: Maybe start an RfC or other wiki page on Meta with a summary of the  
discussion so far?


Take care,


On Sep 3, 2013, at 11:50 AM, Kirill Lokshin  

The thing is, it's kind of a crapshoot anyways.  You might see  
something that you think might be classified and report it; but, unless  
you actually have the corresponding clearance yourself, you have no way  
of knowing for certain whether the material is in fact classified in  
the first place.  Conversely, anyone who does have that information is  
unlikely to confirm it one way or the other, for obvious reasons.

To make things even more convoluted, reporting certain kinds of  
material to the WMF could itself potentially be considered illegal in  
some circumstances, since not everyone at the WMF is considered a US  
person for ITAR purposes.


On Sep 3, 2013, at 2:34 PM, Fred Bauder  

To be fair, none of the people receiving requests through legal@ or
emergency@ have security clearances either.


True, but there are not so many of them. I'm not sure if a request  
a major matter has ever been made through any channel. In a way, that  

kind of a dumb move.


Wikimedia-l mailing list

Re: [Wikimedia-l] [Wikitech-l] HTTPS for logged in users on Wednesday August 21st

2013-08-21 Thread Seb35


I do not really enjoy the way the mandatory-for-editors HTTPS was
introduced, mainly for time frame and communications (still) reasons,
although I’m globally really enthousiastic about a better security and
particularly the activation of HTTPS. Generally speaking I do _hope_ in
the future WMF will give more time and more discussion space to handle
major changes.
end tl;dr

History: (I concede I may lack some readings, but I think I have the big

After the PRISM scandal in June (2.5 months ago) everybody condemned that
program and the Internet security became a major concern for Internet
users. HTTPS is in important means to improve the security (although
concerns about the protocol and the way it is implemented appear) and
since it was a matter of time before it could be globally activated the
blog post published on August 1st announced HTTPS will be activated for
logged-in users 20 days after, with solutions about the blocked China
HTTPS to be found [1], after a discussion on wikitech-l [2].

Some Chinese editors made petitions [3] (starting on 08/08) and Iranian
users raised a similar problem [4] (on 14/08). In parallel these last two
weeks there were discussions on wikitech-l about some way to opt-out by
user and/or geographically. And in parallel the last two weeks there were
discussions on wikitech-l whether some opt-out mechanism should be
implemented with two opposed points of view:
1/ this security about the protection of the password must be for everyone
else it is unuseful (which is true in a perfect world), no matter if China
and other HTTPS-unlucky people cannot login (and hence must edit under IP
or not edit);
2/ although security is very important, not to allow HTTP logins in China
(and other HTTPS-unlucky people) will destroy etablished parts of the
community and should be avoided, so implementation of work-arounds is
And this last discussion had not to be on wikitech-l because it is
political, and was only a few raised elsewhere (where HTTPS is technical
and should be discussed on wikitech-l.)

Finally some work-arounds were implemented; first it was a list of wikis
where HTTP login will be allowed (this decision became public on Monday
[5]) and yesterday (sic) it was announced a geolocalised solution [6].
Secondly there will be a preference for the users, although until
yesterday it was not clear for everybody how exactly it was implemented.
In parallel the central notice was set up two days ago with an
English-only page, pywikipediabot was announced to be ready some hours
ago. And in some hours there should be the deployment target.



I know the fact we now know we are spied is disturbing, but…

Why the hell HTTPS is so truly *urgent* we cannot spent more than three
weeks (at all) to think about the problem, investigate related problems
(including political and communitical here), think about solutions and
user interfaces/interactions, implement solutions, widely avertize the
problem and solutions, and peacefully deploy the patches?

I would have loved some RFC and some discussion elsewhere than on
wikitech-l with structured problems and solutions, and more time allowed
for discussing all that with the community -- because I guess it was
widely discussed internally in technical and operations teams, but the
community discovered these plans and had to report potential problems in a
time frame of 3 weeks.

More generally speaking, I would love the WMF share more their internal
plans long before rollout -- even if I concede writing and discussion is
more time-consuming than oral speak and introduce latencies -- and
probably in some digest and expanded forms (I know there are already both,
it’s probably to be improved and perhaps more targeted to avoid everyone’s
burnout). And perhaps slow the rhythm of the technical changes to have a
more stable environment (I understand this is personal and there are other

~ Seb35

Le Wed, 21 Aug 2013 11:37:35 +0200, Pierre-Selim
a écrit:

First of all, I'm sorry If my tone was not appropriate (keep in mind I'm
not a native speaker).

2013/8/21 Terry Chay

On Aug 21, 2013, at 1:39 AM, Pierre-Selim  

 Just a question: Why imposing HTTPS ? Really, it will be damaging

The reason why is outlined in Ryan's blog post as well as his previous
post and the Wikipedia entry on https linked from that post.

The short answer is the current state is known to present a number of
privacy and security

Re: [Wikimedia-l] law enforcement buying vulnerabilities on black market leaving them unreported for surveillance

2013-08-20 Thread Seb35
I aggree with JP Béland: the computer security obviously affects the  
Wikimedia users, but imho we shouldn’t do more than we can and let the  
responsability of their own security to the users -- although we should  
contribute for a decent security.

For the specific topic you brought about 0-days, I’m not personnaly  
surprised, this type of market was revealed some time ago, see for  

~ Seb35

Le Tue, 20 Aug 2013 07:30:09 +0200, JP Béland a  

I'm not sure what is your point here. How exactly readers of Wikimedia
projects are at risk here because of that story? Are you trying to say it
is the Foundation responsibility to protect the readers from the
vulnerabilities of their operating systems?

JP Béland

2013/8/19 James Salsman

While the trickling release of Edward Snowden's revelations from bad to
worse in weekly incremental steps has been enormously effective in  

public opinion, it has made formulating a meaningful response very

A few weeks ago we learned that the FBI has been purchasing personal
computer operating system vulnerabilities from gray and black-hat  
on the black market, often for several tens of thousands of dollars  

and leaving them unreported and thereby unpatched for use in future
surveillance operations:

Unfortunately, this means that the vulnerabilities remain available to  

criminal computer crime underground, affecting everyone including
Foundation project readers and contributors alike.

Very recently a well respected group of researchers characterized this
state of affairs as preferable to the complexity of additional
surveillance network and systems infrastructure:

This is a false dichotomy which directly places Foundation project  

and editors at risk, but does so along with virtually everyone else who
uses personal computer or smartphone equipment. However, I think it is  
important aspect to address because none of the other recent  
revelations put people at risk to organized computer crime, blackmail,  

extortion in the same way.

Is there any reason to exclude action on a particular issue just  
because it

effects everyone else along with our users?
Wikimedia-l mailing list

Wikimedia-l mailing list

Wikimedia-l mailing list

Re: [Wikimedia-l] Go away, community (from WMF wiki at least)

2013-05-11 Thread Seb35
Le Sat, 11 May 2013 17:50:18 +0200, Marc A. Pelletier a  

Perhaps you should wait for a response from them before you
declare what their wishes may be or what their reasons were?

At the same time, it’s a very bad timing of doing such a controversial  
action just before weekend, and let people wondering during two days the  
reasons behind this action. So waiting still 2 days..


Wikimedia-l mailing list

Re: [Wikimedia-l] Go away, community (from WMF wiki at least)

2013-05-11 Thread Seb35

Thanks a lot for this explanation.

On the other side, wikis not only need content producers (here WMF) but  
also curators (wikignomes) who are sorting the pages, deleting and moving  
pages, typocorrecting, templating things, helping new users in formatting  
texts, etc. (I read some of the Florence’s blogposts :) -- and not being  
admin restricts a lot the possible actions.

And on the example you give about disagreement between two editors (e.g.  
staffer and volunteer), in theory there is no reason the staffer’s  
solution is better or worse than the volunteer’s solution, but perhaps a  
mean solution can be better than any of the two initial solutions; and in  
this case, the spent time is not a waste of time.


Le Sat, 11 May 2013 18:48:38 +0200, Sue Gardner a  

Gayle is travelling today and not online, so I'll take a crack at
responding to this.

The editors are responsible for the projects: the Wikimedia Foundation
knows that, acknowledges it, and is deeply appreciative (as are all
readers) for the work that volunteers do in the projects. The Wikimedia
Foundation is responsible for the Wikimedia Foundation wiki (and the  

We are grateful to get community help there, and a small number of
community members do really good work with us on both the WMF wiki and  

blog. But ultimately that wiki, and the blog, are our responsibility, and
we are accountable for making sure that e.g. the staff page, the Board
bios, the resolution texts, etc., are maintained and in good shape. Most
material on the WMF is not created via collaborative production processes
-- it's corporate in nature, meaning that it is developed by the
Wikimedia Foundation, for an audience of Wikimedia Foundation  
which includes community members and prospective community members,  

readers of the projects, media, and others.

My understanding is that administrator rights have been removed from a
small number of volunteers, but that those people still have basic  
rights. My understanding is that the Wikimedia Foundation staff who work  

the Foundation wiki have been grateful (and are grateful) for the help
they've gotten from community members in maintaining the Foundation wiki,
and that we hope they'll continue to help us. They've been great, and  


But, my understanding is also that occasionally volunteers have  

decisions made by staff on the Wikimedia Foundation wiki. I don't think
that's ever been a huge problem: I don't think we've ever had a situation
in which extensive discussion hasn't reached an okay conclusion. But, the
extensive discussions --which, I understand, have typically been
one-on-one, by which I mean, not a large number of community members or a
community consensus against something the Foundation has wanted to do,  
rather one volunteer disagreeing with something staff have been asked to  

as part of their job --- occasionally, those discussions have been
extremely time-consuming. That's not good. The staff working on the
Wikimedia Foundation wiki have jobs they've got to get done, in support  

the entire movement. If they spend days or weeks needing to persuade a
single community member of the merits of something they want to do on the
Foundation wiki, or if they need to modify their plans extensively to
accommodate the opinions of a single community member, that reduces the
amount of time available for them to do the rest of their work. Which, I
repeat, is in the service of the movement overall.

So I would say this:

This decision is not about the community versus the WMF. This  
is about the WMF staff, and making it possible for them to do their work  

the WMF wiki with some reasonable degree of efficiency and effectiveness.
This decision clarifies roles-and-responsibilities. On the projects, the
volunteers are the editorial leads, and the WMF plays a supporting role  

creating functionality, maintaining the servers, paying the bandwidth
bills, and so forth. On the WMF wiki, the WMF is the editorial lead, and
volunteers can (and do) play a supporting role helping staff organize
pages, maintain pages, and so forth. That's a reasonable division, and I
think having clarity around it is a good thing.

Slightly more broadly: when the Wikimedia movement was very young,
everybody did everything and there wasn't much division of
roles-and-responsibilities. I remember when the Wikimedia Foundation
budgets were prepared by volunteers, when the trademarks were managed by
volunteers, and so forth. That was appropriate for the time, and even
though it was messy, it was kind of great. Then we all went through a
period in which roles-and-responsibilities were utterly unclear -- it
wasn't at all obvious who should do what, and many
roles-and-responsibilities were hotly disputed. Personally, I feel like
we're moving into a period now in which things are getting clearer. We

Re: [Wikimedia-l] [Wikitech-l] Glossary vs. Glossaries

2013-03-24 Thread Seb35

(CC’ing translators-l also.)

Le Fri, 22 Mar 2013 14:27:44 +0100, Guillaume Paumier a écrit:


Last November, I started to clean up on the Glossary page on meta, as
an attempt to revive it and expand it to include many technical terms,
notably related to Wikimedia Engineering (see e-mail below).

There were (and are) already many glossaries spread around the wikis:
* one for MediaWiki:
* one for Wikidata:
* one for Labs:
* two for the English Wikipedia:
* etc.

My thinking at the time was that it would be better to include tech
terms in meta's glossary, because fragmentation isn't a good thing for
glossaries: The user probably doesn't want to search a term through a
dozen glossaries (that they know of), and it would be easier if they
could just search in one place.

The fact is, though, that we're not going to merge all the existing
glossaries into one anytime soon, so overlap and duplication will
remain anyway. Also, it feels weird to have tech content on meta, and
the glossary is getting very long (and possibly more difficult to
maintain). Therefore, I'm now reconsidering the decision of mixing
tech terms and general movement terms on meta.

Below are the current solutions I'm seeing to move forward; I'd love
to get some feedback as to what people think would be the best way to

* Status quo: We keep the current glossaries as they are, even if they
overlap and duplicate work. We'll manage.

* Wikidata: If Wikidata could be used to host terms and definitions
(in various languages), and wikis could pull this data using
templates/Lua, it would be a sane way to reduce duplication, while
still allowing local wikis to complement it with their own terms. For
example, administrator is a generic term across Wikimedia sites
(even MediaWiki sites), so it would go into the general glossary
repository on Wikidata; but DYK could be local to the English
Wikipedia. With proper templates, the integration between remote and
local terms could be seamless. It seems to me, however, that this
would require significant development work.

* Google custom search: Waldir recently used Google Custom Search to
created a search tool to find technical information across many pages
and sites where information is currently fragmented:
. We could set up a similar tool (or a floss alternative) that would
include all glossaries. By advertising the tool prominently on
existing glossary pages (so that users know it exists), this could
allow us to curate more specific glossaries, while keeping them all
searchable with one tool.

Right now, I'm inclined to go with the custom search solution,
because it looks like the easiest and fastest to implement, while
reducing maintenance costs and remaining flexible. That said, I'd love
to hear feedback and opinions about this before implementing anything.



Given each community/wiki develops its own speak, it’s probably better to
keep all pages. Additionally it would be valuable for the global Wikimedia
community to have a simple glossary on meta to ease learning for newcomers
and for translations. So it’s probably good to write down on meta basic
terms and link to specialized glossaries and possibly set up a custom
search as you suggest.

I created some time ago a template on meta for a glossary and applied it
to very basic terms [1], mainly with translation in mind. Another idea is
to use the translate extension on [[meta:Glossary]] to uniformize the
presentation accross languages and to use the translation memory (although
it don’t apply to parts of messages AFAIK). Possibly it can also filled
Extension:WikimediaMessages with some other very basic Wikimedia terms
like editor, FDC, GAC, privacy policy to directly reuse these one
in translations, but it would probably demands a lot of maintenance for
all languages with declensions.

Related to the Wiktionary, some of the terms have a place on the
Wiktionary (analytics, API, backlog, boldness, etc.) but certainly not
all. Given this fact and your suggestion of using Wikidata, I had the idea
of an application based on Wikidata/Omegawiki to create custom
dictionaries, which could hold many specialized lexicons (e.g. wikispeak,
internet slang, etc.). I am going to the [[Wiktionary future]] page :)


~ Seb35

On Tue, Nov 20, 2012 at 7:55 PM, Guillaume Paumier wrote:


The use of jargon, acronyms and other abbreviations throughout the
Wikimedia movement is a major source of communication issues, and
barriers to comprehension and involvement.

The recent thread

Re: [Wikimedia-l] [Wikitech-l] Help needed to complete and expand the Wikimedia glossary

2012-11-21 Thread Seb35

I support this effort to create a common glossary/vocabulary.

And I add, since I tried to translate some of these words/expressions into
French some time ago, and since it’s quite hard to obtain great and
intuitive translations for many of these expressions, it would be great if
new expressions could be thought with an internationalisation spirit as
far as possible.

As an example, in the Wikimedia Highlights of September, it’s hard to
translate Curation Toolbar since curation don’t have a direct
equivalent in French for this exact meaning (of tacking care of
articles, curation is usually translated by conservation but quite
different of this meaning). This is just an example but it illustrates a
common difficulty for translators, probably for many languages.


Le Tue, 20 Nov 2012 19:55:04 +0100, Guillaume Paumier a écrit:


The use of jargon, acronyms and other abbreviations throughout the
Wikimedia movement is a major source of communication issues, and
barriers to comprehension and involvement.

The recent thread on this list about What is Product? is an example
of this, as are initialisms that have long been known to be a barrier
for Wikipedia newcomers.

A way to bridge people and communities with different vocabularies is
to write and maintain a glossary that explains jargon in plain English
terms. We've been lacking a good and up-to-date glossary for Wikimedia
stuff (Foundation, chapter, movement, technology, etc.).

Therefore, I've started to clean up and expand the outdated Glossary
on meta, but it's a lot of work, and I don't have all the answers
myself either. I'll continue to work on it, but I'd love to get some
help on this and to make it a collaborative effort.

If you have a few minutes to spare, please consider helping your
(current and future) fellow Wikimedians by writing a few definitions
if there are terms that you can explain in plain English. Additions of
new terms are much welcome as well:

Some caveats:
* As part of my work, I'm mostly interested in a glossary from a
technical perspective, so the list currently has a technical bias. I'm
hoping that by sending this message to a wider audience, people from
the whole movement will contribute to the glossary and balance it out.
* Also, I've started to clean up the glossary, but it still contains
dated terms and definitions from a few years ago (like the FundCom),
so boldly edit/remove obsolete content.

Thank you,

Wikimedia-l mailing list