Re: [Wikimedia-l] Donations - show the editors you care?

[Demian]

On Mon, 7 Dec 2020 at 12:03, Dan Garry (Deskana)  wrote:

> Please let us avoid using misleading statistics to make a point.
>


> On Mon, 7 Dec 2020 at 14:02, Dan Garry (Deskana) 
wrote:

> On Mon, 7 Dec 2020 at 12:38, Demian  wrote:
>
>> [...], but to be exact, I was looking to understand why only 2.8% (47 out
>> of 1668
>> <https://xtools.wmflabs.org/ec/meta.wikimedia.org/Seddon_(WMF)#year-counts>)
>> of your mainspace edits since 2016 are made with Visual Editor. To answer
>> Dan: I was unaware of the personal account with 189
>> <https://en.wikipedia.org/w/index.php?title=Special:Contributions/Seddon==600=Seddon>
>> /399 <https://xtools.wmflabs.org/ec/en.wikipedia.org/Seddon#year-counts>
>> mainspace visual edits since 2016, which makes the grand total 11.41% (236
>> out of 2067) of mainspace edits.
>>
>
> At this point, I think looking at the editing environment Seddon used
> across his staff and personal edit history has dubious value to furthering
> this discussion about fundraising.
>

Hello Dan, we haven't met yet. Thank you for your feedback. You've pointed
out that the statistics I've provided was superficial - which it was -,
therefore I've produced exact numbers to satisfy your expectation. Are you
saying this has "dubious value"? I'm sorry if that's how you feel: it made
Seddon's opinion on Visual Editor more understandable than just the work
account that I knew about (the personal account is not declared). I'd say
that's a benefit. Please note that I don't appreciate my work being
described with these words. Accurate facts serve as a basis for quality
work and acquiring those facts takes valuable time.


> While Visual Editor has its benefits and I also use it on meta with
>> similar success rate, for me the dream would be an editor that I can use at
>> least 80% of the time, and the ultimate would be 100% like the service
>> provided by Dropbox Paper, Google Docs, Coda and Nuclino for example.
>>
>
> I think we'd all love that. I certainly would. Making that happen would
> probably be a large organisational pivot; I can't find any statistics about
> how big the team is that made, say, Google Docs, but I suspect it's larger
> than the entire Wikimedia Foundation. This topic would probably have been
> better discussed in the movement strategy conversations, as a thread on a
> mailing list won't make it happen.
>

These are just examples of what's possible, not the focus of my question.

Therefore my concern is if Visual Editor met your expectations well, what
>> was the reason not to use it for 1800+ edits, which includes most major
>> edits on meta?
>>
>
> I'm sure the Editing team would appreciate your help with conducting
> systematic user research. Have you reached out to them?
>

Yes, I did, but the topic of this thread is  not user research, but a
simple question, and it is now getting longer than intended. As the rest of
the topics were exhausted, just this one question remains if Seddon wishes
to answer it.
Thank you for your feedback once again.


Aron
*Senior Software Architect and Analyst*
___
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, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Re: [Wikimedia-l] Donations - show the editors you care?

[Demian]

On Mon, 7 Dec 2020 at 11:32, Joseph Seddon  wrote:

> I believe the nature of the edits speak for themselves.
>
> Seddon
>

I'm assuming this points to the namespace of the edits, although it's not
clear. It's unfortunate that Visual Editor can only be used in mainspace, I
wish that wasn't the case, but to be exact, I was looking to understand why
only 2.8% (47 out of 1668
<https://xtools.wmflabs.org/ec/meta.wikimedia.org/Seddon_(WMF)#year-counts>)
of your mainspace edits since 2016 are made with Visual Editor. To answer
Dan: I was unaware of the personal account with 189
<https://en.wikipedia.org/w/index.php?title=Special:Contributions/Seddon==600=Seddon>
/399 <https://xtools.wmflabs.org/ec/en.wikipedia.org/Seddon#year-counts>
mainspace visual edits since 2016, which makes the grand total 11.41% (236
out of 2067) of mainspace edits.
While Visual Editor has its benefits and I also use it on meta with similar
success rate, for me the dream would be an editor that I can use at least
80% of the time, and the ultimate would be 100% like the service provided
by Dropbox Paper, Google Docs, Coda and Nuclino for example. Therefore my
concern is if Visual Editor met your expectations well, what was the reason
not to use it for 1800+ edits, which includes most major edits on meta?


Thank you.

Aron
*Senior Software Architect and Analyst*



> On Mon, Dec 7, 2020 at 5:55 AM Demian  wrote:
>
>> Hey Seddon,
>>
>> On Sun, 6 Dec 2020 at 16:23, Joseph Seddon  wrote:
>>
>>> Short answer: I don't think it's a cynical lie. I think that the
>>> donations our donors give do results in benefits to the community, even if
>>> they aren't transactional or tangible things. We definitely don't want to
>>> give any misleading impression that the benefits are tangible so we will
>>> look into this and if we can, try and to improve it.
>>>
>>> Long answer: If I look at where things are now versus where things were
>>> when I first started editing, it's amazing the amount of progress the
>>> editing experience has made. Even some of the projects with the bumpiest
>>> entries into the movement have been profoundly impactful. Some might raise
>>> an eyebrow in my use of it as an example, but I am astounded by how much
>>> easier the visual editor makes writing articles. Especially with the tools
>>> that are built into like Citoid. It is a dream to use.
>>>
>>
>> Visual Editor was a big step for the WMF. I appreciate very much that it
>> exists, along with other projects, like Flow and MediaViewer, despite the
>> community's initial/final rejections (respectively).
>> Unfortunately, I can only use it effectively when I don't plan on editing
>> templates or links, those workflows are inefficient and easy to make
>> mistakes. I like to use Citoid, but I always have to fix up the result.
>> With the lengthy loading time, every time I have to weigh whether it's
>> worth the time using Visual Editor. As a result I use it roughly once a
>> month (estimate), although I wish it would be feasible to use it more often.
>>
>> Looking at the greater picture I'm happy that new editors are somewhat
>> more likely to use the Visual Editor, proving its benefit. On the other
>> hand, as a senior software architect who had worked on improving Visual
>> Editor, I am aware of the technical reasons that caused the community's low
>> acceptance - and how it can be fixed -, therefore I fully understand the
>> community's response.
>>
>> With these different aspects in mind I wonder why you find the Visual
>> Editor a dream to use, given that on average at most 4 in 500 of your
>> edits
>> <https://meta.wikimedia.org/w/index.php?title=Special:Contributions/Seddon_(WMF)=20201127030700=500=Seddon+%28WMF%29>
>>  (2
>> <https://meta.wikimedia.org/w/index.php?title=Special:Contributions/Seddon_(WMF)=20200714140036=500=Seddon+%28WMF%29>,
>> 3
>> <https://meta.wikimedia.org/w/index.php?title=Special:Contributions/Seddon_(WMF)=20200218092358=500=Seddon+%28WMF%29>,
>> 4
>> <https://meta.wikimedia.org/w/index.php?title=Special:Contributions/Seddon_(WMF)=20200113155502=500=Seddon+%28WMF%29>,
>> 5
>> <https://meta.wikimedia.org/w/index.php?title=Special:Contributions/Seddon_(WMF)=20191017132130=500=Seddon+%28WMF%29>,
>> search: "visual edit") are made using Visual Editor.
>>
>>
>> Aron
>> *Senior Software Architect and Analyst*
>>
>>
>>
>>>
>>> Or on the multilingual front with the content translation tool which has
>>> seen 700,000 articles at last count? In the last couple of years we will
>&

Re: [Wikimedia-l] Donations - show the editors you care?

[Demian]

Hey Seddon,

On Sun, 6 Dec 2020 at 16:23, Joseph Seddon  wrote:

> Short answer: I don't think it's a cynical lie. I think that the donations
> our donors give do results in benefits to the community, even if they
> aren't transactional or tangible things. We definitely don't want to give
> any misleading impression that the benefits are tangible so we will look
> into this and if we can, try and to improve it.
>
> Long answer: If I look at where things are now versus where things were
> when I first started editing, it's amazing the amount of progress the
> editing experience has made. Even some of the projects with the bumpiest
> entries into the movement have been profoundly impactful. Some might raise
> an eyebrow in my use of it as an example, but I am astounded by how much
> easier the visual editor makes writing articles. Especially with the tools
> that are built into like Citoid. It is a dream to use.
>

Visual Editor was a big step for the WMF. I appreciate very much that it
exists, along with other projects, like Flow and MediaViewer, despite the
community's initial/final rejections (respectively).
Unfortunately, I can only use it effectively when I don't plan on editing
templates or links, those workflows are inefficient and easy to make
mistakes. I like to use Citoid, but I always have to fix up the result.
With the lengthy loading time, every time I have to weigh whether it's
worth the time using Visual Editor. As a result I use it roughly once a
month (estimate), although I wish it would be feasible to use it more often.

Looking at the greater picture I'm happy that new editors are somewhat more
likely to use the Visual Editor, proving its benefit. On the other hand, as
a senior software architect who had worked on improving Visual Editor, I am
aware of the technical reasons that caused the community's low acceptance -
and how it can be fixed -, therefore I fully understand the community's
response.

With these different aspects in mind I wonder why you find the Visual
Editor a dream to use, given that on average at most 4 in 500 of your edits

 (2
,
3
,
4
,
5
,
search: "visual edit") are made using Visual Editor.


Aron
*Senior Software Architect and Analyst*



>
> Or on the multilingual front with the content translation tool which has
> seen 700,000 articles at last count? In the last couple of years we will
> finally have integrated editor onboarding tools that are being worked on
> which are critical for the health of our communities? From personal
> experience, having better onboarding will massively improve community
> projects that aim to engage and bring in new editors to the movement.
>
> At one level you have the discrete improvements being worked on or
> completed with things like partial blocks, revision scoring, visual diffs,
> real time watchlists. At a more global level things like Structure Data on
> Commons or Abstract Wikipedia have the potential to solve massive problems
> the community has faced like multilingual categories or global templates.
> Those have the potential to bring huge benefits to the editing community on
> the projects.
>
> The benefits aren't always tangible to a specific individual and can often
> be invisible even if it enables or supports community focused work further
> downstream. It's worth noting that many of the pragmatic and mission driven
> choices made cumulatively over 15 years have made this work harder for us.
> The limited resources in the earlier years meant that we accumulated a huge
> amount of technical debt and digging out of that is always harder after the
> fact. I'd defer to the opinions of my colleagues but the increasing
> investment over the last few years has allowed us to start actually making
> headway, even if there is still a long way to go.
>
> On Sun, Dec 6, 2020 at 1:37 PM Pelagic via Wikimedia-l <
> wikimedia-l@lists.wikimedia.org> wrote:
>
>> [ Cross-posted from
>> https://meta.wikimedia.org/wiki/Meta:Babel#Donations_-_show_the_editors_you_care%3F
>> ]
>>
>> I had the misfortune of visiting Wikipedia logged-out the other day, and
>> was struck by the large size of the donation banner, and the odd wording of
>> the appeal. (Something about awkward and humble.) Re-checking now, the
>> "awkward" bit is gone, but the following sentences are still there:
>>
>> "If Wikipedia has given you $2.75 worth of knowledge, take a minute
>> to donate. 

Re: [Wikimedia-l] Annoying ads

[Demian]

Hey Seddon,

Thank you for reading and considering the feedback provided. I'd like to
add one more perspective to the picture:

IIRC in recent years the amount of donations was constantly increasing
year-by-year and it's now far more than what's necessary to cover
operational expenses of the WMF.
I believe one of the concerns with the fundraiser is that the size and
pushiness of the ad keeps growing while the WMF becomes less in need of
those donations. While it seems that the ad's size is proportional to the
funds raised, making this a successful strategy in the short term, it does
not come free as Wikipedia's reputation is traded in the long term.

A major concern is the sentences that manipulate readers' emotions to feel
bad if they don't donate. I think we have seen that approach for
fundraising many times in our lives from different sources, past and
present and it never raised trust.

Another non-obvious reason in my opinion why a big part of the community
can't condone these fundraisers is that we see the donations being
channeled to causes that don't benefit the communities proportionally to
the costs.
At the same time directly beneficial areas such as the developer team lacks
the funds to hire decently productive engineers with current knowledge -
leaving the software that makes Wikipedia possible always a decade behind
current software development and UX design practices.
The WMF's current goals with the Movement Strategy would also benefit from
hiring professional mediators and code of conduct educators to give a
chance for the UCoC to be implemented true to its purpose instead of a
dangerous tool in the hands of presumably untrained personnel.

These investments would make me suggest people to donate to the WMF, as it
goes to a clearly beneficial causes, but currently the way I see it the WMF
has more donations than it can invest beneficially. I find only a message
that's *humble in its length* - instead of just claiming to be humble -
would be appropriate.


Thank you for reading.

Aron


On Sat, 5 Dec 2020 at 18:04, Joseph Seddon  wrote:

> Hey Michel,
>
> There are some other points that Fae raised particularly around user
> experience and technical implementation that are distinctly more complex
> tasks and we are going to need to discuss and plan our testing to work on
> them, and the team is at very limited capacity on a Saturday. (I myself had
> been out enjoying the rather brisk winter air that's visiting the UK). Due
> to their very nature, rolling back the emoji's in the messaging could be
> done immediately.
>
> I've already brought the feedback back to the team, and I'll be reviewing
> with the team on Monday and hopefully work on them this week.
>
> Seddon
>
> On Sat, Dec 5, 2020 at 4:36 PM Michel Vuijlsteke 
> wrote:
>
>> I don't quite think the emoji were the only thing people hated
>> about this.
>>
>> On Sat, 5 Dec 2020 at 17:09, Joseph Seddon  wrote:
>>
>>> Hey all,
>>>
>>> To avoid burying the lead, the feedback is appreciated and we do listen
>>> whenever feedback is raised. I've just been coordinating with the team, and
>>> we've rolled back this change.
>>>
>>> For some background, the emojis in this messaging were a recent addition
>>> earlier this week. Emojis have become a core part of the way the world
>>> communicates, especially with younger demographics, practically becoming an
>>> ideographic language in and of itself. The team has been keen to see if
>>> there are ways we can leverage this, especially on mobile and we’ve been
>>> experimenting with them over the last couple of years in a number of
>>> campaigns.
>>>
>>> I want to recognise that we missed the mark on this one and that your
>>> feedback is heard, much appreciated and acted upon. The team really does
>>> care about the messaging and how it represents us, and the projects as a
>>> whole. Our processes on approving content have massively improved over the
>>> years and I think it reflects in the messaging we use. A number of people
>>> have noted that it has improved for the better over the years.
>>>
>>> At the same time I want to take some ownership of this misstep myself.
>>> I've been proactively working in real time with some volunteers, discussing
>>> concepts and gathering feedback on campaigns. This feedback has definitely
>>> shown that for such a new concept, I should have made sure to have
>>> highlighted and gotten more input on this.
>>>
>>> I'll be gathering input on how we use emojis in our messaging and I'd be
>>> happy to follow up with people about this. Just an additional note that if
>>> anyone wants to talk through any feedback with me I can be found on IRC,
>>> Discord, Telegram or send it through via email ( seddon at wikimedia.org
>>> ).
>>>
>>> My apologies but also my genuine thanks for the feedback.
>>>
>>> Seddon
>>>
>>> On Sat, Dec 5, 2020 at 2:24 PM Gnangarra  wrote:
>>>
 tend to agree there should be a mobile friendly version, the article
 should be visible at 

Re: [Wikimedia-l] June 4 1800 Maggie Dennis office hour (with a twist)

[Aron Demian]

On Sun, 31 May 2020 at 05:50, Newyorkbrad  wrote:

> Every time I see the title of this thread, I momentarily wonder why this
> event is being held 220 years ago.
>

Military time :-)
___
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] Trust and safety on Wikimedia projects

[Aron Demian]

On Sun, 24 May 2020 at 04:25, AntiCompositeNumber <
anticompositenum...@gmail.com> wrote:

> Would it be fair to say that:
>  - Enforcement of a universal code of conduct would happen though a
> fair, clearly-defined process without significant bias and with
> significant community oversight and input
> - Universal code of conduct enforcement actions would be appealable
> through a fair, clearly-defined process with significant community
> oversight that allowed statements from involved parties and uninvolved
> community members
> - To ensure proper community oversight, code of conduct enforcement
> actions and appeals would be made as public as possible as often as
> possible (excepting issues where public disclosure would harm privacy
> or safety)
>
> AntiComposite
>

Yes! These are fundamental requirements that need to be met by the process
that will be implemented in the second phase (Aug - end of 2020).
It seems there will be an opportunity to incorporate these requirements:

The second phase, outlining clear enforcement pathways, and
> *refined with** broad input from the Wikimedia communities*, will be
> presented to the Board
> for ratification by the end of 2020;


I'd add a few more points:
- To handle workload and different languages, local boards should be
selected as the first step of the process, with possible escalation to a
global board if necessary (eg. for conflict-of-interest reason).
- To minimize bias the boards should consist of people from different
areas. As long as the local DR processes remain operational (ANI and the
likes), there should be a clear separation of powers: CoC board members
should not be involved with local DR to avoid concentration of power. Being
an admin should not be a requirement, in fact adminship and dispute
resolution should be separate roles, as the latter requires specific
training or experience, which is not part of the requirements to be admin.
- There should be at least 2 independent global boards so one can review
the other's decisions and handle appeals. Cases should be evaluated by the
board that has more members unrelated to the involved parties.
- Functionaries and board members should be regularly reviewed and terms
limited to a few years.

About the DR process:
- Most of our communication is publicly visible on-wiki, therefore the
cases should be resolved in public. Transparency is crucial for community
review and a great learning opportunity about dispute resolution.
- Privately handled cases should only happen when all parties agree to
it, so one party can't use "privacy" as a means to avoid the burden of
proof. Non-public evidence should only be taken into account if there is a
very strong justification, proportional to the sanction that comes from it.
- Reports, however, should be created privately and published only when the
case opens. Before the case opens the reporter might seek advice and help
to create the report from people they trust. I've outlined a process draft
for this in the context of the User Reporting System
<https://meta.wikimedia.org/wiki/Talk:Community_health_initiative/User_reporting_system_consultation_2019#Factual,_evidence_based_reporting_tool_-_draft,_proposal>
.
- Reports should be treated with respect, as the personal experience of a
person. Nobody should be sanctioned for what a report contains, whether the
boards, or the community finds that true or false, as that would be a
deterrent to reporting influential users, who made a mistake or lost their
way.
- The focus should be on dispute *resolution. *Disputes and the resulting
reports often start with disagreements, not bad intent towards each other.
Mediation is an effective approach to finding a mutually agreeable
resolution in these situations. Such resolutions create a more cooperative
environment and allow for personal growth, learning from mistakes.
Mediators should be hired and board members offered mediator training to
support this path.
- When necessary, only the minimal sanctions should be applied that prevent
the reported behaviour, to reduce the abuse potential of blocking. Partial
blocks was a great step in this direction: typical conduct issues should be
addressed early on with minor sanctions, not after years of misconduct,
when a ban becomes warranted. Bans and project-wide blocks should only be
used after numerous escalations and repeated sanctions, or in clear-cut
cases of extreme misconduct.

Dispute resolution is difficult and often requires effort from all parties.
The above approaches are unusual compared to the traditional handling of
disputes, which often results in one-sided sanctioning of the party with
less support from the community. However, adopting new ways of dispute
resolution is necessary to create an inclusive community, where editors are
treated equally and fairly, regardless of their status.

These are just superf

Re: [Wikimedia-l] Commons

[Aron Demian]

On Sun, 17 May 2020 at 10:32, Tito Dutta  wrote:

> 1) I remember a major discussion took place somewhere on Wikimedia Commons
> when one of the strategy2030 draft recommendations suggested uploading
> non-free images on Wikimedia Commons. That discussion was also on the scope
> of Wikimedia Commons. I wish I could recall where exactly it took place.
>

 In August 2019 this question was brought up in the first round (iteration)
of the Recommendations. It was unfortunately intertwined with another
heavy, but tangential topic: the ToU. Accordingly half of the discussions
are unrelated to this question on the page. There was quite a bit of drama
caused by the superficial proposal, I'm surprised it's already forgotten
:-D
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Recommendations/Iteration_1/Diversity/9#Q_3_What_will_change_because_of_the_Recommendation?

The most acceptable solution proposed at that time was a separate wiki that
would run the same software as Commons:
https://meta.wikimedia.org/wiki/NonFreeWiki
That's a pretty good proposal (actually the second one in years) that has
run out of energy, just like the previous one.


IMHO Commons and the mediawiki software gives no benefits over popular and
easy-to-use image sharing services for non-wikipedians. Additionally, on
wiki newcomers can get dragged into wikidramas despite their best intent
and there is no protection for them. Learning the non-straightforward
communication patterns on-wiki and establishing a "standing" is a
multi-year effort, which simply is not necessary on the popular platforms.
There content creators can focus on building their follower-base instead.
The features and services they benefit from don't coincide with the
features the wiki software and communities are creating or looking for.
Uploading to Wikimedia is more like an ideological statement that might
require significant investment without benefits or with unexpected negative
benefits.
Tl;dr: why would anyone take a hard and uncomfortable path, when there is
an easy and beneficial path.

Regardless, a not-strictly-free media-hosting wiki would be great imho. For
wikipedians. To develop a product and culture that's suitable for regular
photographers would require talented and strongly motivated IT and HR
personnel, which is not present in the WMF, nor is it attainable: we've
seen people, who have put their hearts into their work, just to leave
prematurely, under unclear circumstances. Presumably the work environment
is not supportive of people who could envision and manifest such a product.


> 2) Wikimedia Commons is most possibly/definitely less popular than
> Wikipedia. I believe many editors start from Wikipedia and then move to
> Wikimedia Commons.


That's true for me. As a newcomer / non-wikipedian the first issue I had
with "Commons" was: "What does it mean?" I think outside Wikimedia this
name might be meaningless for many people.
"The commons is the cultural and natural resources accessible to all
members of a society, including natural materials such as air, water, and a
habitable earth."
Though there is logic in that, it's very abstract. I don't associate that
naturally with "Let's share my photos!" Rather, it makes me think of
sharing the water I bring from a fountain.

I remember when I've learned it's about sharing media - images primarily -
I was thrilled. After uploading dozens of images, requesting and learning
AWB - to effectively manage images in batches - my impression is it's good
to have, but takes serious, hard work to use it properly, involving some
advanced level form-filling skills, that's fun to learn (at least for me,
just for the challenge), but not fun to do regularly and I assume it's not
even fun to learn for many people.


> 3) Yes, the difficulty of using the app/web interface might be an issue of
> seeing less contribution as well. You have different photo-sharing
> platforms which uploads photos in 1-click. Commons upload process is
> longer. (I am not saying the process is bad, of course, we need all the
> steps, and there is not an unnecessary step there.)
>

4) The human emotion and interaction part is kind of missing: On Facebook,
> Instagram the likes, comments etc one gets, work as a motivation. This is a
> major issue. On FB, or Instagram an uploader can connect with people
> instantly, and their responses/reactions are quick as well. (Here also, I
> am not really suggesting anything, just keeping it as an observation)
> Let's talk about Google Photos, their badges, photo views analytics, and
> email time to time (eg: Your photo is making a difference, or You are a
> star) is good for motivation as well.
>

IMHO the primary motivation to use those platforms is the social aspect:
creating a follower-base, that brings the benefits: patreon, social
influencing, gigs.
Wikis don't have these incentives, the rules of the game (in terms of game
theory) are fundamentally different, social status is not the result 

Re: [Wikimedia-l] Brand Project: Who are we as a movement?

[Aron Demian]

My 2 cents: Imho the pressure from English Wikipedia on other projects of
the movement is very realistic in many kinds of matters, that I've
experienced myself too. Other projects are not independent socially or
culturally, the rules, practices, expectations and editorial behaviour is
strongly related to that on enwp with all its positive *and* negative
benefits. Often the negative benefits seem to outweigh the positive,
unfortunately.

Aron

On Sun, 15 Mar 2020 at 11:17, Peter Southwood 
wrote:

> It is grossly unrealistic to blame English Wikipedia and its editing
> community for what you appear to consider the shortcomings of other
> Wikipedias.

En: does not require or pressurise other projects to comply with its
> editorial standards, which are those developed by en:WP, and for en:WP.
> Other projects are free to set and use their own standards for content,
> within the general WMF terms of use, and generally do. If they choose to
> emulate en:WP that is their prerogative.
> If you think that Cebuan Wikipedia does a better job of informing on the
> subject matter it covers than other projects, and would like to convince
> other projects that this is a realistic and rational opinion, and that they
> should follow that example, you are free to produce documentary evidence
> from experts that this is the case, and present it to the editing
> communities of those projects for consideration.
> If Commons are exceeding their remit by refusing to host material that is
> not used on en:WP, that is not the policy or the fault of the en:WP
> community who have no authority over Commons.
> As a general rule, when discussing a topic where there is scope for
> confusion, there is less likely for confusion to occur when you are
> sufficiently specific when referring to the ambiguous entities.
> Cheers,
> Peter
>
> -Original Message-
> From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On
> Behalf Of Gerard Meijssen
> Sent: 15 March 2020 08:37
> To: Wikimedia Mailing List
> Subject: Re: [Wikimedia-l] Brand Project: Who are we as a movement?
>
> Hoi,
> By making the point that there is no Wikipedia AND that almost universally
> but particularly people who buy into English Wikipedia consider Wikipedia
> English Wikipedia, I expected that this is understood. I then address
> English Wikipedia specifically because it is its conventions that prevent
> the sum of all our knowledge to be shared.
>
> Just to make that point specific, Cebuan Wikipedia does a better job
> informing on the total of the subject matters it covers, it is a project of
> a father who wants his children to have access to knowledge in their
> maternal language. From a Wiki point of view he deserves praise and
> gratitude in stead he gets scorn because it is against English Wikipedia
> conventions. Furthermore the approach of using data to bring knowledge in
> other languages is frustrated from within WMF.  We could do a better job, a
> job that will work for any language but it is actively discouraged. The
> result is that we do NOT share in the sum of all knowledge, not even the
> knowledge that is available to us. In other words, English Wikipedia
> conventions prevent us from working towards our stated goal.
> Thanks,
>GerardM
>
> On Sun, 15 Mar 2020 at 06:19, Peter Southwood <
> peter.southw...@telkomsa.net>
> wrote:
>
> > Gerard, You start off by correctly specifying that Wikipedia is about 300
> > projects and make several good points about how people confuse Wikipedia
> > with English Wikipedia, how this bias adversely affects various other
> > projects, and then claim that "Wikipedia" is "universally understood to
> be
> > highly toxic".  Are you referring to all 300 odd projects, or are you
> using
> > the generic term for the specific project in the way you previously
> > objected to? Something else that is not obvious?
> > Cheers,
> > Peter
> >
> > -Original Message-
> > From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On
> > Behalf Of Gerard Meijssen
> > Sent: Saturday, March 14, 2020 2:12 PM
> > To: Wikimedia Mailing List
> > Subject: Re: [Wikimedia-l] Brand Project: Who are we as a movement?
> >
> > Hoi,
> > Essie, the work done by Snøhetta centres on the notion of Wikipedia as a
> > unifying brand. The problem is that Wikipedia on its own is 300 projects
> > and that for many, if not most people English Wikipedia *is *Wikipedia.
> >
> > When we are all to be Wikipedia we will all suffer from the bias that
> > English Wikipedia brings us. The problem with bias is that the negative
> > effects are not felt, considered by those people who self identify with
> > English Wikipedia.
> >
> > * Research centres on English Wikipedia, when research is done for
> projects
> > other than English Wikipedia, it is hard to get research published
> > * New functionality is almost always written for the English Wikipedia,
> the
> > notion of the "other languages" is often not considered in the

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

[Aron Demian]

On Wed, 19 Feb 2020 at 22:35, Andy Mabbett 
wrote:

> I have just come across a case on en.Wikipedia where the daughter of
> an article subject added details of his funeral (his death in 1984,w
> as already recorded) and his view about an indent in his life.

[...]
>
As well as being reverted, she now has three templates on her talk
> page; two warning her of a CoI, and sandwiching one notifying her of a
> discussion about her on the COI noticeboard. These total 4094
> characters or 665 words.
>

This is a topic that's seldom discussed and somewhat taboo in certain
areas, therefore not many people are aware of what experiences many
newcomers have. These events go generally unnoticed, but if you were
wondering why editor retention is a constant issue, the pattern that lies
behind this single case you brought to our attention is a top reason.

I've tried to help in a similar case of a footballer unknown in
English-speaking countries. She was repeatedly reverted without the edits
being evaluated or the rules being explained. She never returned and I was
frowned upon by the admin, who was involved, for trying to help.

I've noticed this "shoot first, ask later" pattern in many cases, not just
with newcomers. Unfortunately, this is all too common and a contributing
factor to the toxicity.

I've noticed the following issues:
1) The general unwelcoming treatment of newcomers: "noobs" are considered
lacking the proper understanding and necessary knowledge, unless they jump
right into RC patrolling, which is not the sign of a new editor.
2) The lack of protection given to newcomers:  "You have no rights" being
explicitly said to one newcomer, that I recall.
3) Preferential treatment and authority bias: the experienced/established
user is "trusted", thus must be right, therefore unwelcoming - and often
hostile - conduct is not considered uncivil or it's "not actionable".
4) The excessively vilifying application of the most frowned-upon rules
such as COI, socking. Editors tagged as such are treated the same
regardless of the effect of their actions and whether that has caused any
damage, which can scale from none to introducing bias to many articles for
years.

Currently, there is no effort to mitigate these issues, to improve the
policies and community practices. It's also a problem that while the
"biting newbies" and "civility" policies are very well written, these are
almost never applied and definitely not in the protection of newcomers. By
that I don't mean these should always result in sanctions, but that the
community - and primarily who get involved with handling disputes - should
take these seriously, approach with a neutral mindset and remind the
editors about our policies, but that almost never happens and such
complaints are either ignored or blindly decided in favor of the editor
with more supporters, enabling the abuse of newcomers.

Tl;dr:  newcomers don't enjoy the safety net created by editors who know
and care for each other and the community processes are not set up to
create a welcoming and/or safe environment, this purpose is not manifested
in any kind of endeavors or practices. If the WMF and the movement take the
Mid-Term target of a welcoming environment seriously, that's a difficult,
long-term target that will take a lot of effort.

Aron (Demian)
___
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, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>