[Wikimedia-l] Re: About raising money

[Martijn Hoekstra]

>
>
>
> So now we're left with how we raise money, and the common complaints about
> the size, frequency, and tone of fundraising banners. The argument is that
> fundraising messages use unduly alarmist language, and that donors are
> therefore misled into thinking that Wikimedia is facing imminent danger. I
> do believe that not enough credit is given to the people who craft those
> messages in banners and emails. These people care an extraordinary amount
> about doing the "right thing." They have literally spent years doing A/B
> tests to soften the tone and figure out the least alarming language
> possible to raise the required amounts. All that while enduring constant
> criticism of their work. They are heroes.
>
> But beyond that, there is also a real sense of urgency that the most vocal
> of us here generally do not sense. There are very real threats to our
> mission, much closer in time than we imagine. [5] Assuming that, just
> because we've been around and successful for 20 years, we'll be around and
> just as successful for the next 20, is wishful thinking underpinned by
> normalcy bias. [6]
>
> [5] https://meta.wikimedia.org/wiki/2018_Revenue_strategy/Summary
> [6] https://en.wikipedia.org/wiki/Normalcy_bias
>

Stressing the good will and effort of the people who craft these messages
to do the right thing is important. That doesn't make the outcome beyond
reproach though. Questioning the outcome doesn't have to involve
questioning the good will and effort of these people. Getting the
impression that questioning the outcome in some way makes people believe it
questions the good will and effort of these people is hurtful.

Without going in to that point too far, is there data on whether the
perception of donors about the financial situation of the foundation
reflects reality, what donors think the WMF spends money on vs what it
spends it on, and perceptions vs reality of after how much time which
projects would go black without new funding. I have the anecdotal
impression these lay pretty far apart, but anecdotal impressions don't make
data.

If we don't at least have a common understanding of those facts, we can
argue about this for another two decades without coming any closer to an
understanding.
___
Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/72J4E7BLNJRXNQ75PBEE6RBAPNBEW6VB/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

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

[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: 
https://meta.wikimedia

Re: [Wikimedia-l] Foundation management of volunteers

[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

[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 i

Re: [Wikimedia-l] Foundation management of volunteers

[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, 201

Re: [Wikimedia-l] Foundation management of volunteers

[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

[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&S 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: Wikime

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

[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

[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&S 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&s 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

[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&s 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 non-resp

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

[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)

[Martijn Hoekstra]

On Fri, Dec 5, 2014 at 7:11 PM, phoebe ayers  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/

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

[Martijn Hoekstra]

On Thu, Dec 4, 2014 at 9:26 PM, MZMcBride  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
> , 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:
> . 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,
> 
>
___
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

[Martijn Hoekstra]

On Dec 4, 2014 2:46 PM, "Jean-Frédéric"  wrote:
>
> > Thanks again, I tried to remain brie-f
>
>
> 2014-12-03 18:06 GMT+00:00 Christophe Henner :
>
> > 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,

___
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] Fundraising banners (again)

[Martijn Hoekstra]

On Dec 3, 2014 12:00 PM, "Federico Leva (Nemo)"  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] Fundraising banners (again)

[Martijn Hoekstra]

On Dec 3, 2014 3:46 AM, "Ryan Lane"  wrote:
>
> Megan Hernandez  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

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

[Martijn Hoekstra]

On Nov 26, 2014 11:21 PM, "Kim Bruning"  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, 

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

[Martijn Hoekstra]

On Oct 25, 2014 8:03 PM, "Amir E. Aharoni" 
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" 
> כתב:
>
> > On Oct 25, 2014 7:20 PM, "Amir E. Aharoni" 
> > 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" 
> > כתב:
> > > > >
> > > > > > 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 . 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"

[Martijn Hoekstra]

On Oct 25, 2014 7:20 PM, "Amir E. Aharoni" 
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" 
> כתב:
>
> > On Oct 25, 2014 6:17 PM, "Amir E. Aharoni" 
> > 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"  כתב:
> > >
> > > > 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 . 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"

[Martijn Hoekstra]

On Oct 25, 2014 6:17 PM, "Amir E. Aharoni" 
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"  כתב:
>
> > 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 . 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,
> > 
> ___
> 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,

___
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] To Flow: on featured article discussions

[Martijn Hoekstra]

On Mon, Sep 15, 2014 at 7:24 PM, Danny Horn  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, 

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

[Martijn Hoekstra]

On Thursday, September 11, 2014, John Mark Vandenberg 
wrote:

> On Thu, Sep 11, 2014 at 8:21 AM, Wil Sinclair  > 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,
>  ?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, 

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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 10:42 PM, Diego Moya  wrote:

> On 10 September 2014 19:49, Martijn Hoekstra 
> wrote:
> > On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya  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 Preferences>Beta (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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 7:54 PM, Gerard Meijssen 
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  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 
> > 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,
> > 
> >
> ___
> 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,
> 
>
___
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] To Flow or not to Flow

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 7:17 PM, Diego Moya  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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 2:42 PM, Risker  wrote:

> On 10 September 2014 07:54, Andrew Gray  wrote:
>
> > On 8 September 2014 08:22, David Gerard  wrote:
> > 
>
>
>
> >
> > * 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
> 
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
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] To Flow or not to Flow

[Martijn Hoekstra]

I'd like to note that the following is my personal opinion, and any
resemblance to the opinions of the Wikipedia community or any parts therof,
Jimmy Wales, the NSA, the Dutch government, Y-combinator, the national
library of Australia, the British Housewives' League, and/or any other
opinion of any individual and/or organisation is purely coincidental. (am I
doing this right?)

On Wed, Sep 10, 2014 at 10:28 AM, Keegan Peterzell 
wrote:

> In case it's not clear enough in my sig, this is my personal opinion:
>
> On Wed, Sep 10, 2014 at 12:20 AM, Martijn Hoekstra <
> martijnhoeks...@gmail.com> wrote:
>
> > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" 
> wrote:
> > >
> > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  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_Alaska&diff=prev&oldid=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.
>
>
> ​I agree with you, Martjin. If you follow the cookie crumbs you'd see that
> I registered an account on the English Wikipedia /solely/ so I could sign a
> complaint about a resource I used and loved, and I thought it best to give
> respect back by registering and figuring out how to sign my complaint. I
> was also incredibly lucky as a n00b to have positive interactions, right
> from the get-go, which makes it a little more clear to me why I'm still
> around after all this time. I'm thirty-three years old, to me a nine-year
> unintentional commitment is a lifetime :)
>
> I'm also aware, through my experiences through the past nine years, that my
> experience is Golden™, and I desperately wish all new users could have such
> an experience.
>
> This kind of thing starts with software changes that break my workflow. I
> hate that. But to be fair, my workflow is ridiculous because the software
> is.​
>
> ​The steps I have to take to do the things that I do would, IMO, make a
> rational person cry :).  I really don't understand the theory that new
> users have to go through the same experiences as I did, no matter how
> pleasant, again IMO, my experiences were.


Neither do I, really - which is why I support auto signing and a
quick-reply button added to the current interface

Hazing is an antiquated and
> unfruitful process. It only breaks people down to rebuild them in the image
> that you want, and that's contradictory to the individualism that Wikimedia
> promotes.


I think you're attacking a straw man. I certainly want new users to have a
positive experience, and not, in your words haze them.


> I enjoy the fact that Wikimedia sites allow flexibility and
> customization on a personal account and institutional level. On the other
> hand, the world keeps moving and I sta​y in the same place unless I choose
> to go through the process of acceptance of a changing world. I do not
> consider the world changing to be something shoved down my throat; it's a
> reality of life.
>
> --
> ~Keegan
>
> https://en.wikipedia.org/wiki/User:Keegan
>
> 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

[Martijn Hoekstra]

On Wed, Sep 10, 2014 at 9:55 AM, Gerard Meijssen 
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 
> wrote:
>
> > On Sep 10, 2014 9:35 AM, "Gerard Meijssen" 
> > 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" 
> > wrote:
> > > > >
> > > > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair 
> 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_Alaska&diff=prev&oldid=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

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

[Martijn Hoekstra]

On Sep 10, 2014 9:35 AM, "Gerard Meijssen" 
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 
> wrote:
>
> > On Sep 10, 2014 5:11 AM, "Keegan Peterzell" 
wrote:
> > >
> > > On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  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_Alaska&diff=prev&oldid=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

[Martijn Hoekstra]

On Sep 10, 2014 5:11 AM, "Keegan Peterzell"  wrote:
>
> On Tue, Sep 9, 2014 at 10:04 AM, Wil Sinclair  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_Alaska&diff=prev&oldid=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,

___
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] To Flow or not to Flow

[Martijn Hoekstra]

On Sat, Sep 6, 2014 at 6:49 AM, Erik Moeller  wrote:

> Hi all,
>
> 
>
> Sincerely,
> Erik
>
> [1]
> https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html
> [2]
> https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=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,
> 



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, 

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

[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  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
>  wrote:
> > On Wed, Sep 3, 2014 at 10:04 AM, Wil Sinclair  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>

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

[Martijn Hoekstra]

On Wed, Sep 3, 2014 at 10:04 AM, Wil Sinclair  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,
> 
>
___
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] Let's fix templates

[Martijn Hoekstra]

On Sep 3, 2014 4:46 AM, "MZMcBride"  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 mobil

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

[Martijn Hoekstra]

On Tue, Sep 2, 2014 at 4:46 PM, Brad Jorsch (Anomie) 
wrote:

>  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] Let's fix templates

[Martijn Hoekstra]

On Tue, Sep 2, 2014 at 1:34 PM, pi zero  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/button&action=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>

[Wikimedia-l] Let's fix templates

[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
Wikimedia

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

[Martijn Hoekstra]

On Sep 1, 2014 5:10 PM, "Marc A. Pelletier"  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, 

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

[Martijn Hoekstra]

On Aug 31, 2014 11:46 PM, "Pine W"  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,

___
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] Interest in a community strategic planning meeting?

[Martijn Hoekstra]

On Mon, Jul 14, 2014 at 9:25 AM, Pine W  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, 

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

[Martijn Hoekstra]

On Jun 17, 2014 3:55 AM, "Kevin Godfrey"  wrote:
>
>
> > On 17 Jun 2014, at 4:17 am, edward  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,

___
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 Announcements] [PRESS RELEASE] Airtel Offers Nigerians Free Access to Wikipedia

[Martijn Hoekstra]

On Thu, May 29, 2014 at 11:24 PM, Jens Best  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 :
>
> > 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,
> > 
> >
>
>
>
> --
> --
> Jens Best
> Präsidium
> Wikimedia Deutschland e.V.
> web: http://www.wikimedia.de
> mail: jens.best @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,
> 
>
___
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 and Harassment Policy

[Martijn Hoekstra]

On Wed, May 28, 2014 at 10:32 PM, Wil Sinclair  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 find.

Re: [Wikimedia-l] A personal note.

[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  wrote:
> > On Wed, May 28, 2014 at 1:07 PM, Wil Sinclair  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=14&t=4680&p=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,
> 
>
> ___
> 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,
> 
>
___
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] About Wikipedia medical entries

[Martijn Hoekstra]

On Wed, May 28, 2014 at 8:18 PM, Jane Darnell  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, 

Re: [Wikimedia-l] A personal note.

[Martijn Hoekstra]

On May 28, 2014 7:09 PM, "Wil Sinclair"  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=14&t=4680&p=96600#p96600
>
> ,Wil
>
> On Wed, May 28, 2014 at 9:57 AM, Risker  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  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=14&t=4680&start=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æ  wrote:
> >> > On 28/05/2014, Lila Tretikov  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

Re: [Wikimedia-l] About Wikipedia medical entries

[Martijn Hoekstra]

On Tue, May 27, 2014 at 4:27 PM, geni  wrote:

> On 27 May 2014 15:22, Marc A. Pelletier  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,
> 
>
___
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] About Wikipedia medical entries

[Martijn Hoekstra]

On Tue, May 27, 2014 at 4:01 PM, Marc A. Pelletier  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,
> 
>
___
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

[Martijn Hoekstra]

On Fri, May 23, 2014 at 10:04 PM, Wil Sinclair  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,
> 
>
___
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

[Martijn Hoekstra]

On Fri, May 23, 2014 at 8:23 PM, Wil Sinclair  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 
> 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 
> wrote:
> >>
> >>
> >>
> >> On May 23, 2014, at 10:09 AM, Risker  wrote:
> >>
> >>> On 23 May 2014 13:05, Wil Sinclair  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:
> http

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

[Martijn Hoekstra]

On Thu, May 15, 2014 at 12:53 PM, Andy Mabbett wrote:

> On 14 May 2014 14:26, Everton Zanella Alvarenga
>  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,
> 
>
___
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] Howdy from Wil

[Martijn Hoekstra]

On Mon, May 5, 2014 at 8:30 PM, Wil Sinclair  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,
> 
___
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] I'm back

[Martijn Hoekstra]

On Fri, Apr 18, 2014 at 4:23 PM, Andy Mabbett wrote:

> On 18 April 2014 14:20, Milos Rancic  wrote:
>
> > Rakija is the right Serbian product. Do you remember drinking it
> > in Pristina? Or not? :P
>
> Unfortunately, I remember both drinking the lovely Rakija, and the
> morning after...
>

If you do it the right way, you shouldn't remember the former.

Anyway, let me jump on the "welcome back" bandwagon. As someone already
said in your goodbye email, even while you temporarily left, it's
impossible to stop being a WikiMedian. Welcome back to active duty.

>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] Sponsorship/donations to other organizations

[Martijn Hoekstra]

On Tue, Apr 15, 2014 at 9:50 PM, Erik Moeller  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,
> 
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Thu, Apr 10, 2014 at 3:28 PM, Anders Wennersten  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
> session"re-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

[Martijn Hoekstra]

On Tue, Apr 8, 2014 at 12:46 AM, James Salsman  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,
> 
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Tue, Apr 8, 2014 at 11:14 AM, Gerard Meijssen
wrote:

> Hoi,
> From where I stand ie Wikidata, the license we use is CC-0. When a GLAM
> wants to share data it has to be CC-0. When it is CC-by or CC-by-sa, we
> cannot use it. We do not retrieve it from their database we will find the
> same data from elsewhere where there is no such burden.
>
> When people use CC-by-sa data in for instance Wikipedia, we do harvest that
> information because once it is embedded in Wikipedia, it is no longer part
> of the original database that prohibits us from using it based on the
> database rights. At that point it is part of a completely different set of
> information. It is retrieved one factoid at a time and the origin of the
> data is no longer an issue.
> Thanks,
>   GerardM
>

Why are we talking about the license of Wikidata in this thread?

Come to think of it, why are we still talking at all in this thread?



>
>
> On 8 April 2014 10:40, Jane Darnell  wrote:
>
> > Gerard,
> > I think you mean "There are organisations that want to share CC-0
> > information with us under a CC-0 license and there are those who want
> > to share CC-0 information under a CC-by
> > license." We are fine with organizations sharing CC-by information
> > under a CC-by license, no?
> >
> > O and I agree completely on the Wikidata thing.
> >
> > Jane
> > PS: I also agree that the person who said these words is, in fact a
> > member of the community like the rest of us and therefore has every
> > right to use those words in a meeting during which community issues
> > are being discussed. I have heard worse in discussions by members of
> > one part of the community (Commons people) talking about other members
> > of the community (Dutch Wikipedians) and the other way around. Maybe
> > it's a cultural thing and we swear a lot in our internal meetups in
> > the Netherlands, dunno about that, but I never felt offended when I
> > heard these statements and in context have agreed with both parties.
> >
> > 2014-04-08 8:22 GMT+02:00, Gerard Meijssen :
> > > Hoi,
> > > Take one step back. What our aim is, is to share in the sum of all
> > > knowledge. Arguably, this is the main and overriding objective of what
> we
> > > do. There are many strategies to get to the point where we share
> > > information. From where I stand, with Wikidata we have the opportunity
> to
> > > do better than with an only Wikipedia strategy: with Wikipedia we share
> > the
> > > sum of knowledge that is available in one Wikipedia and with Wikidata
> we
> > > share in the sum of all the knowledge that is available to us.
> > >
> > > Wikidata provides access to more information than any Wikipedia by a
> > large
> > > margin.
> > >
> > > There are those in our communities who aim to restrict the practices
> that
> > > realise Wikidata as the resource of information that is available to
> us.
> > To
> > > say it in a political correct way, they can be and should be ignored.
> > There
> > > are organisations that want to share information with us under a CC-0
> > > license and there are those who want to share information under a CC-by
> > > license. The later can and should be ignored as well.
> > >
> > > However, when I am to argue these points in a private setting, I will
> say
> > > that they can screw themselves. It is to make the point forcefully, it
> is
> > > to hammer on the fact that our objective is not the community but the
> > > sharing of knowledge. Yes, the community is important but that is the
> > > extend of it. When we can gain authoritative information provided by a
> > > GLAM, we should not consider the fact that we can enter all that
> > > information by hand. Those who want to add statements by hand can do so
> > but
> > > they should not force their behaviour and attitudes on others.
> > > Thanks,
> > >   GerardM
> > >
> > >
> > >
> > > On 8 April 2014 00:45, Hubert Laska  wrote:
> > >
> > >> With all due respect, Gerard, not the bearer ofthe message, Tomas, is
> > the
> > >> problem, the problem arises where there are people who can make
> > decisions
> > >> with far-reaching consequences - and be selected for it - but then
> > assume
> > >> one for me unacceptable position against that group whose services are
> > the
> > >> basis for their own position.
> > >>
> > >> Fuck the Community, who cares, was not the only thing, much worse for
> me
> > >> is the meaning, that free knowledge is easier to buy than to get by
> > edits
> > >> and edits.
> > >>
> > >> Of whose money? By those who make one edit after the other? Taking
> > photos,
> > >> one after another and upload them?
> > >>
> > >> I know Steffen good enough and I know, that he is able to tell apart
> > >> explanations which happens within an special group dynamic process. If
> > >> this
> > >> has occured, he would not have written this in his blog.
> > >>
> > >> h
> > >> Am 07.04.2014 12:52, schrieb Gerard Meijssen:
> > >>
> > >>  Hoi,
> > >>> What is it that you intend to do. Han

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

[Martijn Hoekstra]

On Mon, Apr 7, 2014 at 1:37 PM, Tomasz W. Kozlowski
wrote:

> 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

[Martijn Hoekstra]

eople were "being difficult" and overstepping their boundaries?
Was this discussed internally? If so, what was the outcome, and why? Did
fundraising identify the concerns about the job description as an important
problem, or did it get more or less dismissed as meddling 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

[Martijn Hoekstra]

On Mon, Mar 24, 2014 at 1:56 PM, MZMcBride  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]  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,
> 
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Mar 15, 2014 7:47 AM, "James Salsman"  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] WMIL Board & members withdraw from international activities

[Martijn Hoekstra]

On Mon, Feb 3, 2014 at 6:40 PM, Itzik Edri  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 :
>
> > 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 :
> >
> > > 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 w

Re: [Wikimedia-l] My choice for ED

[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  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) 
> 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/Pluralism,_internationalism,_and_diversity_policy
> >
> >
> > Nemo
> >
> > ___
> > 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] My choice for ED

[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"  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  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  wrote:
> >
> > > On Sat, Feb 1, 2014 at 3:29 AM, ENWP Pine 
> > 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,
> > 
> >
> > ___
> > 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] [Wikitech-l] Reasonator use in Wikipedias

[Martijn Hoekstra]

On Jan 23, 2014 6:42 PM, "Gerard Meijssen" 
wrote:
>
> Hoi,
> Having Reasonator generated content in a "draft" namespace is *NOT* a bad
> idea.
>
>- I do not know enough about the draft namespace.. Is there a way to
>discover that an article exists in Draft ??
>- My personal target for this functionality is very much the smaller
>projects. By using a "draft" environment I am afraid it becomes easily
too
>complicated in these environments.
>- "Red links", are they allowed to point to the draft namespace?
>- How about disambiguation because, Wikidata is very likely to create
>ambiguity ... then again, as there is an "auto describe" function, it
is
>possible to add suffixes like "actor" "politician" etc..
>- Magnus indicated that providing information to templates is well
>possible.  he calls it low tech 
>   - So far we prefer to show a label in stead of  a "Qnumber".
>   - We would *REALLY* like to have a personal fall-back chain of
>   languages based on #babel information..
>   - There is no API to read #Babel yet
>   - Obviously this has implications for caching..
>   - HOWEVER as we share this content with Wikidata and all other
>   projects, it can aggregate in one cache.. do not know if that is
> good or bad
>
> Thanks,
>  GerardM
>
>

Pointing redlinks to draft seems like a marvelous idea, and pre-populating
them with wikidata even better.

Having an in between "yellow" link for draft content including wikidata
content, and red link for nothing seems to me like an even better idea, but
dependent on how drafts will turn out in practice.

We could do amazing things with this.

> On 23 January 2014 16:26, Daniel Mietchen wrote:
>
> > What about having the Reasonator sit in the Draft namespace, with a
> > link from the search results or the text preloaded for non-existing
> > pages in the main namespace?
> >
> > Daniel
> > --
> >
> >
http://www.naturkundemuseum-berlin.de/en/institution/mitarbeiter/mietchen-daniel/
> > https://en.wikipedia.org/wiki/User:Daniel_Mietchen/Publications
> > http://okfn.org
> > http://wikimedia.org
> >
> >
> > On Thu, Jan 23, 2014 at 4:12 PM, Magnus Manske
> >  wrote:
> > > Hi Andy,
> > >
> > > I thought about that as well. Besides the intro text, the info box
would
> > be
> > > the main "attraction"; but if infoboxes were to fall back on wikidata
> > > information, which they could technically already do, all we'd have
to do
> > > is add a blank infobox, and it should automatically fill up with the
> > > wikidata information. In light of that, writing code to fill an
infobox
> > > with values form wikidata to paste into the article seems ... low-tech
> > ;-)
> > >
> > > Cheers,
> > > Magnus
> > >
> > >
> > > On Thu, Jan 23, 2014 at 3:05 PM, Andy Mabbett <
a...@pigsonthewing.org.uk
> > >wrote:
> > >
> > >> On 22 January 2014 08:35, Gerard Meijssen 
> > >> wrote:
> > >>
> > >> > There are many ways to skin a cat. The most obvious
> > >> > one is to add a {{Reasonator}} template as a place
> > >> > holder in a Wikipedia. Another is to capture a not
> > >> > found or a red link and insert Reasonator info. What
> > >> > I am trying to do is to give a sense of direction. I am
> > >> > not indicating how it will be done for sure.
> > >>
> > >> [I'm not on the devs list, so trimmed from the CC]
> > >>
> > >> I would like people to be able to "subst" that template (or have a
big
> > >> button that does the same thing), and have some code draft a stub
> > >> article based on the statements in Wikidata, say:
> > >>
> > >>  "X was a German painter born in [[Munich]] on
> > >>  27 May 1801. He died in [[Berlin]] on 3
> > >>  March 1899"
> > >>
> > >> with formatted references, a reflist template, and a pre-populated
> > >> infobox. It would be delivered in preview state, allowing further
> > >> editing before publication.
> > >>
> > >> A suitably prominent warning would alert editors that they still bear
> > >> responsibility for ensuring that the subject is notable, and the
> > >> article fit for publication, according to local standards. A hidden
> > >> category and/or an edit tag would allow tracking.
> > >>
> > >> Because of the complexity of this task, we could pilot it for one
type
> > >> of subject (say, buildings, or people, or even a subset of one of
> > >> those) in one or two languages.
> > >>
> > >> --
> > >> Andy Mabbett
> > >> @pigsonthewing
> > >> http://pigsonthewing.org.uk
> > >>
> > >> ___
> > >> Wikimedia-l mailing list
> > >> Wikimedia-l@lists.wikimedia.org
> > >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
,
> > >> 
> > >>
> > >
> > >
> > >
> > > --
> > > undefined
> > > ___
> > > Wikimedia-l mailing list
> > > Wikimedia-l@lists.wikimedia.org
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinf

Re: [Wikimedia-l] Thanking anonymous users

[Martijn Hoekstra]

On Jan 13, 2014 7:25 AM, "MZMcBride"  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,

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

Re: [Wikimedia-l] Paid editing v. paid advocacy (editing)

[Martijn Hoekstra]

On Fri, Jan 10, 2014 at 7:17 PM, Federico Leva (Nemo) wrote:

> Arne Klempert, 10/01/2014 17:51:
>
>> I've heard that before from Wikipedians. However, it does not match
>> with what communication professionals keep telling me. Even larger
>> companies with solid communication departments are usually not in a
>> place to spend enough ressources to correct their articles beyond
>> basic facts. [...]
>>
>
> That only means that their return on investment is too little for them,
> not that they wouldn't have enough resources. Usually, that's because what
> they're trying to do is impossible, so they keep hitting a wall. Wiki-PR's
> very reasonable prices show that the job can be very cost-effective and not
> so heavy, if one knows what can survive in the system.
> In my experience, every time you talk with a company's communication
> person you have to spend hours convincing them that every single thing they
> thought or wanted to do on Wikipedia is totally impossible, then after a
> complete mind-reset you can teach them the simple things they can do
> successfully. Things could be much smoother, but our approaches are too
> inefficient (or our resources insufficient by several orders of magnitudes
> with current approaches) for the necessary mass-education of communication
> professionals to happen and enable them to productive interaction.
>
> Nemo
>
>
I very much agree with this. Currently we just don't have the manpower to
explain to 'the corporate world' in an understanding and clear fashion that
what they are trying to do is *all wrong*, and what it is they *can*
actually do. As long as corporate spam outnumbers well-meaning Wikipedians
who are willing to invest time and effort in explaining by roughly a factor
1 : 10, there is little we can do. But at the same time, it's the work
environment of those tons of spam that make our editors treat every new
contribution and contributer like spam and spammers - even the ones that
aren't, which fosters an aggressive uninviting environment that inhibits
the influx of people who can become seasoned Wikipedians who can help deal
with the issue.

I'm pretty sure that's the problem. I wish I had a solution to it too, but
unfortunately I don't.




>
> ___
> 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] Textbooks Which Borrow Heavily from Wikipedia

[Martijn Hoekstra]

On Nov 26, 2013 12:08 PM, "Srikanth Ramakrishnan" 
wrote:
>
> The new textbooks in Tamil Nadu state in India have images from the
Commons
> and links to articles printed at the end.
> This was discussed on the Wikimedia India mailing list in the latter half
> of 2011. You can check the archives.

I never knew that, thank you for sharing. I can at times get a little glum
about our projects, but things like these demonstrate we are still on the
right path doing good.


>
> Sent from the touchscreen equivalent of a Nokia 1100, pardon the sender.
> --
> Srikanth Ramakrishnan,
> Treasurer.
> On Nov 26, 2013 2:23 PM, "David Gerard"  wrote:
>
> > On 26 November 2013 07:26, James Heilman  wrote:
> >
> > > They are under a CC BY SA license and if you follow the links seen
here
> > > http://books.google.ca/books?id=7avpQBAJ&pg=PA2058 they do
> > eventually
> > > attribute Wikipedia.
> > > They are being offered for free on amazon.com
> > >
> >
http://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=Boudless
> > > and
> > > are being sold for $19.99 on their website. https://www.boundless.com/
> >
> >
> > My first impression is "that sounds excellent!"
> >
> >
> > > So the question is should we have a response? I think this could
generate
> > > position press for our movement. Attribution could be better (I would
> > > consider theirs to be borderline). Additionally should we be adding
this
> > > textbooks to Wikiversity or Wikibooks to make sure they stay free
> > available?
> >
> >
> > We could work with them to fine-tune the attribution.
> >
> > But yeah, if they check out as doing the right thing then this is
> > complete success for us.
> >
> >
> > - d.
> >
> > ___
> > 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] Copyright infringement - The real elephant in the room

[Martijn Hoekstra]

On Nov 20, 2013 1:13 PM, "The Cunctator"  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æ"  wrote:
>
> > On 19 November 2013 20:44, Samuel Klein  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,
> > 
> ___
> 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] Office hours for VisualEditor

[Martijn Hoekstra]

On Oct 31, 2013 2:11 AM, "Steve Zhang"  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  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,
> > 
> >
> ___
> 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] Stack Exchange vs. Wikimedia

[Martijn Hoekstra]

On Mon, Sep 23, 2013 at 6:49 PM, Federico Leva (Nemo) wrote:

> 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/wikis
>
>
I posted on that before, and I do encourgage everybody to collaborate
there. Stackexchange is much better in Q&A 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#c13
> >
>
> Nemo
>
>
> __**_
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.**org 
> Unsubscribe: 
> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l,
>  ?subject=**unsubscribe>
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Mon, Sep 23, 2013 at 6:20 PM, Jan Kučera  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). Q&A 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,
> 
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

[Wikimedia-l] Another wiki* stackexchange proposal

[Martijn Hoekstra]

Another proposal for a new site for wikis on the Q&A suite of sites
stackexchange has opened up for committal. If you're interested, it's over
at http://area51.stackexchange.com/proposals/49276/wikis
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[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) 
>
> > 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,
> 
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Aug 26, 2013 7:53 PM, "George William Herbert" 
wrote:
>
>
>
>
>
> On Aug 26, 2013, at 10:42 AM, JP Béland  wrote:
>
> > 2013/8/26, Martijn Hoekstra :
> >> On Aug 26, 2013 6:30 PM, "JP Béland"  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
> >
> > "Imagine a world in which every single human being can freely share in
> > the sum of all knowledge. That's our commitment."
> > (http://wikimediafoundation.org/wiki/Vision)
> >
> > I agree with you that it is good to discuss about it. The real
> > question we have to ask is what between Wikipedia Zero giving free
> > access to Wikipedia or avoiding that for net neutrality and not
> > undermining the market position for a paid open internet is getting us
> > closer to our vision.
> >
> > JP Béland
> > aka Amqui
>
>
> I believe a nonstandard interpretation of net neutrality is being used
here.
>
> It's intended - as originally posed - to prevent a service provider from
advantaging their own bundled services and disadvantage independent
services via tariff structure.
>
> What competitors for Wikipedia exist?
>
> And to the extent there are such, are we associated with this provider in
some way that causes us to be their service in some preferred way to their
or our benefit?  What benefit do we get?

We get a wider readership, at least in the short term. Why else would we be
doing this? Or was the question rhetorical, as the answer was rather
obvious to me. If it was, I don't understand the point you were trying to
make with it.

>
>
> Sent from Kangphone
> ___
> 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?

[Martijn Hoekstra]

On Aug 26, 2013 6:30 PM, "JP Béland"  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 :
> > 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 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" 
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
,
> >> > 
> >> ___
> >> Wikimedia-l mailing list
> >> Wikimedia-l@lists.wikimedia.org
> >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> >> 
> >>
> >
> >
> >
> > --
> > André Engels, andreeng...@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,

___
Wi

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

[Martijn Hoekstra]

On Wed, Aug 21, 2013 at 10:09 AM, Peter Gervai  wrote:

> On Wed, Aug 21, 2013 at 9:37 AM, Martijn Hoekstra
>  wrote:
> > On Aug 21, 2013 8:56 AM, "Peter Gervai"  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>

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

[Martijn Hoekstra]

On Aug 21, 2013 8:56 AM, "Peter Gervai"  wrote:
>
> I am possibly failing to see the point of this part of the discussion.
>
> On Wed, Aug 21, 2013 at 7:14 AM, FT2  wrote:
>
> >- *If the IP is "sufficiently clearly connected"  to the individual
> >behind the Alice account*,
>
> It is not and possibly almost never will.
>
> However I fail to see how people hanging around quite a long time mix
> up a banned user with a technical measure to _enforce_ a ban (namely,
> blocks). Everyone seem to talk about blocks while meaning to talk
> about bans.
>
> IP based blocks almost never personally targeted since people do not
> have IP addresses: machines do. We (and everyone else) use IP based
> access control to mechanically enforce things on people not following
> the "rules" (eg stay away when instructed to). It is much more like
> putting metal bars on a window looking onto a street with troubled
> neighbourhood.
>
> We reasonably expect ourselves to use IP bans to minimise collateral
> damage but it's guaranteed to be there; people may change IP address
> to evade the blocks (and therefore violate the bans); IP addresses may
> be reassigned to the innocent and obviosuly there are vast armies of
> NAT gateways, multiuser servers, proxies, TOR exit nodes and whatnot.
> The cases where we can 100% assure that one IP or range equals to a
> given person are practically nonexistant.
>
> Because of that I fail to see any possible validity of "legally
> binding action against a person based on an IP address".
>
> Peter
>
>

This kind of discussion does not need to go in to how theoretically IP
addresses can be tied to individuals. We tell users to stop doing what they
are doing, analogous to the cease and desist in this case. Obviously a
warning to stop is not a cease and desist, but the court in this case
didn't appeal to the legal weight if a cease and desist, but used it as a
clear indication to tell the other party his actions are not allowed by the
site. To that end the two messages to stop are identical.

The block then is also identical. 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.

This alligns perfectly with the blocking policy and definition of block
evasion on at least the English Wikipedia, and probably other projects too.
It is completely different from the discussed change of browser to make use
of features not accessible to those browsers, and comparing that situation
only obfuscated the issue.

There is still the issue of evidence that the possible suspect is indeed
the person to whom the warning was sent. That however is a question of
proofing that a person broke the law, which might be far harder to answer
in the case of an individual editing Wikipedia on a residential IP
allocation than it is in the linked case. 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.

--Martijn

___
> 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] Block evasion might be a federal offense

[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, 

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

[Martijn Hoekstra]

On Sat, Aug 10, 2013 at 5:31 PM, Huib Laurens  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 
> 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,
> 
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[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 
> Unsubscribe: 
> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>,
> <mailto:wikimedia-l-request@**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

[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 
> Unsubscribe: 
> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l,
>  ?subject=**unsubscribe>
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Tue, Aug 6, 2013 at 3:10 PM, Richard Farmbrough  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 
> Unsubscribe: 
> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l,
>  ?subject=**unsubscribe>
>
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Tue, Jul 30, 2013 at 1:01 PM, David Gerard  wrote:

> On 30 July 2013 09:06, Martijn Hoekstra  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] On the gentrification of Wikipedia, by Superbass (was: Visual Editor)

[Martijn Hoekstra]

On Tue, Jul 30, 2013 at 12:26 PM, Robert Rohde  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
>  wrote:
> > On Jul 30, 2013 4:58 AM, "Marc A. Pelletier"  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 syn

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

[Martijn Hoekstra]

On Tue, Jul 30, 2013 at 11:43 AM, Robert Rohde  wrote:

> On Tue, Jul 30, 2013 at 1:06 AM, Martijn Hoekstra
>  wrote:
> 
> > 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.
> 
>
> 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 "".
>
> 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)

[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" 
> 
> >
> 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"  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<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<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>
>>> ,
>>>
>> <mailto:wikimedia-l-request@**lists.wikimedia.org
>> ?subject=**unsubscribe>
>> __**_
>> Wikimedia-l mailing list
>> Wikimedia-l@lists.wikimedia.**org 
>> Unsubscribe: 
>> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>,
>> <mailto:wikimedia-l-request@**lists.wikimedia.org
>> ?subject=**unsubscribe>
>>
>
>
> __**_
> Wikimedia-l mailing list
> Wikimedia-l@lists.wikimedia.**org 
> Unsubscribe: 
> https://lists.wikimedia.org/**mailman/listinfo/wikimedia-l<https://lists.wikimedia.org/mailman/listinfo/wikimedia-l>,
> <mailto:wikimedia-l-request@**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)

[Martijn Hoekstra]

On Jul 30, 2013 4:58 AM, "Marc A. Pelletier"  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,

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

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

[Martijn Hoekstra]

On Jul 30, 2013 3:49 AM, "Marc A. Pelletier"  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,

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

Re: [Wikimedia-l] Progress...

[Martijn Hoekstra]

On Fri, Jul 26, 2013 at 1:48 PM, Fred Bauder  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,
> 
___
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

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

[Martijn Hoekstra]

On Jul 24, 2013 9:57 AM, "Erik Moeller"  wrote:
>
> On Tue, Jul 23, 2013 at 9:25 AM, Tom Morris  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,

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

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

[Martijn Hoekstra]

On Jul 10, 2013 8:59 AM, "David Gerard"  wrote:
>
> On 10 July 2013 07:51, Fred Bauder  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,

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

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

[Martijn Hoekstra]

On Fri, Jun 7, 2013 at 6:24 PM, Matthew Roth  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  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 :
> > > 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.

Re: [Wikimedia-l] "Somebody Will"

[Martijn Hoekstra]

On Jun 3, 2013 2:17 PM, "Sumana Harihareswara" 
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] Protecting the Encylopedia vs Destroying a human

[Martijn Hoekstra]

On Wed, May 29, 2013 at 2:22 PM, Eddy Paine  wrote:

> Hello,
> First of all I was asked to take a look at the following case. I found it
> very strange how people behave against other people and I would like to
> write about it and ask opinions. I'm sure this is not only for this user
> but there are more users like this.
> I understand that its needed for people to block users when the
> encyclopedia or the project is in danger, but where do will place the
> border? I think destroying people or behaving against people like I will
> describe below is also endangering the project. We should all remember that
> we are humans and not robots and everybody makes mistakes. Therefor I am
> sure that there was behavior that was totally wrong, but the way the whole
> international community decided to handle it was wrong also.
> First of all we have a policy against socks. In that policy we describe
> that its not right to edit with two accounts at the same time or working
> together with 2 accounts to get something done. Secondly its not right to
> use new accounts to evade blocks. Lastly bot accounts are not seen as socks
> neither are old and unused accounts. Besides that we have a policy in place
> that says that people are free to leave the project or abandon a username
> and continue with a new name. This I guess is for protecting the project
> and protecting the people that work on it.
> Now to get to my case. On 3 July on Meta a attack started against a former
> Dutch Wikipedia user. This attack was mainly started by people of the Dutch
> Wikipedia. The same people that are willing to destroy this user. (
> http://meta.wikimedia.org/wiki/Requests_for_comment/Abigor) now before
> you all click away this message hear me out and give me opinions. This is
> now almost two years ago and a good moment to look back. If I am wrong
> please point me to that and lets keep a good talk instead of going all
> "don't waste our time".
> In this case there was a big list of names that where socks and this
> "sockmaster" needed to be blocked. But when we look at our policies and on
> that list we see the following:
> Abigor (talk • contribs • block • SULinfo • x-wiki • CA) - thats meAbiBot
> (talk • contribs • block • SULinfo • x-wiki • CA) No sock its a bot, only
> did bot editsAbiBot.nl.wiki (talk • contribs • block • SULinfo • x-wiki •
> CA) No sock its a bot, only did bot editsAbibot (talk • contribs • block •
> SULinfo • x-wiki • CA) (renamed to AbiBot[2], self acknowledged)Huib (talk
> • contribs • block • SULinfo • x-wiki • CA) Created on request by meta
> communety en en.wiki communety, because I sign with Huib while I'm
> abigor... Its points to my abigor account and its created to protect my own
> account. Execpt for the rename edits, it didn't edit at all.Huib (old)
> (talk • contribs • block • SULinfo • x-wiki • CA) Did a rename request to
> get Huib free..Sterkebak (talk • contribs • block • SULinfo • x-wiki • CA)
> old account... on my userpage is a note that I used to use that
> oneSterkeBak (talk • contribs • block • SULinfo • x-wiki • CA) old
> account... on my userpage is a note that I used to use that oneSterkebot
> (talk • contribs • block • SULinfo • x-wiki • CA) No sock its a bot, only
> did bot editsSterkeBot (talk • contribs • block • SULinfo • x-wiki • CA)
> (renamed from Sterkebot[3][4] and later renamed to AbiBot[5][6])P.J.L
> Laurens (talk • contribs • block • SULinfo • x-wiki • CA) - Its a account
> created for my uploads, it has a different userpage on Commons with
> information about me as photographer. Didn't do any edits just created for
> the userpage and information. All my uploads are pointed to this one with a
> link.WikiLinkBot (talk • contribs • block • SULinfo • x-wiki • CA) No sock
> its a bot. Only editted on nl.wiki to let its userpage be removed, the
> dutch admins didn't want to remove the page.This list is ctrl C Ctrl V from
> Meta.
> Now go to the policy:
> Abigor is the account of the user. Than we have AbiBot, AbiBot.nl.Wiki and
> Abibot sterkebot SterkeBot as bot accounts. According to the policy
> accounts used by a bot without human edits are not socks. Huib and Huib
> (old) Sterkbak SterkeBak P.J.L Laurens. All those names are old accounts
> without overlapping edits so according to the policy its not socking. Some
> accounts doesn't have edits at all but where only there to redirect.
> WikiLinkBot is intresting cause its now in use by a other user. This user
> is also the source for the blocking on the Dutch Wikipedia. Abigor would
> have placed personal attacks against this user and now the user is having
> that accounts. Very intresting don't you think.
> Then we get a bunch of accounts:
> Accounts with only a few edits and no CU results where linked to this
> users. I strongly believe that we should have proof before pointing
> something out and say "hey it was you". But the account where I want to
> speak about is Delay. We have the policy that says that you can sta

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

[Martijn Hoekstra]

On Jan 9, 2013 1:07 AM, "Kim Bruning"  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))

[Martijn Hoekstra]

On Jan 5, 2013 1:03 AM, "George Herbert"  wrote:
>
> On Fri, Jan 4, 2013 at 3:56 PM, Martijn Hoekstra
>  wrote:
> > On Jan 5, 2013 12:51 AM, "George Herbert" 
wrote:
> >>
> >> On Fri, Jan 4, 2013 at 10:05 AM, David Gerard 
wrote:
> >> > On 4 January 2013 17:56, Mark  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
>
> You think I haven't done hours (days, weeks, at one point a month)
> worth of AfC work?
>
> I thought AfC was a great place to ramp up my WP skills when I was
> getting in sync.  Pick something I knew about but not enough to write
> an article, go research it, zap.
>
>
> --
> -george william herbert
> george.herb...@gmail.com
>

George, sorry about implying you didn't. Ill follow up with a smarter
response later.

___
> 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))

[Martijn Hoekstra]

On Jan 5, 2013 12:51 AM, "George Herbert"  wrote:
>
> On Fri, Jan 4, 2013 at 10:05 AM, David Gerard  wrote:
> > On 4 January 2013 17:56, Mark  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] Editor retention (was Re: "Big data" benefits and limitations (relevance: WMF editor engagement, fundraising, and HR practices))

[Martijn Hoekstra]

On Fri, Jan 4, 2013 at 8:36 PM, Steven Walling wrote:

> On Fri, Jan 4, 2013 at 5:03 AM, Fred Bauder 
> 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:Contributions&contribs=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))

[Martijn Hoekstra]

On Fri, Jan 4, 2013 at 2:41 PM, David Gerard  wrote:

> On 4 January 2013 13:39, Fred Bauder  wrote:
>
> > I'm afraid the shooting gallery is already coded into Twinkle/Huggle. It
> > is the use of that coding that is at issue. It could be used to
> > encourage, reward and advise as well as to enforce.
>
>
> This is currently implemented by templating, which is how human
> editors can fail the Turing test.
>
> Unfortunately, just banning Twinkle/Huggle/similar
> first-person-shooter games is unlikely to fly.
>
>
> - d.
>
>
The fact that it can be used as a first-person-shooter is not the problem.
The problem is people using it as such. Making mistakes is possible, but
the users should know that making that mistake is worse than any single
instance of vandalism, and their good edits don't excuse that.


> ___
> 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