Re: [Wikimedia-l] Treatment of newbies with mild CoI

2020-02-27 Thread Martijn Hoekstra
As a quick/rough data point  I don't frequently edit wikipedia anymore, and
when I do I never log in.

About 2/3 edits no further interactions happen. About 10% gets reverted,
about 10% of the time I get a warning and the last 10% I get a welcome
template.



On Thu, Feb 27, 2020, 15:52 Marshall Miller 
wrote:

> Thanks for mentioning the WMF Growth team [1], Pine.  This is a really
> interesting thread that has touched on much of what the team has been
> working on alongside the Czech, Korean, Arabic, and Vietnamese Wikipedia
> communities (and with the advice of people from many different communities
> along the way).
>
> We've tried to base our approach in research on newcomers, which taught us
> that newcomers face three main types of challenges: technical, conceptual,
> and cultural [2].  For instance, the research tells us that the rules of
> the wiki are hard to learn, and that a negative first interaction can cause
> a newcomer to leave the wiki and not return -- but that a positive
> interaction, such as getting advice from a friendly editor, can cause them
> to stay.
>
> Over the last year and a half, we have experimented on mid-size Wikipedias
> with features that promote good communication between new and experienced
> users [3], that help newcomers teach themselves [4], and that give
> newcomers easy tasks to do [5].  The goal is to build an experience for
> newcomers that helps them get on a positive track in their first days on
> the wiki, and want to stick around to join their communities.  It's
> possible that what we've learned and built so far will apply differently to
> the largest Wikipedias.
>
> I hope that anyone who is interested in newcomers can tell us about their
> own experiences and ideas on our team's discussion page [6], or on the
> discussion pages of any of our projects.  It's very important to us that
> the things we build fit in with how communities work today.  Over the next
> year, we're planning to expand the Growth features to more wikis, so we
> definitely want to talk to people who think the features might be a good
> fit for their wikis.
>
> To keep informed about the Growth team, please subscribe to our newsletter
> [7].
>
> [1] https://www.mediawiki.org/wiki/Growth
> [2] https://www.mediawiki.org/wiki/New_Editor_Experiences
> [3]
>
> https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Newcomer_homepage#Mentorship_module
> [4] https://www.mediawiki.org/wiki/Growth/Focus_on_help_desk
> [5]
> https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Newcomer_tasks
> [6] https://www.mediawiki.org/wiki/Talk:Growth
> [7] https://www.mediawiki.org/wiki/Growth/Newsletters
>
> On Wed, Feb 26, 2020 at 3:07 AM Vi to  wrote:
>
> > Not really, drawing practical advices/lessons (e.g. "differentiate among
> > kinds of COIs") is the only sensible path towards solving issues.
> > "Let's be kind" is close to a tautology.
> >
> > Vito
> >
> > Il giorno mer 26 feb 2020 alle ore 09:59 Andy Mabbett <
> > a...@pigsonthewing.org.uk> ha scritto:
> >
> > > On Tue, 25 Feb 2020 at 20:36, Vi to  wrote:
> > > >
> > > > Hard to tell anything without the relevant link(s).
> > >
> > > For you, maybe. Others have already given helpful replies.
> > >
> > > My question was generic, and not about the specific case I gave as an
> > > example.
> > >
> > > I chose not to post links to to the example, both in order to avoid a
> > > pile-on, and to avoid us being distracted by the minutiae of the
> > > incident concerned.
> > >
> > > --
> > > Andy Mabbett
> > > @pigsonthewing
> > > http://pigsonthewing.org.uk
> > >
> > > ___
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > > https://meta.wikimedia.org/wiki/Wikimedia-l
> > > New messages to: Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > 
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > https://meta.wikimedia.org/wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
>
>
>
> --
> Marshall Miller
> marshall.h.mil...@gmail.com
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 

Re: [Wikimedia-l] Foundation management of volunteers

2019-06-21 Thread Martijn Hoekstra
On Fri, Jun 21, 2019, 07:43 Mister Thrapostibongles <
thrapostibong...@gmail.com> wrote:

> Martin
>
>
> > No, I'm saying that it's ridiculous to judge wikipedia on its policy that
> > citing itself is disallowed.
> >
>
> Perhaps, then, rather than telling us what it is that you don't agree with,
> you would like to propound your own position, and in your own words.


I'm under no such obligation, and I'm not much inclined to argue with you
on the details - but I do want to call out when something so egregiously
off base is put forward as the assertion that wikipedia is unreliable
*because* it has a policy that prevents it from citing itself, while the
very opposite is true: that any source would completely destroy its
credibility if it would cite itself and claim that is a sign of reliability.

That's the topic at hand here. My views on the reliability on wikipedia are
off topic for that discussion. But I'll  humor you and answer it anyway.


Do
> you believe that Wikipedia is a success?


It accomplishes bringing true information to many people, which I'd a
succes. It very occasionally brings false information to people, which is a
problem.

Improvements to reach, localization, and reliably are all important.


That it merits the description
> of "encyclopaedia"?


Yes, that's a reasonable description  though it is broader in scope.


In particular that it is reliable?
>


Reliable is not a yes/no answer, but you can rely on wikipedia to be likely
correct, much like more traditional encyclopedias. In addition, you can
often rely on it to cite its sources, though not always, and arguably not
often enough. You cant trust its editorial board though, as it has none, in
stark contrast to traditional encyclopedias.


> Thrapostibongles
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Foundation management of volunteers

2019-06-20 Thread Martijn Hoekstra
On Thu, Jun 20, 2019, 13:16 Mister Thrapostibongles <
thrapostibong...@gmail.com> wrote:

> Martin
>
> You really think that it is ridiculous that encyclopaedias in general and
> Wikipedia in particular should be judged, among other criteria, on their
> reliability?  If so, I disagree.
>


No, I'm saying that it's ridiculous to judge wikipedia on its policy that
citing itself is disallowed.

You keep rephrasing what I say in order to disagree with something I dont
say. Stop doing that.




> However, if you really believe that an encyclopadia does not ned to be
> reliable, then it seems that on this specific point we may need to agree to
> disagree.  How about the other points I adduce, such as the millions of
> unreferenced or inadeqautely referenced articles discovered at
>
> https://wikimediafoundation.org/2019/04/03/can-machine-learning-uncover-wikipedias-missing-citation-needed-tags/
> --
> is that evidence of success?  The thousands of articles in
> https://en.wikipedia.org/wiki/Category:Unreferenced_BLPs -- is that
> evidence of success?
>
> Thrapostibongles
>
> On Tue, Jun 18, 2019 at 1:44 PM Martijn Hoekstra <
> martijnhoeks...@gmail.com>
> wrote:
>
> > No.
> >
> > What I'm saying is this: setting meeting the reliable sources policy of
> > wikipedia as a condition for success, or not meeting that policy as
> > evidence of failure is ridiculous.
> >
> > On Tue, Jun 18, 2019, 14:29 Mister Thrapostibongles <
> > thrapostibong...@gmail.com> wrote:
> >
> > > Martin, Dennis
> > >
> > > The tenor of your arguments appears to be that Wikipedia is in fact
> > > reliable, because it uses reliable sources, but that it pretends not to
> > be
> > > because it's too hard to prevent people writing article based on other
> > > articles.  This is not in accord with the facts.  As I pointed out, and
> > as
> > > Foundation research has shown, millions -- literally millions, and
> when I
> > > say "literally" I literally mean "literally" -- of articles, about one
> in
> > > five, are not founded on reliable sources, and some thousands of those,
> > > being biographies of living people, should have been instantly deleted.
> > So
> > > we cannot rely on any of those millions of articles, by your own
> > > reasoning.  The reason why Wikipedia deems itself unreliable is that it
> > is
> > > an open wiki, and all such sources are forbidden, because anyone can
> > write
> > > anything on them: "Content from websites whose content is largely
> > > user-generated
> > > is also generally unacceptable."  Wikipedia is cited in the policy as
> > > merely another example of such unreliable sources.
> > >
> > > The way forward, however unpalatable this may be to people who would
> like
> > > to believe that this is somehow silly or sophistry, is to look the
> facts
> > in
> > > the face and accept that some form of editorial policy, content
> workflow
> > > management and supervision of the volunteer effort is necessary to make
> > > Wikipedia what aspires to be, but is not currently, namely an
> > > encyclopaedia.
> > >
> > > Thrapostibongles
> > >
> > > On Mon, Jun 17, 2019 at 11:06 PM Martijn Hoekstra <
> > > martijnhoeks...@gmail.com>
> > > wrote:
> > >
> > > > Wikipedia itself can never be more reliable than the sources it
> cites.
> > If
> > > > it's allowed to cite itself, then there is no "bottom" to lean on,
> and
> > > its
> > > > quality would quickly drop.
> > > >
> > > > That you conclude from that that wikipedia is unreliable and
> therefore
> > > > failed is IMO such a silly proposition, that I dont know whether you
> > > > seriously think this, in which case we should probably take this off
> > > list,
> > > > or that you're engaging in sophistry and using arguments you don't
> > think
> > > > are reasonable in the first place.
> > > >
> > > > On Mon, Jun 17, 2019, 19:56 Mister Thrapostibongles <
> > > > thrapostibong...@gmail.com> wrote:
> > > >
> > > > > Dennis,
> > > > >
> > > > > I started this thread to discuss both conduct and content policies
> on
> > > > > Wikipedia, and indeed how the two interact.  Wikipedia is a project
> > to
> > > > > build an encyclopaedia.  By its own criteria, encyclopaedias are

Re: [Wikimedia-l] Foundation management of volunteers

2019-06-18 Thread Martijn Hoekstra
No.

What I'm saying is this: setting meeting the reliable sources policy of
wikipedia as a condition for success, or not meeting that policy as
evidence of failure is ridiculous.

On Tue, Jun 18, 2019, 14:29 Mister Thrapostibongles <
thrapostibong...@gmail.com> wrote:

> Martin, Dennis
>
> The tenor of your arguments appears to be that Wikipedia is in fact
> reliable, because it uses reliable sources, but that it pretends not to be
> because it's too hard to prevent people writing article based on other
> articles.  This is not in accord with the facts.  As I pointed out, and as
> Foundation research has shown, millions -- literally millions, and when I
> say "literally" I literally mean "literally" -- of articles, about one in
> five, are not founded on reliable sources, and some thousands of those,
> being biographies of living people, should have been instantly deleted.  So
> we cannot rely on any of those millions of articles, by your own
> reasoning.  The reason why Wikipedia deems itself unreliable is that it is
> an open wiki, and all such sources are forbidden, because anyone can write
> anything on them: "Content from websites whose content is largely
> user-generated
> is also generally unacceptable."  Wikipedia is cited in the policy as
> merely another example of such unreliable sources.
>
> The way forward, however unpalatable this may be to people who would like
> to believe that this is somehow silly or sophistry, is to look the facts in
> the face and accept that some form of editorial policy, content workflow
> management and supervision of the volunteer effort is necessary to make
> Wikipedia what aspires to be, but is not currently, namely an
> encyclopaedia.
>
> Thrapostibongles
>
> On Mon, Jun 17, 2019 at 11:06 PM Martijn Hoekstra <
> martijnhoeks...@gmail.com>
> wrote:
>
> > Wikipedia itself can never be more reliable than the sources it cites. If
> > it's allowed to cite itself, then there is no "bottom" to lean on, and
> its
> > quality would quickly drop.
> >
> > That you conclude from that that wikipedia is unreliable and therefore
> > failed is IMO such a silly proposition, that I dont know whether you
> > seriously think this, in which case we should probably take this off
> list,
> > or that you're engaging in sophistry and using arguments you don't think
> > are reasonable in the first place.
> >
> > On Mon, Jun 17, 2019, 19:56 Mister Thrapostibongles <
> > thrapostibong...@gmail.com> wrote:
> >
> > > Dennis,
> > >
> > > I started this thread to discuss both conduct and content policies on
> > > Wikipedia, and indeed how the two interact.  Wikipedia is a project to
> > > build an encyclopaedia.  By its own criteria, encyclopaedias are
> reliable
> > > sources and Wikipedia is not a reliable source; hence by its own
> > criteria,
> > > Wikipedia is not an encyclopaedia.  That is, it is currently in a state
> > of
> > > failure with respect to its own mission.
> > >
> > > One of the reasons for that state of failure is indeed the failure to
> > > provide a collegial working atmosphere.
> > >
> > > Thrapostibongles
> > >
> > >
> > >
> > > On Mon, Jun 17, 2019 at 2:19 PM Dennis During 
> > wrote:
> > >
> > > > "One (and not the most important) pieces of evidence for Wikipedia
> > being
> > > in
> > > > a failed state is precisely that
> > > > it does not, by the community's own admission, constitute a reliable
> > > source
> > > > "
> > > >
> > > > You have made this argument more than once. That might be a piece of
> > > > evidence seems both wrong and not relevant to the sense in which
> people
> > > > here as saying WP has failed, which is as a welcoming, "safe"
> > environment
> > > > for contributors and would-be contributors.
> > > >
> > > > It is good policy to make sure that contributors reach out to other
> > > > sources, even when one believes that Wikipedia is as reliable as the
> > > > average tertiary source we allow as a reference. It prevents us from
> > > > relying exclusively on what can easily turn out to be a very narrow
> set
> > > of
> > > > points of view.  Does/did the Encyclopedia Britanica cite other EB
> > > articles
> > > > as references rather than include them as "see alsos"?
> > > >
> > > > On Mon, Jun 17, 2019 at 8:27 AM Mister Thrapostib

Re: [Wikimedia-l] Foundation management of volunteers

2019-06-17 Thread Martijn Hoekstra
Wikipedia itself can never be more reliable than the sources it cites. If
it's allowed to cite itself, then there is no "bottom" to lean on, and its
quality would quickly drop.

That you conclude from that that wikipedia is unreliable and therefore
failed is IMO such a silly proposition, that I dont know whether you
seriously think this, in which case we should probably take this off list,
or that you're engaging in sophistry and using arguments you don't think
are reasonable in the first place.

On Mon, Jun 17, 2019, 19:56 Mister Thrapostibongles <
thrapostibong...@gmail.com> wrote:

> Dennis,
>
> I started this thread to discuss both conduct and content policies on
> Wikipedia, and indeed how the two interact.  Wikipedia is a project to
> build an encyclopaedia.  By its own criteria, encyclopaedias are reliable
> sources and Wikipedia is not a reliable source; hence by its own criteria,
> Wikipedia is not an encyclopaedia.  That is, it is currently in a state of
> failure with respect to its own mission.
>
> One of the reasons for that state of failure is indeed the failure to
> provide a collegial working atmosphere.
>
> Thrapostibongles
>
>
>
> On Mon, Jun 17, 2019 at 2:19 PM Dennis During  wrote:
>
> > "One (and not the most important) pieces of evidence for Wikipedia being
> in
> > a failed state is precisely that
> > it does not, by the community's own admission, constitute a reliable
> source
> > "
> >
> > You have made this argument more than once. That might be a piece of
> > evidence seems both wrong and not relevant to the sense in which people
> > here as saying WP has failed, which is as a welcoming, "safe" environment
> > for contributors and would-be contributors.
> >
> > It is good policy to make sure that contributors reach out to other
> > sources, even when one believes that Wikipedia is as reliable as the
> > average tertiary source we allow as a reference. It prevents us from
> > relying exclusively on what can easily turn out to be a very narrow set
> of
> > points of view.  Does/did the Encyclopedia Britanica cite other EB
> articles
> > as references rather than include them as "see alsos"?
> >
> > On Mon, Jun 17, 2019 at 8:27 AM Mister Thrapostibongles <
> > thrapostibong...@gmail.com> wrote:
> >
> > > Vito
> > >
> > > This rather tends to support my point.  One (and not the most
> important)
> > > pieces of evidence for Wikipedia being in a failed state is precisely
> > that
> > > it does not , by the community's own admission, constitute a reliable
> > > source:whereas "Reputable tertiary sources
> > > , such as
> > > introductory-level university textbooks, almanacs, and encyclopedias,
> may
> > > be cited".  So Wikipedia fails in its aim of being an encyclopaedia on
> > one
> > > of the most important tests one could imagine, namely reliability.
> And a
> > > reason for that is its lack of effective content management policies
> and
> > > mechanisms to put them into effect (in the old days we called that
> being
> > an
> > > editor, but that word on Wikipedia now is more or less a redundant
> > synonym
> > > for contributor).
> > >
> > > Now suppose that Wikipedia had effective editorial policies and
> processes
> > > that allowed it to assume the status of a reliable source, just like
> the
> > > encyclopaedia it aims to be.  You say that even in that situation, it
> > would
> > > be easy to manipulate.  On that assumption, how much easier it must be
> to
> > > "trick" it today when it has no such effective policies and processes
> in
> > > place!
> > >
> > > Thrapostibongles
> > >
> > >
> > >
> >
> > --
> > Dennis C. During
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > https://meta.wikimedia.org/wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Foundation management of volunteers

2019-06-16 Thread Martijn Hoekstra
I disagree that Wikipedia not considering Wikipedia as an admissible source
is indicative of Wikipedia being a failure.



On Sun, Jun 16, 2019, 14:18 Mister Thrapostibongles <
thrapostibong...@gmail.com> wrote:

> Dear all,
> The discussion triggered by recent WMF T actions has tended to focus on
> the merits or otherwise of that specific action (even though as I have
> pointed out elsewhere this is very much a case of those who know don;t talk
> and those who talk don't know).  So I though it might be helpful to try and
> abstract some more general points for discussion.
>
> The long-term future of the Community, and the relationship between the
> Foundation and its volunteers is under discussion in an elaborately
> structured consultation announced already here in September 2017.  It would
> not be particularly helpful to try to run a parallel discussion here.  But
> in the short to medium term, it seems that it will be necessary for the
> Foundation to take a different stance with respect to the management of the
> various projects, and the English Wikipedia in particular.
>
> It is often said that "The problem with Wikipedia is that it only works in
> practice. In theory, it can never work."  Well, that's half true.  What the
> experiment has proved is that the theory was indeed correct -- Wikipedia,
> as currently constituted, does not work.  There are two inter-related
> aspects to its failure: content and conduct, inextricably related in a
> project founded on crowd-sourcing.
>
> Let's look at the content first.  Even on Wikipedia's own terms, it has
> failed.  It is a principle that Wikipedia is founded on reliable sources,
> and by its own admission, Wikipedia itself is not such a source.  That
> bears repetition -- a project aiming to be an encyclopaedia, that compares
> itself with Britannica, explicitly is not reliable.  Foundation research
> has shown that about one fifth of Wikipedia articles are supported  by
> references that are inadequate to support the text or simply are not
> there.  That's about a million articles each on of the larger Wikpedias.
> Some thousands of those are biographies of living people and in view of the
> risk of defamation, no such articles should exist on Wikipedia at all.
> There are several thousand articles that are possible copyright violations:
> again such articles should not be there.  And when I say "should not", I
> mean according to the rules adopted by the Wikipedia volunteer community
> itself.
>
> This links to the conduct aspects.  The self-organising policies of the
> "encyclopaedia that anyone can edit" have flattened out the formal
> hierarchy to the extent that it has been replaced, necessarily, by an
> informal but strong hierarchy based on a reputation econiomy.  This creates
> an unpleasant and hence ineffective working environment, and makes it all
> but impossible to organise a volunteer workforce into coping with the major
> violations of content policy alreay mentioned.  Indeed, the conduct policy
> makes it all but impossible to effectively handle cases of major abuse,
> witting ot uwitting.  For example, one reason for the failure to manage
> copyright violations is that some thousand of articles were written by a
> volunteer who was unable or unwilling to comply with the copyright
> requirements applicable to their contributions   There is simply no
> mechanism that allows for contributions to be effectively checked either
> when contributed or subsequently, bcause there is no mechanism that makes
> it possible to manage or organise the work of the volunteers, and existing
> community norms will not accept such a degree of organisation.
>
> These mutually reinforcing failures make to necessary for some degree of
> organisation and management of content and conduct to be imposed from
> outside the volunteer community.  The Foundation has the resources and is
> the only entity that can acquire and deploy the expertise required to do
> so.  No doubt this is unpalatable to some of the more vociferous members of
> the community -- those who stand highest in the reputation economy and have
> most to lose by it being replaced by an effective management policy.  But
> the fact remains -- Wikipedia is failing, and in its present form will
> inevitably continue to do so.
>
> Foundation or failure -- which is it to be?
>
> Thrapostibongles
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: 

Re: [Wikimedia-l] Fram en.wp office yearlock block

2019-06-14 Thread Martijn Hoekstra
 if Fram was not an admin, all these discussions would not have been done)
[citation needed]




why we (other users) have allowed such an attitude without intervening to
> stop it.
>
>
> Camelia
>
>
> --
> *Camelia Boban*
>
> *| Java EE Developer |*
>
> *Affiliations Committee - **Wikimedia *Foundation
> Coordinator - Diversity Working Group for Wikimedia Strategy 2030
> Chair & co-founder - WikiDonne User Group *| WikiDonne Project ideator*
>
> *Diversity Space @ Wikimania 2019 Co-Lead*
> WMIT - WMSE - WMCH - WMAR Member
>
> M. +39 3383385545
> camelia.bo...@gmail.com
> *Aissa Technologies* * | *Twitter
>  *|* *LinkedIn
> *
> *Wikipedia  **|
> **WikiDonne
> UG * | *WikiDonne Project
>  *
>
>
>
>
>
>
>
>
>
>
>
> Il giorno ven 14 giu 2019 alle ore 14:32 Mister Thrapostibongles <
> thrapostibong...@gmail.com> ha scritto:
>
> > Fæ
> >
> > [...] the pre-existing understanding that the WMF do not replace
> > > existing and perfectly adequate community agreed procedures for
> > > banning bad behaviour on our projects.
> >
> >
> > Unfortunately, there is ample evidence that the existing English
> Wikipedia
> > community processes are not "perfectly adequate" for that purpose.
> >
> >
> > > If the English
> > > Wikipedia's policies are not fit for purpose, or implementation of
> > > policy is incompetent, we need a much bigger discussion
> >
> >
> > Indeed.  Unfortunately the tone of the discussion here and at
> >
> >
> https://en.wikipedia.org/wiki/Wikipedia:Community_response_to_the_Wikimedia_Foundation%27s_ban_of_Fram
> > suggests
> > that the requisite discussion is now less, not more, likely to happen or
> be
> > productive.
> >
> > Thrapostibongles
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> > https://meta.wikimedia.org/wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
> https://meta.wikimedia.org/wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 


Re: [Wikimedia-l] Fram en.wp office yearlock block

2019-06-12 Thread Martijn Hoekstra
I would like to reserve the right to say "fuck arbcom", "fuck the WMF", or
"fuck the admins", just like I deserve the right to say "fuck the police"
or "fuck the judiciary system".

Regardless whether you think so or not, I dont think that's within WMFs
remit to police and enforce.

On Wed, Jun 12, 2019, 10:09 Chris Keating 
wrote:

> I think we should probably reflect on the fact we've got to the point where
> arguments along the lines of
>
> "This guy shouldn't be blocked, he was only telling people to fuck
> themselves"
>
> are sort of normal.
>
> This kind of behaviour wouldn't be acceptable in any other movement or
> community or workplace... Why here?
>
> (Also I think it's clear this was not the only issue... so while I have
> some  concerns about the "how" here, I'm struggling to disagree with the
> outcome)
>
> Chris
>
> On Wed, 12 Jun 2019, 07:44 Yair Rand,  wrote:
>
> > Philippe, the email from Trust & Safety said quite clearly that the ban
> was
> > triggered by edit 895438118. I assume that T would not lie about their
> > reasons for something like this.
> >
> > ‫בתאריך יום ג׳, 11 ביוני 2019 ב-22:35 מאת ‪Philippe Beaudette‬‏ <‪
> > phili...@beaudette.me‬‏>:‬
> >
> > > Nathan writes:
> > >
> > > *“Why are WMF staffers so*
> > >
> > > *deeply, fundamentally disconnected from the communities where they
> feel
> > > the*
> > > *right to ban people for saying "fuck arbcom"?”*
> > >
> > >
> > > I’ve seen no evidence that this is the case here and would be utterly
> > > shocked if a t staff member had indeed banned for saying that.
> > >
> > > If the situation is anything like what it was when I was at WMF, a ban
> > such
> > > as this requires multiple levels of review by a couple of different
> teams
> > > (in my time, we would not have considered a ban such as this without
> sign
> > > off from the community and legal teams, for instance). I don’t know if
> > the
> > > process is the same now but I would be surprised to hear that any
> single
> > > staff member would feel comfortable banning on his or her authority
> > alone.
> > > Multiple levels of review exist in order to ensure that ban reasons are
> > > valid and appropriate.
> > >
> > > Philippe
> > >
> > > On Tue, Jun 11, 2019 at 6:55 PM Nathan  wrote:
> > >
> > > > Wow, what a cluster. How does the WMF get themselves into these
> > things? I
> > > > have ten edits to en.wp since 2018 and even I could have 100%
> predicted
> > > the
> > > > entire spectrum, and scale, of the reaction here. Why are WMF
> staffers
> > so
> > > > deeply, fundamentally disconnected from the communities where they
> feel
> > > the
> > > > right to ban people for saying "fuck arbcom"?
> > > >
> > > > On Tue, Jun 11, 2019 at 3:49 PM Todd Allen 
> > wrote:
> > > >
> > > > > Amir, yes, ArbCom members must sign the WMF confidentiality
> agreement
> > > for
> > > > > nonpublic information (
> > > > >
> > > > >
> > > >
> > >
> >
> https://meta.wikimedia.org/wiki/Confidentiality_agreement_for_nonpublic_information
> > > > > )
> > > > > , as must all functionaries (checkuser, oversight, etc.). I was on
> > the
> > > > > English Wikipedia ArbCom for two years, and it was routine for us
> to
> > > deal
> > > > > with sensitive, private information.
> > > > >
> > > > > Todd
> > > > >
> > > > > On Tue, Jun 11, 2019 at 9:46 AM Amir Sarabadani <
> ladsgr...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > People who oppose the ban: Are you aware of all aspects and
> things
> > > Fram
> > > > > has
> > > > > > done? Do you have the full picture? It's really saddening to see
> > how
> > > > fast
> > > > > > people jump to conclusion in page mentioned in the email. I
> > > personally,
> > > > > > don't know what happened so I neither can support or oppose the
> > ban.
> > > As
> > > > > > simple as that.
> > > > > >
> > > > > > So what should be done IMO. If enwiki wants to know more, a
> > community
> > > > > body
> > > > > > can ask for more information, if body satisfy two things:
> > > > > >  - They had signed NDA not to disclose the case
> > > > > >  - They are trusted by the community
> > > > > >
> > > > > > I think the only body can sorta work with this is stewards but
> not
> > > sure
> > > > > > (Does ArbCom NDA'ed?)
> > > > > >
> > > > > >
> > > > > > On Tue, Jun 11, 2019 at 3:58 PM Paulo Santos Perneta <
> > > > > > paulospern...@gmail.com> wrote:
> > > > > >
> > > > > > > Lack of transparency from the WMF, whatelse is new.
> > > > > > > I'm currently under a funding ban secretly decided (by who?)
> > based
> > > > on a
> > > > > > > false accusation, without providing any evidence. Until now I'm
> > > > waiting
> > > > > > for
> > > > > > > an explanation from the WMF. So, this sort of attitude doesn't
> > > > surprise
> > > > > > me
> > > > > > > at all.
> > > > > > > It is very unfortunate that the WMF apparently thrives in this
> > kind
> > > > of
> > > > > > > medieval obscurity, the opposite of the values of the Wikimedia
> > > > > Movement.
> > > > > > > 

Re: [Wikimedia-l] Fram en.wp office yearlock block

2019-06-12 Thread Martijn Hoekstra
Phillipe,

Can you imagine a hypothetical situation where it would have been
appropriate for this WMF office action to exist though - that is to say,
not serious enough to ban a user from any other wiki than en. and serious
enough to take direct action outside of the community?

I sure can't, yet here it happened. That means I also can't really
disqualify any other points that I can't imagine as surely false. Can you,
from your personal experience reconcile what happened here good enough, so
that when you say you can't imagine, that dismisses the issue? Or do you
maybe also have to suspend your judgement on what probably did or didn't
happen as you are also in the realm of "can't imagine" already?

On Wed, Jun 12, 2019, 04:35 Philippe Beaudette 
wrote:

> Nathan writes:
>
> *“Why are WMF staffers so*
>
> *deeply, fundamentally disconnected from the communities where they feel
> the*
> *right to ban people for saying "fuck arbcom"?”*
>
>
> I’ve seen no evidence that this is the case here and would be utterly
> shocked if a t staff member had indeed banned for saying that.
>
> If the situation is anything like what it was when I was at WMF, a ban such
> as this requires multiple levels of review by a couple of different teams
> (in my time, we would not have considered a ban such as this without sign
> off from the community and legal teams, for instance). I don’t know if the
> process is the same now but I would be surprised to hear that any single
> staff member would feel comfortable banning on his or her authority alone.
> Multiple levels of review exist in order to ensure that ban reasons are
> valid and appropriate.
>
> Philippe
>
> On Tue, Jun 11, 2019 at 6:55 PM Nathan  wrote:
>
> > Wow, what a cluster. How does the WMF get themselves into these things? I
> > have ten edits to en.wp since 2018 and even I could have 100% predicted
> the
> > entire spectrum, and scale, of the reaction here. Why are WMF staffers so
> > deeply, fundamentally disconnected from the communities where they feel
> the
> > right to ban people for saying "fuck arbcom"?
> >
> > On Tue, Jun 11, 2019 at 3:49 PM Todd Allen  wrote:
> >
> > > Amir, yes, ArbCom members must sign the WMF confidentiality agreement
> for
> > > nonpublic information (
> > >
> > >
> >
> https://meta.wikimedia.org/wiki/Confidentiality_agreement_for_nonpublic_information
> > > )
> > > , as must all functionaries (checkuser, oversight, etc.). I was on the
> > > English Wikipedia ArbCom for two years, and it was routine for us to
> deal
> > > with sensitive, private information.
> > >
> > > Todd
> > >
> > > On Tue, Jun 11, 2019 at 9:46 AM Amir Sarabadani 
> > > wrote:
> > >
> > > > People who oppose the ban: Are you aware of all aspects and things
> Fram
> > > has
> > > > done? Do you have the full picture? It's really saddening to see how
> > fast
> > > > people jump to conclusion in page mentioned in the email. I
> personally,
> > > > don't know what happened so I neither can support or oppose the ban.
> As
> > > > simple as that.
> > > >
> > > > So what should be done IMO. If enwiki wants to know more, a community
> > > body
> > > > can ask for more information, if body satisfy two things:
> > > >  - They had signed NDA not to disclose the case
> > > >  - They are trusted by the community
> > > >
> > > > I think the only body can sorta work with this is stewards but not
> sure
> > > > (Does ArbCom NDA'ed?)
> > > >
> > > >
> > > > On Tue, Jun 11, 2019 at 3:58 PM Paulo Santos Perneta <
> > > > paulospern...@gmail.com> wrote:
> > > >
> > > > > Lack of transparency from the WMF, whatelse is new.
> > > > > I'm currently under a funding ban secretly decided (by who?) based
> > on a
> > > > > false accusation, without providing any evidence. Until now I'm
> > waiting
> > > > for
> > > > > an explanation from the WMF. So, this sort of attitude doesn't
> > surprise
> > > > me
> > > > > at all.
> > > > > It is very unfortunate that the WMF apparently thrives in this kind
> > of
> > > > > medieval obscurity, the opposite of the values of the Wikimedia
> > > Movement.
> > > > > Matter for Roles & Reponsibilities.
> > > > >
> > > > > Best,
> > > > > Paulo
> > > > >
> > > > >
> > > > > Benjamin Ikuta  escreveu no dia terça,
> > > > 11/06/2019
> > > > > à(s) 05:45:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks for this.
> > > > > >
> > > > > > I'm glad to see I'm not the only one dismayed by the
> unilateralism
> > > and
> > > > > > lack of transparency.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Jun 10, 2019, at 8:25 PM, Techman224 <
> techman...@techman224.ca>
> > > > > wrote:
> > > > > >
> > > > > > > Forwarding to WIkimedia-l since WikiEN-l is relatively dead.
> > > > > > >
> > > > > > > Since this message, an Arbcom member (SilkTork) stated that
> they
> > > > > weren't
> > > > > > consulted, nor did this action was the result of Arbcom
> forwarding
> > a
> > > > > > concern to the office. [1]
> > > > > > >
> > > > > > > The only 

Re: [Wikimedia-l] Solve legal uncertainty of Wikidata

2018-07-04 Thread Martijn Hoekstra
I have no dog in this race, but facts are not eligible for copyright
protection.

On Wed, Jul 4, 2018, 17:11 Andreas Kolbe  wrote:

> On Fri, May 18, 2018 at 1:54 AM, Denny Vrandečić 
> wrote:
>
> > Gnom1 on Phabricator has offered to actually answer legal questions, but
> we
> > need to come up with the questions that we want to ask.
> >
> >
>
> In the Phabricator discussion, Denny and others spent some considerable
> effort to come up with the following questions (I am quoting below from
> Denny's last post on Phabricator, dated May 26th):
>
> ---o0o---
>
> Denny wrote on Phabricator:
>
> So, given the discussion as it has been going, I hope that the following
> questions sound good to everyone:
>
>1. Can you comment on the practice of having processes that in bulk
>extract facts from Wikipedia articles, which are published under
> CC-BY-SA,
>and store the results in Wikidata, where they are published under CC-0?
>
>
>1. Particular sets of facts we are interested in to consider would be:
>a) interwiki links, b) facts extracted from infobox templates, c) facts
>extracted from prose through natural language processing.
>
>
>1. What, if anything, may be imported from ODBL licensed databases like
>OSM into Wikidata, and republished under CC-0?
>
> If I don't hear back by the mid of the next week, I'm going to raise these
> as the questions we would kindly ask to be answered.
>
> ---o0o---
>
> Given that more than a month has passed, have these questions actually been
> answered?
>
>
>
>
>
>
> >
> > On Thu, May 17, 2018 at 4:15 PM Rob Speer  wrote:
> >
> > > > As always, copyright is predatory. As we can prove that copyright is
> > the
> > > enemy of science and knowledge
> > >
> > > Well, this kind of gets to the heart of the issue, doesn't it.
> > >
> > > I support the Creative Commons license, including the share-alike term,
> > > which requires copyright in order to work, and I've contributed to
> > multiple
> > > Wikimedia projects with the understanding that my work would be
> protected
> > > by CC-By-SA.
> > >
> > > Wikidata is engaged in a project-wide act of disobedience against
> > CC-By-SA.
> > > I would say that GerardM has provided an excellent summary of the
> > attitude
> > > toward Creative Commons that I've encountered on Wikidata: "it's
> holding
> > us
> > > back", "it's the enemy", "you can't copyright knowledge", "you can't
> make
> > > us follow it", etc.
> > >
> > > The result of this, by the way, is that commercial entities sell
> modified
> > > versions of Wikidata with impunity. It undermines the terms of other
> > > resources such as DBPedia, which also contains facts extracted from
> > > Wikipedia and respects its Share-Alike terms. Why would anyone use
> > DBPedia
> > > and have to agree to share alike, when they can get similar data from
> > > Wikidata which promises them it's CC-0?
> > >
> > > On Wed, 16 May 2018 at 21:43 Gerard Meijssen <
> gerard.meijs...@gmail.com>
> > > wrote:
> > >
> > > > Hoi,
> > > > Thank you for the overly broad misrepresentation. As always,
> copyright
> > is
> > > > predatory. As we can prove that copyright is the enemy of science and
> > > > knowledge we should not be upset that *copyright *is abused we should
> > > > welcome it as it proves the point. Also when we use texts from
> > everywhere
> > > > and rephrase it in Wikipedia articles "we" are not lily white either.
> > > >
> > > > In "them old days" generally we felt that when people would use
> > > Wikipedia,
> > > > it would only serve our purpose; share the sum of all knowledge. I
> > still
> > > > feel really good about that. And, it has been shown that what we do;
> > > > maintain / curate / update that data that it is not easily given to
> do
> > as
> > > > well as "we" do it.
> > > >
> > > > When we are to be more precise with our copyright, there are a few
> > things
> > > > we could do to make copyright more transparent. When data is to be
> > > uploaded
> > > > (Commons / Wikipedia or Wikidata) we should use a user that is OWNED
> > and
> > > > operated by the copyright holder. The operation may be by proxy and
> as
> > a
> > > > consequence there is no longer a question about copyright as the
> > > copyright
> > > > holder can do as we wants. This makes any future noises just that,
> > > > annoying.
> > > >
> > > > As to copyright on Wikidata, when you consider copyright using data
> > from
> > > > Wikipedia. The question is: "What Wikipedia" I have copied a lot of
> > data
> > > > from several Wikipedias and believe me, from a quality point of view
> > > there
> > > > is much to be gained by using Wikidata as an instrument for good
> > because
> > > it
> > > > is really strong in identifying friends and false friends. It is
> > superior
> > > > as a tool for disambiguation.
> > > >
> > > > About the copyright on data, the overriding question with data is: do
> > you
> > > > copy data wholesale in Wikidata. That is what a database copyright is
> > > > 

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-05 Thread Martijn Hoekstra
On Fri, Dec 5, 2014 at 7:11 PM, phoebe ayers phoebe.w...@gmail.com wrote:

 Hello all,

 I just re-read this whole thread (!) this morning and here are the
 themes of points raised that I'm seeing ... I'll add this to the talk
 of https://meta.wikimedia.org/wiki/Fundraising_principles too.

 Anything else I missed? My editorializing is in brackets [ ].

 ==communication re: fundraising season==
 * develop banner approaches in the off-season [the fundraising team
 already does this, but there's desire for community discussion too]
 * if you do something new (in a geography etc.) make sure you
 communicate it to the stakeholders
 * fundraising team seen as sometimes unresponsive [though acknowledged
 that this, the en.wp fundraiser, is their biggest crunch week]
 * Also many thanks for the acknowledged very efficient, remarkable job
 at fundraising to the team; The fundraising team is amazing at their
 jobs

 ==message content==
 * don't mislead about ads: potential implication that if we don't get
 the money we'll run ads is not ok [agreed.]
 * don't mislead about WMF finances: potential implication that we'll
 go off the air immediately if you don't donate is not ok [note, I'm
 not seeing this in the current message, but I may not be seeing it
 because every fundraising appeal I've ever gotten is crouched in
 crisis terms.]
 * message sounds like an obituary/doesn't sound like an obituary/is
 clear/is too American [the latter is a problem esp. with English
 Wikipedia messaging, I suspect]
 * comments about emails, too [note, previous donors get 1 email a year]
 * comment that 1/fundraiser a year is not true for those unlucky souls
 who get a/b tested
 * as contributors, we want to be proud of Wikimedia, and not
 demotivated by the banners. some find the fundraising demotivating
 because of above points.

 ==banner size==
 * pop-ups are no good [pretty clear consensus]
 * sticky banners no good [I'm not sure if there's consensus on this point]
 * banners that obscure content are no good [note, though we agree on
 the principle, I am personally skeptical about the claim of this
 banner interfering with our mission; the content is still right there]
  * mobile banners too big, x to dismiss too small

 ==brand image==
 * current messages are seen as harming brand image because of above
 content points
 * harming brand image is not ok [I think we're all agreed on this]
 * messages should encourage people to contribute content as well [def.
 worth exploring]
 * user sentiment analysis is important [possible action point: maybe
 user sentiment re: brand should be more highly weighted in the banner
 tests?]
 * what would happen if donors were shown financials alongside banners?
 [note this seems very impractical to me. The majority of donors do not
 have experience with big nonprofit finances or a scope of comparison.
 Yes, I look at the 990s of charities I give to, but I suspect I'm
 unusual in that way].

 ==data==
 * we want all the data, because we are Wikipedians
 * especially .. user sentiment methodology  raw data
 * social media reaction: it seems very negative/more negative than
 past??/how much is there/should we worry about it?
 * how many impressions do people see? Is it really less? [note, we've
 been trying to optimize for fewer impressions for a long while, hence
 the shorter fundraiser]

 ---

 Other questions for me:
 Nemo asks about minutes. I suspect they'll be out in a couple of
 weeks, and then there will be a week of delay or so as the board
 approves them. All delays are on the trustee end, not on the
 secretary's end. Note though that I already summarized probably the
 most exciting discussion.

 Andreas asks about the editor survey report. I looked through my
 papers the last time you asked, and I don't think I have it. I'd send
 it to you if I did.

 best,
 Phoebe


Hi Phoebe,

Thanks for re-reading the whole thread, that must have been fun, and for
summarizing the points. From my perspective, you caught pretty much
everything. The one thing I still have to add is the subject line of the
Jimmy email. That came across as incredibly spammy and misleading to me
(Why the hell is Jimmy mailing me telling me he'll keep it short? Oh, it's
just a fundraiser email). The subject of the email is not Jimmy keeping it
short, but a request to donate. That should be clearer in the subject line.
And the sender should IMO be the Wikimedia Fundraising team or the WMF, not
Jimmy.

To others I imagine it reads like those spam emails with Have you seen
this article? in the subject line with spoofed email addresses.

Thank you for keeping working on this, and not getting pulled into emotion.

Cheers,

--Martijn

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

Re: [Wikimedia-l] [Wikimedia France] WikiCheese crowdfunding - Let's photograph 'em all

2014-12-04 Thread Martijn Hoekstra
On Dec 4, 2014 2:46 PM, Jean-Frédéric jeanfrederic.w...@gmail.com wrote:

  Thanks again, I tried to remain brie-f


 2014-12-03 18:06 GMT+00:00 Christophe Henner christophe.hen...@gmail.com
:

  110% !!! We bleu our first goal.
 

 Christophe, whether you are posting out of love for this awesome project
or
 just for the sake of making puns, I cantal.

A little humor on this thread may annoy some, but it's really a Brie of
fresh air to me.

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

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-04 Thread Martijn Hoekstra
On Thu, Dec 4, 2014 at 9:26 PM, MZMcBride z...@mzmcbride.com wrote:

 I checked my inbox today to find a note from a friend asking if
 Wikipedia was okay. My reply was essentially Wikipedia is fine, if you
 want to donate, make an edit or two.

 I wonder how many Wikimedians are getting the same notes of concern. I'd
 be quite surprised, for example, if Wikimedia Foundation department heads
 weren't getting these types of notes right now. It's a bit sad. And I
 wonder how others reply to sincere concerns about Wikipedia's health.
 (Again, nobody knows what Wikimedia is, for better or worse.)

 Meanwhile, also in my inbox, the author of this piece sent me a link to
 http://newslines.org/blog/stop-giving-wikipedia-money/, which was silly
 in parts, but an interesting perspective to read.

 Lila Tretikov wrote:
 I recommend those of you who would like to come up with some test wording
 assuming the current word count do so and after you pick top 3-5 we can
 pilot with one of our next user groups.

 Eh, fair play. I've started a page here:
 https://meta.wikimedia.org/wiki/Fundraising_banners/December_2014. I'm
 busy today, but I'll try to brainstorm some better options. If we must
 have donation advertising (a necessary evil, for now, we assume), we can
 probably at least stop shouting at and misleading our readers/donors. :-)

 MZMcBride


I gave it a go. It's not good, but it's a wiki, so someone go make it good
:)

As a positive (non-statistically significant) datapoint, I did some asking
around with people who didn't know I was a wikipedian what their general
impressions on the banners were (from memory, everybody did indeed see
them), and what they thought the financial health of the Foundation was
like. They didn't feel that the text implied that the foundation was in
financial trouble/crisis or anything like that. When I explained the
financial situation of the Foundation, and the distribution of money to
development, operations/keeping the lights on and programmatic work
(roughly), they were fine with it, and didn't find the copy misleading. One
of them told me he donated again after I told him why I was asking those
questions, and that we're so concerned we're not being honest enough with
our readers/donors.

A couple did however note that they've seen banners earlier this year, and
started questioning the honesty of the statement that it was a once a year
thing to raise sufficient funds for another year now they were seeing
banners again a few months later. That possibility never really occurred to
me. Turns out the Quantum Mechanical idea that you can't measure something
without affecting its outcome holds for A/B testing in fundraising.

-- Martijn



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

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

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-03 Thread Martijn Hoekstra
On Dec 3, 2014 3:46 AM, Ryan Lane rlan...@gmail.com wrote:

 Megan Hernandez mhernandez@... writes:

 
 
  As Lila’s email said, we launched our end of year English fundraising
  campaign on Tuesday. I wanted to share a little more background on the
  mechanics of the English Wikipedia campaign, and where we are on our
goals
  this year to-date.
 
  Starting today, banners are being shown to 100% of anonymous readers on
  English Wikipedia in the US, UK, Canada, Australia and New Zealand. Our
end
  of year campaign goal is $20 million. As Lila mentioned, our goal is to
  serve more powerful reminders to be able to limit the total number of
  banners each reader sees. We are constantly experimenting with new
methods
  to reach our readers and optimize the donation experience.
 

 I know I used to write an email internally every year, saying our banners
 are getting out of control, but that's because every year they get bigger
 and more obscuring of the content. This year, as usual, is not an
exception.
 However, this year the banners didn't just get bigger, the copy seems to
be
 more fear inducing as well.

 Today I had a coworker private message me, worried that Wikipedia was in
 financial trouble. He asked me if the worst happened, would the content
 still be available so that it could be resurrected? I assured him that
 Wikimedia is healthy, has reserves, and successfully reaches the budget
 every year. Basically I said there wasn't much to worry about, because
there
 isn't.

 The messaging being used is actively scaring people. This isn't the first
 person that's asked me about this. When they find out there's not a real
 problem, their reaction quickly changes. They become angry. They feel
 manipulated.

 My coworker told me that he donates generously every year, which is rare
for
 him because he doesn't often donate to charities. He said this year's ads
 are putting him off. He doesn't feel like he should donate.

 I understand that efficient banner ads are good, because they reduce the
 number of times people need to see the ad, but it's not great when people
 stop posting funny banner memes and start asking Wikimedia to switch to an
 advertising model (seriously, do a quick twitter search).

 - Ryan Lane


Excuse the cynicism, but maybe automating the message to go out every year
on the first week of December will save you frustration and effort. I know
how this will end. It'll end like last year, and the year before, etc. etc.
Where we conclude, yes, what we did now really cross the line, we have to
tone it down a bit, with thank yous to those concerned, and apologies for
taking it too far. I have no doubt it's exactly the same next year. So
please see the email below I'll automate for the first week of December for
now on.

Dear fundraising team. Thank you for your efforts to make the fundraiser as
quick as possible. I understand that effective banners allow us to keep the
yearly donation drive as short as possible.

Yet the banners I'm seeing this year leave me troubled about the appearance
and the message presented. For the appearance, it is the size and
obnoxiousness that bothers me. They seem to be designed to annoy the reader
as much as possible. I know they only work when people notice them but do
we really *have* to (select one from list:  play audio/ obscure our content
forcing a click through / use animated content / take up the majority of
the screen above the fold). It annoys our users, the people we do it all
for, to no end. Take a look at Twitter, it's not just one or two people.

Secondly I'm alarmed about the content. That should come to no surprise to
the fundraising team, because I can't imagine this content hasn't been
written to evoke the maximum amount of alarm.
But it crosses the line towards dishonesty. Yes the WMF can use the
donations, and yes they generally spend it well. But the lights won't go
off next week if You don't donate Now. The servers won't go offline. We're
not on immediate danger. Yet that's what this year's campaign seems to want
the message to be. But don't take my word for it, take a look at the
messages accompanying the donations. People are genuinely worried. They
will be angry if they find out they're being manipulated, and they would be
right. Generally I'm proud of what we do as movement and proud of much of
the way we do it. These banners make me ashamed of the movement I'm part
of. And frustrated that I seem to be unable to change it in the long run, I
think I may have send out a similar email to this one last year.

For now, two requests.
# could you please stop misleading the reader in our appeal?
# could you please make the banners a little less invasive? So that the
don't obscure content unless dismissed, and so that they take up more than
50% of the space above the fold.

I know you work hard for the fundraiser to be successful, and as brief as
possible, but please take in consideration the dangers of damaging our
reputation for openness and 

Re: [Wikimedia-l] Fundraising banners (again)

2014-12-03 Thread Martijn Hoekstra
On Dec 3, 2014 12:00 PM, Federico Leva (Nemo) nemow...@gmail.com wrote:

 Martijn Hoekstra, 03/12/2014 10:13:

 I will automate this message for the first Tuesday of December, around
 10:00 a.m. UTC. If others could automate their messages to not exactly
 coincidence with this one, that would help.


 Why December? Fundraising banners are up all year long. Due to the
banners, there are concerned citizens who literally stop me while I walk in
Milan to ask me what's going on, pretty much any time.

 Nemo

I could do it monthly, but that would probably become disruption.

I now regret that I didn't think of disrupting Wikipedia to raise a fund
earlier. Then again, it's probably for the better.

-Martijn



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

Re: [Wikimedia-l] WaPo Wikipedia's 'complicated; relationship with net neutrality

2014-12-01 Thread Martijn Hoekstra
On Nov 26, 2014 11:21 PM, Kim Bruning k...@bruning.xs4all.nl wrote:


 Washington post article

http://www.washingtonpost.com/blogs/the-switch/wp/2014/11/25/wikipedias-complicated-relationship-with-net-neutrality/

 sincerely,
 Kim


This is obviously not the first time this comes up, and it's probably not
going to be the last time either. I think that Wikipedia Zero is a great
and valuable project that does the right thing. I also agree it violates
net neutrality for any reasonable definition of net neutrality, and there
is a number of very good objections to the practice. It would be great if
we were confident enough of this project to come out and say yes, this
violates net neutrality and here are the reasons why we think it's a good
thing in this case. It would make a far stronger case than the well,
actually, ... rule lawyer, question evasion, goalposts moving, talking
around the issue ... and that's why it has nothing to do with net
neutrality!

Wikipedia Zero is a great project that does amazingly good stuff for many
people who need it most. That's an awesome reason to violate net
neutrality, even when it has real dangers and drawbacks. When we start to
deny the dangers and drawbacks, all discussion becomes muddled, and stains
the zero project with dishonesty.

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

Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor

2014-10-25 Thread Martijn Hoekstra
On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il
wrote:

 Thank goodness this wasn't written five years ago, otherwise somebody
could
 get the awful idea to implement it.

Having a side by side really time wikitext - display doesn't sound like an
aweful idea at all to me. I'm quite surprised anyone would find that aweful
actually. I don't understand why you're so dismissive of that idea.

--Martijn
 בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב:

  I spotted this article linked from news.ycombinator.com,
  arguing -well- what it says on the tin. ;-)
 
  Apologies if someone else already posted a link.
 
 
 
https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8
 
  I'm not sure scratches head. Well, if we allow lua in templates,
  I suppose things actually are already pretty Interesting.
 
  sincerely,
  Kim Bruning
 
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 ___
 Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor

2014-10-25 Thread Martijn Hoekstra
On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il
wrote:

 Because, even though I'm well aware of the fact that lots of experienced
 wikipedians love wiki syntax, the wiki syntax must go away, and will go
 away. Maybe in five years, maybe ten, maybe twenty. But it will go away.
 Investing effort in an IDE for it is pointless.

So fortunately we didn't invest in something five years ago with an
expected lifespan of 10 to 25 years?


 Templates are, indeed, programs. Articles aren't. Wikidata and Winter (or
 something like Winter) will remove the need to edit transclusions as part
 of the articles' source code in maybe three years (maybe much less).
 Development should focus on that, rather than on an IDE for a language
that
 should as soon as possible become transparent to all editors.

 (This is not an official representation of the Wikimedia Foundation's
 opinion.)
 בתאריך 25 באוק 2014 19:40, Martijn Hoekstra martijnhoeks...@gmail.com
 כתב:

  On Oct 25, 2014 6:17 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il

  wrote:
  
   Thank goodness this wasn't written five years ago, otherwise somebody
  could
   get the awful idea to implement it.
 
  Having a side by side really time wikitext - display doesn't sound like
an
  aweful idea at all to me. I'm quite surprised anyone would find that
aweful
  actually. I don't understand why you're so dismissive of that idea.
 
  --Martijn
   בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl כתב:
  
I spotted this article linked from news.ycombinator.com,
arguing -well- what it says on the tin. ;-)
   
Apologies if someone else already posted a link.
   
   
   
 
 
https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8
   
I'm not sure scratches head. Well, if we allow lua in templates,
I suppose things actually are already pretty Interesting.
   
sincerely,
Kim Bruning
   
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
   ___
   Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 ___
 Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Wikipedia needs an IDE, not a WYSIWYG editor

2014-10-25 Thread Martijn Hoekstra
On Oct 25, 2014 8:03 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il
wrote:

 Perpetuating it with a dedicated IDE wouldn't help it go away.

I doubt that. Side by side wikitext and result, making you see the result
of either in the other in real time could help adoption of wysiwyg
techniques, help improve them, and help people ease in to using them. Your
wonton dismissiveness is worrysome to me.

 בתאריך 25 באוק 2014 20:51, Martijn Hoekstra martijnhoeks...@gmail.com
 כתב:

  On Oct 25, 2014 7:20 PM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il

  wrote:
  
   Because, even though I'm well aware of the fact that lots of
experienced
   wikipedians love wiki syntax, the wiki syntax must go away, and will
go
   away. Maybe in five years, maybe ten, maybe twenty. But it will go
away.
   Investing effort in an IDE for it is pointless.
 
  So fortunately we didn't invest in something five years ago with an
  expected lifespan of 10 to 25 years?
 
  
   Templates are, indeed, programs. Articles aren't. Wikidata and Winter
(or
   something like Winter) will remove the need to edit transclusions as
part
   of the articles' source code in maybe three years (maybe much less).
   Development should focus on that, rather than on an IDE for a language
  that
   should as soon as possible become transparent to all editors.
  
   (This is not an official representation of the Wikimedia Foundation's
   opinion.)
   בתאריך 25 באוק 2014 19:40, Martijn Hoekstra 
martijnhoeks...@gmail.com
  
   כתב:
  
On Oct 25, 2014 6:17 PM, Amir E. Aharoni 
  amir.ahar...@mail.huji.ac.il
  
wrote:

 Thank goodness this wasn't written five years ago, otherwise
somebody
could
 get the awful idea to implement it.
   
Having a side by side really time wikitext - display doesn't sound
like
  an
aweful idea at all to me. I'm quite surprised anyone would find that
  aweful
actually. I don't understand why you're so dismissive of that idea.
   
--Martijn
 בתאריך 25 באוק 2014 18:26, Kim Bruning k...@bruning.xs4all.nl
  כתב:

  I spotted this article linked from news.ycombinator.com,
  arguing -well- what it says on the tin. ;-)
 
  Apologies if someone else already posted a link.
 
 
 
   
   
 
 
https://medium.com/@MrJamesFisher/wikipedia-needs-an-ide-not-a-wysiwyg-editor-7acd85b582c8
 
  I'm not sure scratches head. Well, if we allow lua in
templates,
  I suppose things actually are already pretty Interesting.
 
  sincerely,
  Kim Bruning
 
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe:
  https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org
  ?subject=unsubscribe
 ___
 Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe:
  https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
   ___
   Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 ___
 Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] To Flow: on featured article discussions

2014-09-16 Thread Martijn Hoekstra
On Mon, Sep 15, 2014 at 7:24 PM, Danny Horn dh...@wikimedia.org wrote:

 Figuring out how Flow integrates with the watchlist and Echo is one of the
 toughest and most important parts of the project.


I think that may be an overstatement. I'm not saying it isn't tough, but
exploring in what ways wikipages are currently used as a vehicle for
organizing discussions across different projects and different wikis (and
possibly third parties), and supporting all those different use-cases seems
far tougher than how to interact with watchlists and notifications.

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

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-11 Thread Martijn Hoekstra
On Thursday, September 11, 2014, John Mark Vandenberg jay...@gmail.com
wrote:

 On Thu, Sep 11, 2014 at 8:21 AM, Wil Sinclair w...@wllm.com
 javascript:; wrote:
  Tim, do you think that this list of all the useful stuff that talk
  pages can currently includes things that aren't being done because
  they are too advanced for newbie editors or too inconvenient for
  veterans?
 
  Regardless, you make a strong argument for keeping a meta-document
  that spans threads and/or should be more persistent. A lot of this
  stuff seems indispensable to recording decisions and linking to stuff
  that backs them up, avoiding constant rehashing of issues. My concern
  is how such a documents could be tied to pertinent threads in the
  discussion oriented software. Maybe we could create anchors in such a
  document that could make it easier for the right sections to be
  displayed alongside threads that reference them in the UI.

 The concept of a meta document, which uses wikitext and is editable
 using VE, would alleviate a lot of the concerns about Flow.  It would
 be relatively simple to change processes from using 'Talk:x' to using
 'MetaDoc:x' (still a big migration task, but less problematic than
 going through process re-engineering for every Wikipedia process in
 250+ projects with their own language).

 If that meta document also had a talk namespace (MetaDocTalk:x), which
 uses wikitext, the old-timers (and bots) will still have a place to
 hold discussions and post notes using wikitext if they wish to.

 --
 John Vandenberg



+1, at least as transition mechanism.

--Martijn


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

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Martijn Hoekstra
On Sep 10, 2014 5:11 AM, Keegan Peterzell keegan.w...@gmail.com wrote:

 On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com wrote:

 
  FWIW, I signed my first comment by hand. I missed the comments about
  sigs in the wikitext editor interface. If it weren't for my family
  situation, I'm pretty sure I would have bailed. In any case, it was
  much easier to engage at WO, and that was partly- but not mostly- due
  to the fact that they run discussion software over there.
 
  ,Wil
 
 
 ​This - signing by hand - is pretty much a universal experience for new
 users, myself included.


https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaskadiff=prevoldid=26555079
 ​


 --
 ~Keegan

 https://en.wikipedia.org/wiki/User:Keegan

I'm not saying that isn't crap and unwelcoming: it is, and it deters new
users. But it's hardly the end of the world either. By signing the wrong
way no real harm is done, if someone just tells you about the option to use


It's crap and archaic and should be fixed, but it's also an example of the
idea that there are no mistakes on a wiki. So you did something not right?
Great, that means you contributed. So we fix it (collaboratively) and
improve your contribution, no harm done.

That said, auto sign and a reply button would be a *whole* lot friendlier
than what we have now, and would be great improvements over the current
situation.

Flow definitely has a reply button, and automatic signing as well, but I
can't help but think that just those features in isolation would be better
then completely overhauling talk pages.

--Martijn


 This is my personal email address. Everything sent from this email address
 is in a personal capacity.
 ___
 Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Martijn Hoekstra
On Sep 10, 2014 9:35 AM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 Hoi.
 When you look at talk pages in isolation, you look at them on a computer
 screen. A mobile or tablet screen is increasingly not used in isolation.

I'm not sure what you mean by this.

It
 is where we find our new users and editors. We cannot afford to ignore
 them; they are our future. This is why tinkering with talk pages is not an
 option. Moving away from talk pages because of mobiles and tablets is the
 killer reason why we need to move away from talk pages.

 It is a killer reason because it makes all arguments to the contrary pale
 away.
 Thanks,
  GerardM

What I find most painful about talk pages on mobile (on the desktop skin,
because so far I've been too impatient to find talk pages and edit
functionality on mobile) have been that editing huge text areas really
sucks (the scrolling and positioning the cursor is a huge pain). This is
not limited to talk pages by the way, but is identical for mainspace pages.

A reply button that inserts an isolated comment at the correct indentation
level would fix that. Am I overlooking stuff?

 On 10 September 2014 09:20, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

  On Sep 10, 2014 5:11 AM, Keegan Peterzell keegan.w...@gmail.com
wrote:
  
   On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com wrote:
  
   
FWIW, I signed my first comment by hand. I missed the comments about
sigs in the wikitext editor interface. If it weren't for my family
situation, I'm pretty sure I would have bailed. In any case, it was
much easier to engage at WO, and that was partly- but not mostly-
due
to the fact that they run discussion software over there.
   
,Wil
   
   
   ​This - signing by hand - is pretty much a universal experience for
new
   users, myself included.
  
  
 
 
https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaskadiff=prevoldid=26555079
   ​
  
  
   --
   ~Keegan
  
   https://en.wikipedia.org/wiki/User:Keegan
 
  I'm not saying that isn't crap and unwelcoming: it is, and it deters new
  users. But it's hardly the end of the world either. By signing the wrong
  way no real harm is done, if someone just tells you about the option to
use
  
 
  It's crap and archaic and should be fixed, but it's also an example of
the
  idea that there are no mistakes on a wiki. So you did something not
right?
  Great, that means you contributed. So we fix it (collaboratively) and
  improve your contribution, no harm done.
 
  That said, auto sign and a reply button would be a *whole* lot
friendlier
  than what we have now, and would be great improvements over the current
  situation.
 
  Flow definitely has a reply button, and automatic signing as well, but I
  can't help but think that just those features in isolation would be
better
  then completely overhauling talk pages.
 
  --Martijn
 
  
   This is my personal email address. Everything sent from this email
  address
   is in a personal capacity.
   ___
   Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
 ___
 Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Martijn Hoekstra
On Wed, Sep 10, 2014 at 9:55 AM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 Hoi,
 I expected that it was obvious... Arguments that are based on desktop
 experiences are futile because  the desktop experience is the lesser of two
 evils. The desktop experience is already bad, the experience on mobiles and
 tablets is much worse it is intolerably unusable,


I meant I didn't understand what you meant by A mobile or tablet screen is
increasingly not used in isolation.


 Yes, you are overlooking stuff when you only consider inserting an isolated
 comment that may help. That is not the only problem and not even the main
 problem. Reading and analysing talk pages is already next to impossible in
 this environment therefore inserting an isolated comment does not help
 enough to make the experience at least bearable.
 Thanks,
   GerardM


Yeah, reading long intricate discussion on mobile sucks, but I'm not sure
how Flow will help combat that - I'm very open to being shown a wider
perspective. I'm still convinced that the primary difficulty in reading and
analyzing long, intricate, branching discussions on mobile is caused by
them being long, branching and intricate, not due to any software or
rendering issues.


 On 10 September 2014 09:47, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

  On Sep 10, 2014 9:35 AM, Gerard Meijssen gerard.meijs...@gmail.com
  wrote:
  
   Hoi.
   When you look at talk pages in isolation, you look at them on a
 computer
   screen. A mobile or tablet screen is increasingly not used in
 isolation.
 
  I'm not sure what you mean by this.
 
  It
   is where we find our new users and editors. We cannot afford to ignore
   them; they are our future. This is why tinkering with talk pages is not
  an
   option. Moving away from talk pages because of mobiles and tablets is
 the
   killer reason why we need to move away from talk pages.
  
   It is a killer reason because it makes all arguments to the contrary
 pale
   away.
   Thanks,
GerardM
 
  What I find most painful about talk pages on mobile (on the desktop skin,
  because so far I've been too impatient to find talk pages and edit
  functionality on mobile) have been that editing huge text areas really
  sucks (the scrolling and positioning the cursor is a huge pain). This is
  not limited to talk pages by the way, but is identical for mainspace
 pages.
 
  A reply button that inserts an isolated comment at the correct
 indentation
  level would fix that. Am I overlooking stuff?
  
   On 10 September 2014 09:20, Martijn Hoekstra 
 martijnhoeks...@gmail.com
   wrote:
  
On Sep 10, 2014 5:11 AM, Keegan Peterzell keegan.w...@gmail.com
  wrote:

 On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com
 wrote:

 
  FWIW, I signed my first comment by hand. I missed the comments
  about
  sigs in the wikitext editor interface. If it weren't for my
 family
  situation, I'm pretty sure I would have bailed. In any case, it
 was
  much easier to engage at WO, and that was partly- but not mostly-
  due
  to the fact that they run discussion software over there.
 
  ,Wil
 
 
 ​This - signing by hand - is pretty much a universal experience for
  new
 users, myself included.


   
   
 
 
 https://en.wikipedia.org/w/index.php?title=Talk:History_of_Alaskadiff=prevoldid=26555079
 ​


 --
 ~Keegan

 https://en.wikipedia.org/wiki/User:Keegan
   
I'm not saying that isn't crap and unwelcoming: it is, and it deters
  new
users. But it's hardly the end of the world either. By signing the
  wrong
way no real harm is done, if someone just tells you about the option
 to
  use

   
It's crap and archaic and should be fixed, but it's also an example
 of
  the
idea that there are no mistakes on a wiki. So you did something not
  right?
Great, that means you contributed. So we fix it (collaboratively) and
improve your contribution, no harm done.
   
That said, auto sign and a reply button would be a *whole* lot
  friendlier
than what we have now, and would be great improvements over the
 current
situation.
   
Flow definitely has a reply button, and automatic signing as well,
 but
  I
can't help but think that just those features in isolation would be
  better
then completely overhauling talk pages.
   
--Martijn
   

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

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Martijn Hoekstra
On Wed, Sep 10, 2014 at 2:42 PM, Risker risker...@gmail.com wrote:

 On 10 September 2014 07:54, Andrew Gray andrew.g...@dunelm.org.uk wrote:

  On 8 September 2014 08:22, David Gerard dger...@gmail.com wrote:
  snip



 
  * potential to work with Notifications (tell me when anyone replies
  to this discussion) without needing individual pings or relying on
  spotting one talkpage edit in a busy watchlist - especially since on
  some pages a comment may come two years later.
 
 

 You know, Andrew, this was always something that I thought would be one of
 the real features of Flow, one of the things that could pull people over to
 supporting the transition.  Until it got turned it on.

 I have 'watch-listed' the Flow-specific pages on Mediawikiwiki (MWW) and
 English Wikipedia for a very long time.  When they turned on notifications
 at MWW about a week ago, my mailbox and notifications were flooded - I'm
 not talking just a little bit, I mean I got so many notifications that I
 couldn't sort out the ones that weren't related to that one specific Flow
 page - and that was with a single Flow stream being watched.  I suppose I
 expected it to be like the email notices we get when a watched page gets
 edited on non-Wikipedia projects (e.g., Meta, MWW) - that is, the first
 change would generate an email/notification and nothing more until I went
 to the page itself.  From what I've been told, this isn't something that
 Echo/notifications does or was meant to do.

 I know the Flow team is scrambling to try to reduce the overwhelming nature
 of the notifications.  But it occurs to me that there was a reason why
 email notification was never turned on for Wikipedia projects - the sheer
 volume of messages that would be generated for users with hundreds or
 thousands of pages on their watchlists - and that's going to be just as
 much an issue for Flow as it would be if we just turned on those email
 messages today.  Looks brilliant on paper, but reality is a different
 thing.

 Risker/Anne


I think this is something of an oops, and not really something we should
judge the product on. Currently the broken mess is notify on all posts on
all threads on the page, which should be notify on all posts on the
subscribed thread, and possible on new threads on the watched page.
Everybody acknowledges the former is a mistake and stuff like that can
happen in testing.

--Martijn

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

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

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Martijn Hoekstra
On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialm...@gmail.com wrote:

 On 10 September 2014 17:47, Martijn Hoekstra
  I think this is something of an oops, and not really something we should
  judge the product on. Currently the broken mess is notify on all posts
 on
  all threads on the page, which should be notify on all posts on the
  subscribed thread, and possible on new threads on the watched page.

 The feature shouldn't be notify on all posts on the subscribed
 thread either. I don't want to be notified every time a new thread
 appears at any one of my watched pages.


Hence the on the subscribed thread not on any thread on the
board/watched page


 However, it's hard to tell whether such suggestions ever reach the
 development team; it's clear that this one need didn't arrive in time
 to be taken into account before the release.


Says who? What do you consider a release exactly?




  Everybody acknowledges the former is a mistake and stuff like that can
  happen in testing.

 This is not testing, this was rolled out to the production
 environment.


I'm confused. Where? Did I miss something? (please don't hesitate to say
yes if the answer is yes)


 The release has been interfering with the work of those
 editors who happen to have participated in any Flow page. This is more
 than an oops, it's affecting the mission. Why is experimentation
 still being released to all editors, instead of limiting it to those
 willing to participate in it?

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

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

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Martijn Hoekstra
On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen gerard.meijs...@gmail.com
wrote:

 Hoi,
 Asap stands for as soon as possible. It is obvious that there I do not
 like the talk pages at all. That does not mean that it makes sense to
 replace them tomorrow.

 I want us to cut the crap. Absolutely get rid of talk pages and understand
 what it is EXACTLY what the cost benefit is of such a change. When you talk
 about detailed watchlists in the context of Talk pages I have no clue
 what you are on about. It does not make sense to me at all.

 When a specific way of working insists on talk pages, it means that the
 associated workflow has to be revisited and changed with urgency. It cannot
 be permitted that special interests take the whole of the much needed
 change hostage. Leaving this material unchecked ... is FUD. It is not an
 argument that prevents change, at most it means that a different mechanism
 has to be designed for that special interest.
 Thanks,
  GerardM


Gerard,

It would really help me if you would go a little lower on the hyperbole. As
soon as possible is indeed not tomorrow. It's today. Only we both agree
that would be a very bad idea. What you probably mean is As soon as a
reasonable replacement for processes and talk pages can be found - but
when I phrase it like that, it becomes open for discussion what that
reasonable replacement could be. It makes it very hard to keep taking your
posts seriously if you keep speaking in such hyperbole.

--Martijn


 On 10 September 2014 19:25, Diego Moya dialm...@gmail.com wrote:

  Gerard, please think of the consequences of what you're proposing.
  There are features at talk pages (detailed watchlists, incremental
  diffs, true deletion of content) that allow editors and admins to
  detect and combat vandalism and remove BLP sensible material and
  libel; features which are not available in Flow as of today.
 
  Leaving this material unchecked would expose the Foundation to legal
  risk. Would you allow that possibility so that editors can edit from
  mobile devices? I hope not, but that's exactly what you've suggested.
  The tinkering is needed so that the core functions are not lost in
  the process to deploy nice-to-have features (and yes, mobile editing
  is in the nice to have category if you compare it to finding and
  removing oversightable material of sensible nature).
 
  On 10 September 2014 18:59, Gerard Meijssen gerard.meijs...@gmail.com
  wrote:
   Hoi,
   Ditch talk pages asap. In my opinion tinkering is mostly a waste of
  effort.
   Thanks,
   GerardM
  
 
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
 ___
 Wikimedia-l mailing list, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-10 Thread Martijn Hoekstra
On Wed, Sep 10, 2014 at 10:42 PM, Diego Moya dialm...@gmail.com wrote:

 On 10 September 2014 19:49, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:
  On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya dialm...@gmail.com wrote:
  The feature shouldn't be notify on all posts on the subscribed
  thread either. I don't want to be notified every time a new thread
  appears at any one of my watched pages.
 
 
  Hence the on the subscribed thread not on any thread on the
  board/watched page
 

 That doesn't make any difference, Martijn. I ''want'' to be subscribed
 to all the topics at my 3000 pages, I just don't want to get a
 notification for all them; I want to actively seek most of those at
 the watchlist in an opportunistic way.


A single thread is a single topic.



 Notifications from a few selected subset of pages would be a godsend;
 however, if it was deployed to all talk pages with the current design,
 I'd have to disable the category of notifications from conversations -
 it's simply too distracting. The howler notification widget (is that
 its name? I first heard it this week) draws all attention when it's
 activated, in particular with that bright red color; I want it to be
 activated only for things I deem important, so  that I only have to
 evaluate it for things that require my immediate evaluation. If it
 gets triggered too often, it disrupts the attention I pay to my other
 main tasks. This distinction between actively seeking updates in the
 Watchlist and passive notification from Echo seems missing from the
 design, at least for events that are not alerts.


 
  However, it's hard to tell whether such suggestions ever reach the
  development team; it's clear that this one need didn't arrive in time
  to be taken into account before the release.
 
 
  Says who? What do you consider a release exactly?
 

 Anything that can affect what an editor can see at en.wiki or any
 other community site without activating it at PreferencesBeta (that's
 the official channel for opting in to experimental features, right?)


 
 
   Everybody acknowledges the former is a mistake and stuff like that can
   happen in testing.
 
  This is not testing, this was rolled out to the production
  environment.
 
 
  I'm confused. Where? Did I miss something? (please don't hesitate to say
  yes if the answer is yes)

 Yes, editors who subscribed to Wikiproject Breakfast and Wikiproject
 Hampshire have been receiving some strange, months-old notifications
 this week from those Flow pages. Danny had to step in at en:Talk:Flow
 and recommend that users disabled notifications from Flow to avoid
 problems.

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

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

Re: [Wikimedia-l] To Flow or not to Flow

2014-09-06 Thread Martijn Hoekstra
On Sat, Sep 6, 2014 at 6:49 AM, Erik Moeller e...@wikimedia.org wrote:

 Hi all,

 snip

 Sincerely,
 Erik

 [1]
 https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html
 [2]
 https://meta.wikimedia.org/w/index.php?title=LiquidThreadsoldid=100760
 [3] https://translatewiki.net/wiki/Support
 [4] https://www.mediawiki.org/wiki/Project:Support_desk
 [5]
 https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png
 [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design
 [7] https://gerrit.wikimedia.org/r/#/c/119243/
 [8] https://www.mediawiki.org/wiki/Flow/Architecture
 --
 Erik Möller
 VP of Engineering and Product Development, Wikimedia Foundation

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



This email almost exactly embodies what I mean when I say that we are told
not to worry, everything will be OK in the earlier stages of development,
when in the later stages near deployment we're being told that the feature
has been under development for months or even years, and only *now* we come
with all these demands.

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

Re: [Wikimedia-l] Let's fix templates

2014-09-03 Thread Martijn Hoekstra
On Sep 3, 2014 4:46 AM, MZMcBride z...@mzmcbride.com wrote:

 Hi Martijn. Thanks for starting this thread.

 Martijn Hoekstra [roughly] wrote:
 * Catalog the problems with [dev issue]. Make a comprehensive list that
   enumerates the problems with [dev issue] we have now, categorise the
   problems (right now I'm roughly thinking in style, wikitext parsing
   rules and generated HTML, creation and writing issues (let's hope there
   is little of this one left after Scribunto), and usability by editors).
 * Note which quirks that lead to technical difficulties are used in the
   wild as features rather than bugs.
  * Brainstorm possible (partial) solutions.
  * Find candidates that have high bang-for-buck possible solutions
   without impeding future improvements much.
  * Refine those solutions so we know quite exactly what it will fix, what
   it won't fix, and what it would possibly break.
  * Define sane fallback procedures for when things break; this should
   mainly come from the editing communities, but could probably use some
   guidance of what is possible/easy/logical/feasible from a technical POV
   from the development community.
  * Fix [dev issue].

Yeah there are a couple of dev issues above. This email is purposefully
sent to the broadest list I could find, because it are broad issues, and
the dev community is part of the audience of this list. One of the issues
(but not the only issue) is that if templates were less troublesome, it
would be easier for dev to make great products. It would be easy to say
that is their problem, but since everyone benefits from the software being
better, helping dev by reducing template madness helps all of us.


 I don't disagree with what you're saying, but I don't think it's really
 specific to templates. We should roughly be following these steps for most
 development issues, no?

 There won't be a one size fits all approach to templates.

 In the recent discussions/debacles about technical and stylistic
advances,
 a recurring theme is that the use of some templates causes major
 headaches, and a commonly heard complaint from the developers and
 designers is that their products exhibit problems and shortcoming because
 of that. Anecdotal evidence I've lately encountered includes:
 
 * The mobile skin obfuscates talk page access because the templates
   commonly found on talk pages makes them render horribly.

 Talk page templates are dumb. We should integrate their functionality into
 a MediaWiki extension. We currently have people going around assessing
 articles on talk pages and adding talk page banners using iterator tools
 such as AutoWikiBrowser. These are fine people and they're doing fine
 work, but the mechanism by which they're doing it is sorely lacking.
 We can easily store and manage page properties such as an article's
 quality assessment or which WikiProjects are interested in the article in
 a structured database. We already track (and can query!) by many page
 properties. Let's leverage the software platform we've built.

 Regardless of whether we use a built-in tool or we continue to use
 templates, you're talking about trashing templates because of CSS issues.
 That doesn't make much sense to me. Templates make life vastly easier. We
 can likely update most talk page templates on large wikis with a single
 edit to a meta-template or perhaps even just a CSS edit. That's great!

 * The mobile skin special-cases some templates (notably issue templates
   and infoboxes) because they would render horribly.

 Second mention of the mobile skin. Perhaps it's the mobile skin that needs
 work. I think the mobile experience is horribly and painfully deficient
 and flawed. Any help you can provide in trying to make it better would
 surely be welcome. I've tried a few times and it only results in sadness.

There are a couple of interlocking problems here. Templates are often
inline styled for the desktop. Writing and maintaining inline styles is a
bit cumbersome, writing good styles that work for desktop and mobile isn't
all that easy, and those two amplify each other.

The mobile skin does the wrong thing (stripping inline styles) because the
templates have inline styles that aren't suitable for mobile, and they have
to do something to get an acceptable end result.

The templates don't have suitable styles for mobile because it's so hard to
inline style something. If the styling of the templates becomes less
cumbersome, we can start making them better suited for mobile, the mobile
skin can stop special casing them, and everyone will be happier.


 * Media-viewer has a tough time doing to correct thing with attribution
   and license information because parsing template-madness is hard.

 Structured data, a.k.a. Wikidata, as Brad noted.

 * VE development has spent a large amount of time around templates, and
   it's still one of its weakest suits. Template substitution is still a
   problem, as well as templates that produce wikitext that in itself

Re: [Wikimedia-l] Let's fix templates

2014-09-03 Thread Martijn Hoekstra
On Wed, Sep 3, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com wrote:

  tl;dr: We've been collectively whining about templates for long enough.
 Who
  wants to help with fixing them?

 I want to help fix them.


Great to hear. Getting my ass in to gear is one of my greatest weaknesses,
and from what I know from you you're really good at that. :)


  I hope we can, for the coming period, accomplish the following:
 
  * Catalog the problems with templates. Make a comprehensive list that
  enumerates the problems with templates we have now, categories the
 problems
  (right now I'm roughly thinking in style, wikitext parsing rules and
  generated HTML, creation and writing issues (let's hope there is little
 of
  this one left after Scribunto), and usability by editors).
  * Note which quirks that lead to technical difficulties are used in the
  wild as features rather than bugs.
  * Brain storm possible (partial) solutions.
  * Find candidates that have high bang-for-buck possible solutions without
  impeding future improvements much.
  * Refine those solutions so we know quite exactly what it will fix, what
 it
  won't fix, and what it would possibly break.
  * Define sane fallback procedures for when things break; this should
 mainly
  come from the editing communities, but could probably use some guidance
 of
  what is possible/easy/logical/feasible from a technical POV from the
  development community.
  * Fix templates.

 I'd like to add distribution as one of the pain points. I wanted to
 have the templates that are available on enwiki for another Mediawiki
 installation, but I couldn't get them to work. It seems like every
 template has a maze of dependencies, and when I resorted to exporting
 all of the templates from the Mediawiki site, the software
 consistently crashed before all templates were exported. I might have
 been doing it wrong, but I couldn't find any other options. Ideally,
 something like a package management system for templates, extensions,
 and skins would be a godsend.


A Mediawiki core templates pack sounds like a good idea - as would making
template and module interdependencies explicit to somewhat avoid the Great
Tangle.

aside - wikitech-l as well as #mediawiki freenode are in my experience
happy to help with individual setup woes, which could help you with the
acute import issues /aside


  What do you all think? Should we make this happen?

 I'm no template expert, but I agree with a lot of what you've said
 based on the experiences I've had. I think we should discuss this
 somewhere that is less transient than this list.


Stop rushing me all y'all! ;)


 ln short, I'm down.

 ,Wil

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

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

Re: [Wikimedia-l] Let's fix templates

2014-09-03 Thread Martijn Hoekstra
I'm thinking a page on Meta to start with. I'll get round to it when I get
home from work tonight CET.


On Wed, Sep 3, 2014 at 11:33 AM, Wil Sinclair w...@wllm.com wrote:

 Exsqueeze the ignorance. I'm still a n00b. Martijn, where should we
 set this discussion up?

 It's clear that there are several people who are interested in talking
 templates. I'm getting my hands dirty with them on another project I'm
 working on. I don't mean to rush you; just tell me what to set up for
 this discussion and where, and I'll make sure it gets done.

 ,Wil

 On Wed, Sep 3, 2014 at 1:48 AM, Martijn Hoekstra
 martijnhoeks...@gmail.com wrote:
  On Wed, Sep 3, 2014 at 10:04 AM, Wil Sinclair w...@wllm.com wrote:
 
   tl;dr: We've been collectively whining about templates for long
 enough.
  Who
   wants to help with fixing them?
 
  I want to help fix them.
 
 
  Great to hear. Getting my ass in to gear is one of my greatest
 weaknesses,
  and from what I know from you you're really good at that. :)
 
 
   I hope we can, for the coming period, accomplish the following:
  
   * Catalog the problems with templates. Make a comprehensive list that
   enumerates the problems with templates we have now, categories the
  problems
   (right now I'm roughly thinking in style, wikitext parsing rules and
   generated HTML, creation and writing issues (let's hope there is
 little
  of
   this one left after Scribunto), and usability by editors).
   * Note which quirks that lead to technical difficulties are used in
 the
   wild as features rather than bugs.
   * Brain storm possible (partial) solutions.
   * Find candidates that have high bang-for-buck possible solutions
 without
   impeding future improvements much.
   * Refine those solutions so we know quite exactly what it will fix,
 what
  it
   won't fix, and what it would possibly break.
   * Define sane fallback procedures for when things break; this should
  mainly
   come from the editing communities, but could probably use some
 guidance
  of
   what is possible/easy/logical/feasible from a technical POV from the
   development community.
   * Fix templates.
 
  I'd like to add distribution as one of the pain points. I wanted to
  have the templates that are available on enwiki for another Mediawiki
  installation, but I couldn't get them to work. It seems like every
  template has a maze of dependencies, and when I resorted to exporting
  all of the templates from the Mediawiki site, the software
  consistently crashed before all templates were exported. I might have
  been doing it wrong, but I couldn't find any other options. Ideally,
  something like a package management system for templates, extensions,
  and skins would be a godsend.
 
 
  A Mediawiki core templates pack sounds like a good idea - as would
 making
  template and module interdependencies explicit to somewhat avoid the
 Great
  Tangle.
 
  aside - wikitech-l as well as #mediawiki freenode are in my experience
  happy to help with individual setup woes, which could help you with the
  acute import issues /aside
 
 
   What do you all think? Should we make this happen?
 
  I'm no template expert, but I agree with a lot of what you've said
  based on the experiences I've had. I think we should discuss this
  somewhere that is less transient than this list.
 
 
  Stop rushing me all y'all! ;)
 
 
  ln short, I'm down.
 
  ,Wil
 
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
  ___
  Wikimedia-l mailing list, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

[Wikimedia-l] Let's fix templates

2014-09-02 Thread Martijn Hoekstra
tl;dr: We've been collectively whining about templates for long enough. Who
wants to help with fixing them?

In the recent discussions/debacles about technical and stylistic advances,
a recurring theme is that the use of some templates causes major headaches,
and a commonly heard complaint from the developers and designers is that
their products exhibit problems and shortcoming because of that. Anecdotal
evidence I've lately encountered includes:

* The mobile skin obfuscates talk page access because the templates
commonly found on talk pages makes them render horribly.
* The mobile skin special-cases some templates (notably issue templates and
infoboxes) because they would render horribly.
* Media-viewer has a tough time doing to correct thing with attribution and
license information because parsing template-madness is hard.
* VE development has spent a large amount of time around templates, and
it's still one of its weakest suits. Template substitution is still a
problem, as well as templates that produce wikitext that in itself doesn't
map cleanly to HTML tokens.
* Scribunto has been developed specifically because writing and maintaining
templates with more complicated logic is horrible, both from a
writers/maintainers perspective as well as from a performance perspective

All this together is sufficient to assert we have a template problem. The
main editing community has a problem with how templates are and must be
used, the readers have a problem with display issues on mobile as well as
style inconsistencies, the technical editing community has a problem with
writing and maintaining templates, and the development community has a
problem with the difficulty in correctly parsing and interpreting templates
and there contents.

It would be great if this problem were tackled; it would be even greater if
the WMF could work together with the community to identify the pain points,
and jointly take steps to tackle them. Templates are currently
extraordinarily powerful, and most if not all of this power is finding use
in the projects, possibly in ways nobody ever foresaw. As we all know from
Uncle Ben, with great power comes great responsibility, and it's about time
we all took our share of that responsibility, tough up, and fix it.

We should keep in mind that current use is paramount, and any fixing of
templates that breaks the wiki is frankly unacceptable, which probably
means we can't go from insane to sane overnight, even if we could define
sane and insane with regards to templates overnight. At the same time we
shouldn't shy away from fixes that would break some exotic use of
templates, if as part of the process of making things better, before
implementation, we can fix those templates.

I hope we can, for the coming period, accomplish the following:

* Catalog the problems with templates. Make a comprehensive list that
enumerates the problems with templates we have now, categories the problems
(right now I'm roughly thinking in style, wikitext parsing rules and
generated HTML, creation and writing issues (let's hope there is little of
this one left after Scribunto), and usability by editors).
* Note which quirks that lead to technical difficulties are used in the
wild as features rather than bugs.
* Brain storm possible (partial) solutions.
* Find candidates that have high bang-for-buck possible solutions without
impeding future improvements much.
* Refine those solutions so we know quite exactly what it will fix, what it
won't fix, and what it would possibly break.
* Define sane fallback procedures for when things break; this should mainly
come from the editing communities, but could probably use some guidance of
what is possible/easy/logical/feasible from a technical POV from the
development community.
* Fix templates.

Personally, I'm all talk and no action, so to get this of the ground we
would need a lot of help. First, we need to know if I'm on to something, or
if this is just the raving of a lunatic (please tell me if it is!). If the
idea is sound, we need to set up the infrastructure. We probably need a
Meta page set up to organise things and set up initial reconnaissance. We
need a lot of grunt work categorising issues and problems from all
perspectives: reader (this is difficult, but many groups that don't
directly represent the readers care deeply about their needs, so that's
something), template users, template maintainers, and template
infrastructure maintainers (developers). For that we need to reach out to
those different communities; this email is posted to wikimedia-l only
(because I couldn't think of a better one, but I acknowledge this doesn't
fit like a glove), but there are bound to be other interested parties out
there who want to help that this email isn't reaching.

What do you all think? Should we make this happen?

--Martijn
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines

Re: [Wikimedia-l] Let's fix templates

2014-09-02 Thread Martijn Hoekstra
On Tue, Sep 2, 2014 at 1:34 PM, pi zero wn.pi.z...@gmail.com wrote:

 On Tue, Sep 2, 2014 at 5:40 AM, Martijn Hoekstra 
 martijnhoeks...@gmail.com
 wrote:

  tl;dr: We've been collectively whining about templates for long enough.
 Who
  wants to help with fixing them?
 

 Improving on templates is broadly what I've been doing with my dialog tools
 https://en.wikinews.org/wiki/Help:Dialog, which I've been working on for
 about three years and am hoping to start using seriously pretty soon (I've
 got a few more tweaks in mind to do first; after that, further improvements
 I expect to be driven by experience with serious use).  I've been
 developing these tools using javascript under the hood, although I'm sure
 they could in theory be done better as a wiki extension, because I reckoned
 the design would need to be able to turn on a dime and I'd observed the
 wiki-extension approval process was, well, not.

 The dialog tools mediate passing data from page to page, using elements
 specified using wiki markup, with the particular intent that a wiki
 community could use these tools to crowdsource wizards
 https://en.wikipedia.org/wiki/Wizard_%28software%29 entirely written in
 wiki markup.

 Data is entered using input elements such as text boxes and dropdown menus,
 then passed to the next page via buttons, all placed via templates like
 {{dialog/textarea}}, {{dialog/button}}.  At the receiving page, dialog data
 can go into other input elements, but can also be substituted for template
 parameters, and expressions using template-expansion can be used to specify
 values for input elements, so that the whole thing meshes tolerably well
 with the template system rather than competing with it.  Each
 {{dialog/button}} specifies an action to be performed.  The usual action in
 the middle of a dialog is view, to display a page, but there's also an
 action edit --- hedged around with safeguards against abuse, of course;
 safeguards predicated on the assumption that admins are trustworthy.

 In designing dialog-action edit, I uncovered something curious that hints
 to me (as a programming-language designer) that the whole concept of wiki
 templates might have been subtly flawed... though I don't imagine the flaw
 could have been anticipated at the time, and I agree wholeheartedly that at
 this late date, not breaking things is paramount.  With the API edit
 action, there's an optional preload page; and I'd originally imagined that
 for dialog edit I'd want to allow the preload page to take template
 parameters; but when I actually started creating dialog edit, keeping in
 mind the sorts of wiki activities I was familiar with that one might want a
 wizard for, I realized that it was more natural to provide a form page
 that would be fully template-expanded to produce the raw content for the
 edited page.  In techspeak, this difference between preload pages with
 template-parameter substitution, versus dialog-edit forms with full
 template-expansion to generate raw content, is essentially that the preload
 page is a macro
 
 https://en.wikipedia.org/wiki/Macro_%28computer_science%29#Syntactic_macros
 ,
 while the dialog edit form is a fexpr https://en.wikipedia.org/wiki/Fexpr
 .


This is what I consider an excellent example of the power of templates, and
the power we want to have editors to have.

At the same time, it's also a great demonstration why templates suck so
much as a programming language. I can't really imagine anyone being able to
quickly (or, honestly, slowly) make much sense of
https://en.wikinews.org/w/index.php?title=Template:Dialog/buttonaction=edit
and the amount of hoops it requires you to jump through to do something
useful, like make a button.

If I quickly scan it it seems to be a template that conditionally calls a
subtemplate with different parameters, that calls a lua module which is  an
interpreter for some custom dialect of Lisp, which evaluates the string
passed in. All tied together with javascript.

If we have to resort to such magic to make templates do what we want,
templates are quite simply broken; how can we explain that to a newcomer.
To help with these templates, all you have to know about are wikitext
templates, our own implementation of lisp, Javascript, and Lua, and you'll
be good to go. I suspect the number of people in the world who know how to
do that is very close to 1. Especially for usecases like this, we need
something less complicated.
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Let's fix templates

2014-09-02 Thread Martijn Hoekstra
On Tue, Sep 2, 2014 at 4:46 PM, Brad Jorsch (Anomie) bjor...@wikimedia.org
wrote:

 This reply is still my own personal views, and in no way represents
 anything official

 On Tue, Sep 2, 2014 at 10:20 AM, Martijn Hoekstra 
 martijnhoeks...@gmail.com
  wrote:

  If we have to resort to such magic to make templates do what we want,
  templates are quite simply broken; how can we explain that to a newcomer.
  To help with these templates, all you have to know about are wikitext
  templates, our own implementation of lisp, Javascript, and Lua, and
 you'll
  be good to go. I suspect the number of people in the world who know how
 to
  do that is very close to 1. Especially for usecases like this, we need
  something less complicated.


 If we (TINW) actually want dialogs (which I'm not convinced of beyond a
 few very special cases), trying to do it in templates with embedded code is
 the wrong way to do it.


Well, that's the discussion I'm trying to open: If that's the wrong way, is
there a right way (yet) ? I'd like to look at this from the perspective of
what the correct way would be to make that happen.

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

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

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

2014-09-01 Thread Martijn Hoekstra
On Aug 31, 2014 11:46 PM, Pine W wiki.p...@gmail.com wrote:

 Just in terms of the amount of everyone's time that MediaViewer,
 Superprotect
 and related issues are absorbing, this situation is a net negative for the
 projects.
 Also, the amount of emotional hostility that this situation involves is
 disheartening.
 Personally, I would like to see us building on each other's work instead
of
 feuding,
 and I'm getting MediaViewer issue fatigue.

 WMF's principal argument against letting projects make local decisions
 about
 configurations of MediaViewer seems to be that having a multitude of site
 configurations is impractical for site maintainability and development of
 new
 features. The Technical Committee would be in a good position to make
global
 decisions on a consensus basis.

 Pine

I've heard the argument that it is difficult to maintain and develop for
having different default states of this setting across different projects,
and frankly, I'm not buying it, unless the setting is intended to be
removed completely.

Could someone explain to me how having a different default state for the
setting has much, or any, impact?

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

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

2014-09-01 Thread Martijn Hoekstra
On Sep 1, 2014 5:10 PM, Marc A. Pelletier m...@uberbox.org wrote:

 Warning, tl;dr rant below in which live my personal opinion.

Thank you for that. A heartfelt rant feels a lot better than being told my
call is important to you.

(snip)

 The fundamental issue is that the WMF is attempting to provide some
 direction, and the communities do not want any (for various and
 divergent reasons).

I don't really have all that much of a problem with direction. I have a
problem though with strong arming change, which is snap happened here.

(snip)

 The process *does* need community engagement.  That'd seriously
 increases the value of what (and how) the WMF does things, and likely
 reduce the number of bad ideas from the outset.

 But the community engagement it needs is one that is done in good faith;

Yes, from both sides. The flow example cited  in another email shows this
well. There is a large contingent of thank you for your concern. We won't
do that because we believe x rather than y, effectively closing
discussion. That's not a great atmosphere to share ideas in. Another
frequent problem is saying in the early stages not to worry, it's only the
early stages, and all that will be fixed, just come back in a few months,
and you'll see how great it'll be, and when it isn't say that earlier
feedback would have helped, but nobody showed interest in the early stages.

 something which I have yet to see more than exceptions here and there.
 It also needs fewer reactionnary hotheads.  Editing sucks.  Reading is
 lacking.  Most of the tooling is crap.  That X editors have gotten used
 to it and have implemented piles of workarounds doesn't justify keeping
 the old shit around.

 MV is a perfect example.  99% of the problems it objectively has (we
 ignore here matters of taste) derive from the difficulty of parsing the
 multitude overcomplicated templates living on File: pages to work around
 the fact that a wikitext page is complete and utter crap at storing
 metadata.  It's not an argument against MV, it's an argument for getting
 rid of the horrid way we handle File: pages with ad-hoc workarounds.

Yes! This must be said more often!

 The *correct* solution is to fix the damn image pages, not to remove MV.

The *correct* solution is to make MV bail completely on pages it fails to
parse, falling back to the known bad-but-sufficient behaviour, and maybe
adding a hidden category unparsable by MV to the image, so that it can be
addressed. If 10% of the effort spent on the long tail of template madness
was spent on implementing when in doubt, bail much debate would have been
unnecessary. Doing the right thing 90% of the time and nothing 10% of the
time is preferable over doing the right thing 98 % of the time and the
wrong thing 2%.

The same, by the way, goes for VE, which should have had bail and give me
what you have now as wikitext from the onset, and Flow which needs a bail
and convert this thread to ye olde talkpage thread (which I fear will be
batted away as reactionary crank talk, and by the time flow will be done
unneeded anyway)

-- Martijn


 How is it that the old saying goes?  'We've always done things this
 way' is the most dangerous statement in any language?

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

Re: [Wikimedia-l] Interest in a community strategic planning meeting?

2014-07-14 Thread Martijn Hoekstra
On Mon, Jul 14, 2014 at 9:25 AM, Pine W wiki.p...@gmail.com wrote:

 Hi community members,

 I'm wondering how many people might be interested in having an IRC meeting
 regarding the community's relationship to WMF and potentially developing
 our own strategic plan that would be independent of WMF. In the past few
 days I've heard some defense of WMF but mainly criticism and pessimism,
 especially people recalling past hurts and feeling powerless to negotiate
 with WMF. Perhaps it's time that we in the community create our own
 strategic plan and develop strategic options.

 Please note that this would be a long-term planning meeting and we are not
 likely to make major decisions, but we would start brainstorming and laying
 some foundations.

 Topics of possible discussion regarding our relationship with WMF:

 1. Strategic options, such as finding alternative organizations to WMF for
 hosting Wikimedia sites or creating a new hosting organization that is
 aligned with community values.


I think this isn't as mad as it may sound. It seems some editors of the
English Wikipedia have a strong dislike for many of the WMF decisions, and
distrust the WMF staff to make the calls that are best for our shared
goals, and vice versa. It's been often said that competition would be good
for the project. It would lead to duplicated effort, yes. It also gives the
opportunity to learn from each other. I have always believed, and I still
believe, that the success of English Wikipedia hinges on the ability of the
community to generate content, and that that's the absolutely most
important part of English Wikipedia - all else, including consumption by
end users - follows from that. A fork where one project is more content
creation focused, and one more end-user presentation focused, with strong
cooperation between the two projects would IMO be absolutely great. Who has
the keys to the servers is less important IMO (which also keeps the option
open for an in-house fork).

As an aside, I don't think there is such a thing as community values. I
sincerely doubt there is even such a thing as a community, or community
consensus, even for a single project (though it might (still) exist for
smaller projects), and certainly not for the WikiMedia movement as a whole.

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

Re: [Wikimedia-l] Court decision in Jones v. Dirty World Recording Entertainment LLC

2014-06-17 Thread Martijn Hoekstra
On Jun 17, 2014 3:55 AM, Kevin Godfrey kevin.darkli...@gmail.com wrote:


  On 17 Jun 2014, at 4:17 am, edward edw...@logicmuseum.com wrote:
 
  On 16/06/2014 21:07, Newyorkbrad wrote:
  In its decision, the Sixth Circuit takes a broad view of Section 230
and
  holds that Section 230 protection is not lost even where the website
  operator solicited contributors to post unsourced and uncorroborated
dirt
  about anyone they pleased, and even where the website operator selected
  which contributions would be published.
  Isn't that rather a bad thing? What was the rationale behind its view?
 

 Would this allow the WMF to exercise a degree of editorial control over
the projects without jeopardizing their S230 immunity? I'm specifically
thinking of BLPs.

 Kevin

Don't they already do that? I see office actions on rare occasions.

--Martijn

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

Re: [Wikimedia-l] [Wikimedia Announcements] [PRESS RELEASE] Airtel Offers Nigerians Free Access to Wikipedia

2014-05-29 Thread Martijn Hoekstra
On Thu, May 29, 2014 at 11:24 PM, Jens Best jens.b...@wikimedia.de wrote:

 Hi Marc,

 zero-rating a special service or a certain website on you mobile contract
 is a clever way to undermine net neutrality, even when it comes as such a
 noble service to give free knowledge to the people.

 Free knowledge of the leading global encyclopedia is surely connected with
 a totally different approach as, let's say, a certain music-streaming
 website which is included zero-rated in a mobile contract, but
 nethertheless it is way to undermine/break net neutrality. A noble cause
 doesn't necessarily make breaking an important principle unproblematic.

 There is already a discussion in the community about the prospective
 complex of problems with zero-rating as an icebreaker for introducing
 different price tags on data. It could be the time to start talking
 globally about an in-the-future exit strategy on the surely noble
 initiative e.g. when certain milestones are reached in participating
 countries/regions.

 best regards

 Jens Best


It would be interesting to hear where the EFF stands on this. I think
Wikipedia Zero is a great and awesome initiative, greatly outweighing the
possible net neutrality undermining, but I appreciate the concern.

--Martijn



 2014-05-29 23:02 GMT+02:00 Marc A. Pelletier m...@uberbox.org:

  On 05/29/2014 04:55 PM, rupert THURNER wrote:
   another sad day, wikimedia foundation as the vicarious servant of the
   telecom industry on its way destroying net neutrality.
 
  I would *really* like to hear your reasoning on this, given that there
  is absolutely nothing that prevents any telco provider from zero-rating
  Wikipedia.  Net neutrality doesn't even enter into it.
 
  What *does* enter into it, however, is that literally /millions/ more
  people now have free access to Wikipedia that could not before afford it.
 
  -- Marc
 
 
  ___
  Wikimedia-l mailing list, guidelines at:
  https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 



 --
 --
 Jens Best
 Präsidium
 Wikimedia Deutschland e.V.
 web: http://www.wikimedia.de
 mail: jens.best http://goog_17221883@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, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

Re: [Wikimedia-l] A personal note.

2014-05-28 Thread Martijn Hoekstra
On May 28, 2014 7:09 PM, Wil Sinclair w...@wllm.com wrote:

 Thanks, I wasn't aware I could do this. I'm assuming that it would be
 obvious who was an employee at Wikimedia in the log, too. I posted the
 following to Wikipediocracy a few minutes ago:

 
 I may have misread which page the rev was on, or I misunderstood the
 person who said s/he revdeleted it in thinking that it had been
 revdeleted in the previous few minutes. This is exactly why I prefer
 public recorded forums. Now no one can go back to clear up the
 confusion. For all I know, I might have to apologize for a
 misunderstanding, and it would really suck if I somehow misrepresented
 things and didn't have any opportunity to straighten things out.

 Of course, it is entirely on me. I knew that the IRC channels weren't
 logged, and that it was a bannable offense to log them (for those who
 aren't familiar with IRC, this essentially means that you aren't
 supposed to save conversations there; in most channels that's A-OK,
 but on all of the most used wikipedia channels it seems to be
 disallowed).

I think you may have misunderstood. Public logging is not allowed, but it's
fine to keep logs for yourself.

I wouldn't mind public logging myself, by the way.

Next time I have a concern, I will take it to wikimedia-l
 or one of the other mailing lists. As this example also shows, one
 can't be sure that the revs on a page within Wikimedia's wikis
 themselves won't be redacted after-the-fact. I'm not expressing an
 opinion about whether stuff should be redacted or on what grounds, but
 I am asserting that it is possible to do so.
 

Your observation is correct. It is possible to delete revisions from
history. This will be logged. I'm a little surprised you seem surprised by
this. Am I misunderstanding what you mean?


 There is a discussion about this issue there, as well. It can be
 followed at the link I posted earlier. Here's the last page of the
 discussion that includes the comment above:
 http://wikipediocracy.com/forum/viewtopic.php?f=14t=4680p=96600#p96600

 ,Wil

 On Wed, May 28, 2014 at 9:57 AM, Risker risker...@gmail.com wrote:
  Wil, the deletion log of the page in question is publicly visible.
 There
  are no WMF employees who have deleted anything on that page, ever. This
is
  information you can check for yourself instead of relying on the words
of
  others.
 
  Risker
 
 
  On 28 May 2014 12:23, Wil Sinclair w...@wllm.com wrote:
 
  Hi Fae, if you're referring to the discussion on this page, then I
  think I make it quite clear why I won't engage with WMF employees
  going forward:
  http://wikipediocracy.com/forum/viewtopic.php?f=14t=4680start=150.
 
  To be sure, I'm not used to having anyone from Lila's team immediately
  emailing her through their official company addresses as soon as I ask
  a question in a public forum. In this case, the WMF has made it quite
  clear that the IRC channels aren't official and/or sponsored by the
  WMF, and I was asking about community affairs WRT to those channels.
  So my question about why a user was kicked from the channel didn't
  have anything to do with the WMF. I still don't understand why this
  employee felt it was necessary to bring Lila's attention to safety
  concerns through official WMF employee channels, although I'm sure he
  or she felt it was the right thing to do and I've given them the
  benefit of the doubt that it was. Of course, I can't form my own
  independent opinion, since a WMF employee revdeleted the rev in
  question in the ~10 minutes between when it was first posted and when
  I tried clicking on the link.
 
  In any case, it should be made clear that the WMF did not ask me to
  disengage with employees and has not yet asked me to stop posting to
  Wikipediocracy directly. So far, the organization itself has respected
  my individuality; I can only appeal to everyone in the WP community
  and all WMF employees to do the same in the future. I will be engaging
  with the broader WP community in whatever way I can, but I've made the
  hard decision to limit my engagement with WMF employees to public,
  logged forums from now on.
 
  ,Wil
 
  On Wed, May 28, 2014 at 5:59 AM, Fæ fae...@gmail.com wrote:
   On 28/05/2014, Lila Tretikov l...@wikimedia.org wrote:
   ...
   independent individual
   able to speak with his own voice and ask his own questions. He does
not
   take direction from me. He will not work for the WMF or engage with
the
  WMF
   employees.
  
   Thanks for making these distinctions. It is sad to see that your time
   and energy is being used so early on in your introduction to the
   Wikimedia community, in creating a political distance between
yourself
   and the public actions of your life partner, due to his casual
   curiosity about Wikimedia projects. A curiosity that only manifested
   itself shortly after the public announcement of your employment by
the
   Foundation board.
  
   I do not really understand the point being made about not 

Re: [Wikimedia-l] About Wikipedia medical entries

2014-05-28 Thread Martijn Hoekstra
On Wed, May 28, 2014 at 8:18 PM, Jane Darnell jane...@gmail.com wrote:

 What I think is funny about this whole article and this email thread
 is that the quality of Wikipedia is not brought into relation with
 anything else. For example, I know that one of the main causes of
 death in the Netherlands today has to do with improper dosages of
 medicine, caused both by failure to follow instructions in the medical
 information accompanying pharmaceuticals and by mistakes in that
 medical information.

 Wikipedia may be full of mistakes, but so is the official medical
 information offered to doctors and patients.


Let's not focus on what others are doing wrong, but improve on what we may
be doing wrong - that's the only thing we have most influence on in
changing.

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

Re: [Wikimedia-l] A personal note.

2014-05-28 Thread Martijn Hoekstra


 We are all interested in hearing all sides of every story here, aren't
 we? I'm starting to get the feeling that there are things that some
 people on this list don't want *anyone* to discuss.


Which things, and which people are you aiming at, particularly?

--Martijn


 After all, you
 could simply ignore my messages or even filter them from your inbox,
 if you are so inclined. This impression has been troubling me greatly.
 Do you know that this is *precisely* what many on Wikipediocracy are
 saying about this list? Are they right?

 ,Wil

 On Wed, May 28, 2014 at 10:23 AM, Nathan nawr...@gmail.com wrote:
  On Wed, May 28, 2014 at 1:07 PM, Wil Sinclair w...@wllm.com wrote:
 
  Thanks, I wasn't aware I could do this. I'm assuming that it would be
  obvious who was an employee at Wikimedia in the log, too. I posted the
  following to Wikipediocracy a few minutes ago:
 
  
  I may have misread which page the rev was on, or I misunderstood the
  person who said s/he revdeleted it in thinking that it had been
  revdeleted in the previous few minutes. This is exactly why I prefer
  public recorded forums. Now no one can go back to clear up the
  confusion. For all I know, I might have to apologize for a
  misunderstanding, and it would really suck if I somehow misrepresented
  things and didn't have any opportunity to straighten things out.
 
  Of course, it is entirely on me. I knew that the IRC channels weren't
  logged, and that it was a bannable offense to log them (for those who
  aren't familiar with IRC, this essentially means that you aren't
  supposed to save conversations there; in most channels that's A-OK,
  but on all of the most used wikipedia channels it seems to be
  disallowed). Next time I have a concern, I will take it to wikimedia-l
  or one of the other mailing lists. As this example also shows, one
  can't be sure that the revs on a page within Wikimedia's wikis
  themselves won't be redacted after-the-fact. I'm not expressing an
  opinion about whether stuff should be redacted or on what grounds, but
  I am asserting that it is possible to do so.
  
 
  There is a discussion about this issue there, as well. It can be
  followed at the link I posted earlier. Here's the last page of the
  discussion that includes the comment above:
 
 http://wikipediocracy.com/forum/viewtopic.php?f=14t=4680p=96600#p96600
 
  ,Wil
 
 
 
  Hi Wil,
 
  This is exactly why others have suggested that you slow down, and focus
 on
  learning the basics of the Wikimedia projects and movements before
 jumping
  into the hottest, most controversial issues. It takes time to develop the
  understanding necessary to draw conclusions, especially in areas most
  likely to erupt into drama and heated exchanges.
 
  To wit, I don't believe it can even be determined if someone is logging a
  channel, and many people (including Wikimedians) log all of their
 channels.
  Several Wikimedia-related channels are publicly logged. Other channels
  prohibit people from publishing logs.
 
  It's also quite common knowledge that revisions can be deleted (by any
  administrator, where they remain viewable by administrators) or
 suppressed
  altogether (by users with Oversight rights). I think if you considered it
  with a full possession of the facts, you would agree that this is good
 and
  necessary.
 
  In any case, thank you Lila for your note! I appreciate that you have
 made
  it clear you've seen the threads of the last few weeks and understand the
  concerns that posters have described.
 
  ~Nathan
  ___
  Wikimedia-l mailing list, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

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

Re: [Wikimedia-l] Child Protection and Harassment Policy

2014-05-28 Thread Martijn Hoekstra
On Wed, May 28, 2014 at 10:32 PM, Wil Sinclair w...@wllm.com wrote:

 Martijn asked me which things I thought that some people on this list
 don't want anyone to discuss, so here are the two examples that I'm
 most interested in:

 Child Protection- I'd like to hear about ways that policy might be
 changed here to better protect children, especially given some of the
 content on Commons.


There is content on Wikipedia and on Commons, and probably on other
projects as well, that most probably doesn't find suitable for children.
What makes the matter worse is that some searches that one doesn't expect
to bring up sexually explicit content do in fact bring it up, i.e. the
famous toothbrush image. There are a couple of separate questions.

* Is the presence of sexually explicit material on commons a problem? Why?
* Is the abundance of sexually explicit material on commons a problem? Why?
* Is the unexpectedly turning up of the sexually explicit material on
commons a problem? Why?

Most agree that the presence of sexually explicit material on commons in
itself is not a problem in itself, and if it is, hosting some educational
material on sexually explicit subjects is more important than shielding
children from accessing the material.

The abundance of sexually explicit material on commons is odd, and probably
worthless. We frankly don't need any more low quality pictures and videos
of penises, masturbation, and other sexual acts that we already have lots
of. Does it really hurt us to have so much of it though? As long as it
doesn't get in the way, I'd say no. I'm not a commons person, and I know
that loads of low quality redundant sexually explicit images have already
been deleted - because it does get in the way. Should more be deleted?
Likely. Should all of it be deleted? No. So what should we do? On each
upload ask if it is a low quality sexually explicit image that doesn't
really add anything to the content that's already there? That makes for an
odd upload form. Ask those uploading not to upload more? I do believe we're
already doing that, to little effect. (correct me if I'm wrong, if we're
not, we probably should) But again, it's not it's presence that's a
problem, it's its in-the-wayness.

It has been argued, and I agree with that, that there are two categories of
people finding sexually explicit material in commons. Those explicitly
trying to find it, and those that come across it by accident. This goes for
all age groups. I think it's fairly reasonable to say that those looking
for it will find it no matter what, and that shouldn't be the focus of
improvement. What should be a focus, is improving the search functionality
so that the accidental doesn't happen, or at least doesn't happen so
ridiculously often as it does now: that is what I mean with it being in the
way, as demonstrated by the famous toothbrush search result. Categorization
and tagging could play a large role in this, as well as (recently
implemented) improvements in the search back-end. It's something that has
recently been brought up on this list. I'm horrible with the archives, but
I'm sure someone else will be able to point to the relevant discussion, and
what, if anything, has been undertaken on commons to act on this, or what
blockers we still have.

Now I've focused only on sexually explicit content, because that's whats
mostly what bothers people. Obviously, there is lots of other material I
wouldn't like to expose children to. There has been a recent discussion
about (valuable, suitable, and greatly disturbing) video material of WWII
concentration camps being on the front page of commons. There is also a lot
of images of medical issues that aren't the nicest to look at to put it
mildly, and there is a lot of material on the atrocities of war as well.
The first and third arguments go for this as well.

These problems are discussed frequently and have been quite recently. We
haven't found and implemented a solution though. What I can say is that the
'objectional images on commons' subject is a frequent subject for this
mailinglist. It's not that we don't want anyone to discuss it, but more
that we discuss it all the time, would love to fix it, and haven't been
able yet. Which makes many a little annoyed with someone from the outside
coming in with an 'hey, hey, what about all the dick pics on commons? Did
you know about those?'. We know, we're all annoyed with it, not only
because it makes us a just target of ridicule, but more importantly because
we've went over it again and again, quite often and quite recently, and we
haven't got an answer yet. The community has discussed the fairly obvious
option - an image filter - at great length, and didn't find that an
acceptable solution.



 I'd also like to hear about specific examples of
 content on Commons that a parent might not find appropriate for their
 children.


lots and lots and lots. It's not hard to find. I've already touched on some
subjects above, it should be easy to 

Re: [Wikimedia-l] About Wikipedia medical entries

2014-05-27 Thread Martijn Hoekstra
On Tue, May 27, 2014 at 4:01 PM, Marc A. Pelletier m...@uberbox.org wrote:

 On 05/27/2014 09:44 AM, Stevie Benton wrote:
  American Osteopathic Association

 I'm not an expert on the latest woo-woo, but isn't Osteopathy one of the
 numerous faith-based 'medecine'?

 -- Marc


That issue was discussed before too. From what I remember from it is that
what is called Osteopathy in the UK isn't the same thing that's called
Osteopathy in the US, where the UK one is basically voodoo, and the US one
a legitimate specialty in medicine (but correct me if I'm wrong)

-- Martijn


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

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

Re: [Wikimedia-l] About Wikipedia medical entries

2014-05-27 Thread Martijn Hoekstra
On Tue, May 27, 2014 at 4:27 PM, geni geni...@gmail.com wrote:

 On 27 May 2014 15:22, Marc A. Pelletier m...@uberbox.org wrote:

 
  Ah, that explains it.  :-)
 
  Regardless, Don't diagnose yourself with Wikipedia seems to be
  infinitely good advice, regardless of any hyperbole about article
 accuracy!
 
 

 The problem is the number of doctors who use wikipedia.


s/use wikipedia/rely on the completeness and accurancy of Wikipedia to
practice their profession/

There is nothing *wrong* with using Wikipedia as a doctor, but there may be
something wrong with the way they use it.

-- Martijn

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

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

Re: [Wikimedia-l] Child Protection Policy

2014-05-23 Thread Martijn Hoekstra
On Fri, May 23, 2014 at 8:23 PM, Wil Sinclair w...@wllm.com wrote:

 This is really helpful.

 To clarify:

 Is it correct that each project/subdomain of Wikipedia and Wikimedia
 has its own, potentially unique Child Protection Policy?
 How many of those policies are marked as Proposed?
 Are the Proposed policies enforced?
 Are there projects/subdomains of Wikipedia and Wikimedia that have no
 Child Protection Policy at all?

 I'll follow up on the issue of harassment policy in another thread,
 since it seems like Child Protection Policy has been addressed
 specifically with its own policies.

 Thanks, all!
 ,Wil


Hi Will,

See https://en.wikipedia.org/wiki/Wikipedia:Policies_and_guidelines for how
policies on Wikipedia work. The Terms of Service Federico pointed at are
probably different, but I don't know how different.

--Martijn


 On Fri, May 23, 2014 at 10:48 AM, Andrew Gray andrew.g...@dunelm.org.uk
 wrote:
  I suppose the caveat would be that what actually happens may be
  *broader* than the policy suggests, if anything (eg deleting personal
  information on a pre-emptive basis)
 
  On the English Wikipedia, see also
 
  https://en.wikipedia.org/wiki/Wikipedia:Protecting_children%27s_privacy
  https://en.wikipedia.org/wiki/Wikipedia:Guidance_for_younger_editors
  https://en.wikipedia.org/wiki/Wikipedia:Advice_for_parents
 
  In addition to the English Wikipedia policy, note that there's
  versions on four other wikis, as well. Catalan notes that theirs was
  adaptat de l'anglesa i de Commons, so probably close in general
  content, and judging by the dates on them I suspect the others had a
  similar source, but you may want to check this.
 
  The Commons policy is at:
 
  https://commons.wikimedia.org/wiki/Commons:Child_protection
 
  - also adapted from enwiki but marked as 'proposed'.
 
  There's a policy also marked as proposed on meta, dating from 2010;
  however, as it quotes the terms of service, I think we can reasonably
  conclude that the content does have the force of policy despite this
  tag :-)
 
  https://meta.wikimedia.org/wiki/Child_protection
 
  The Wikimedia-wide terms of use were formally codified in 2012 (there
  had been ToU before then, but they mostly dealt with copyright issues)
  and do include relevant material in Section 4. But I know this has
  been a topic raised on many occasions well before 2010-2012...
 
  Andrew.
 
  On 23 May 2014 18:34, George William Herbert george.herb...@gmail.com
 wrote:
 
 
 
  On May 23, 2014, at 10:09 AM, Risker risker...@gmail.com wrote:
 
  On 23 May 2014 13:05, Wil Sinclair w...@wllm.com wrote:
 
  Is the following a full statement of Wikipedia's Child Protection
  Policy, reflecting all responsibilities that the Wikipedia community
  and the Wikimedia Foundation have taken on to protect children in all
  of the projects they are involved with and/or sponsor?
 
  https://en.wikipedia.org/wiki/Wikipedia:Child_protection
 
  Are there any other *published* policies of WP or the WMF pertaining
  to child protection that I might have missed?
 
  I know that this is a very politically charged issue in the WP
  community. I'd appreciate a high light:heat ratio if anyone has
  comments beyond links to current policy statements.
 
  Thanks!
  ,Wil
 
 
  English Wikipedia policy:
  https://en.wikipedia.org/wiki/Wikipedia:Child_protection
 
  The existence of a 'formalized' policy has been a topic of heated
 debate
  since its creation, although there is some truth that its original form
  more or less documented existing practice at the time.
 
  Risker/Anne
 
  Right.
 
  I can guarantee you that the policy more or less as written will be
 implemented by most senior experienced admins.  It documented existing very
 poorly publicized informal practice in that regard.
 
  There is and has been much controversy as to whether it's good, fair,
 reasonable, appropriate.
 
  As with the responding to threats of harm essay (originally responding
 to threats of suicide, now expanded), there were considerable theory based
 top down discussions that did not resolve, followed by someone documenting
 what was actually being done most of the time and that settling is as
 precedent.
 
  This is perhaps not the best process.  However, even in the absence of
 total community support on these issues, admins and arbcom and senior
 community members will act to protect individual people and the community
 and encyclopedia and foundation.  It seems to be agreed that documenting
 usual parameters for that, so people understand the usual responses, was a
 net positive.
 
 
  -george william herbert
  george.herb...@gmail.com
 
  Sent from Kangphone
  ___
  Wikimedia-l mailing list, guidelines at:
 https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 

Re: [Wikimedia-l] Child Protection Policy

2014-05-23 Thread Martijn Hoekstra
On Fri, May 23, 2014 at 10:04 PM, Wil Sinclair w...@wllm.com wrote:

  Then stick to
 
  https://en.wikipedia.org/wiki/Wikipedia:Help_desk
 
  Straight What is the policy on X questions aren't really the purpose of
  this mailing list.
 
  --
  geni

 Thanks for the advice; that's exactly the kind of thing a newbie like
 me could use. Also, thanks for the link; I'll read through that page.
 I've gotten a lot of great information here, so I'd prefer to keep
 this thread open if anyone else has anything to contribute.

 ,Wil


We don't really have a process for closing threads. Any thread will
always be open as long as anyone wants to contribute anything.

--Martijn


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

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

Re: [Wikimedia-l] How to Criticize with Kindness

2014-05-15 Thread Martijn Hoekstra
On Thu, May 15, 2014 at 12:53 PM, Andy Mabbett a...@pigsonthewing.org.ukwrote:

 On 14 May 2014 14:26, Everton Zanella Alvarenga
 everton.alvare...@okfn.org wrote:

  How to compose a successful critical commentary [...]

 That strikes me as very long winded, and so not conducive to a
 succinct email exchange.


This style of communication is indeed quite longwinded and can be rather
cumbersome. It also creates somewhat of a mess in mailinglist archives, and
makes it far more difficult to find the exact point. It can also come
across as condescending, which can make it counterproductive, and not only
not worth the trouble, but actively harmful. There are definitely cases
where this style isn't a good idea. I should try to keep that in mind more
often.

That said, in other cases it can prevent people putting their heels in the
sand, and lead to more constructive debate, and less arguing. The initially
longer communication style in that case actually saves time (and
frustration) in the longer run. In some ways it can be compared to band-aid
fixes in software design. It might be quicker and easier now, but can lead
to headaches and trouble later. Most (all?) programming best-practices
should sometimes be avoided, and there can be a lively debate on when they
should and shouldn't be ignored. A communication style like this can be
seen as an analogy to a development best practice. Sometimes it's a good
idea, sometimes it adds nothing but hassle, and sometimes its actively
counterproductive and harmful. But it's always worth knowing and
considering, especially since mailinglists don't tend to have an --amend
switch for commits.

--Martijn



 --
 Andy Mabbett
 @pigsonthewing
 http://pigsonthewing.org.uk

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

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

Re: [Wikimedia-l] Howdy from Wil

2014-05-05 Thread Martijn Hoekstra
On Mon, May 5, 2014 at 8:30 PM, Wil Sinclair w...@wllm.com wrote:

 I'm Wil Sinclair, Lila Tretikov's significant other.

 I've always wanted a good excuse to get involved in the Wikipedia
 project and the Wikipedia community. Lila's appointment would be about
 as good as it gets. :)


Conflict of interest! Burn him!


 I'm looking forward to getting to know everyone and understanding more
 about what makes the community and the Foundation tick.


Drama, mostly


 Feel free to contact
 me directly at wllm(at)wllm(dot)com anytime about anything.


 Best.
 ,Wil


Welcome, and good luck, you brave man.

--Martijn


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

Re: [Wikimedia-l] Sponsorship/donations to other organizations

2014-04-15 Thread Martijn Hoekstra
On Tue, Apr 15, 2014 at 9:50 PM, Erik Moeller e...@wikimedia.org wrote:

 Hi folks,

 I'd be interested in hearing broader community opinions about the
 extent to which WMF should sponsor non-profits purely to support work
 that Wikimedia benefits from, even if it's not directed towards a
 specific goal established in a grant agreement.

 This comes up from time to time. One of the few historic precedents
 I'm aware of is the $5,000 donation that WMF made to FreeNode in 2006
 [1]. But there are of course many other organizations/communities that
 the Wikimedia movement is indebted to.

 On the software side, we have Ubuntu Linux (itself highly indebted to
 Debian) / Apache / MariaDB / PHP / Varnish / ElasticSearch / memcached
 / Puppet / OpenStack / various libraries and many other dependencies [2],
 infrastructure tools like ganglia, observium, icinga, etc. Some of
 these projects have nonprofits that accept and seek sponsorship and
 support, some don't.

 One could easily expand well beyond the software we depend on
 server-side to client-side open source applications used by our
 community to create content: stuff like Inkscape, GIMP and LibreOffice
 (used for diagrams). And there are other communities we depend on,
 like OpenStreetMap.

 So, should we steer clear of this type of sponsorship altogether
 because it's a slippery slope, or should we try to come up with
 evaluation criteria to consider it on a case-by-case basis (e.g. is
 there a trustworthy non-profit that has a track record of
 accomplishment and is in actual need of financial support)?

 I could imagine a process with a fixed giving back annual budget
 and a community nominations/review workflow. It'd be work to create
 and I don't want to commit to that yet, but I would be interested to
 hear opinions.

 MariaDB specifically invited WMF to become a sponsor, and we're
 clearly highly dependent on them. But I don't think it makes sense for
 us to just write checks if there's someone who asks for support and
 there's a justifiable need. However, if there's broad agreement that
 this is something Wikimedia should do more of, then I think it's worth
 developing more consistent sponsorship criteria.

 Thanks,
 Erik


 [1] https://wikimediafoundation.org/wiki/Resolution:Freenode_Donation
 [2] Cf. https://www.mediawiki.org/wiki/Upstream_projects
 --
 Erik Möller
 VP of Engineering and Product Development, Wikimedia Foundation



Hi Erik,

It's a difficult question. I'm in favour in general, and I think it's a
good idea to support projects that we use and need the money. The problem I
have with it (and that is absent in your points above) is in how far we
have the moral right to spend the money donors gave us on other projects.
Transparency to sponsors - especially since we get a lot of small donations
- is something I feel strongly about. If this were set up in a way
integrated in our fundraising policy (Donate X, allow for Y to be spent on
projects we are dependent on for example) I'd be in favour, but I'm
uncomfortable with re-gifting some random donors money to Varnish.

--Martijn


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

Re: [Wikimedia-l] Funding of decentralized organizational structure

2014-04-10 Thread Martijn Hoekstra
On Thu, Apr 10, 2014 at 3:28 PM, Anders Wennersten m...@anderswennersten.se
 wrote:

 Thanks Ting for some very interesting thoughts and for giving a few ideas
 of alternative set up of the movement. It ought to be a good input to the
 sessionre-imagine Wikipedia movement on Saturday at the Chapter Meeitng

 My reflection is that you are discussing a more decentralized approach,
 thinking todays is too centralized.

 But I do not see that you discuss the real radical decentralized model.
 Skip WMF and the Board, and let each project take care of it self including
 steering and financing. And as all info and software is free this can be
  realty momentary, if wished, the only hindrance is the use of the Logo

 I have in my mind worked through this for my pet project: Wikipedia for
 Swedish language And as far as I can see it would be doable. The cost for
 running that project on completely separate servers would be very moderate
 and the operations and board for WMSE is already a good way in
 professionalization and would probably be able to handle, both the issue of
 server operations and getting financing, a few million dollar/year would
 probably be enough to run both chapter and servers

 But would I as a committed contributer like this scenario. No (at least
 not for now).
 I am very happy that software is developed in one place to ensure it is
 not getting out of date. And I am happy all servers are run by one
 organization, bot to ensure quality but also good interconnection between
 the servers/project. Wikidata (as commons) also shows there are
 opportunistic in getting the project more integrated. Also I am very
 impressed in the professional way WMF runs the funding activities, and to
 be honest I know that even a rich country like Sweden is an net receiver of
 fundings from the people in US (shame on us swedes). So I have no interest
 of having the funding more decentralized (besides utilizing some local
 sponsors better).

 And I would be unhappy if the divergence between project became too big,
 POV paid editing etc we will be stronger as a totality if we abide to the
 same base guidelines

 So I question your urge and need to decentralize. For am as a contributer
 the most important part is that I know my inputs is securely stored and
 will not be misused by  actors like google or plain advertising. And for
 this reason I believe in a centralized structure as about today (for now)

 Anders



The thing that I'm most concerned about with regards to local fundraising
is the target audience and the fundraising entity. Who is (for example)
WMDE to have the monopoly on fundraising on de.wiki? (just as who is the
WMF to have the total monopoly on fundraising?) With a radically
distributed funding infrastructure, would that mean that the entities that
do the fundraising and collect the funds also become responsible for that
part of the infrastructure they are raising funds on? If so, who becomes
responsible for overarching infrastructure? Would it lead to inefficient
fracturing of the communities, and possibly infrastructure (not only the
hardware infrastructure, but also programmatic work)? Should we give the
donors the choice who they want to fund, WMDE or WMF (or some thorg, or a
different chapter)? Isn't this massively confusing?

I have no answers to any of these questions, but I'm happy it's on the
agenda.

--Martijn Hoekstra







 Ting Chen skrev 2014-04-10 13:23:

  Hello dear all,

 now the second mail



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

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

Re: [Wikimedia-l] WMF FDC Proposal: we invite your participation

2014-04-08 Thread Martijn Hoekstra
On Tue, Apr 8, 2014 at 12:46 AM, James Salsman jsals...@gmail.com wrote:

 Pete Forsyth wrote:
 
 ... there are very good reasons to be cautious about how much
  and what kind of advocacy the Wikimedia Foundation engages
  in, but by and large, the reasons are not *legal* ones. They're
  related to our vision, our mission, our strategic plan, and our
  model of community governance.

 Any new set of potential advocacy topics based on no editor growth
 instead of exponential editor growth should be reviewed for legality,
 compatibility with vision and mission, but not strategy or governance,
 because choices made for those topics are necessarily influenced by
 the volunteer growth rate. Thereby circular dependency in reasoning
 can be avoided. If someone implies that some of them are illegal or
 incompatible with vision or mission without saying which ones or why,
 then I generally don't take them seriously. People have had plenty of
 time to raise specific objections for specific reasons, and over time
 the extent to which they have or have not becomes significant. And I
 agree with James Alexander's concern about spreading effort too thin,
 which is why I've been trying to encourage ranking the combined set at
 http://www.allourideas.org/wmfcsdraft
 which has been picking up a little lately.


Interesting. What is it supposed to measure? If it is supposed to measure
what the Wikimedia community thinks the WMF should prioritize, it got me
fooled, and is potentially very misleading. When first looking at it I
thought it was about what I find more important. Those are to very distinct
things. It may not be measuring what you think it's measuring.



 So I hope the Foundation will survey an accurately representative
 cross-section of volunteers to find their relative preferences on a
 set of advocacy topics which assumes no editor growth instead of
 exponential editor growth. Any such survey would have design
 trade-offs involving how much to weigh preferences by volunteer
 effort, and I very much want to move on to that topic, except for the
 fact that it should be possible to collect that data and decide later
 by looking at how different rankings turn out. Which may be the only
 way to do it, because I can't figure out how to decide how much more
 important someone's opinion should be if they've made thousands of
 edits compared to someone who's made a dozen. I will raise that
 question on wiki-research-l when I come up with something that feels
 like a reasonable answer two it, or a week or two if I can't. But
 again, the Foundation can do this and should do it. Luckily community
 volunteers can do it to, so if there is ever any question about fraud
 or misconduct, that can be audited by the community, which is what
 open collaborative editing is supposed to be about.

 Best regards,
 James Salsman

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

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

Re: [Wikimedia-l] Fuck the community, who cares

2014-04-07 Thread Martijn Hoekstra
On Mon, Apr 7, 2014 at 1:37 PM, Tomasz W. Kozlowski
tom...@twkozlowski.netwrote:

 Chris Keating wrote:

  This was exactly because we wanted people to speak freely and not worry
 about a witch-hunt on an email list if a couple of trolls got hold of some
 out-of-context quotes.


 I wish you answered the question instead of smearing me on a public
 mailing list, Chris. I have no idea who you are, but I would expect you to
 adhere to elementary rules of debating, which suggest not to resort to
 personal attacks.

 If you are a Wikipedian, I should not have to explain this to you.


I call no real Scotsman.

--Martijn Hoekstra


 What a shameful comment, Chris.

 Tomasz


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

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

Re: [Wikimedia-l] Timothy Sandole and (apparently) $53, 690 of WMF funding

2014-04-01 Thread Martijn Hoekstra
 troublemakers?
Maybe promises or expectations were given to the Stanton Foundation and the
Belfer Center that left fundraising feeling there was no way back anymore?

3. [I]t was flagged internally at the WMF that paid editing is
controversial in the Wikimedia community. Despite these concerns being
raised, the residency continued unchanged.

Again, how, and why? Was it something that petered out with little
attention given?

When I read the decisions made, they leave little doubt that something like
this in the narrow sense will never happen again. Decisions 1 to 3 take
care of that very well. That's a great win, but a narrow one, it is only
relevant in the realm of a very specific kind of donation. I think we can
do better. Decision 4: The ED plans, with the C-level team, to develop a
better process for staff to escalate and express concerns about any WMF
activities that staff think may in tension with, or in violation of,
community policies or best practices. It will take some time to develop a
simple, robust process: we aim to have it done by 1 May 2014 is a step in
the right direction. Providing an effective escalation path can rectify
mistakes quickly after they happen.

What none of these do however, is provide a means how such mistakes can in
the future be avoided. The central question to me is unchanged, and
unanswered: looking at the mistakes made, why did they happen, and once we
find out that why, can we eliminate it?

--Martijn Hoekstra


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

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

Re: [Wikimedia-l] Update on search for the WMF Executive Director

2014-03-24 Thread Martijn Hoekstra
On Mon, Mar 24, 2014 at 1:56 PM, MZMcBride z...@mzmcbride.com wrote:

 Steve Zhang wrote:
 It probably means nothing, but the other day I noticed that the Executive
 Director post had been removed from the Job Openings page on the WMF wiki
 and was curious. Has there been an update on the search for the new ED,
 has Sue decided to stay or was it all just a coincidence and nothing has
 changed? :)

 Hi.

 The job posting being taken down was already noted on Meta-Wiki.[1]

 On 10 March 2014, Jan-Bart posted a status update[2] to Meta-Wiki:

 ---
 As mentioned before we have taken a different tactic in finding new
 candidates and we have met with several people and we have had several
 meetings with candidates with two or more members of the Transition Team.

 We are at a point where we have three candidates that we all feel are
 great. We hope to speak to them in the coming week or two and hope to go
 into the final process (reference checking, terms negotiation etc.) after
 that. We would then likely be looking to announce the new ED in May.

 Sue touched upon this subject during the Metrics update which took place
 on March 6th.[3] (recorded; although the whole meeting is interesting the
 ED Search update is from the 31st minute onwards)

 Jan-Bart de Vreede
 ---

 MZMcBride

 [1] https://meta.wikimedia.org/wiki/Special:Permalink/7861323#March.3F
 [2] https://meta.wikimedia.org/wiki/Special:Permalink/7861348
 [3] https://meta.wikimedia.org/wiki/Special:Permalink/7792051



This was also touched upon in the last office hours with Gayle:
https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2014-03-13starting
from
* [19:12:17] Philippe MissGayle: can you give us a brief update on the
search for ED, since you mentioned it?

--Martijn



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

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

Re: [Wikimedia-l] draft revised volunteer community survey

2014-03-17 Thread Martijn Hoekstra
On Mar 15, 2014 7:47 AM, James Salsman jsals...@gmail.com wrote:

 Oliver Keyes, okeyes at wikimedia.org, wrote:
 
 ... I don't see a lot of things that are likely enough to succeed
  and provide a meaningful impact

 That's how I feel about copyright term extension efforts, but we have
 been standing firm on them as a defense against the very real
 possibility of losses to the public domain. The sources which speak on
 the topics affecting volunteer lives can only go so far. At some point
 volunteers need to help say which efforts we think are most likely to
 help achieve our goals, including the existential threat of volunteer
 attrition.

 Here is an alternative survey method, also appropriate for statistical
 sampling and independent validation, which includes a way for everyone
 to add their own suggestions in-line in real time:

 http://www.allourideas.org/wmfcsdraft

 ... lawyers would likely consider this absolutely anathema
  to our legal restrictions around lobbying

 The legal department has had plenty of time to raise objections to any
 of the specific proposals. I would personally love for the Foundation
 to support a slate of candidates if volunteers could manage meaningful
 endorsements tied to the mission, but in the US at least, that line is
 drawn between issues and candidates, with parties being on the
 candidate side of that line. I wonder if it would be legal to formally
 endorse a green donkey in the US.

 Best regards,
 James

James, you are definitely going off the rails here, and I think you know
it. If you're trying to make a point by making ridiculous proposals, it's
probably more effective to make your point directly - I for me am rather
lost at what point you are trying to make. Maybe something with that you
think the WMF is spending too much money and effort in copyright lobbying?

If this is actually a serious proposal of something you would like to see
happen, it's probably a good idea to drop it. Nobody seems to support it.

--Martijn Hoekstra


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

Re: [Wikimedia-l] My choice for ED

2014-02-03 Thread Martijn Hoekstra
I understand your reasoning, but we already have an extremely difficult
time finding a suitable candidate. While such community vetting would
definitely weed out the people we don't want, it will also slim down the
pool we do want, which currently sits  around a cool 0. I don't think we
can afford that either.
On Feb 1, 2014 4:47 PM, Todd Allen toddmal...@gmail.com wrote:

 I'm sure dismissively calling people's legitimate concerns playing with
 (a) toy will help greatly in that regard.

 If someone's going to apply for a job where they'll be scrutinized by a
 large volunteer community, it is not unreasonable to determine if they can
 withstand that type of scrutiny by a real world test, nor to find whether
 they'll be responsive and direct to concerns brought up when that happens.
 The community has had enough of diplomatic null statements with lots of
 words, and should be. Someone needs to give an answer, not just blather on
 and wind up saying nothing concrete at all.

 It is right for the community to be fed up with that and demand that a
 candidate go through that process. Yes, it would be hard. Yes, it would
 discourage some applicants. Those are the applicants we want to discourage.
 We want someone who fits well with our particular project, and who will be
 responsive and direct with our volunteer community. They are the
 underpinnings of every project WMF undertakes.

 Todd Allen


 On Sat, Feb 1, 2014 at 8:13 AM, Tony Souter to...@iinet.net.au wrote:

  Folks: are we still playing with this toy?
 
  I've sat here and watched this discourse - variously frivolous, slightly
  insulting, and embarrassing - and said nothing in the hope it would just
  fizzle away.
 
  But amazingly, it's still here.
 
  We have to accept that while crowdsourcing is the genius of Wikipedia and
  a few of its sister projects, it's totally inappropriate for choosing the
  executive director of a big, prominent Foundation that lives in a
  competitive, complex, and often negative jungle. There's a bunch of
 reasons
  for doing this largely away from the gaze of the rest of the world. Do I
  really need to spell them out?
 
  It would be good to move on to more useful and practical topics.
 
  Tony
 
 
 
 
 
 
  On 02/02/2014, at 1:32 AM, Benjamin Lees emufarm...@gmail.com wrote:
 
   On Sat, Feb 1, 2014 at 3:29 AM, ENWP Pine deyntest...@hotmail.com
  wrote:
  
  
   Chad, I wonder if Rory has been considered. (:
  
  
   Given his history of biting newbies, I'm not sure he'd be in a good
   position to help solve the editor retention problem.
   ___
   Wikimedia-l mailing list
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
  ___
  Wikimedia-l mailing list
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] My choice for ED

2014-02-03 Thread Martijn Hoekstra
Rory is the Legal mascot, and is indeed a tiger (though some say it is
stuffed, I wouldn't bank on it). See
http://wikimediafoundation.org/wiki/Rory and
http://wikimediafoundation.org/wiki/Staff_and_contractors under legal


On Mon, Feb 3, 2014 at 12:14 PM, Tony Souter to...@iinet.net.au wrote:

 Oh what on earth are you talking about? I have no idea who Rory is. You
 need to withdraw your libelous comment.

 Tony


 On 03/02/2014, at 10:10 PM, Federico Leva (Nemo) nemow...@gmail.com
 wrote:

  Tony Souter, 01/02/2014 16:13:
  [...] totally inappropriate for choosing the executive director [...]
 in a competitive, complex, and often negative jungle.
 
  You shouldn't be blaming Rory for her origin in the jungle. Please
 refrain from commenting on specific candidates, especially if your comment
 doesn't comply with WMF's HR policies.
  https://wikimediafoundation.org/wiki/Non_discrimination_policy
  
 https://wikimediafoundation.org/wiki/Pluralism,_internationalism,_and_diversity_policy
 
 
  Nemo
 
  ___
  Wikimedia-l mailing list
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe


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

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

Re: [Wikimedia-l] WMIL Board members withdraw from international activities

2014-02-03 Thread Martijn Hoekstra
On Mon, Feb 3, 2014 at 6:40 PM, Itzik Edri it...@infra.co.il wrote:

 Hi Nathan,

 Allow me to correct - WMIL is not withdrawing from international
 activities. For example, WMIL will probably going to be one of the leading
 chapters supporting WLE, and many others international projects with others
 chapters. Alongside participating in the ChapConf and Wikimania (although
 right now it seem like we can't offer scholarships to editors from Israel
 like recent years).

 The board only asked, for a temporary period of time, from his members who
 are active in working groups and others committees, to understand that it's
 gonna be a hard year for WMIL and we need every help that they can give.
 Meaning that if before I dedicated my volunteering time 70% for the
 chapters and 30% for others international committees and for writing blog
 posts and updates, now I'm going to dedicated 100% of my time to help
 stabilize my chapter, in order to allow us soon to be back on track and
 return to our international involvement like before.

 WMIL is proud to be a leading chapters as part of the Wikimedia movement -
 and will continue to be one like that also in the future.


So, what happened exactly that makes such a change from last year? If I
interpret everything I read correctly, WMIL receives a 30% higher grant
than it received last year, and still must reduce its activities. Was the
FDC aware of these changes that require a higher budget for the same or
fewer activities, and was it taken in to consideration for the requested
grant?

Martijn





 2014-02-03 Nathan nawr...@gmail.com:

  I'm sure that the WMIL Board put a lot of thought into this decision,
 but I
  think it's a mistake. The Wikimedia movement is by nature global,
  cooperative and collective. I don't see how it will benefit either WMIL
 or
  the movement as a whole if Israeli participants withdraw from
 international
  cooperation and activity, even if they are able and willing to redirect
 the
  same energy to local fundraising efforts.
 
  Maybe the FDC did something wrong in that some applicants did not take
 the
  20% increase guardrail seriously. I hope that FDC messaging and
  communication can be improved in the future so that recipients of large
  grant increases feel grateful instead of insulted, because it is an
  obviously poor outcome if an institution receives two hundred thousand
  dollars of donor money and is so upset that it announces it is all but
  exiting the international community.
 
 
  2014-02-03 Itzik Edri it...@infra.co.il:
 
   Hello,
  
  
   Wikimedia Israel board sent earlier today a letter to the chapter
   members. For your convince I'm attaching translation to English.
  
  
   --
  
  
   Dear friends and colleagues,
  
  
   As you know, the FDC has allocated only a partial amount of the budget
   requested by Wikimedia Israel in order to execute its 2014 work plan as
   approved by the board and general assembly. Specifically, an amount of
   709,000 NIS was approved; this represents 45% of the requested
   budget
  
 
 https://meta.wikimedia.org/wiki/Grants:APG/Proposals/2013-2014_round1/Wikimedia_Israel/Proposal_form
   of
   1,553,837 NIS. Just to set the record straight, the approved amount
   suffices only to cover basic operating cost for the chapter, and is
   insufficient for expanding our projects and initiatives (we’ve stated
 as
   much in our appeal
  
 
 https://meta.wikimedia.org/wiki/Grants:APG/FDC_portal/Appeals_to_the_Board_on_the_recommendations_of_the_FDC#Wikimedia_Israel
   ).
   Nevertheless, WMF’s board turned
   down
  
 
 https://meta.wikimedia.org/wiki/Grants:APG/FDC_portal/Appeals_to_the_Board_on_the_recommendations_of_the_FDC#Board_decision_on_Wikimedia_Israel.27s_appeal
   our
   appeal, as well as WMIN’s appeal. It should be noted that the FDC
   process received criticism, and WMDE has begun an open
   discussion
  
 
 https://meta.wikimedia.org/wiki/Grants:APG/FDC_portal/Comments/Extensive_feedback_from_WMDE_to_the_FDC_process
   on
   the process, and you’re more than invited to take part.
  
  
   Needless to say, we were very disappointed from both the original
  decision
   and the rejection of our appeal, and we see both responses as stemming
  from
   irrelevant considerations, to “make an example” of WMIL (and WMIN), to
   prohibit other chapters from requesting significant budgets to allow
 them
   to grow their operation.
  
  
   This left WMIL in a difficult situation. WMIL board members and staff
  have
   been working tirelessly over the last few weeks to adapt the work plan
 to
   the reality of the low budget. Direct implications of this reality
   includes: less paid human resources required for supporting our
  volunteers
   and for becoming more professional at what we do; cuts in bursaries and
   grants to community projects, less involvement in international
 affairs,
   delaying our academic program and many additional changes.
  
  
   Nevertheless, we’re 

Re: [Wikimedia-l] Thanking anonymous users

2014-01-12 Thread Martijn Hoekstra
On Jan 13, 2014 7:25 AM, MZMcBride z...@mzmcbride.com wrote:

 Steven Walling wrote:
 With my product manager for Growth hat on... Like Kaldari said we can't
 give people who aren't logged in Echo notifications at the moment. The
 only alternative is to post to the IP talk page. This would require us to
 basically build a user account, i.e. a bot, in to Thanks to deliver a
Talk
 page message for the IP.

 I don't follow what you're saying about a bot account being the only
 alternative. You can use the exact same user interface exposure (i.e.,
 little (thanks) links) and simply post to the IP's talk page rather than
 creating an Echo (logged-in user) notification. I can't see any need for a
 separate bot account.

 That's probably not going to happen, to be honest, and there isn't the
 manpower behind Echo right now to design/build proper anonymous
 notifications. If you're gung-ho about this idea I think Nemo is right,
 just use the Talk page. :)

 Ignoring Echo and the Thanks extension-specific logging, if I had to
 guess, I imagine strictly adding in the ability to thank anonymous users
 would take about thirty minutes of work. We've had a stable API for
 posting talk page messages for years and the user interface code is
 already written and deployed. As far as I can tell, you'd simply do a
 quick check after someone clicks the thanks link and then clicks ok that
 goes something like...

 if ( target user is anon ) { post to IP talk page }

 else if ( target user is logged in ) { send Echo notification }

 If you're gung-ho about implementing the ability to thank anonymous users,
 I think the correct answer is to submit a changeset with proposed
 modifications to the Thanks extension to make that dream a reality.

 MZMcBride

Tangentially related, have we ever considered adding the required fields
for creating an account, username and password, to the edit interface for
IP editors? We could have a save edit as attributed to your IP button as we
have now, and next to it a save as new user with those two fields. Has such
a setup been discussed before? (I understand there is probably more reading
to be presented for creating an account, but there probably are reasonably
user friendly solutions to be found that don't deter the anon edit that it
would lead to a net loss of edits)




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

Re: [Wikimedia-l] Copyright infringement - The real elephant in the room

2013-11-20 Thread Martijn Hoekstra
On Nov 20, 2013 1:13 PM, The Cunctator cuncta...@gmail.com wrote:

 Yes, let's keep on pushing for policies that drive away editors!

I'm not sure exactly what kind of policy you are getting at here. Could you
elaborate a little?

 On Nov 20, 2013 2:10 AM, Fæ fae...@gmail.com wrote:

  On 19 November 2013 20:44, Samuel Klein meta...@gmail.com wrote:
   Aside @Fae: the tineye crew are curious  quite pro-freeculture, I bet
  they
   would be glad to help design a bot that uses their API to check image
   copyvios.
 
  This is an area this spins off from my little experiments with better
  management of uploads to Commons from mobile devices. I would like to
  look at this again and perhaps get a funding proposal together (or
  partnership with Tineye if they are up for it), It is one of several
  creative back-burner volunteer projects that I hope to have time to
  dig into again next year.
 
  Fae
 
  ___
  Wikimedia-l mailing list
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Office hours for VisualEditor

2013-10-31 Thread Martijn Hoekstra
On Oct 31, 2013 2:11 AM, Steve Zhang cro0...@gmail.com wrote:

 I have to say, I'm amazed such a long discussion has occured over a
 question about the time for an office hours sessions.

I'm amazed nobody has brought up leap seconds yet, which make 23:59:59 roll
over to 23:59:60 and would steal not one but two whole seconds in Tims
example.


 *Steven Zhang*
 *cro0...@gmail.com*


 On 31 October 2013 09:42, Tim Starling tstarl...@wikimedia.org wrote:

  On 31/10/13 02:51, Newyorkbrad wrote:
   In an arbitration committee election a couple of years ago, I
definitely
   recall confusion about whether a deadline of  on a given date
meant
   that the deadline expired as of the beginning of that date or the end
of
   that date.
 
  Voting periods in SecurePoll are actually half-open intervals [S, E),
  i.e. starting at exactly time S, proceeding up to but not including
  time E. So E = 2013-11-03 00:00:00 is actually the correct way to
  express a voting interval that includes the whole of 2013-11-02 and
  nothing after that. However, I have been browbeaten into using
  23:59:59 in more recent elections, thus stealing a whole second of
  potential voting time from our poor voters.
 
  -- Tim Starling
 
 
  ___
  Wikimedia-l mailing list
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Stack Exchange vs. Wikimedia

2013-09-23 Thread Martijn Hoekstra
On Mon, Sep 23, 2013 at 6:20 PM, Jan Kučera kozuc...@gmail.com wrote:

 Hi there,

 is anyone out here participating in any of the Stack Exchange projects?


Yes, I participate in Stackoverflow mainly


 Do people here still really think voting is a bad thing and wiki is the
 easiest way to collaborate?


No, and meh. But voting on a consensus driven model is bad. And a wiki is a
decent way to collaborate. It is starting to show its age (real time
collaboration as i.e. etherpad is far more awesome, but we're a decent bit
away from that). QA sites aren't a way to collaborate. They fill a
different niche.


 I have repeatedly had proposals for employing some voting mechanism at
 least on the back-stage, but no one was listening to me...

 Cheers,
 Kozuch


That's probably because voting is a bad way to create consensus.



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

Re: [Wikimedia-l] Stack Exchange vs. Wikimedia

2013-09-23 Thread Martijn Hoekstra
On Mon, Sep 23, 2013 at 6:49 PM, Federico Leva (Nemo) nemow...@gmail.comwrote:

 Jan Kučera, 23/09/2013 18:20:

  Hi there,

 is anyone out here participating in any of the Stack Exchange projects?


 http://area51.stackexchange.**com/proposals/49276/wikishttp://area51.stackexchange.com/proposals/49276/wikis


I posted on that before, and I do encourgage everybody to collaborate
there. Stackexchange is much better in QA than we are.



  Do
 people here still really think voting is a bad thing and wiki is the
 easiest way to collaborate?

 I have repeatedly had proposals for employing some voting mechanism at
 least on the back-stage, but no one was listening to me...


 Relevant bugzilla ticket (filed by you, I know): 
 https://bugzilla.wikimedia.**org/show_bug.cgi?id=29923#c13https://bugzilla.wikimedia.org/show_bug.cgi?id=29923#c13
 

 Nemo


 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe

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

Re: [Wikimedia-l] is wikipedia zero illegal because it violates net neutrality?

2013-08-27 Thread Martijn Hoekstra
On Tue, Aug 27, 2013 at 1:32 PM, Denny Vrandečić 
denny.vrande...@wikimedia.de wrote:

 2013/8/27 Federico Leva (Nemo) nemow...@gmail.com

  Denny Vrandečić, 27/08/2013 11:39:
 
   That's like saying
  printing out an article of Wikipedia and giving it to a student is a
  violation of net neutrality because we didn't print out the rest of the
  Web
  and gave it to them too.
 
 
  This analogy doesn't work very well because the we here is most likely
  not an ISP and it's only ISP being subject to net neutrality.
 
  Nemo
 

 Exactly. Neither is Wikipedia Zero an ISP, which is why the analogy does
 work. :)

 Denny


I'm rather amazed that I'm the one being called out by George Herbert for
making excessively legalistic rather than factually or
morally based remarks (which I find odd, and rather insulting at that. I
don't think I made a legalistic argument anywhere, and indeed, law tends to
be the last thing I consider in where we should stand on ethical issues). I
find this reasoning to be rule lawyering. We're not the ISP violating net
neutrality, no. It's the ISP's we actively work together with and strongly
encourage.

I now find myself in the somewhat uncomfortable position where I defend the
position where I say that this isn't a black and white issue, and net
neutrality does play a role, which makes it appear as if I think we are
doing horrible, horrible things to the world by providing Wikipedia Zero.
For clarity, that is not at all how I feel about the issue.



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

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

Re: [Wikimedia-l] is wikipedia zero illegal because it violates net neutrality?

2013-08-26 Thread Martijn Hoekstra
On Aug 26, 2013 6:30 PM, JP Béland lebo.bel...@gmail.com wrote:

 And if it is illegal or borderline according to, say,
 netherlands, swiss, or german law, is it appropriate to do it in
 countries where the law is less developed? 

 As said Kevin, it is impossible to respect the law of all countries in
 every country (Wikipedia already fails at that in its current state by
 the way, with or without Wikipedia Zero). So no we cannot just
 abstain from any
 activity which might be perceived as illegal somewhere. After that,
 are you suggesting we should apply the laws of some developed
 countries to all countries and just ignore the others, this is way
 more morally wrong in my opinion.

 That being said, the law on net neutrality you cited applies to ISP,
 which Wikipedia Zero or the WMF isn't, so it doesn't apply to it.

 But of course, we as a community and the WMF should still keep high
 ethical and moral standards.

 JP Beland
 aka Amqui



I do think there is some merit in the net neutrality argument, at least
sufficiently so to be open to discussion on whether or not offering
Wikipedia Zero is a good thing. It comes down to the question if we believe
that having a walled garden variety of internet consisting only of
Wikipedia for free, and with that undermining the market position for a
paid, open internet is a net positive. I'm inclined to say it is, but the
opposite position, though counter-intuitive, is pretty defensible.

-Martijn

 2013/8/26, Andre Engels andreeng...@gmail.com:
  Dutch telecommunication law, article 7.4a (the net neutrality article),
  paragraph 3:
 
  Aanbieders van internettoegangsdiensten stellen de hoogte van tarieven
  voor internettoegangsdiensten niet afhankelijk van de diensten en
  toepassingen die via deze diensten worden aangeboden of gebruikt.
 
  Offerers of internet access services do not make the tariffs for
internet
  access services dependent on the services and applications that are
offered
  or used via these services.
 
  If an isp offers Wikipedia for free, and some other internet usage not,
  then it has a different tariff dependent on the service that is offered.
 
 
 
  On Mon, Aug 26, 2013 at 6:05 PM, Stephen Bain stephen.b...@gmail.com
wrote:
 
  To the best of my knowledge, every jurisdiction that has legislated on
net
  neutrality has concentrated on preventing ISPs from blocking,
degrading or
  charging extra for particular services; not one of them has a problem
with
  providers giving away certain data for free.
 
  S
  On 26 Aug 2013 04:51, rupert THURNER rupert.thur...@gmail.com
wrote:
 
   hi,
  
   most people know some advantage of wikipedia zero and everybody can
   look up the advantages by just typing wikipedia zero into some search
   engine. as i am not sure about the answer and anyway get asked in
rare
   cases what i think of wp:zero i guess it should be best answered on
   the mailing list:
  
   is wikipedia zero illegal in some countries because it violates net
   neutrality? and if it is illegal or borderline according to, say,
   netherlands, swiss, or german law, is it appropriate to do it in
   countries where the law is less developed? or should wikimedia
   foundation apply a higher moral standard and just abstain from any
   activity which might be perceived as illegal somewhere?
  
   just for the ones not so sure about net neutrality [1]:
   Internet service providers and governments should treat all data on
   the Internet equally, not discriminating or charging differentially
by
   user, content, site, platform, application, type of attached
   equipment, and modes of communication.
  
   [1]  https://en.wikipedia.org/wiki/Net_neutrality
  
   rupert.
  
   ___
   Wikimedia-l mailing list
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
,
   mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
  ___
  Wikimedia-l mailing list
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
 
 
 
 
  --
  André Engels, andreeng...@gmail.com
  ___
  Wikimedia-l mailing list
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
  mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

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

Re: [Wikimedia-l] Block evasion might be a federal offense

2013-08-21 Thread Martijn Hoekstra
On Wed, Aug 21, 2013 at 10:09 AM, Peter Gervai grin...@gmail.com wrote:

 On Wed, Aug 21, 2013 at 9:37 AM, Martijn Hoekstra
 martijnhoeks...@gmail.com wrote:
  On Aug 21, 2013 8:56 AM, Peter Gervai grin...@gmail.com wrote:

  The account and/or underlying IP is
  blocked. That is the technical impediment. The action that is now a
 federal
  offense, it seems, is to defy the warning, by circumventing the block by
  changing IP and/or account to do what you were told not to do on the
  warning.

 Technicalities aside if I follow you right then it is a federal
 offense to edit Wikipedia when you were told not to (eg. banned but
 _not_ blocked). If that's the case the IP part of the discussion is
 mainly irrelevant as one does not have to evade a block to violate the
 ban.


[insert IANAL disclaimer here]

No, the linked case (and I apologize for posting a feedly link[0], it links
to an ars article, I was on my phone at the time, but the link is good)
demonstrates that if there is a ban to violate, the technical evasion of
the block becomes a crime. Evading a block without an indication to stop
seems to be not a violation, nor is editing in defiance of a ban while no
block is present.  It is quite possible that a final warning could be
considered a ban, but that's straying a bit from the original case.

[0] the target for the original link was
http://arstechnica.com/tech-policy/2013/08/changing-ip-address-to-access-public-website-ruled-violation-of-us-law/



  The central issue though, that it
  seems block evasion is a federal offense, is not affected by the
 difficulty
  in proving evidence for it. It is the question whether the evasion is a
  crime that bothers me.

 [insert meetoo here]

 g

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

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

[Wikimedia-l] Block evasion might be a federal offense

2013-08-19 Thread Martijn Hoekstra
http://feedly.com/k/14WeLcY

I wish I was grossly misrepresenting the situation here. If I am, please do
set me straight.
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Fwd: [Wikimania-l] git.wikimedia.org dead due to wikimania ; )

2013-08-10 Thread Martijn Hoekstra
On Sat, Aug 10, 2013 at 5:31 PM, Huib Laurens sterke...@gmail.com wrote:

 Hello,

 I always believed that our servers where monitored 24/7? But nobody seems
 to be arround to fix a core part in our systems?

 Huib

 -- Forwarded message --
 From: rupert THURNER rupert.thur...@gmail.com
 Date: Sat, Aug 10, 2013 at 5:24 PM
 Subject: [Wikimania-l] git.wikimedia.org dead due to wikimania ;)
 To: Wikimania general list (open subscription) 
 wikimani...@lists.wikimedia.org


 it seems git.wikimedia.org is down due:
 * no volunteer has access
 * no paid person works on weekends
 * everybody else is at wikimania

 rupert.



Doesn't this imply that nobody is at Wikimania?



 ___
 Wikimania-l mailing list
 wikimani...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikimania-l



 --
 Met vriendelijke groet,

 Huib Laurens
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe

Re: [Wikimedia-l] Visual Editor temporary opt-out

2013-08-06 Thread Martijn Hoekstra
On Tue, Aug 6, 2013 at 3:10 PM, Richard Farmbrough rich...@farmbrough.co.uk
 wrote:

 Apparently important.  I am aware, as probably everyone is, that this is
 the first most obvious step to make article editing more accessible, and
 address certain inclusiveness goals.  I am also aware that there is no data
 to support the theory that a visual editor means more inclusive editing,
 let alone that it will result in better content.

 I will simply add a couple of observations.

 The learning curve for wikitext is one of the shallowest of any
 application.  Press edit, type in the box and press save.  If you can type
 and press edit and save (the latter two of which /are/ HMI issues IMHO) you
 can edit Wikimedia projects.

 Secondly, and anecdotally, most full functioned word-processors have a
 plethora of functions that are usually only known about by the same
 tech-savvy  group that we currently believe are at home with wiki-text.

 Thirdly I vividly remember my first editing experiences - I did not think
 I would /ever /be touching stuff like infoboxes and categories, but they
 made no real obstacle to editing.  (The keyboard only method of formatting
 text took seconds to understand, and saves a huge amount of time.)

 I would not be surprised if the /choice/ of editor turns out to be the
 reason that editing has fallen off more rather than the VE itself.


Not discrediting the rest of your email, your note about that a new editor
now has to choose  which editor he would like to use is indeed a very smart
one (the paradox of choice and all that). Has any research been done or
planned on the subject?



 On 06/08/2013 08:04, MZMcBride wrote:

 I cannot and will not blame the Wikimedia Foundation for working on this
 project. It's an important project

 ...

 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe

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

Re: [Wikimedia-l] Visual Editor temporary opt-out

2013-08-06 Thread Martijn Hoekstra
On Tue, Aug 6, 2013 at 4:51 PM, Kevin Wayne Williams 
kwwilli...@kwwilliams.com wrote:

 Op 2013/08/05 23:44, MZMcBride schreef:

  This leaves us to consider the biggest question: opt-in vs. opt-out. Erik
 and James are both quite smart, they are true Wikimedians, and they make
 reasonable points about choosing opt-out over opt-in.

 This is the point on which we fundamentally disagree. Their argument for
 'opt-out' is based solely upon the quality and quantity of testing that it
 affords to VE. VE is not a mission-critical feature: while we have concerns
 about Wikipedia's sustainability, there's no question that it has survived
 for years and will survive for years more. The stability of the site is
 much more important than testing this code, and the testing strategy of
 presenting it as if it was functioning software and seeing what people did
 with it wasn't a reasonable decision: it was completely and absolutely
 irresponsible.

 KWW


Opt-out with a beta or experimental notice (as it is now when enabled on
en.wiki) doesn't seem to have the problem of presenting it if it were
mature software you present as the pivotal problem in this post.




 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe

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

Re: [Wikimedia-l] Visual Editor temporary opt-out

2013-08-06 Thread Martijn Hoekstra
On Tue, Aug 6, 2013 at 5:06 PM, Kevin Wayne Williams 
kwwilli...@kwwilliams.com wrote:

 Op 2013/08/06 7:55, Martijn Hoekstra schreef:

 On Tue, Aug 6, 2013 at 4:51 PM, Kevin Wayne Williams 
 kwwilli...@kwwilliams.com wrote:

Their argument for
 'opt-out' is based solely upon the quality and quantity of testing that
 it
 affords to VE. VE is not a mission-critical feature: while we have
 concerns
 about Wikipedia's sustainability, there's no question that it has
 survived
 for years and will survive for years more. The stability of the site is
 much more important than testing this code, and the testing strategy of
 presenting it as if it was functioning software and seeing what people
 did
 with it wasn't a reasonable decision: it was completely and absolutely
 irresponsible.


  Opt-out with a beta or experimental notice (as it is now when enabled on
 en.wiki) doesn't seem to have the problem of presenting it if it were
 mature software you present as the pivotal problem in this post.

 Their deployment strategy (not labeling the software as beta on the user
 interface, changing the function of the existing buttons, no warning when
 the software was entered, deploying it to new editors that had no chance of
 having seen notices about it) hinged on getting the unwary and uninformed
 to press the edit button without realizing what they were getting into.
 Saying that it is reasonable *now* doesn't excuse the five weeks that
 preceded it.

 KWW


No, and I'm very concerned about the deployment as it happened, as well as
its immediate aftermath. I believe those are incredibly important and hard
discussions we as a movement (and that includes you, WMF employees!) have
to have, lest things go this wrong in the future again. I find the
discussion on having opt-in or opt-out in the current situation where the
button is clearly marked as beta to be unimportant or even trivial in
comparison, and think that if we keep talking about the last implementation
disagreements, we are taking attention away from the issue that should be
discussed, which is how we can avoid a fiasco like this the next time.

--Martijn



 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe

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

Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

2013-07-30 Thread Martijn Hoekstra
On Jul 30, 2013 3:49 AM, Marc A. Pelletier m...@uberbox.org wrote:

 On 07/29/2013 07:00 PM, David Gerard wrote:
  Are there any wikitext constructions that are actually going to be
  deprecated?

 I'm not privy to the architecture decisions, but I'm pretty sure that
 the absolute worst monstrosity is the possibility of opening markup in a
 (possibly deeply recursive or, worse, conditional) template that is
 closed in a different template

I can dream up horrors you can't even imagine. Consider a template
consisting if two single quotes. For a demonstration, see
http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2

 Getting it rid of /just/ that would
 lose us no content (though it would break some frankenstein-grade
 markup) and gain us a couple orders of magnitude in parsoid reliability
 and simplicity.

 And probably would make most of the VE team cry in relief.

 -- Marc


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

Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

2013-07-30 Thread Martijn Hoekstra
On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@uberbox.org wrote:

 On 07/29/2013 10:02 PM, Rschen7754 wrote:
  If I'm reading this right, it *would* cause massive problems on the
English Wikipedia

 Oh, it *would* if the syntax was just disabled outright!

 Now, if it were me that was in charge of fixing wiki markup, this is
 what I would do:

 (a) require that syntactic elements opened in a template be closed in
 that template during transclusion* (without a change in code now; i.e.:
 deprecate but not enforce yet).
 (b) provide a mechanism by which templates which do this are
 categorized/marked and otherwise findable.
 (c) wait suitably long
 (d) convert current invalid (according to (a) and identified by (b))
 syntax by substituting still transcluded templates inline (thus not
 breaking content)
 (e) delete/blank/comment out those templates
 (f) render the previous syntax invalid (by implicitly closing any
 syntactic construct at the end of transclusion)
 (g) provide a list of all the subst done in part (d) to the community so
 that automated tools can fixup/convert/cleanup with new markup/LUA where
 applicable.

Something like the following process might be a little easier on the
projects. Assuming that ultimately want each page to be a valid fragment,
suitably defined:

Introduction period:

1. Deprecate the alternative *right now*, by publicly announcing what it is
exactly we would rather not see exist, wikitext wise.

2. Start engaging the projects, and set up wikiprojects that are
responsible for finding the cases where no reasonable alternative for the
current legitimate uses is, and work on expanding the language to make sure
these cases are covered as well as being responsible for setting up forums
for getting help on how to migrate away from depricated syntax.

Transition period:

3. For a suitably long time, display a warning when such a page is saved,
refering users to the local working group that can help them learn how to
write New Wikitext. More legitimate uses will emerge, and reasonable
alternatives must be found or created for everything we are able to do now.

4. Block the creation of new templates with deprecated syntax. Also block
saving templates that were free of deprecated syntax would an edit
introduce deprecated syntax.

5. When the wikiprojects are no longer buckling under the load of the
stream of unimagined creative and useful yet horrible uses of wikitext they
didn't forsee, and a good deal of templates have been fixed, start showing
warnings when saving pages that transclude pages with deprecated syntax.
Repeat the above steps of waiting and fixing.

6. Announce a date from where on saving a page with a transcluded legacy
template will be blocked. Expect public outcry.

7. Deal with the outcry by making a list of things yet to be fixed. Move
the deployment date to a month after all* bugs have been closed.

8. Block saving pages that contain brokenness. Expect outcry.

If outcry, roll back and go to 7.

9. With sufficient technical ingenuity, freeze and archive the dark legacy.
Don't make it mix with the brave new world.

10. Celebrate successful deployment, and wish each other a happy 2020.

An important consideration that all developers must keep in mind is that
though the current syntax is quite horrible, it also serves a purpose, and
though its existence in itself is quite horrible, the fact that it is
widely used is completely reasonable.

*: for a sufficiently reasonable value for all.


 Hopefully, whatever the delay in (c) is would need to be long enough
 that the more egregious cases or complicated templates have time enough
 to be transitioned manually, leaving the following subst/cleanup to take
 care of edge cases and little used templates where the disruption is
 nowhere as bad.

 -- Marc

 * This would include, indirectly, the code fragment templates like
 Erik describe since they contain fragments meant to be interpreted in
 the context of an open syntactic element** -- those are trickier to
 /find/, but (f) would make them pointless.
 ** Making, potentially, a giant leap towards making wikimarkup
 context-free which would solve so many problems with parsoid it's not
 even funny.



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

Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

2013-07-30 Thread Martijn Hoekstra
On Tue, Jul 30, 2013 at 9:36 AM, Peter Southwood 
peter.southw...@telkomsa.net wrote:

 Beside being  way more effort than it is worth, what is particularly
 Lovecraftian about that?
 Cheers,
 Peter


What's bad about it, is that the meaning of the transcluded content changes
radically on the context into which it is transcluded.

What's Lovecraftian about it is that it changes the syntactical meaning of
elements on the page that it is transcluded in to, without even having to
be near it.

--Martijn


A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?




 - Original Message - From: Martijn Hoekstra 
 martijnhoeks...@gmail.com
 To: Wikimedia Mailing List 
 wikimedia-l@lists.wikimedia.**orgwikimedia-l@lists.wikimedia.org
 
 Sent: Tuesday, July 30, 2013 8:39 AM
 Subject: Re: [Wikimedia-l] On the gentrification of Wikipedia, by
 Superbass (was: Visual Editor)



  On Jul 30, 2013 3:49 AM, Marc A. Pelletier m...@uberbox.org wrote:


 On 07/29/2013 07:00 PM, David Gerard wrote:
  Are there any wikitext constructions that are actually going to be
  deprecated?

 I'm not privy to the architecture decisions, but I'm pretty sure that
 the absolute worst monstrosity is the possibility of opening markup in a
 (possibly deeply recursive or, worse, conditional) template that is
 closed in a different template


 I can dream up horrors you can't even imagine. Consider a template
 consisting if two single quotes. For a demonstration, see
 http://en.Wikipedia.org/wiki/**User:Martijn_Hoekstra/**
 Lovecraftian_horror2http://en.Wikipedia.org/wiki/User:Martijn_Hoekstra/Lovecraftian_horror2

 Getting it rid of /just/ that would

 lose us no content (though it would break some frankenstein-grade
 markup) and gain us a couple orders of magnitude in parsoid reliability
 and simplicity.

 And probably would make most of the VE team cry in relief.

 -- Marc


 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l
 ,

 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe
 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe



 __**_
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.**org Wikimedia-l@lists.wikimedia.org
 Unsubscribe: 
 https://lists.wikimedia.org/**mailman/listinfo/wikimedia-lhttps://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
 mailto:wikimedia-l-request@**lists.wikimedia.orgwikimedia-l-requ...@lists.wikimedia.org
 ?subject=**unsubscribe

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

Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

2013-07-30 Thread Martijn Hoekstra
On Tue, Jul 30, 2013 at 11:43 AM, Robert Rohde raro...@gmail.com wrote:

 On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
 martijnhoeks...@gmail.com wrote:
 snip
  4. Block the creation of new templates with deprecated syntax. Also block
  saving templates that were free of deprecated syntax would an edit
  introduce deprecated syntax.
 snip

 Strictly speaking this is impossible.  While there are some common
 cases that could be recognizable on a per template basis, there are
 other cases that are only recognizable as problems when placed in the
 context in which the are used.

 To give a ridiculous example:

 A template {{foo}} consisting of  Nothing here  looks innocuous
 enough until embedded in a page that reads div{{foo}}/div.

 Because templates can contain tag, table, and other markup fragments,
 the implications for the parser aren't necessarily clear until the
 template is used in context with other elements.  So one could
 identify this as an issue when saving the page that uses it, but there
 is no general way to identify all templates that might be problematic
 at the time the template is written.

 -Robert Rohde


Drat, you are clearly right. I was hoping there was a way to dream up a
transition where at no point a seperation between old syntax transcusion
and new syntax transclusion would have to be made until the very last
moment (my step 9 above). It should still be possible to find and mark
templates that are broken through a one time exhaustive search (find all
transclusions, and check if the generated DOM for the transcluded fragment
is identical to the generated DOM of the fragment itself) and make a split
there.

My first thought was that it would be completely unfeasible bordering
impossible to do that on every page save, but now that I think of it, while
it would undoubtably be very rough on the backend, for a cause as noble as
moving away from template madness it might be worth it ( a single extra
query and the number of inclusions extra full page parses - but some parse
results could be cached for a transitional period, and you can stop once
you have found one failing parse). The WMF devs should be far more able to
estimate its impact, but It's a little soon to discuss that, as the wish to
deprecate the current semantics hasn't even been officially stated.

--Martijn


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

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

Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

2013-07-30 Thread Martijn Hoekstra
On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde raro...@gmail.com wrote:

 When discussing issues like this.  One should keep in mind that we
 don't really want to be in the business of solving hard problems
 simply by pushing the difficulties onto other people.  Wikitext has
 some characteristics that make parsing it hard (some might say
 ridiculous).  Changing wikitext will create problems elsewhere (and a
 lot of work for volunteers).  In addition one should be careful that
 any changes are made in such a way that important workflows are not
 made significantly harder for editors.


my point three wasn't something trivial, and will require a heck load of
engineering (for refrerence:
3. For a suitably long time, display a warning when such a page is saved,
referring users to the local working group that can help them learn how to
write New Wikitext. More legitimate uses will emerge, and reasonable
alternatives must be found or created for everything we are able to do now.
)



 To give a common example, see {{nom}}, which consists of:

 style=background: #FDD; color: black; vertical-align: middle;
 text-align: {{{align|center}}}; {{{style|}}} class=no table-no2 |
 Nominated

 A clever person will quickly realize that this is used in a table context
 like:

 {|
 | Golden Globes || Best Actress || {{nom}}
 |}

 Where the {{nom}} template carries with it not just the text
 Nominated but also part of the styling to be applied to the table.

 This would seem to be a hard example to reimplement in a context
 agnostic way.  At present the template content only makes sense
 because it is placed in the context of a wiki table.  Getting around
 that would seem to be awkward.  You could try to fudge it by applying
 the {{nom}} styles to something like a div block.  However, placing
 that block within the table cell would run the risk of cell padding
 and other table properties causing conflicts or bad appearance, not to
 mention that such an approach couldn't be used if the template is also
 passing colspan / rowspan directives to the cell.  Alternatively, one
 would pretty much have to pull all or most of the table into the
 template, which would seem to lead to new headaches and make the
 source that is much more complicated for authors than the present
 version.


I'm convinced that the MediaWiki devs will be able to device a way to do
this better. My markup and style foo is too weak to even speculate about
what that better may be like.



 This is one of the examples where there would seem to be few good
 alternatives.  Maybe the devs who are imagining reengineering wikitext
 can also think up good alternatives for some of the uses they might
 contemplate making obsolete?


 -Robert Rohde


When I said celebrate a happy 2020, it was a case of ha ha only serious.
There are easy nor quick fixes for these issues, and any change will not
only cost a lot of engineering, but will also require a lot of effort from
the communities to fix the breakages it will introduce, which is why I find
it so important to have this discussion long before engineering plans are
drawn up.


 P.S. {{nom}} and its sister templates are an example of templates that
 VE can't presently handle.


Which is why I think it is very important to have this discussion. I also
think I made my points on this thread and list to a sufficient level, and
will try to sit back and read what the people who really know what they are
talking about have to say about it.



 On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
 martijnhoeks...@gmail.com wrote:
  On Jul 30, 2013 4:58 AM, Marc A. Pelletier m...@uberbox.org wrote:
 
  On 07/29/2013 10:02 PM, Rschen7754 wrote:
   If I'm reading this right, it *would* cause massive problems on the
  English Wikipedia
 
  Oh, it *would* if the syntax was just disabled outright!
 
  Now, if it were me that was in charge of fixing wiki markup, this is
  what I would do:
 
  (a) require that syntactic elements opened in a template be closed in
  that template during transclusion* (without a change in code now; i.e.:
  deprecate but not enforce yet).
  (b) provide a mechanism by which templates which do this are
  categorized/marked and otherwise findable.
  (c) wait suitably long
  (d) convert current invalid (according to (a) and identified by (b))
  syntax by substituting still transcluded templates inline (thus not
  breaking content)
  (e) delete/blank/comment out those templates
  (f) render the previous syntax invalid (by implicitly closing any
  syntactic construct at the end of transclusion)
  (g) provide a list of all the subst done in part (d) to the community so
  that automated tools can fixup/convert/cleanup with new markup/LUA where
  applicable.
 
  Something like the following process might be a little easier on the
  projects. Assuming that ultimately want each page to be a valid fragment,
  suitably defined:
 
  Introduction period:
 
  1. Deprecate the alternative *right now*, by publicly announcing what

Re: [Wikimedia-l] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

2013-07-30 Thread Martijn Hoekstra
On Tue, Jul 30, 2013 at 1:01 PM, David Gerard dger...@gmail.com wrote:

 On 30 July 2013 09:06, Martijn Hoekstra martijnhoeks...@gmail.com wrote:

  6. Announce a date from where on saving a page with a transcluded legacy
  template will be blocked. Expect public outcry.
  An important consideration that all developers must keep in mind is that
  though the current syntax is quite horrible, it also serves a purpose,
 and
  though its existence in itself is quite horrible, the fact that it is
  widely used is completely reasonable.


 The question then will be how to keep parsing old versions reasonably.
 I suppose we could keep an old wikitext parser around. *shudder*

 (Or just punt the question into the long grass. Do old page versions
 pull in contemporary versions of the page's templates or use the
 current versions? If the latter, then heh, too bad.)


This *sounds* horrible, but is exactly what happens now. If a template
changes, old revisions break. I suppose that if MediaWiki would go for a
change in template semantics, an option besides letting them break, is to
substitute all 'legacy' templates into their parents last revision before
the changeover. How many revisions back one would want to do this and in
what timeframe sounds like a discussion point, but I don't see this as a
far more broken process than template changes cause right now.


 [These are technical questions, but I think they have sufficient
 impact to discuss more widely, e.g. on this list. Assuming enough
 relevant devs are around to comment.]


 - d.

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

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

Re: [Wikimedia-l] Progress...

2013-07-26 Thread Martijn Hoekstra
On Fri, Jul 26, 2013 at 1:48 PM, Fred Bauder fredb...@fairpoint.net wrote:

 As with other inventions that produced an inferior product at a much
 lower price, from the printing press to the steam-driven loom to
 Wikipedia, what happens now is largely in the hands of the people
 experimenting with the new tools, rather than defending themselves from
 them.


 http://chronicle.com/blogs/conversation/2013/07/08/moocs-and-economic-reality/

 Fred



Those bloody kids and their newfangled inventions like the steam loom and
the printing press just don't have any respect any more.

I seriously have no idea what that paragraph is trying to say.






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

Re: [Wikimedia-l] Feedback for the Wikimedia Foundation

2013-07-25 Thread Martijn Hoekstra
On Jul 24, 2013 9:57 AM, Erik Moeller e...@wikimedia.org wrote:

 On Tue, Jul 23, 2013 at 9:25 AM, Tom Morris t...@tommorris.org wrote:

  Should that even be a concern? I mean, if lots of newbies and
  technophobes start using the Visual Editor and a bunch of us
  dorks who love writing markup don't, would that matter?

 That's a great question, Tom. :)

 We're confident that in the long run, we'll be able to offer features
 and capabilities that will give experienced community members
 compelling reasons to use VisualEditor, so when people say things like
 I will never use VisualEditor, I can only note that never is a very
 long time, and the bulk of our continued effort will go into making
 VisualEditor the best possible editing experience it can be.

 This is not a feature we're launching and forgetting about. This isn't
 an effort that's scheduled to end. Enabling collaboration is part of
 our core mission; it's at the heart of what we do. We've got our work
 cut out for us for the next few months, and we also know what some of
 the longer term objectives are (integration with discussions,
 real-time collaboration). Beyond that - sky's the limit.

 So, does it matter if people continue to use markup? Probably not -
 but if you're a human, we'll aim to give you a much better tool to get
 the job done. So even if you are, as you put it, a markup-loving dork,
 we hope you'll come visit us in VisualEditor-land every once in a
 while and mingle with us. We do have cookies, and tales of template
 madness.

 Erik
 --
 Erik Möller

Speaking of template madness, the current horrible brokenness that are
templates seem to be on the long term roadmap to be fixed. Fixing them
requires breaking a whole lot, far more than a visual editor preference. Is
two way community dialog on how to handle that on the roadmap? It might
still be years and years away, but boy will it hurt, and we better brace
ourselves.

 VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikimedia-l] Russian Wikipedia in trouble /yet/ again

2013-07-10 Thread Martijn Hoekstra
On Jul 10, 2013 8:59 AM, David Gerard dger...@gmail.com wrote:

 On 10 July 2013 07:51, Fred Bauder fredb...@fairpoint.net wrote:

  It is easiest to analyze if the work has never been published.
  Distributing it then is a taking of intellectual property regardless of
  whether the original is physically taken or only a copy. The theft is of
  the possible gain lost. Actually, rather like claim jumping. It is not
  the ore that is lost but the right to mine it and profit from it.


 Fred, what's your actual point and suggested course of action with
 this thread, and what does it have to do with the original starting
 point?


 - d.

+1. Could we abandon the discussion whether or not copyright violation is
theft or not ASAP, and get this thread back to what we can do about the
possible shutdown of Russian Wikipedia? The copyright status could be
interesting for a different thread and/or meta. The discussion copyvio vs
theft may be nice for irc or Usenet or something.


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

Re: [Wikimedia-l] Blocking of HTTPS connection by China

2013-06-08 Thread Martijn Hoekstra
On Fri, Jun 7, 2013 at 6:24 PM, Matthew Roth mr...@wikimedia.org wrote:

 We have had contact with the authors of the blog and they have said they
 will publish our response to their article, though I'm not sure when or in
 what format.

 This is the content of our response:

 The Wikimedia Foundation doesn’t hold any readers of our projects in any
 less regard than others. Our mission is to bring the knowledge contained in
 the Wikimedia projects to everyone on the planet. There is no strategic
 consideration around how we can make one or another language project more
 accessible or readable in one part of the world or another. We do not have
 control over how a national government operates its censorship system. We
 also do not work with any national censorship system to limit access to
 project knowledge in any way.

 It is worth noting the blog post makes some incorrect assumptions about
 Wikimedia culture - including incorrect titling of some Wikimedia
 Foundation staff (e.g. Sue Gardner is the Executive Director of the
 Wikimedia Foundation, the non-profit that operates Wikipedia -- Wikipedia
 is written by tens of thousands of volunteers and has no director and no
 hierarchy of editors). There is also an incorrect assertion that Jimmy
 Wales has a direct role in working with our staff in making changes to core
 infrastructure. Of course Jimmy plays a role in the conversation, but he is
 participating in the conversation along with anyone else from the volunteer
 editor community.

 On the larger topic, the implementation of HTTPS by default across all
 Wikimedia sites for all readers and users is non-trivial, and a
 conversation is ongoing within the Wikimedia Foundation and within the
 community about how we might make this possible. We do have plans to
 eventually enable HTTPS as the default, but it's difficult and we're taking
 steps toward this goal over time.

 Our first step is to force HTTPS for logged-in users. The next step will be
 to expand our SSL cluster and to do some testing on a wiki-by-wiki basis
 with anonymous HTTPS. At some point later we'll attempt to enable HTTPS for
 anons on all projects. Then we'll look at enabling HSTS, so that browsers
 know they should always use HTTPS to access our sites.


 We've only had proper native HTTPS for about a year and a half. We
 attempted to force HTTPS by default for logged-in users last month and
 rolled it back. We'll be attempting this again soon. So, it's something
 we're actively working on. We've also hard-enabled HTTPS on all of our
 private wikis and have soft-enabled HTTPS on a single wiki (Uzbek
 Wikipedia), when it was requested by the volunteer editor community there.



Great response, which makes it clear that there is no politically biased
motives here, just techinical issues. I hope they will be publishing it in
some sort of decent form, though unfortunately the damage is generally
never restored, it might go a long way.

On a tiny side note: Is calling non logged in users on official
communications a good idea? I've always found it to be sounding quite
denigrating.









 On Fri, Jun 7, 2013 at 6:50 AM, shi zhao shiz...@gmail.com wrote:

  https://upload.wikimedia.org also blocked
  Chinese wikipedia: http://zh.wikipedia.org/
  My blog: http://shizhao.org
  twitter: https://twitter.com/shizhao
 
  [[zh:User:Shizhao]]
 
 
  2013/6/7 Benjamin Chen bencmqw...@gmail.com:
   Hi,
  
   Since 31 May, China's Great Firewall has blocked the HTTPS connection
 to
  all language versions of Wikipedia, by blocking port 443 on two of our
 IPs.
  I was also told that service to Wikimedia Commons may be affected. Other
  projects, such as en.wikisource are not affected by this block (but they
  may still be subjected to keyword censoring on HTTP).
  
   Compared to the previous short-lived half-day block, this time the
 block
  has been in place for a week and as usual no one knows if it will last
 for
  long.
  
   Here is an article that has some explanation, some comments, and
 (their)
  opinions and suggestions for the Foundation.
  
  
 
 https://en.greatfire.org/blog/2013/jun/wikipedia-drops-ball-china-not-too-late-make-amends
  
   Regards,
  
   Benjamin Chen / [[User:Bencmq]]
  
  
   ___
   Wikimedia-l mailing list
   Wikimedia-l@lists.wikimedia.org
   Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
 
  ___
  Wikimedia-l mailing list
  Wikimedia-l@lists.wikimedia.org
  Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
 



 --

 Matthew Roth
 Global Communications Manager
 Wikimedia Foundation
 +1.415.839.6885 ext 6635
 www.wikimediafoundation.org
 *http://blog.wikimedia.org/*
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Somebody Will

2013-06-03 Thread Martijn Hoekstra
On Jun 3, 2013 2:17 PM, Sumana Harihareswara suma...@wikimedia.org
wrote:

 Cynics, skip this message!

 http://www.sassafrassmusic.com/songs/sci-fi-fantasy-fandom/somebody-will/

 I came across this sentimental song about a world of encouragement and
 productivity, in which everyone is encouraged to create, support and
 work toward ideals and it reminded me of our shared mission,

Also, classic Marxism. Draw your own conclusions and parallels as you see
fit.

so I
 wanted to share it with you.
 -Sumana

 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))

2013-01-08 Thread Martijn Hoekstra
On Jan 9, 2013 1:07 AM, Kim Bruning k...@bruning.xs4all.nl wrote:

 On Fri, Jan 04, 2013 at 03:51:42PM -0800, George Herbert wrote:
  Along the lines of noneuclidian geometry...
 
  What if we experiment (at least conceptually) with inverting that
  instruction?  Encourage people to write on subjects they know...
 
  Normal people won't be so much of an expert that using their own
  professional or academic work as a reference is even applicable.
 
  Actual experts, we can include a Please cite your sources, rather
  than your own work, thanks! and leave it at that.
 
  Actual experts who fail to heed that are a problem, but a much smaller
  and easier to communicate with and explain problem than the no-newbies
  one.

 You know, this is starting to sound like we're the 2001 wikipedia to
provide
 input to the nascent Nupedia? ;-)

 My proposal would be to replace AFC with an unstable branch wikipedia.
 (And cherry-pick from there). This proposal has the upside that it uses
proven
 technology and processes ;-)

 sincerely,
 Kim bruning


So, how bold are you? Also: where is the sign up page? I think I'd feel
very much at home on a wiki that is a wiki.


 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))

2013-01-04 Thread Martijn Hoekstra
This thread may have started weird, but it seems to be going in a very good
direction: we're all very concerned about editor retention, we all see
problem areas we agree on, and we are all grasping at new ideas that seem
more or less like straws. This is bad news, but it has to remain on the
agenda, and we have to keep thinking about it or the project runs the risk
of actually failing - the very thing we all laughed away for a long time
seeing wikipedia's success.

When I look back on my wiki time, I see a transition much as Erik
described. I joined in 2005 with the great influx that was going on, or
just coming to an end at the time. The editors who were there, who learned
me the ropes, still very strongly believed in WP:IAR, and the 'it's just a
guideline' principle. What I believe happened is that a new generation of
editors - roughly new editors since the time I joined - who didn't create
the rules had more distance from the rules, and in some ways more respect
for them. These are the vandalism fighters and the new page patrollers
Risker mentions were - and are - very needed. If they are not here, we
might well collapse under the load of bad faith edits. Everyone obviously
believes that their view of what wikipedia is is right, but I believe they
don't grok wikipedia. They don't grok the meaning of a wiki, and neither do
they grok IAR. And yet we need them desperately. As a community we started
revering the rules over the project, and that's very very wrong.

I'm going to go ahead and postulate that the greatest problem with editor
retention is that it is really really hard to do something good for
wikipedia - too hard for many people - and far harder still to grok
wikipedia. This is a two sided problem. The first side is the problem for
new editors: We have set up rules to justify fixing the good faith errors
they have made which are enforced quite strictly. To grok wikipedia you
need experience. As a rule of thumb, I would say about 1000 edits which are
not anti-vandalism edits, and you could grok it. I am willing to go
further, and say that none or very few of those 1000 edits will actually be
very good. But we don't have the manpower in experience to guide all those
1000 edits, kindly explain what's wrong with them, and that it's absolutely
fine that the edits aren't very good. Before that moment has arrived, we
will have had a good meaning good faith vandal fighter strongly
discouraging this user. It's a miracle people even make it this far.

So what can we do? Well, first off, we could stop bothering new editors
about the rules. There are far too many anyway, and while they are a fun
mental exercise for the experienced wikipedian, a new wikipedian only needs
to know a few things: Don't act like a dick, be bold, content should be
verifiable, and you are here for the project - not personal gain. An editor
writes the most horrific sucky article ever, but passes those above rules?
Cool! Thanks! Carry on! Feedback can come later, he already took the hurdle
of writing something that passes the basic rules. (note this is not how
[[WP:AfC]] works). An editor breaks one of the above rules? Take ownership
and responsibility for the rule. If you agree to the rule, you don't need
the blue link to tell him what they did wrong. Hey, you wrote this and
that article, and you didn't name your sources. Without them our readers
will rightfully question the truthfullness - to them, it's just some guy on
the internet who wrote that. Could you fix that? No need to bother them
with the finer points of [[WP:V]] and [[WP:RS]]. They're just policy pages
- a pretty nifty summary of consensus.

Now that might be a little awkward and getting used to for our editing
community, but there is another painful truth out there. The people who
have the ability to properly understand wikipedia are spread far to thin to
give this personal attention to newcomers, attention they very much need to
come to be grown up wikipedians, and still be productive in their own
right. We need a cure for that. We tried the cure of dedicated vandal
fighters, and it didn't work, it landed us in the situation where we are
now. We need something else, and whatever that something else will be, it
will be very very painful, and will go against everything our wikispirit
stands for, and we will hate it, but it will be needed. Possibly flagged
revisions on all pages. Possibly a far simpler blocking policy (I for one
strongly support abolishing any form of time-expiring block which are
punitive almost by definition. You are blocked indefinitely, and you are
unblocked if you ask for it, and give a good reason why the problematic
behaviour won't be recurring. There is never a reason to unblock because
three days have passed) If some administrator has the strong feeling that
they are not here to build an encyclopedia, begone. Is that fair? No. There
is a large factor of arbitarity there, mistakes will be made, and it
requires far more responsibility from our 

Re: [Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))

2013-01-04 Thread Martijn Hoekstra
On Fri, Jan 4, 2013 at 8:36 PM, Steven Walling steven.wall...@gmail.comwrote:

 On Fri, Jan 4, 2013 at 5:03 AM, Fred Bauder fredb...@fairpoint.net
 wrote:

  With respect to welcoming and assisting new users on the English
  Wikipedia where there is a bewildering volume of varied activity by new
  and experienced users it might be helpful if we had a recent changes
  options that showed only edit by new editors with less than say 100 edits
  that could be monitored. Newbie helpers could then welcome, comment,
  compliment, or otherwise assist the new user. Obviously access to such a
  recent changes option by those looking for trouble could also be used in
  ways that would discourage the new user. Perhaps access could be limited
  to only flagged newbie helpers.
 

 These aren't power tools like what vandalfighters have in Huggle or
 Twinkle, but I would check out the two following feeds of new editor
 activity, if you want to give this kind of task a try:

 --

 https://en.wikipedia.org/w/index.php?title=Special:Contributionscontribs=newbie
 shows newbie edits of all sorts


This is pretty cool cool. How hard would it be to hack together something
like the curation tool for which I have much love, but for recent changes
by newbies instead?


 -- https://en.wikipedia.org/wiki/Special:FeedbackDashboard which shows the
 positive, negative, and just plain confused comments by new editors who
 have at least clicked the edit button once. This one in particular needs
 attention from thoughtful, experienced contributors.

 Steven
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Editor retention (was Re: Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))

2013-01-04 Thread Martijn Hoekstra
On Jan 5, 2013 12:51 AM, George Herbert george.herb...@gmail.com wrote:

 On Fri, Jan 4, 2013 at 10:05 AM, David Gerard dger...@gmail.com wrote:
  On 4 January 2013 17:56, Mark delir...@hackish.org wrote:
 
  1a. Do *not* pick a source that you have a particularly close personal
or
  emotional connection to: it is not good to start with your own
research,
  your supervisor's or colleague's research, a project of yours or that
you're
  involved with, a nationalist/political/religious subject you feel
strongly
  about, the history of your own family, etc.
 
 
  This can be a problem in that people will become interested first in
  fixing something they think is wrong because they know about it. I do
  realise all the steps from that to here, and that a list of
  instructions pretty much won't be read.

 Along the lines of noneuclidian geometry...

 What if we experiment (at least conceptually) with inverting that
 instruction?  Encourage people to write on subjects they know...

 Normal people won't be so much of an expert that using their own
 professional or academic work as a reference is even applicable.

 Actual experts, we can include a Please cite your sources, rather
 than your own work, thanks! and leave it at that.

 Actual experts who fail to heed that are a problem, but a much smaller
 and easier to communicate with and explain problem than the no-newbies
 one.
 .


Please resubmit this suggestion after three hours of AfC work


 --
 -george william herbert
 george.herb...@gmail.com

 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Big data benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices)

2013-01-03 Thread Martijn Hoekstra
On Jan 3, 2013 11:01 AM, Thomas Morton morton.tho...@googlemail.com
wrote:

 On 3 January 2013 06:38, Tim Starling tstarl...@wikimedia.org wrote:

  You don't need big data to see what needs to be done.


 It might help; often it is surprising how statistical analysis can help
 narrow the focus of such efforts.

 For example; it is taken as a given that incivility drives away new users,
 but do we have hard statistical evidence to back that up?

We don't even have a proper working definition of civilty, stats of how
many times and how early in their editing life someone has been uncivil to
would be hard to come by.

And if that is a
 true situation, can we identify specifically what uncivil things are
 driving the most editors away (rudeness, templating, etc.).


Editor retention programmes have some data there. Check wp:wer on en.wiki.
how the data for the other projects match up I don't know.

 Although please lets do it without words like big data, which makes me
 squirm :P

Can we make use of big microdata for future projects?



 Tom
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Language links and double language links on the Wikipedias

2012-06-26 Thread Martijn Hoekstra
This number, 99.2% was also mentioned on the Berlin Hackathon. It
sounds much higher than what my (very scientifically relevant,
obviously) gut feeling tells me. Could you indicate where this number
is coming from?

On Tue, Jun 26, 2012 at 2:45 PM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
 Ziko,

 it does not jeopardize the Wikidata goal -- the current language link
 system won't be switched off, but can be further used. Everything that
 is working currently will still be possible afterwards. Wikidata can
 still be used to represent the 99.2% of language links that are simple
 -- this would still be a huge improvement over the current state.

 As soon as these are out of the way, we can think about if and how to
 extend the system in order to deal with the rest.

 Cheers,
 Denny

 2012/6/25 Ziko van Dijk vand...@wmnederland.nl:
 Hello,

 So may I guess that double links are usually the result of a
 Wikipedian who was not sure which language link to set, so in doubt,
 he simply put in the language links for two different articles?

 And in general, is it imagineable that different languages divide the
 knowledge in different ways, which could jeopardize the whole goal of
 Wikidata unifiying the language links?

 Kind regards
 Ziko


 2012/6/25 Delirium delir...@hackish.org:
 Thanks for this list. For the languages I know, I've started going through
 and fixing ones that are clearly wrong. If a number of people do that, that
 should improve the general quality/consistency of interwiki links. I second
 the other comment that it'd be nice if the parsing could be re-run to
 exclude commented-out links, but the list is still useful as is.

 There are some difficult cases, though, when languages make different
 choices on how to group subjects, so the articles aren't actually in 1-to-1
 correspondence. For example, the English article [[en: Móði and Magni]]
 unsurprisingly has two outgoing interwiki links, when linking to languages
 that split them, such as [[da:Magni]] and [[da:Modi]]. It's not clear what
 to do about these cases.

 Best,
 Mark


 On 6/25/12 12:29 PM, Denny Vrandečić wrote:

 Hi all,

 I ran some analysis last week, to get some numbers out of the
 Wikipedia language links. One type of reports that were generated was
 the list of all articles in the main namespaces of the Wikipedias that
 link to more than one article in another language edition of Wikipedia
 (so called double language links). There are not that many of them
 (about 19,000 in total), split by language, all available here:

 http://simia.net/languagelinks/

 Double language links are not errors per se, but they contain a few
 nuisances
 * they lead to two links in the language links list that just look the
 same (you have to hover over them to see that they link to different
 languages), which is not really optimal from the user experience side
 * they are not saved in the langlinks table and thus are ignored in
 certain reports and also in the respective export

 I am not sure how to reach out to the respective Wikipedia
 communities, or if I should at all. Should I post to their respective
 version of the village pump? Remembering from the time I was active on
 the Croatian Wikipedia, I would have appreciated that list to check
 the entries. I reckoned the wikipedia-l list would be the right place,
 but that list looks rather dead.

 Cheers,
 Denny



 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l



 --

 ---
 Vereniging Wikimedia Nederland
 dr. Ziko van Dijk, voorzitter
 http://wmnederland.nl/

 Wikimedia Nederland
 Postbus 167
 3500 AD Utrecht
 ---

 ___
 Wikimedia-l mailing list
 Wikimedia-l@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.

 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] Who invoked principle of least surprise for the image filter?

2012-06-23 Thread Martijn Hoekstra
Jussi, I'm not finding the post you are replying too, what's the context here?

On Sat, Jun 23, 2012 at 3:29 AM, Jussi-Ville Heiskanen
cimonav...@gmail.com wrote:
 The core problem here is that the Board is not alive and well.
 The Board of Trustees is dead in their shoes. What precisely
 are they *Trustees* of?

 --
 --
 Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]

 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] CheckUser openness

2012-06-15 Thread Martijn Hoekstra
Two points that might help bring people on different sides of the
issue closer together.

1. How about notifying people that they have been check-usered 2
months after the fact? By that time I hope all investigations are
complete, and is the risk of tipping off the nefarious should be over.

2. Though the strategies of when to checkuser and how to interpret the
results are private, the workings of CheckUser are not. It is free
software, and its useage described at
http://www.mediawiki.org/wiki/Extension:CheckUser I would imagine any
tech-savy user with malicioius intent will check how CheckUser can be
used to detect their malicious editing, and what means they have to
avoid detection. Notifying someone they have been checkusered does not
give them any information they didn't have already, apart from being
under investigation.

On Fri, Jun 15, 2012 at 8:43 AM, Neil Babbage n...@thebabbages.com wrote:

 Notification of some checks would always have to be withheld to allow complex 
 investigations to be completed without tipping off. There is public 
 information that suggests there have been complex abuse cases (real abuse, 
 like harassment, not vandalism). To notify parties suspected of involvement 
 while these long running investigations are underway is broadly analogous to 
 receiving an automated email when your name is searched on the FBI national 
 computer: the innocent want an explanation that wastes police time; the 
 guilty realise they are being investigated and are tipped off to adapt their 
 behaviour.  As soon as there is an option to suppress the alert you are back 
 to square 1: CUs may suppress the notification to hide what they are doing.

 End of the day, the communities elected the CUs knowing they'd be able to 
 secretly check private data - so you have to trust them to do what you ask 
 them to do or elect someone else you do trust.


 Neil / QuiteUnusual@Wikibooks

 -Original Message-
 From: Nathan nawr...@gmail.com
 Sender: wikimedia-l-boun...@lists.wikimedia.org
 Date: Thu, 14 Jun 2012 22:10:33
 To: Wikimedia Mailing Listwikimedia-l@lists.wikimedia.org
 Reply-To: Wikimedia Mailing List wikimedia-l@lists.wikimedia.org
 Subject: Re: [Wikimedia-l] CheckUser openness

 On Thu, Jun 14, 2012 at 8:06 PM, Dominic McDevitt-Parks
 mcdev...@gmail.comwrote:

 I think the idea that making the log of checks public will necessarily be
 a service to those subject to CheckUser is misguided. One of the best
 reasons for keeping the logs private is not security through obscurity but
 the prevention of unwarranted stigma and drama. Most checks (which aren't
 just scanning a vandal or persistent sockpuppeteer's IP for other accounts)
 are performed because there is some amount of uncertainty. Not all checks
 are positive, and a negative result doesn't necessarily mean the check was
 unwarranted. I think those who have been checked without a public request
 deserve not to have suspicion cast on them by public logs if the check did
 not produce evidence of guilt. At the same time, because even justified
 checks will often upset the subject, the CheckUser deserves to be able to
 act on valid suspicions without fear of retaliation. The community doesn't
 need the discord that a public log would generate. That's not to say that
 there should be no oversight, but that a public log is not the way to do it.


 Dominic


 The threat of stigma can be ameliorated by not making the logs public,
 which was never suggested. A simple system notification of The data you
 provide to the Wikimedia web servers has been checked by a checkuser on
 this project, see [[wp:checkuser]] for more information would be enough.

 En Pine's reply to my queries seems calibrated for someone who is
 unfamiliar with SPI and checkuser work. I'm not - in fact I worked as a
 clerk with checkusers at SPI for a long time and am quite familiar with the
 process and its limitations. I know what's disclosed, approximately how
 frequently checks are run, the general proportion of checks that are public
 vs. all checks, etc. I still am not clear on how disclosing the fact of a
 check helps socks avoid detection, and I still believe that it's worthwhile
 for a transparent organization like Wikimedia to alert users when their
 private information (information that is, as Risker has mentioned,
 potentially personally identifying) has been disclosed to another
 volunteer.

 Nathan
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] CheckUser openness

2012-06-15 Thread Martijn Hoekstra
On Fri, Jun 15, 2012 at 11:18 AM, Stephanie Daugherty
sdaughe...@gmail.com wrote:
 On Fri, Jun 15, 2012 at 4:52 AM, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

 Two points that might help bring people on different sides of the
 issue closer together.

 1. How about notifying people that they have been check-usered 2
 months after the fact? By that time I hope all investigations are
 complete, and is the risk of tipping off the nefarious should be over.

 That's an interesting concept, and I'd think this would be the only way to
 notify users without compromising the effectiveness of the tool, but I
 still have serious reservations about disclosure here for reasons
 previously cited and below. Also, there are conceivably complex abuse cases
 where an investigation would take longer than 2 months, particularly in the
 sort of cases that eventually end up before en.wiki's arbcom.



 2. Though the strategies of when to checkuser and how to interpret the
 results are private, the workings of CheckUser are not. It is free
 software, and its useage described at
 http://www.mediawiki.org/wiki/Extension:CheckUser I would imagine any
 tech-savy user with malicioius intent will check how CheckUser can be
 used to detect their malicious editing, and what means they have to
 avoid detection. Notifying someone they have been checkusered does not
 give them any information they didn't have already, apart from being
 under investigation.


 The privacy rules surrounding it are very much public as well. That makes
 the effectiveness of checkuser as a tool very much dependent on
 carelessness or ignorance of person targeted, things we want to preserve as
 much as possible lest checkuser stop being effective or massive relaxation
 of privacy policies become necessary to preserve its effectiveness.


Am I correct to summorise here than that CU works because people don't
know it doesn't?

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l


Re: [Wikimedia-l] CheckUser openness

2012-06-15 Thread Martijn Hoekstra
On Fri, Jun 15, 2012 at 9:51 PM, ENWP Pine deyntest...@hotmail.com wrote:

 Hi Nathan,

 For a moment, let's suppose that there is a global policy that all CU
 checks must be disclosed to the person being checked, with the
 information
 disclosed in private email, and only consisting of the date of the check
 and the user who performed the check. What benefit does this have to the
 user who was checked? This information doesn't make the user more secure,
 it doesn't make the user's information more private, and there are no
 actions that the user is asked to take. Perhaps there is a benefit, but I
 am having difficulty thinking of what that benefit would be. I can think
 of
 how this information would benefit a dishonest user, but not how it would
 benefit an honest user. If there is a valuable benefit that an honest
 user
 receives from this information, what is it?

 Thanks,


 Pine


 Pine: As you have said, checkuser oversight comes from AUSC, ArbCom and
 the
 ombudspeople. These groups typically respond to requests and complaints
 (well, the ombuds commission typically doesn't respond at all). But you
 only know to make a request or complaint if you know you've been CU'd. So
 notifying people that they have been CU'd would allow them to follow up
 with the oversight bodies. My guess is most would choose not to, but at
 least some might have a reason to. It's also plain that even if there is
 no
 recourse, people will want to know if their identifying information has
 been disclosed.


 Hi Nathan,

 Thanks, I think I understand your points better now. Let me see if I can
 respond. I'm not a Checkuser or CU clerk, and I am commenting only from my
 limited ability to get information as an outsider.

 If we notify all users who have been CU'd as we are discussing, what I
 speculate will happen is an increase in the volume of people who contact the
 CU who used the tool, their local AUSC or ArbCom, other local CUs, OTRS, and
 the ombudsmen. This will increase the workload of emailed questions for the
 CU who used the tool and anyone else who might be contacted. This increase
 in workload could require an increase the number of people on AUSC or other
 audit groups who have access to the tool in order to supervise the CUs who
 are doing the front-line work, and this increase in the number of CUs makes
 it more possible for a bad CU to slip through.

 Another other problem that I foresee is that if a user appeals the original
 CU decision to another CU or any group that audits CUs, then the user is put
 in the position of trusting that whoever reviews the first CU's work is
 themselves trustworthy and competent. The user still doesn't get the
 personal authority to review and debate the details of the CU's work. Since
 my understanding is that CUs already check each other's work, I'm unsure
 that an increase in inquiries and appeals to supervisory groups would lead
 to a meaningful improvement as compared to the current system in CU accuracy
 or data privacy.

 So, what I foresee is an increase in workload for audit groups, but little
 meaningful increase to the assurance that the CU tool and data are used and
 contained properly. Additionally, as has been mentioned before, I worry
 about the risk of giving sockpuppets additional information that they might
 be able to use to evade detection.

 I agree with you that there might be bad CUs in the current system, although
 personally I haven't heard of any. Where I think we differ is on the
 question of what should be done to limit the risk of bad CUs while balancing
 other considerations. At this point, I think the available public evidence
 is that there are more problems with sophisticated and persistent
 sockpuppets than there are problems with current CUs. I hope and believe
 that current CUs and auditors are generally honest, competent, and vigilant
 about watching each other's work.

 Pine


I do hear and understand the argument here, but it is somewhat
problematic to have to have the argument if we do this, we'll be
handing over information to sockpuppeteers we don't want them to have,
and we can't tell you what that information is, because otherwise
we'll be handing over information to sockpuppeteers we don't want them
to have. While I think the methods currently used are probably sound,
and the information would indeed give them more possibilities to evade
the system, I can't be sure of it, because I can't be told what that
information is.

I don't think this is a viable long-term strategy. The Audit Committee
is a way around this, but as indicated before, there is somewhat of an
overlap between the committee and the Check-User in-crowd, which could
(again, could, I'm not sure if it is indeed true).

Apart from the 'timed release' of information I proposed earlier, I
don't really see a viable solution for this, as I doubt we have enough
people that are sufficiently qualified on a technical level to
actually judge the checkuser results, who also have 

Re: [Wikimedia-l] Wikimedia events: staging area?

2012-04-19 Thread Martijn Hoekstra
If we can't manage to set this up on-project because of rules, we
collectively fail Wiki 101

On Thu, Apr 19, 2012 at 6:06 PM, Kevin Gorman kgor...@gmail.com wrote:
 If we don't want to develop an internal solution, it would be pretty
 simple to set up a private flickr album and email it out to all
 attendees for feedback.

 
 Kevin Gorman
 user:kgorman-ucb

 On Thu, Apr 19, 2012 at 8:07 AM, Samuel Klein meta...@gmail.com wrote:
 However this is done, it could also be a cheap first pass at a
 quarantine for images being worked on with a GLAM institution as well,
 while cleaned up / license-cleared / de-duped.

 S.

 On Thu, Apr 19, 2012 at 8:26 AM, Sage Ross ragesoss+wikipe...@gmail.com 
 wrote:
 On Thu, Apr 19, 2012 at 8:19 AM, Lodewijk lodew...@effeietsanders.org 
 wrote:
 Hi all,

 With all the Wikimedia events it is a problem that keeps coming back:
 whether participants do or do not want to be photographed. Often we get to
 a very crude binary result: either everything is allowed, or nothing at
 all. And still most people seem to violate that simply.

 Hence, I was thinking whether a more personal and photo specific option
 would be available - allowing people to veto certain pictures before they
 get 'really' published. After all, Commons doesn't allow deletion simply
 because you dont like the quality or dont want to become public in that
 position.

 Would it be an option to create a staging area, where people can upload
 their event photos of Wikimedia events, and where people can simply veto
 their own pictures? The vetoing doesnt have to be water tight, but rather
 easy. A password to enter the staging area for that specific event could be
 given to the participants where they can check the photos and veto them.
 Then we can proceed with 'no veto = published' and mass upload the
 non-vetoed photos after a while to Wikimedia Commons.

 If we can develop this centrally (and make it available to all Wikimedia
 events) or install something on Wikimedia servers that already does this,
 that would save a lot of event organizers headaches. Any feedback, anyone
 who would be willing and able to pick this up?



 This is a really good idea, Lodewijk!

 Keeping track of who does and doesn't want their photos up on Commons
 (and which photos they want) can be quite a hassle.

 -Sage

 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l



 --
 Samuel Klein          identi.ca:sj           w:user:sj          +1 617 529 
 4266

 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

 ___
 Wikimedia-l mailing list
 Wikimedia-l@lists.wikimedia.org
 Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l

___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l