Thank you for the clarification, Gerard. I was indeed misunderstanding the
proposal.
We need to find a central place to discuss a proposal.
2013/3/11 Gerard Meijssen <gerard.meijssen(a)gmail.com>
> Hoi,
> There is no point at all in maintaining the software currently used by
> OmegaWiki. That would be foolish. Nobody who knows OmegaWiki will ask for
> that.
>
> What we are asking for is that we ensure that the structures that exist in
> OmegaWiki are replicated in Wikidata for reasons that are clear and
> obvious. Technically there are a few things that make sense to have..
>
> For instance.. In the Dutch language we have a noun, a verb an adjective
> .... we do not have a country in this class. A noun can be male, female or
> neutral .... we do not have a stupid. We have singular and plural and we
> do not have dual like in Arabic.
>
> When there is a concept, we have synonyms and translations that are used as
> such but do not cover the original concept well. We want to be able to
> indicate this.
>
> Really Denny, all we need is to keep the structure, the data. We do not
> even want to be dogmatic about this (too much). What we want are things
> that fulfil a need, that have a purpose.
> Thanks,
> GerardM
>
>
> On 11 March 2013 15:51, Denny Vrandečić <denny.vrandecic(a)wikimedia.de
> >wrote:
>
> > Sorry about the wrong link, I meant this IEG proposal:
> >
> > <
> >
> http://meta.wikimedia.org/wiki/Grants:IEG/Wiktionary_-_the_way_it_should_be
> > >
> >
> > but as far as I can tell, this one didn't make it into round 1 (pity,
> > something like that would have made sense, but I understand that the
> > proposal was obviously not detailed enough. Whatever.)
> >
> > I fully agree with Andrea and Nemo that some use cases would be very easy
> > to implement, especially linking between the projects. Commons and
> > Wiktionary though are very different and require more thought:
> >
> > Commons:
> > * easy goals: link to appropriate items for some of the pages in Commons,
> > use data from Wikidata in the creator namespace and similar
> > * more engaging: add metadata to the media files in Commons itself and
> link
> > them to each other and to Wikidata
> >
> > Wiktionary:
> > * easy goals: none. The conceptualization of Wiktionary simply is not a
> > direct fit to the conceptualization in Wikipedia and Wikidata.
> > We need to figure out how they work together. Maybe this page is a good
> > start, and maybe we should collect the ideas there.
> >
> > <https://www.wikidata.org/**wiki/Wikidata:Wiktionary<
> > https://www.wikidata.org/wiki/Wikidata:Wiktionary>
> > >
> >
> > I mean, OmegaWiki has been around for a while, and they learned many,
> > extremely valuable lessons. A lot of work has went into it, and it would
> be
> > a shame not to build on its experiences and lessons. But I would like to
> > ask the question whether it is the right software or not, even though it
> is
> > a painful question. But please be reminded that I have spent many years
> in
> > the development of Semantic MediaWiki, with the one goal to have it
> > switched on the Wikipedias -- and then to come to the conclusion to *not*
> > use the software as is, and start from scratch.
> >
> > We need a discussion on Wiktionary, and how it can evolve, and if it even
> > should. And I do not think that a cross-mailing list discussion like the
> > current one is the right place, and I do not even know where the right
> > place is.
> >
> > So, first question: where should this discussion take place?
> >
> > Cheers,
> > Denny
> >
> >
> >
> >
> >
> > 2013/3/11 Federico Leva (Nemo) <nemowiki(a)gmail.com>
> >
> > > Denny Vrandečić, 11/03/2013 14:52:
> > >
> > > There is currently a number of things going on re the future of
> > >> Wiktionary.
> > >>
> > >> There is, for example, the suggestion to adopt OmegaWiki, which could
> > >> potentially complicate a Wikibase-Solution in the future (but then
> > again,
> > >> structured data is often rather easy to transform):
> > >> <
> > http://meta.wikimedia.org/**wiki/Requests_for_comment/**Adopt_OmegaWiki<
> > http://meta.wikimedia.org/wiki/Requests_for_comment/Adopt_OmegaWiki>
> > >> >
> > >>
> > >> There is this grant proposal for elaborating the future of Wiktionary,
> > >> which I consider a potentially smarter first step:
> > >>
> > >> <
> > >> http://meta.wikimedia.org/**wiki/Grants:IEG/Elaborate_**
> > >> Wikisource_strategic_vision<
> >
> http://meta.wikimedia.org/wiki/Grants:IEG/Elaborate_Wikisource_strategic_vi…
> > >
> > >>
> > >>>
> > >>>
> > > That's Wikisource. :)
> > >
> > >
> > >
> > >> There's this discussion on Wikdiata itself:
> > >>
> > >> <https://www.wikidata.org/**wiki/Wikidata:Wiktionary<
> > https://www.wikidata.org/wiki/Wikidata:Wiktionary>
> > >> >
> > >>
> > >> And I know that Daniel K. is very interested in working into this
> > >> direction.
> > >>
> > >> Personally, I regard Wiktionary as the third priority, following
> > Wikipedia
> > >> and Commons. A lot of the other projects -- like Wikivoyage or
> > Wikisource
> > >> -- can be served with only small changes to Wikidata as it is, but
> both
> > >> Commons and Wiktionary would require a bit of thought (and here again,
> > >> Commons much less than Wiktionary).
> > >>
> > >
> > > Actually Wikiquote and Wikivoyage use interwikis exactly like
> Wikipedia;
> > > Commons in the same way except it's interproject; Wiktionary in the
> same
> > > way except it's case-sensitive and not about concepts (opr about a
> > stricter
> > > definition of concept); Wikisource in a completely different way;
> > > Wikibooks, Wikinews and Wikiversity I'm not sure.
> > > As for phase II, it's another story. Wikisource and Commons would
> benefit
> > > a lot from it; for Wiktionary it could be a revolution; for Wikispecies
> > > idem but with less effort (?); Wikiquote would become
> > >
> > >
> > > I would appreciate a discussion with
> > >> the Wiktionary-Communities, and also to make them more aware of the
> > >> OmegaWiki proposal, the potential of Wikidata for Wiktionary, etc.
> Just
> > to
> > >> give a comparison: it took a few months to write the original Wikidata
> > >> proposal, and it was up for discussion for several months before it
> was
> > >> decided and acted upon. I would strongly advise to again choose slow
> and
> > >> careful planning over hastened decisions.
> > >>
> > >
> > > It's impossible to plan or discuss anything without knowing what
> matters.
> > >
> > > Nemo
> > >
> >
> >
> >
> > --
> > Project director Wikidata
> > Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
> > Tel. +49-30-219 158 26-0 | http://wikimedia.de
> >
> > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter
> > der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> > Körperschaften I Berlin, Steuernummer 27/681/51985.
> > _______________________________________________
> > Wikimedia-l mailing list
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> >
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Thank you for the clarification, Gerard. I was indeed misunderstanding the
proposal.
We need to find a central place to discuss a proposal.
2013/3/11 Gerard Meijssen <gerard.meijssen(a)gmail.com>
> Hoi,
> There is no point at all in maintaining the software currently used by
> OmegaWiki. That would be foolish. Nobody who knows OmegaWiki will ask for
> that.
>
> What we are asking for is that we ensure that the structures that exist in
> OmegaWiki are replicated in Wikidata for reasons that are clear and
> obvious. Technically there are a few things that make sense to have..
>
> For instance.. In the Dutch language we have a noun, a verb an adjective
> .... we do not have a country in this class. A noun can be male, female or
> neutral .... we do not have a stupid. We have singular and plural and we
> do not have dual like in Arabic.
>
> When there is a concept, we have synonyms and translations that are used as
> such but do not cover the original concept well. We want to be able to
> indicate this.
>
> Really Denny, all we need is to keep the structure, the data. We do not
> even want to be dogmatic about this (too much). What we want are things
> that fulfil a need, that have a purpose.
> Thanks,
> GerardM
>
>
> On 11 March 2013 15:51, Denny Vrandečić <denny.vrandecic(a)wikimedia.de
> >wrote:
>
> > Sorry about the wrong link, I meant this IEG proposal:
> >
> > <
> >
> http://meta.wikimedia.org/wiki/Grants:IEG/Wiktionary_-_the_way_it_should_be
> > >
> >
> > but as far as I can tell, this one didn't make it into round 1 (pity,
> > something like that would have made sense, but I understand that the
> > proposal was obviously not detailed enough. Whatever.)
> >
> > I fully agree with Andrea and Nemo that some use cases would be very easy
> > to implement, especially linking between the projects. Commons and
> > Wiktionary though are very different and require more thought:
> >
> > Commons:
> > * easy goals: link to appropriate items for some of the pages in Commons,
> > use data from Wikidata in the creator namespace and similar
> > * more engaging: add metadata to the media files in Commons itself and
> link
> > them to each other and to Wikidata
> >
> > Wiktionary:
> > * easy goals: none. The conceptualization of Wiktionary simply is not a
> > direct fit to the conceptualization in Wikipedia and Wikidata.
> > We need to figure out how they work together. Maybe this page is a good
> > start, and maybe we should collect the ideas there.
> >
> > <https://www.wikidata.org/**wiki/Wikidata:Wiktionary<
> > https://www.wikidata.org/wiki/Wikidata:Wiktionary>
> > >
> >
> > I mean, OmegaWiki has been around for a while, and they learned many,
> > extremely valuable lessons. A lot of work has went into it, and it would
> be
> > a shame not to build on its experiences and lessons. But I would like to
> > ask the question whether it is the right software or not, even though it
> is
> > a painful question. But please be reminded that I have spent many years
> in
> > the development of Semantic MediaWiki, with the one goal to have it
> > switched on the Wikipedias -- and then to come to the conclusion to *not*
> > use the software as is, and start from scratch.
> >
> > We need a discussion on Wiktionary, and how it can evolve, and if it even
> > should. And I do not think that a cross-mailing list discussion like the
> > current one is the right place, and I do not even know where the right
> > place is.
> >
> > So, first question: where should this discussion take place?
> >
> > Cheers,
> > Denny
> >
> >
> >
> >
> >
> > 2013/3/11 Federico Leva (Nemo) <nemowiki(a)gmail.com>
> >
> > > Denny Vrandečić, 11/03/2013 14:52:
> > >
> > > There is currently a number of things going on re the future of
> > >> Wiktionary.
> > >>
> > >> There is, for example, the suggestion to adopt OmegaWiki, which could
> > >> potentially complicate a Wikibase-Solution in the future (but then
> > again,
> > >> structured data is often rather easy to transform):
> > >> <
> > http://meta.wikimedia.org/**wiki/Requests_for_comment/**Adopt_OmegaWiki<
> > http://meta.wikimedia.org/wiki/Requests_for_comment/Adopt_OmegaWiki>
> > >> >
> > >>
> > >> There is this grant proposal for elaborating the future of Wiktionary,
> > >> which I consider a potentially smarter first step:
> > >>
> > >> <
> > >> http://meta.wikimedia.org/**wiki/Grants:IEG/Elaborate_**
> > >> Wikisource_strategic_vision<
> >
> http://meta.wikimedia.org/wiki/Grants:IEG/Elaborate_Wikisource_strategic_vi…
> > >
> > >>
> > >>>
> > >>>
> > > That's Wikisource. :)
> > >
> > >
> > >
> > >> There's this discussion on Wikdiata itself:
> > >>
> > >> <https://www.wikidata.org/**wiki/Wikidata:Wiktionary<
> > https://www.wikidata.org/wiki/Wikidata:Wiktionary>
> > >> >
> > >>
> > >> And I know that Daniel K. is very interested in working into this
> > >> direction.
> > >>
> > >> Personally, I regard Wiktionary as the third priority, following
> > Wikipedia
> > >> and Commons. A lot of the other projects -- like Wikivoyage or
> > Wikisource
> > >> -- can be served with only small changes to Wikidata as it is, but
> both
> > >> Commons and Wiktionary would require a bit of thought (and here again,
> > >> Commons much less than Wiktionary).
> > >>
> > >
> > > Actually Wikiquote and Wikivoyage use interwikis exactly like
> Wikipedia;
> > > Commons in the same way except it's interproject; Wiktionary in the
> same
> > > way except it's case-sensitive and not about concepts (opr about a
> > stricter
> > > definition of concept); Wikisource in a completely different way;
> > > Wikibooks, Wikinews and Wikiversity I'm not sure.
> > > As for phase II, it's another story. Wikisource and Commons would
> benefit
> > > a lot from it; for Wiktionary it could be a revolution; for Wikispecies
> > > idem but with less effort (?); Wikiquote would become
> > >
> > >
> > > I would appreciate a discussion with
> > >> the Wiktionary-Communities, and also to make them more aware of the
> > >> OmegaWiki proposal, the potential of Wikidata for Wiktionary, etc.
> Just
> > to
> > >> give a comparison: it took a few months to write the original Wikidata
> > >> proposal, and it was up for discussion for several months before it
> was
> > >> decided and acted upon. I would strongly advise to again choose slow
> and
> > >> careful planning over hastened decisions.
> > >>
> > >
> > > It's impossible to plan or discuss anything without knowing what
> matters.
> > >
> > > Nemo
> > >
> >
> >
> >
> > --
> > Project director Wikidata
> > Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
> > Tel. +49-30-219 158 26-0 | http://wikimedia.de
> >
> > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
> > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
> unter
> > der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> > Körperschaften I Berlin, Steuernummer 27/681/51985.
> > _______________________________________________
> > Wikimedia-l mailing list
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> >
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
>
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
It has resurfaced here in Australia
http://www.sbs.com.au/news/article/2014/12/14/comment-will-editing-disputes-
mean-end-wikipedia
Nothing to do with me, I should add.
Kerry
_____
From: wiki-research-l-bounces(a)lists.wikimedia.org
[mailto:wiki-research-l-bounces@lists.wikimedia.org] On Behalf Of Oliver
Keyes
Sent: Wednesday, 17 December 2014 12:04 AM
To: Research into Wikimedia content and communities
Subject: Re: [Wiki-research-l] commentary on Wikipedia's community behaviour
(Aaron gets a quote)
I think area of focus is likely to be a big factor. There's a stereotype,
for example, of new page patrollers as particularly uncaring and harried:
when we surveyed patrollers, and compared the results to the surveys of the
overall editing population, we found that the major demographic difference
or difference in priorities is simply that new page patrollers patrol new
pages. So where people choose to work definitely plays a part. And,
anecdotally, there are some areas that just attract combative individuals
and so become less-pleasant for those who (quite rightly) don't want to
tolerate that - articles around Israel/Palestine, for example, or the
Balkans.
At the end of the day, though, it's the people who make the environments
unpleasant just as much as it is the environments altering the people.
On 15 December 2014 at 23:28, mjn <mjn(a)anadrome.org> wrote:
Perhaps it depends on what part of the encyclopedia? Has anyone
attempted to characterize how the editing environment varies with
different subject matter? I often run across descriptions that don't
comport with either my experience, or that of people I've interviewed,
but it's hard to tell precisely why. I've encountered quite different
beliefs about what the en.wikipedia community is like, even among people
who to me seem to otherwise have a similar background.
Entirely anecdotally, areas of interest seem to be one correlated
factor. For example, writing an article on an archaeological site (one
thing I've mentored new editors in doing) is by and large trouble-free
and friendly, in my experience. But some other areas are not. I haven't
attempted to characterize that factor in any detail.
-Mark
WereSpielChequers <werespielchequers(a)gmail.com> writes:
> We have problems, I don't dispute that. But "ugly and bitter as 4chan"?
That has to be an exaggeration.
>
> Regards
>
> Jonathan Cardy
>
>
>> On 13 Dec 2014, at 01:03, Andrew Lih <andrew.lih(a)gmail.com> wrote:
>>
>> I certainly hope you're right Sydney. What a horrible mess.
>>
>>
>>> On Fri, Dec 12, 2014 at 5:53 PM, Sydney Poore <sydney.poore(a)gmail.com>
wrote:
>>> I think feminists, especially those who take an interest in STEM, will
pass this article around.
>>>
>>> Sydney
>>>
>>>> On Dec 12, 2014 5:35 PM, "Andrew Lih" <andrew.lih(a)gmail.com> wrote:
>>>> It's a good piece, but honestly I think only the dedicated tech reader
will make it through the entire story. There's a lot of jargon and insider
intrigue such that I could imagine most people never making past the
typewriter barf of "BLP, AGF, NOR" :)
>>>>
>>>>
>>>>> On Fri, Dec 12, 2014 at 5:26 PM, Dariusz Jemielniak
<darekj(a)alk.edu.pl> wrote:
>>>>> While I agree that the article is overly negative (likely because of
the individual experience), I think it still points to an important problem.
I don't perceive this article as really problematic in terms of image. Maybe
naively, I imagine that people will not stop donating because the community
is not ideal.
>>>>>
>>>>> pundit
>>>>>
>>>>>> On Fri, Dec 12, 2014 at 11:16 PM, Kerry Raymond
<kerry.raymond(a)gmail.com> wrote:
>>>>>> There's a saying that everyone likes to eat sausages but nobody likes
to know how they are made. It is not good to have negative publicity like
that during the annual donation campaign (irrespective of the motivations of
the journalist and/or the rights/wrongs of the issue being reported, neither
of which I intend to debate here). As a donation-funded organisation, public
perception matters a lot.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Kerry
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Jonathan Morgan [mailto:jmorgan@wikimedia.org]
>>>>>> Sent: Saturday, 13 December 2014 6:43 AM
>>>>>> To: Research into Wikimedia content and communities
>>>>>> Cc: Kerry Raymond
>>>>>> Subject: Re: [Wiki-research-l] commentary on Wikipedia's community
behaviour (Aaron gets a quote)
>>>>>>
>>>>>>
>>>>>>
>>>>>> I mostly agree. On one hand, it's always nice to see a detailed
description of how wiki-sausage gets made in a major venue. On the other,
this journalist clearly has a personal axe to grind, and used his bully
pulpit to grind it in public.
>>>>>>
>>>>>>
>>>>>>
>>>>>> - J
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 12, 2014 at 1:39 AM, Federico Leva (Nemo)
<nemowiki(a)gmail.com> wrote:
>>>>>>
>>>>>> 1000th addition to the inconsequential rant genre.
>>>>>>
>>>>>> Nemo
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Wiki-research-l mailing list
>>>>>> Wiki-research-l(a)lists.wikimedia.org
>>>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Jonathan T. Morgan
>>>>>>
>>>>>> Community Research Lead
>>>>>>
>>>>>> Wikimedia Foundation
>>>>>>
>>>>>> User:Jmorgan (WMF)
>>>>>>
>>>>>> jmorgan(a)wikimedia.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Wiki-research-l mailing list
>>>>>> Wiki-research-l(a)lists.wikimedia.org
>>>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> __________________________
>>>>> prof. dr hab. Dariusz Jemielniak
>>>>> kierownik katedry Zarządzania Międzynarodowego
>>>>> i centrum badawczego CROW
>>>>> Akademia Leona Koźmińskiego
>>>>> http://www.crow.alk.edu.pl
>>>>>
>>>>> członek Akademii Młodych Uczonych Polskiej Akademii Nauk
>>>>> członek Komitetu Polityki Naukowej MNiSW
>>>>>
>>>>> Wyszła pierwsza na świecie etnografia Wikipedii "Common Knowledge? An
Ethnography of Wikipedia" (2014, Stanford University Press) mojego autorstwa
http://www.sup.org/book.cgi?id=24010
>>>>>
>>>>> Recenzje
>>>>> Forbes: http://www.forbes.com/fdc/welcome_mjx.shtml
>>>>> Pacific Standard:
http://www.psmag.com/navigation/books-and-culture/killed-wikipedia-93777/
>>>>> Motherboard:
http://motherboard.vice.com/read/an-ethnography-of-wikipedia
>>>>> The Wikipedian:
http://thewikipedian.net/2014/10/10/dariusz-jemielniak-common-knowledge
>>>>>
>>>>> _______________________________________________
>>>>> Wiki-research-l mailing list
>>>>> Wiki-research-l(a)lists.wikimedia.org
>>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>>
>>>>
>>>> _______________________________________________
>>>> Wiki-research-l mailing list
>>>> Wiki-research-l(a)lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>
>>> _______________________________________________
>>> Wiki-research-l mailing list
>>> Wiki-research-l(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>> _______________________________________________
>> Wiki-research-l mailing list
>> Wiki-research-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
> _______________________________________________
> Wiki-research-l mailing list
> Wiki-research-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
--
Sent with my mu4e
_______________________________________________
Wiki-research-l mailing list
Wiki-research-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
--
Oliver Keyes
Research Analyst
Wikimedia Foundation
We are to rank all candidates. Shani has also done great work these last
few years and has supported offline efforts during this time. She is
currently on the board so has excellent experience of what is involved.
On Thu, May 19, 2022 at 05:03 <offline-l-request(a)lists.wikimedia.org> wrote:
> Send Offline-l mailing list submissions to
> offline-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe, please visit
>
> https://lists.wikimedia.org/postorius/lists/offline-l.lists.wikimedia.org/
>
> You can reach the person managing the list at
> offline-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Offline-l digest..."
>
> Today's Topics:
>
> 1. WMF board elections are back (Florence Devouard)
> 2. Re: WMF board elections are back (Stephane Coillet-Matillon)
> 3. Re: WMF board elections are back (Federico Leva (Nemo))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 May 2022 20:22:40 +0200
> From: Florence Devouard <fdevouard(a)gmail.com>
> Subject: [Offline-l] WMF board elections are back
> To: Using Wikimedia projects and MediaWiki offline
> <offline-l(a)lists.wikimedia.org>
> Message-ID: <ba08f8da-8409-c867-916b-b0cb69eb21f5(a)gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Dear all,
>
>
> It is back again the time to select representants for our Wikimedia
> Foundation Board of Trustees.
>
> This year, the process is different from previous year. If you want to
> go look in details, I invite you to read ALL the details on :
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022
>
> However, if you want to get the essence of it... here is what you should
> know...
>
> 1) Two people will be selected to join the board, following a two
> step-process
>
> Step 1: From 1 to 15th of July, all affiliates will vote on the initial
> list of candidates. Only one (1) vote per affiliate. From all votes
> pooled together, a short list of 6 candidates will be sorted
> Step 2 : From 15-29th of August, the community will vote on that short
> list.
>
> In between the two... the community can ask questions to the candidates
>
>
> 2) Currently, 13 people are candidates. You may find details here :
>
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Candida…
> They have provided initial statements.
>
> 3) Our affiliate will vote beginning of July. Sam and I will prepare a
> process so that you may cast your votes. From your propositions, we will
> sort ONE name.
>
>
> 4) I will invite all current candidates to promote themselves, should
> they be interested to, on this mailing list
>
>
>
> Cheers
>
>
> Florence
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 May 2022 09:23:50 +0200
> From: Stephane Coillet-Matillon <stephane(a)kiwix.org>
> Subject: [Offline-l] Re: WMF board elections are back
> To: Using Wikimedia projects and MediaWiki offline
> <offline-l(a)lists.wikimedia.org>
> Message-ID: <72AE417B-7084-4BD2-A19B-5F1F02F458D9(a)kiwix.org>
> Content-Type: multipart/alternative;
> boundary="Apple-Mail=_D36D33C5-676F-4C08-85C3-BF27AD27DCD0"
>
> Hi everyone,
>
> Thanks for this Florence. I’ve gone through the list of candidates and
> there are very fine people (better that than the opposite!).
>
> We at Kiwix, however, would like to single out Kunal Mehta <
> https://meta.wikimedia.org/wiki/User:Legoktm> (legoktm), who has been a
> long-time supporter of Kiwix within the Foundation (I might stand corrected
> but he also single-handedly ensured Debian ports for it and volunteered top
> code). Needless to say (but I am still saying it), Kunal has been getting
> our Kiwix-branded chocolates ever since we started sending them out.
>
> I encourage you to read his bio/user page <
> https://meta.wikimedia.org/wiki/User:Legoktm> - Kunal is not just a
> coder, but has a vision for free knowledge. I am told he left the WMF last
> December, so my take here is that we would have a trustee here that 1.
> Understands the tech 2. Understands the WMF and 3. Understands us (the
> offline crowd). That’s a lot boxes to tick.
>
> My little informative email has turned into a longer-than-expected soapbox
> campaigning, but so be it. If you home chapter is undecided about whom to
> support, I encourage you to forward it to them as well.
>
> Cheers,
> Stephane
>
> > Le 18 mai 2022 à 20:22, Florence Devouard <fdevouard(a)gmail.com> a écrit
> :
> >
> > Dear all,
> >
> >
> > It is back again the time to select representants for our Wikimedia
> Foundation Board of Trustees.
> >
> > This year, the process is different from previous year. If you want to
> go look in details, I invite you to read ALL the details on :
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022
> >
> > However, if you want to get the essence of it... here is what you should
> know...
> >
> > 1) Two people will be selected to join the board, following a two
> step-process
> >
> > Step 1: From 1 to 15th of July, all affiliates will vote on the initial
> list of candidates. Only one (1) vote per affiliate. From all votes pooled
> together, a short list of 6 candidates will be sorted
> > Step 2 : From 15-29th of August, the community will vote on that short
> list.
> >
> > In between the two... the community can ask questions to the candidates
> >
> >
> > 2) Currently, 13 people are candidates. You may find details here :
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_elections/2022/Candida…
> > They have provided initial statements.
> >
> > 3) Our affiliate will vote beginning of July. Sam and I will prepare a
> process so that you may cast your votes. From your propositions, we will
> sort ONE name.
> >
> >
> > 4) I will invite all current candidates to promote themselves, should
> they be interested to, on this mailing list
> >
> >
> >
> > Cheers
> >
> >
> > Florence
> > _______________________________________________
> > Offline-l mailing list -- offline-l(a)lists.wikimedia.org
> > To unsubscribe send an email to offline-l-leave(a)lists.wikimedia.org
>
>
Thanks for your input Alhen!
I understand the biblio's point of view in that teachers should have have a minimum amount of wiki experience before assigning stuff to their students. I have been pushing this to my department and above. For this reason we have been holding lots of training sessions since last summer and just had two last week with the participation 15 or so. This gives teachers a good start in of what Wikipedia is about, but it does not generate a large number of teacher edits right away. One thing we have changed is that teachers must upload an article to complete training, generally a translation. You can see this in the course up right now in the tool https://es.wikipedia.org/wiki/Education_Program:Tec_de_Monterrey,_Campus_Ci…
On the other hand, I finally got admin interested in Wiki enough to back our program (called Wiki Learning), an incredibly important step as it makes teachers take the idea more seriously. So Im trying to balance es.wiki's needs along with the my school's (and the Ed Program's) desire to expand working with Wikipedia among students. While teachers will not be anywhere near as experienced as I am (or as my fellow project leaders Paolaricaurte and Lourdes Epstein), they do understand the very basics and have the support of experienced students working with Wiki in other capacities (servicio social, becarios, etc) to as in a capacity similar to Campus Ambassadors. As project leader for Wiki Learning, I am responsible for monitoring the teachers, as well as training people to eventually take over that capacity at campuses outside my own.
If the biblios decide not to grant the tool, I simply means that I will be creating the classes and depending on what teachers decide (es.wiki or Commons) that can be 40 or more classes. In some ways, it is easier. I can create the classes using systematic names but it will be hell for me for the first week or so. (We never 100% know which classes we have until the first week of the semester, go figure.) Well not quite me alone as Jmvkrecords has already indicated that he will give it to Paolaricaurte.
These are major growing pains and granted, a GOOD (as well as unexpected) problem to have.
Leigh
From: alhen.wiki(a)gmail.com
Date: Tue, 16 Dec 2014 14:22:40 -0400
To: education(a)lists.wikimedia.org
Subject: Re: [Wikimedia Education] denied access to course extension
I participated on such discussion about whether to give course coordinator flag to the teachers.
The general idea is that they will need someone monitoring their work. Eswiki, as many others I guess, has a long history of students and teachers using the wiki without reading the policies. That said, I understand why they want to take the process as slow as possible. Please, don't take it personal.
I recommend you get a biblio(sysop) involved so he can back you up and help you control the whole projecta and edits. I see the main problem here is that many users will come to edit on es.wiki with little or no experience, and the course coordinator will have the same experience of those who are participating for the first time. Feel free to correct me if I am missing anything.
Alhen
@alhen_
alhen at most places.
Coordinator at Wikimedia Bolivia
https://www.fb.com/wikimediabolivia
Thrive, live, and bloom.
On Tue, Dec 16, 2014 at 1:03 PM, Leigh Thelmadatter <osamadre(a)hotmail.com> wrote:
Ive been told that they are placing the same requirements on the course coordinator flag as they do on all others.. a certain amount of online history with es.wiki. I have made the arguments that you suggest Samir and User:Jmvkrecords has said he will discuss it with other admins (bibliotecarios), but he has stated that the community has the final say.
Question: why is this tool separated under the various language projects? First, this limits the monitoring/documenting to a single language (if students do projects in en.wiki and es.wiki, there needs to be two extensions) and who needs the tool is very different from the others. Why dont we have one course extension that can scrape the data from whatever project students are working on?
Date: Tue, 16 Dec 2014 18:41:10 +0200
From: selsharbaty(a)wikimedia.org
To: education(a)lists.wikimedia.org
Subject: Re: [Wikimedia Education] denied access to course extension
Hi Leigh,
To help with your question may I ask you first if there is a local policy for the use of the education extension user rights on the Spanish Wikipedia?
If there is a policy that supports the admin's reply, then unfortunately there will be nothing to do with that.
If the answer is no, then you can reapply on the same page or separately on other adimns talk pages relying on many factors:
1. The ed extension user rights help only with ed program pages and don't give any special rights on the article name space.
2. The use of the ed extension is to help the coordinators and volunteers of the program even if they don't have any edits on Wikipedia.
3. On Wikipedia in other languages, admins don't, usually, apply such requirements on ed user rights. (Please note that the policies of each wiki community may vary from another and they are the only authority on their policies and its application)
I hope this helps with your issue.
Cheers,
Samir Elsharbaty
Communications Intern, Wikipedia Education Program
Wikimedia Foundation
+2.011.200.696.77
selsharbaty(a)wikimedia.org
education.wikimedia.org
On 15 Dec 2014 19:46, "Federico Leva (Nemo)" <nemowiki(a)gmail.com> wrote:
Leigh Thelmadatter, 13/12/2014 03:34:
Basically the answer is no. They have to have editing experience and
show that they at least have the ability to speak Spanish and show they
can be good course coordinators.
Did you try asking some more admins (on their talk page) to chime in? Often such request pages are only watched by a small "specialised" group.
Nemo
_______________________________________________
Education mailing list
Education(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/education
_______________________________________________
Education mailing list
Education(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/education
_______________________________________________
Education mailing list
Education(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/education
_______________________________________________
Education mailing list
Education(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/education
I agree that we should not breaden the scope of the current structured data
project, but we should not ignore this earlier proposal either:
1) We should look at the use cases and requirements that Krinkle & Co analyzed,
and see to what conclusions they came. I'm sure there is something to be learned
there.
2) when working on the media metadata spec, we should avoid the assumption that
the subject of that metadata is a file managed in the FIle namespace. It might
also be the content of a wiki page, or a work not present in the wiki at all. It
will probably not be practical to avoid this assumption all the way, but perhaps
we can keep it to the UI level, so the same code and data structures can be
re-used to describe works managed elsewhere.
-- daniel
Am 26.09.2014 23:53, schrieb Fabrice Florin:
> Thanks, Robla and Nemo!
>
> We will bring up these points when we meet with the wikidata team in a week to
> discuss the Structured Data project (1).
>
> My initial impression is that this would be a significant scope increase for an
> already large project. So for practical reasons, we may not be able to take it
> on until after we have implemented structured data for multimedia files.
>
> That said, it would be important to consider this request before we start
> development on structured data for multimedia files, so we can investigate
> solutions that could make this second phase possible. So we will add this
> discussion to our meeting agenda.
>
> We will update the relevant pages after we’ve had a chance to discuss this as a
> team.
>
> To be continued,
>
>
> Fabrice
>
>
> P.S.: I have also Cc:d Luis and Stephen from our legal team, so they can remain
> part of that discussion as well.
>
>
> (1) https://commons.wikimedia.org/wiki/Commons:Structured_data
>
>
>
> On Sep 26, 2014, at 2:37 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com
> <mailto:nemowiki@gmail.com>> wrote:
>
>> Rob Lanphier, 26/09/2014 22:59:
>>> Thanks for the analysis, Gergo! I was going to split Luis' proposal
>>> into a separate wiki page, but I see Nemo has linked to this page as the
>>> "Canonical page on the topic":
>>> https://www.mediawiki.org/wiki/Files_and_licenses_concept
>>>
>>> Without a deep reading that I'm admittedly just not going to have time
>>> for, it's hard to tell how related the page that Nemo linked to is to
>>> the concepts that Luis is trying to capture.
>>
>> The gist of that idea is: associate actual copyright metadata to content; use
>> ContentHandler for certain blobs of information. Krinkle and others were the
>> main authors of that page and the idea was never worked on, but it can be
>> extended in many ways... except that it's a bit pointless to expand it further
>> when even a smaller scope is hard to work on.
>>
>> Other than files, the two classic pain points about copyright metadata are
>> a) display of page authors https://bugzilla.wikimedia.org/show_bug.cgi?id=2994#c14
>> b) metadata about works (e.g. books) stored across pages
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=15071
>>
>>> Could someone (Nemo?
>>> Luis?) merge Luis's requirements into the "canonical page" to Luis'
>>> satisfaction, so I can delete most of the information from our backlog?
>>> I'll keep the item on the MW Core backlog, since I don't know where else
>>> to put it, but it's probably going to be relatively low priority for
>>> that team.
>>>
>>> Multimedia team and Wikidata team, could you make sure you're
>>> considering the requirements that Luis brought up as you build your
>>> solution? Even if you decide to punt on some of the things that aren't
>>> strictly necessary for files, it's still good to make sure you don't
>>> paint us in a corner when if/when we do try to do something more
>>> sophisticated for articles.
>>
>> A solution based on an external wiki (Wikidata) as for files... may work for
>> (b) but won't for (a). That said, the original idea for files could be reused
>> for both (a) and (b).
>>
>>>
>>> One thing I'll note, though, before we get too complacent in thinking
>>> that files are somehow simpler than articles, we should consider these
>>> relatively common scenarios:
>>> * Group photo with potentially different per-person personality rights
>>> * PDF of a slide deck with many images
>>> * PDF of a Wikipedia article :-)
>>
>> The last point being bug 2994 (and friends).
>>
>> Nemo
>>
>> _______________________________________________
>> Multimedia mailing list
>> Multimedia(a)lists.wikimedia.org <mailto:Multimedia@lists.wikimedia.org>
>> https://lists.wikimedia.org/mailman/listinfo/multimedia
>
> _______________________________
>
> On Sep 26, 2014, at 1:59 PM, Rob Lanphier <robla(a)wikimedia.org
> <mailto:robla@wikimedia.org>> wrote:
>
>> (+cc Nemo and Wikidata-tech)
>>
>> On Fri, Sep 26, 2014 at 5:33 AM, Gergo Tisza <gtisza(a)wikimedia.org
>> <mailto:gtisza@wikimedia.org>> wrote:
>>
>> On Fri, Sep 26, 2014 at 2:49 AM, Rob Lanphier <robla(a)wikimedia.org
>> <mailto:robla@wikimedia.org>> wrote:
>>
>> There's an item that's Luis Villa added to the MW Core backlog that
>> I'd like to move to the Multimedia backlog:
>> https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Backlog#Struct…
>>
>> I'm assuming everything that he describes fits nicely into what is
>> planned for Structured Data. Assuming that's true, should I just
>> copy/paste into a new card in Mingle, or a new page on mw.org
>> <http://mw.org/> or what?
>>
>>
>> This seems to be about article text, or mainly about article text
>> (articles imported from other wikis and so on).
>>
>> The plan for the structured data project is to create Wikidata properties
>> for legalese, install Wikibase on Commons (and possibly other wikis which
>> have local images), make that Wikibase use Wikidata properties (and
>> sometimes Wikidata items as values), create a new entity type called
>> mediainfo (which is like a Wikibase item, but associated with a file), and
>> add legal information to the mediainfo entries.
>>
>> Part of that (the Wikidata properties) could be reused for articles and
>> other non-file content - the source, license etc. properties are generic
>> enough. However, if we want to use this structure to attribute files, we
>> would either have to make mediainfo into some more generic thing that can
>> be attached to any wiki page, or abuse the langlink/badge feature to serve
>> a similar purpose. That is a major course correction; if we want to do
>> something like that, that should be discussed (with the involvement of the
>> Wikidata team) as soon as possible.
>>
>>
>> Thanks for the analysis, Gergo! I was going to split Luis' proposal into a
>> separate wiki page, but I see Nemo has linked to this page as the "Canonical
>> page on the topic":
>> https://www.mediawiki.org/wiki/Files_and_licenses_concept
>>
>> Without a deep reading that I'm admittedly just not going to have time for,
>> it's hard to tell how related the page that Nemo linked to is to the concepts
>> that Luis is trying to capture. Could someone (Nemo? Luis?) merge Luis's
>> requirements into the "canonical page" to Luis' satisfaction, so I can delete
>> most of the information from our backlog? I'll keep the item on the MW Core
>> backlog, since I don't know where else to put it, but it's probably going to
>> be relatively low priority for that team.
>>
>> Multimedia team and Wikidata team, could you make sure you're considering the
>> requirements that Luis brought up as you build your solution? Even if you
>> decide to punt on some of the things that aren't strictly necessary for files,
>> it's still good to make sure you don't paint us in a corner when if/when we do
>> try to do something more sophisticated for articles.
>>
>> One thing I'll note, though, before we get too complacent in thinking that
>> files are somehow simpler than articles, we should consider these relatively
>> common scenarios:
>> * Group photo with potentially different per-person personality rights
>> * PDF of a slide deck with many images
>> * PDF of a Wikipedia article :-)
>>
>> Rob
>
>
>
>
>
> _______________________________________________
> Wikidata-tech mailing list
> Wikidata-tech(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
I agree that we should not breaden the scope of the current structured data
project, but we should not ignore this earlier proposal either:
1) We should look at the use cases and requirements that Krinkle & Co analyzed,
and see to what conclusions they came. I'm sure there is something to be learned
there.
2) when working on the media metadata spec, we should avoid the assumption that
the subject of that metadata is a file managed in the FIle namespace. It might
also be the content of a wiki page, or a work not present in the wiki at all. It
will probably not be practical to avoid this assumption all the way, but perhaps
we can keep it to the UI level, so the same code and data structures can be
re-used to describe works managed elsewhere.
-- daniel
Am 26.09.2014 23:53, schrieb Fabrice Florin:
> Thanks, Robla and Nemo!
>
> We will bring up these points when we meet with the wikidata team in a week to
> discuss the Structured Data project (1).
>
> My initial impression is that this would be a significant scope increase for an
> already large project. So for practical reasons, we may not be able to take it
> on until after we have implemented structured data for multimedia files.
>
> That said, it would be important to consider this request before we start
> development on structured data for multimedia files, so we can investigate
> solutions that could make this second phase possible. So we will add this
> discussion to our meeting agenda.
>
> We will update the relevant pages after we’ve had a chance to discuss this as a
> team.
>
> To be continued,
>
>
> Fabrice
>
>
> P.S.: I have also Cc:d Luis and Stephen from our legal team, so they can remain
> part of that discussion as well.
>
>
> (1) https://commons.wikimedia.org/wiki/Commons:Structured_data
>
>
>
> On Sep 26, 2014, at 2:37 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com
> <mailto:nemowiki@gmail.com>> wrote:
>
>> Rob Lanphier, 26/09/2014 22:59:
>>> Thanks for the analysis, Gergo! I was going to split Luis' proposal
>>> into a separate wiki page, but I see Nemo has linked to this page as the
>>> "Canonical page on the topic":
>>> https://www.mediawiki.org/wiki/Files_and_licenses_concept
>>>
>>> Without a deep reading that I'm admittedly just not going to have time
>>> for, it's hard to tell how related the page that Nemo linked to is to
>>> the concepts that Luis is trying to capture.
>>
>> The gist of that idea is: associate actual copyright metadata to content; use
>> ContentHandler for certain blobs of information. Krinkle and others were the
>> main authors of that page and the idea was never worked on, but it can be
>> extended in many ways... except that it's a bit pointless to expand it further
>> when even a smaller scope is hard to work on.
>>
>> Other than files, the two classic pain points about copyright metadata are
>> a) display of page authors https://bugzilla.wikimedia.org/show_bug.cgi?id=2994#c14
>> b) metadata about works (e.g. books) stored across pages
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=15071
>>
>>> Could someone (Nemo?
>>> Luis?) merge Luis's requirements into the "canonical page" to Luis'
>>> satisfaction, so I can delete most of the information from our backlog?
>>> I'll keep the item on the MW Core backlog, since I don't know where else
>>> to put it, but it's probably going to be relatively low priority for
>>> that team.
>>>
>>> Multimedia team and Wikidata team, could you make sure you're
>>> considering the requirements that Luis brought up as you build your
>>> solution? Even if you decide to punt on some of the things that aren't
>>> strictly necessary for files, it's still good to make sure you don't
>>> paint us in a corner when if/when we do try to do something more
>>> sophisticated for articles.
>>
>> A solution based on an external wiki (Wikidata) as for files... may work for
>> (b) but won't for (a). That said, the original idea for files could be reused
>> for both (a) and (b).
>>
>>>
>>> One thing I'll note, though, before we get too complacent in thinking
>>> that files are somehow simpler than articles, we should consider these
>>> relatively common scenarios:
>>> * Group photo with potentially different per-person personality rights
>>> * PDF of a slide deck with many images
>>> * PDF of a Wikipedia article :-)
>>
>> The last point being bug 2994 (and friends).
>>
>> Nemo
>>
>> _______________________________________________
>> Multimedia mailing list
>> Multimedia(a)lists.wikimedia.org <mailto:Multimedia@lists.wikimedia.org>
>> https://lists.wikimedia.org/mailman/listinfo/multimedia
>
> _______________________________
>
> On Sep 26, 2014, at 1:59 PM, Rob Lanphier <robla(a)wikimedia.org
> <mailto:robla@wikimedia.org>> wrote:
>
>> (+cc Nemo and Wikidata-tech)
>>
>> On Fri, Sep 26, 2014 at 5:33 AM, Gergo Tisza <gtisza(a)wikimedia.org
>> <mailto:gtisza@wikimedia.org>> wrote:
>>
>> On Fri, Sep 26, 2014 at 2:49 AM, Rob Lanphier <robla(a)wikimedia.org
>> <mailto:robla@wikimedia.org>> wrote:
>>
>> There's an item that's Luis Villa added to the MW Core backlog that
>> I'd like to move to the Multimedia backlog:
>> https://www.mediawiki.org/wiki/Wikimedia_MediaWiki_Core_Team/Backlog#Struct…
>>
>> I'm assuming everything that he describes fits nicely into what is
>> planned for Structured Data. Assuming that's true, should I just
>> copy/paste into a new card in Mingle, or a new page on mw.org
>> <http://mw.org/> or what?
>>
>>
>> This seems to be about article text, or mainly about article text
>> (articles imported from other wikis and so on).
>>
>> The plan for the structured data project is to create Wikidata properties
>> for legalese, install Wikibase on Commons (and possibly other wikis which
>> have local images), make that Wikibase use Wikidata properties (and
>> sometimes Wikidata items as values), create a new entity type called
>> mediainfo (which is like a Wikibase item, but associated with a file), and
>> add legal information to the mediainfo entries.
>>
>> Part of that (the Wikidata properties) could be reused for articles and
>> other non-file content - the source, license etc. properties are generic
>> enough. However, if we want to use this structure to attribute files, we
>> would either have to make mediainfo into some more generic thing that can
>> be attached to any wiki page, or abuse the langlink/badge feature to serve
>> a similar purpose. That is a major course correction; if we want to do
>> something like that, that should be discussed (with the involvement of the
>> Wikidata team) as soon as possible.
>>
>>
>> Thanks for the analysis, Gergo! I was going to split Luis' proposal into a
>> separate wiki page, but I see Nemo has linked to this page as the "Canonical
>> page on the topic":
>> https://www.mediawiki.org/wiki/Files_and_licenses_concept
>>
>> Without a deep reading that I'm admittedly just not going to have time for,
>> it's hard to tell how related the page that Nemo linked to is to the concepts
>> that Luis is trying to capture. Could someone (Nemo? Luis?) merge Luis's
>> requirements into the "canonical page" to Luis' satisfaction, so I can delete
>> most of the information from our backlog? I'll keep the item on the MW Core
>> backlog, since I don't know where else to put it, but it's probably going to
>> be relatively low priority for that team.
>>
>> Multimedia team and Wikidata team, could you make sure you're considering the
>> requirements that Luis brought up as you build your solution? Even if you
>> decide to punt on some of the things that aren't strictly necessary for files,
>> it's still good to make sure you don't paint us in a corner when if/when we do
>> try to do something more sophisticated for articles.
>>
>> One thing I'll note, though, before we get too complacent in thinking that
>> files are somehow simpler than articles, we should consider these relatively
>> common scenarios:
>> * Group photo with potentially different per-person personality rights
>> * PDF of a slide deck with many images
>> * PDF of a Wikipedia article :-)
>>
>> Rob
>
>
>
>
>
> _______________________________________________
> Wikidata-tech mailing list
> Wikidata-tech(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Thanks everyone who’s responded with such thoughtful comments. I will look further at the "The Pipeline of Online Participation Inequalities: The Case of Wikipedia Editing” paper that Isaac referenced, which seems interesting.
I think the plans that Rebecca Maung described for the 2021 Community Insights survey are bang on. If we want to help answer the question of whether particular races or ethnicities are under-represented, it makes sense to gather the data in a form that can be compared to the general population in a country. E.g. I’d like to have data that say, “X percent of U.S.-based Wikipedia editors identify as Black, whereas according to the latest census, X percent of the U.S. general population identifies as Black.” This is more interesting than data that say, “X percent of all Wikipedia editors in the world identify as Black”.
Another thought is that diversity within each Wikimedia project, not just diversity across all projects, is something people value - especially in the big projects like the English Wikipedia. So it would be helpful to see racial/ethnic identity, country of residence, and gender percentages for each project.
And another thought is that while some people will be offended if you ask them about their race, other people will be offended if you put out a survey that’s intended to measure diversity and doesn’t ask anyone about their race.
Cheers,
Su-Laine
> On Sep 21, 2020, at 1:39 PM, L.Gelauff <lgelauff(a)gmail.com> wrote:
>
> Ah, you're assuming some automated country-detection, rather than
> self-identify. I see.
>
> Lodewijk
>
> On Mon, Sep 21, 2020 at 12:59 PM Stuart A. Yeates <syeates(a)gmail.com> wrote:
>
>> Everyone from China and Saudi Arabia (two countries which
>> systematically block wikipedia) are likely to be taking technical
>> measures to disguise their country.
>>
>> That's a lot of people, but I'm not sure how many editors that is.
>>
>> cheers
>> stuart
>>
>> --
>> ...let us be heard from red core to black sky
>>
>> On Tue, 22 Sep 2020 at 07:01, L.Gelauff <lgelauff(a)gmail.com> wrote:
>>>
>>> Just thinking out loud.. are we looking for actual race/ethnicity/etc
>> data,
>>> or is it rather that we're looking for whether someone belongs to an
>> under
>>> represented group in their specific situation? If it is the latter, there
>>> may be ways to phrase the question without asking for actual
>> demographics.
>>>
>>> Stuart; do you have any indication for how large a portion that group
>> is? I
>>> am aware of public pages being potentially disguised as such, but wasn't
>>> familiar with stories about this happening in a survey context (although
>> it
>>> does not sound implausible).
>>>
>>> Best,
>>>
>>> Lodewijk
>>>
>>> On Mon, Sep 21, 2020 at 11:39 AM Stuart A. Yeates <syeates(a)gmail.com>
>> wrote:
>>>
>>>> Another point not touched on by other commenters is that even if ideal
>>>> race / ethnicity question(s were developed for every country in the
>>>> world, users from some countries commonly disguise their country due
>>>> to censorship in that country, so we there would be a whole class of
>>>> systematic errors where we asked users the wrong country's
>>>> question(s).
>>>>
>>>> cheers
>>>> stuart
>>>> --
>>>> ...let us be heard from red core to black sky
>>>>
>>>> On Tue, 22 Sep 2020 at 05:00, Isaac Johnson <isaac(a)wikimedia.org>
>> wrote:
>>>>>
>>>>> Adding another point from Rebecca Maung who helps run the annual
>>>> Community
>>>>> Insights surveys <https://meta.wikimedia.org/wiki/Community_Insights
>>>
>>>> but
>>>>> isn't currently on this listserv so couldn't respond directly:
>>>>>
>>>>> This year's Community Insights survey (reporting scheduled for early
>>>> 2021)
>>>>> is the first that will ask Wikimedia contributors about race and
>>>>> ethnicity-- but only in certain geographies. Due to all the excellent
>>>>> points made in this thread, we have never asked a race or ethnicity
>>>>> question, but this year we decided to start asking locally relevant
>>>>> questions where we could. This year only editors in the US and
>> Britain
>>>> will
>>>>> see a question about race or ethnicity, tailored to their local
>> contexts.
>>>>> In the coming years, we will expand the countries and geographies
>> that
>>>> see
>>>>> a question like this, prioritizing places where there is a larger
>> editor
>>>>> presence and local laws and norms allow such questions. We have not
>> yet
>>>>> discussed asking about religion in the Community Insights survey.
>>>>>
>>>>> On Mon, Sep 21, 2020 at 9:20 AM Isaac Johnson <isaac(a)wikimedia.org>
>>>> wrote:
>>>>>
>>>>>> As pointed out by others, the highly contextualized nature of
>> religion,
>>>>>> race, and ethnicity between countries makes it very difficult to
>>>> impossible
>>>>>> to craft questions that are not overly reductive but still somewhat
>>>>>> universal. Despite this challenge, understanding diversity in a way
>>>> that
>>>>>> captures these aspects is obviously quite important as they often
>>>> figure
>>>>>> very strongly into power and representation within history, media,
>> etc.
>>>>>>
>>>>>> In general, if you're looking for large-scale surveys of editors,
>> the
>>>> Meta
>>>>>> category (Category:Editor surveys
>>>>>> <https://meta.wikimedia.org/wiki/Category:Editor_surveys>) is
>> actually
>>>>>> quite complete (same for readers
>>>>>> <https://meta.wikimedia.org/wiki/Category:Reader_surveys>). In
>>>>>> particular, I wrote what little I could find about these topics
>> into
>>>> this
>>>>>> section of our recently published knowledge gaps taxonomy:
>>>>>> https://arxiv.org/pdf/2008.12314.pdf#subsubsection.3.1.7
>>>>>>
>>>>>> The April 2011 editor survey took the approach of just asking
>> people
>>>> how
>>>>>> they felt they were different from others in the community -- this
>>>> specific
>>>>>> question is not one that I would advocate today (asking people to
>>>> identify
>>>>>> all the ways in which they may be "outsiders" is not particularly
>>>>>> welcoming) but this is also probably the style of approach (asking
>>>> people
>>>>>> how well they feel represented within Wikipedia content or editor
>>>>>> community) that you'd have to take to get information on ethnicity
>> /
>>>> race /
>>>>>> religion without writing country-specific questions:
>>>>>>
>>>>
>> https://upload.wikimedia.org/wikipedia/commons/7/76/Editor_Survey_Report_-_…
>>>>>>
>>>>>> On Mon, Sep 21, 2020 at 6:12 AM Stuart A. Yeates <
>> syeates(a)gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The ethnicity / race question is an incredibly hard question to
>>>>>>> compose in an internationalised way.
>>>>>>>
>>>>>>> Pretty much every country in the world uses different terms and
>> there
>>>>>>> are some very confusing cases where the same term is used in
>> different
>>>>>>> countries to mean very different things (e,g, "Asian" in UK
>> English vs
>>>>>>> New Zealand English). This is derived from varying legal
>> definitions
>>>>>>> (for example blood quantum vs one-drop laws); the history of
>>>>>>> colonisation and waves of immigration to the country; along with
>>>>>>> cultural differences.
>>>>>>>
>>>>>>> cheers
>>>>>>> stuart
>>>>>>> --
>>>>>>> ...let us be heard from red core to black sky
>>>>>>>
>>>>>>> On Mon, 21 Sep 2020 at 21:55, Federico Leva (Nemo) <
>>>> nemowiki(a)gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Su-Laine Brodsky, 21/09/20 08:19:
>>>>>>>>> I’m wondering if any large-scale surveys have been done that
>> ask
>>>>>>> Wikipedia editors about their race, ethnicity, or religion?
>>>>>>>>
>>>>>>>> What international standards exist to phrase such questions?
>>>>>>>> Denominations commonly used in surveys in one country may be
>>>> considered
>>>>>>>> horrific or even illegal in others.
>>>>>>>>
>>>>>>>> I see OECD considers it a difficult problem too:
>>>>>>>>
>>>>>>>> ----
>>>>>>>>
>>>>>>>> 76. Current NSOs collection practices cluster around three
>> broad
>>>>>>>> categories: 1) all OECD countries collect information on some
>>>> diversity
>>>>>>>> proxies such as country of birth (36 OECD members); 2) a small
>>>> majority,
>>>>>>>> mostly Eastern European countries, the United Kingdom and
>> Ireland,
>>>>>>>> gather additional information on race and ethnicity (16 OECD
>>>> members);
>>>>>>>> and 3) only a handful of countries in the Americas and Oceania
>>>> collect
>>>>>>>> data on indigenous identity (6 OECD members). Diversity
>> statistics
>>>> are
>>>>>>>> collected from the perspective of either enumerating the size
>> of the
>>>>>>>> relevant populations (typically in the census) or of comparing
>>>>>>>> well-being outcomes across different population groups.
>>>>>>>>
>>>>>>>> 77. While privacy and human rights legislation sometimes
>> prevents
>>>> or
>>>>>>>> discourages the routine collection of diversity data, the need
>> to
>>>>>>>> improve data availability and quality is being recognised in
>> most
>>>>>>>> countries. Many countries are piloting the addition of new
>> ethnic
>>>>>>>> response options to more accurately reflect the make-up of their
>>>>>>>> societies (e.g. Ireland, the United States), while Belgium is
>>>>>>>> considering allowing collection of race and ethnicity data
>> within
>>>> the
>>>>>>>> restrictions imposed by the national legal framework. Within the
>>>>>>>> European Statistical System, the inclusion of more detailed
>>>> migration
>>>>>>>> information is also being considered: The Framework Regulation
>> for
>>>>>>>> Production of European Statistics on Persons and Households
>> European
>>>>>>>> foresees the incorporation of questions on the country of birth
>> of
>>>> the
>>>>>>>> respondent’s parents in the Labour Force Surveys (from 2020),
>> the
>>>>>>>> European Health Interview Survey, the European Union Statistics
>> on
>>>>>>>> Income and Living Conditions, the Household Budget Surveys and
>> the
>>>>>>>> Community surveys on ICT usage in households and by
>> individuals. The
>>>>>>>> European Union Agency for Fundamental Rights is pursuing its
>> Roma
>>>> and
>>>>>>>> Travellers Survey to collect comparable data in six selected
>> Member
>>>>>>>> States in 2018 (FRA, 2018[77]).
>>>>>>>>
>>>>>>>> ----
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>> https://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=SDD/D…
>>>>>>>>
>>>>>>>> Federico
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Wiki-research-l mailing list
>>>>>>>> Wiki-research-l(a)lists.wikimedia.org
>>>>>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Wiki-research-l mailing list
>>>>>>> Wiki-research-l(a)lists.wikimedia.org
>>>>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Isaac Johnson (he/him/his) -- Research Scientist -- Wikimedia
>>>> Foundation
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Isaac Johnson (he/him/his) -- Research Scientist -- Wikimedia
>> Foundation
>>>>> _______________________________________________
>>>>> Wiki-research-l mailing list
>>>>> Wiki-research-l(a)lists.wikimedia.org
>>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>>
>>>> _______________________________________________
>>>> Wiki-research-l mailing list
>>>> Wiki-research-l(a)lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>>>
>>> _______________________________________________
>>> Wiki-research-l mailing list
>>> Wiki-research-l(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>>
> _______________________________________________
> Wiki-research-l mailing list
> Wiki-research-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Wikimedia news/numero 20/en
W i K i M e D i A N e W s no. 20 - October 2nd, 2008
Original at: http://www.wikimedia.it/index.php/Wikimedia_news/numero_20/en
Official monthly bulletin from Wikimedia Italia Association.
Table of contents:
* 1 Editorial
* 2 What happened last month
* 3 What will happen next month
* 4 News from our projects
o 4.1 News from Italian WMF projects
o 4.2 News from W@H
* 5 News from Wikimedia Italia
o 5.1 New Project
o 5.2 News from Biblioteca
* 6 Featured Wikimedian/Picture of the month
== Editorial==
A new board, new members and new ideas... this seems to be the output
from the meeting in Caserta, which marks out the activity of our
association during last month. When you read this issue of wikimedia
news you'll notice how ideas, new proposals, and committments of our
association are today various more than ever, so that they need not
only care from the board but also and above that the whole WMI takes
active part in them.
I wish a happy social year to every member and to the board, and I
hope that it will bring growth and development to our Wikimedia
Italia.
Senpai
==What happened last month==
* September 6th, 2008 - at CEFORS, in Marcianise (CE), we held the
Annual Meeting of Wikimedia Italia Association. Its agenda:
1. Report from the Board about the State of the Association
2. Changes to the Regulations of the Association
3. Ratification of the Board Deliberations
4. Approval of the Final Balance for 1H2008
5. Renew of Social Offices
6. Discussion about policies and activities of the Association.
Wiki@Home staff made a WMI report (in Italian) for the event, and
an interview (in Italian) to the new appointed Board.
* September 13th and 14th: we attended the Arezzo Copyleft
Festival. Here there is a short report by Senpai:
The Copyleft Festival in Arezzo has been a really good place to
make contact with the world in favour of the free spread of knowledge.
We have a notable talk with the staff of Schiaffo Edizioni, who will
probably add some of their short stories in Biblioteca. Also notable
was a talk with the organization, which led to the possibility that
next year WMI will take part to Italia Wave (one of the most important
music festivals in Italy). Out presence wouold be important especially
since we are broadening our scope to include music.
We also met the authors of Don_Zauker, an Italian comic strip, who
agreed to look at the articles about them in it.wiki and who gave us
an illustration for the comic in cc-by-sa.
As for participation... well... we had continuing rain, with very
few glimpses of sun. It was however nice to talk with many users of
it.wiki, who asked us a lot of questions and bought some gadget.
From an economic point of view, taking into account the really bad
weather, the result was rather satisfactory.
* September 20th, Schio (VI): we attended "Software Freedom Day"
at the Piazza Telematica di Schio with two talks: "Wikipedia e i
contenuti liberi" (Wikipedia and free contents) and "Wikimedia Commons
e i 500 anni di Palladio" (Wikimedia Commons and Palladio's 500th
Anniversary).
== What will happen next month==
* October 18th, Milano: we will attend European Humanist Forum. We
will have a stall and we will join the panel Digital Technologies to
enslave us or at the service of humanity?. We should also be part of
the working group "Digital Technology".
* October 23th-26th, Firenze: We will attend Festival della
Creatività]. This year we will have a stand in a nice position, at the
entrance of the main pavillon. Moreover wikinews and the blog of the
festival will collaborate. All members of WMI, and especially those
involved in wikinews, are urged to give a hand, since this is a really
big event (last years there were 350.000 visitors in 4 days), so that
we will need a lot of help.
* October 25th: As usual, we will attend Linux Day in several
Italian cities; who would like to represent the Association at a Linux
Day near home should leave his/her name in the relevant page in
wikipedia, asking also for promotional material when possible.
== News from our projects ==
=== News from Italian WMF projects===
* Wikibooks: More than 60% of modules is classified according to
Development stages. More than 3,600 modules are present.
* Wikinotizie: Reached 6,200 articles.
* Wikipedia: Festival della qualità: after the Festival for
rewriting sentences using "purtroppo" ended, now we have Festival for
cleaning RevertBot.
* Wikiquote: Gacio quit from sysop. Verbal and direct sources are
now deprecated, as per the new guidelines.[1] [2] [3]
* Wikisource: OrbiliusMagister has been elected bureucrat.
* Wikiversità: Nick1915 quit from sysop. Reached 5,800 total pages.
* Wikizionario: After voting, Frieda, .mau., Snowdog, The Doc have
been revoked sysop status. Reached 95,000 headwords.
=== News from W@H===
During the meeting in Caserta, a report for the last season of
interviews has been shown. Torsolo won the Wiki@Home Prize 2007/08
(see article (in Italian) on Wikinotizie). An interview to the
mathematician Piergiorgio Odifreddi is in the works; who wants to
cooperate may access the relevant page.
== News from Wikimedia Italia==
* Our Association has a new Board, which includes:
Frieda Brioschi, president
Luca Sileni, vice-president and secretary
Marco Chiesa, board member (and attached to international relationship)
Maurizio Codogno, board member
Federico Leva, board member and treasurer
=== New Project ===
We just started a new project under the umbrella of Wikimedia Italia:
Musica. Its goal is to collect songs, lyrics and scores released under
a free license. Musica will be officially launched at the end of
October at Faenza, during M.E.I. 2008. Before that date, all members
are invited to give their contribution to let this new idea start
well.
=== News from Biblioteca===
After a quick poll we decided to split Biblioteca in two sections, one
for texts which cannot be put on wikisource because of differences in
copyright laws between Italy and U.S., and another for recent texts
released under a Creative Commons license. Now we are discussing al
the project's Village Pump how to put in practice this split.
[modifica] Featured Wikimedian/Picture of the month
The picture of the monty is of course from the meeting in Caserta
....ok, maybe it's time to start working?
....ok, maybe it's time to start working?
==Editorial staff:==
* Luca Sileni;
* Frieda Brioschi;
* Marco Chemello;
* Nemo (section "News from our projects")
* Aubrey (section "News from Biblioteca")
* DracoRoboter and Elitre (section "News from W@H")
To contact the staff, write at: redazione(a)wikimedia.it or directly to
the editor:
* Luca Sileni - wikisenpai(a)gmail.com
* Frieda Brioschi - ubifrieda(a)gmail.com
Notice. This newsletter is exclusively intended for information about
Wikimedia Italia, both to the members and to the general public; as
per Art. 1, Comma 2, Legge 7 marzo 2001 no. 62, it is not an editorial
product
Hello rubin16,
We are not running fundraising in Russia at this time, but I want to assure
you that this was not a decision motivated by politics.
We take compliance with appropriate laws very seriously in everything we
do. Out of an abundance of caution, we're not fundraising in Russia right
now.
Of course, the fact that we are not fundraising in Russia does and will not
have any impact at all on how the WMF continues to support the Russian
language Wikipedia, its sister projects, and the Russian Wikimedian
community.
Thank you,
Lisa Gruwell
On Wed, Nov 12, 2014 at 7:44 PM, rubin.happy <rubin.happy(a)gmail.com> wrote:
> There were no recent changes in sanctions and I don't understand why this
> turn off in donations happened just now.
>
> Ideas about SWIFT kick out are not relevant here, as it was just a
> discussion some months ago but no such action happened.
>
> Furthermore, the sanctions were placed on particular companies and
> individuals, there were no prohibitions against all financial relations.
> So, I could understand if donations weren't accepted when they were sent
> via a couple of banks under sanctions, but I want to repeat that there is,
> for example, no prohibition to receive money from Russians.
>
> rubin16
> 13 нояб. 2014 г. 4:01 пользователь "David Gerard" <dgerard(a)gmail.com>
> написал:
>
> > I'm presuming this is sanctions against Russia kicking in; all sorts
> > of business has been stopped dead in its tracks, not just charity
> > donations. There's even serious moves to kick Russia out of the SWIFT
> > network:
> >
> http://www.businessweek.com/articles/2014-09-04/ultimate-sanction-barring-r…
> > It strikes me as quite unlikely that there's anything at all WMF can
> > actually do about this. Possibly it could have been handled better,
> > but that won't change the fact.
> >
> > On 13 November 2014 00:12, Craig Franklin <cfranklin(a)halonetwork.net>
> > wrote:
> > > I'm sure that you're correct here Joseph, but this is another example I
> > > think where the Foundation should have notified the relevant chapter
> > > *before* taking the action, so that they would be ready when the
> > questions
> > > started rolling in.
> > >
> > > Unfortunately, I think we're getting back to the bad old days of
> chapter
> > > and user group press contacts being the last people to find out about
> > > potentially controversial issues like this.
> > >
> > > Regards,
> > > Craig Franklin
> > > (personal view only)
> > >
> > >
> > > On 13 November 2014 10:07, Joseph Seddon <josephseddon(a)gmail.com>
> wrote:
> > >
> > >> I would hate to preclude any answer from the foundation. However the
> > laws
> > >> that govern the foundation are that of the US. Given the previous and
> > >> renewed ongoing palaver with Ukraine and the presence of economic
> > sanctions
> > >> and the increasing likelihood of on top of what is already present, I
> > >> imagine this related to that.
> > >>
> > >> Im not sure of what legal risks accepting such donations would expose
> > the
> > >> foundation to. However such precautions have been made in the past
> > relating
> > >> to unrest.
> > >>
> > >> Its no slight on the country or its individuals, just a precautionary
> > >> measure.
> > >>
> > >> Seddon
> > >> On 12 Nov 2014 19:48, "Federico Leva (Nemo)" <nemowiki(a)gmail.com>
> > wrote:
> > >>
> > >>> rubin.happy, 12/11/2014 18:48:
> > >>>
> > >>>> We received some alerts from our users that donations are now
> blocked
> > >>>> when user is from Russia:
> > >>>>
> > http://habrastorage.org/files/31b/b1f/ec9/31bb1fec9b9e45abb6ac4babcc2371
> > >>>> 84.png
> > >>>>
> > >>>
> > >>> Thanks for the information. Everyone can see the same warning by
> > clicking
> > >>> the "Russia" link in
> https://wikimediafoundation.org/wiki/Ways_to_Give
> > >>> Through what channels are donations blocked? Did anyone try sending a
> > >>> wire to the EU (SEPA) account (IBAN GB54CHAS60924241034640), or a
> > PayPal
> > >>> donation?
> > >>>
> > >>> Nemo
> > >>>
> > >>> P.s.: ROTFLOL "Please email donate(a)wikimedia.org for more
> information
> > on
> > >>> how to make a bank transfer to the Wikimedia Foundation." In case
> > someone
> > >>> forgets there is an ocean between Europe and USA.
> > >>>
> > >>> _______________________________________________
> > >>> Fundraiser mailing list
> > >>> Fundraiser(a)lists.wikimedia.org
> > >>> https://lists.wikimedia.org/mailman/listinfo/fundraiser
> > >>>
> > >>
> > >> _______________________________________________
> > >> Fundraiser mailing list
> > >> Fundraiser(a)lists.wikimedia.org
> > >> https://lists.wikimedia.org/mailman/listinfo/fundraiser
> > >>
> > >>
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l(a)lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>