True Samuel. We can actually edit [Wikipedia] from our mobile phones. We can't 
use the visual editor. I tried to say it later with the sentence "Desktop 
computers are disappearing. We still can't edit in a good way with our mobile 
phones." but it's true the first time I mentionen this it was not factual.

About the other projects, it doesn't matter where the bottleneck is: we are 
obsolete and we have 100 million dollars. We try to make some improvements 
using a wishlist system that only creates culture of scarcity, instead of 
culture of abundance. There is a reason to create scarcity, but this is a topic 
for another essay.

Have a good weekend

Galder
________________________________
From: Samuel Klein <meta...@gmail.com>
Sent: Saturday, October 16, 2021 3:07 AM
To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.org>
Subject: [Wikimedia-l] Re: 100$ million dollars and still obsolete

Luis writes:
> For what it is worth, I think the current mobile app is pretty good and I 
> regularly finding pleasant surprises

Yea, the mobile app is sweet, editing and all.

Responding to two specific earlier comments:

1. Galder - "It is 2021 and we still can't edit by mobile phone."

-->  Safe to say this is not true :)  But you could say that about your later 
comment on the ability to "write simultaneously ... upload videos ... 
autosave", each of which are common in online collaborative spaces, and which 
we do need to make standard for our wikis.  But the bottlenecks aren't 
primarily design, but rather coordinated vision and focus -- or at least 
unblocking and supporting one another as we design and implement prototypes.  
We need new social norms and clear community use cases for simultaneous 
editing<https://bluespice.com/mediawiki-visualeditor/> (resolving attribution 
and revision history for multiparty edits), video 
uploading<https://www.mediawiki.org/wiki/Extension:TimedMediaHandler> (how to 
note the original upload if we only save a transcode), and 
drafts<https://phabricator.wikimedia.org/T39992> (rallying support behind a 
specific client-side use case to realize).

2. Jonathan -
   "[In my new sw company] we have the autonomy to make the changes in the 
first place, see what happens, and then build from there..."
   "WMF product teams work in an environment where [...] one set of end users 
(editors) has a great deal of both soft and hard power to block changes, even 
when those changes are intended for--and indeed, primarily affect--a different 
set of end users (readers)."

--> These comments highlight a common misframing, about autonomy and curation 
of the reading experience, worth addressing.  (Likely deserves its own thread!)

Much of the friction and tension in our movement stems from different 
understandings of autonomy; and the impedance 
mismatch<https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch>
 of a step function between the norms (of communication, delegation, and 
planning) of a) broad community wikiocracies and b) narrow staff hierarchies. 
Our community has thousands of designers; the staff has scores, who may feel 
constrained to work on only their particular projects. There is abundant talent.

Most active editors and curators are not "end users" of the site, any more than 
developers are -- they are involved before the end, up and down the design and 
implementation stack, building bridges, interfaces, translations.  They are 
project stewards, schedulers, templaters, designers, and maintainers.  So when 
interface designers deploying a new language-selector design are talking with 
layout designers maintaining article flair like 
geo-coordinates<https://en.wikipedia.org/wiki/Wikipedia:How_to_add_geocodes_to_articles>
 and article status 
indicators<https://www.mediawiki.org/wiki/Help:Page_status_indicators>, they 
should feel they are on the same team: improving the site skin together.

This is a solved problem in some corners, but the solutions are not evenly 
distributed.  Within Wikimedia, and within the WMF, there are groups and 
projects of all sizes that have developed without this sort of contention.  But 
we spend most of our time and energy talking about the ones that fail to do so. 
 [The article always ends on the wrong 
version<https://meta.wikimedia.org/wiki/The_Wrong_Version>; confusion is always 
due to the other person :-]   Let's learn from the successes, and not fall into 
stereotyping any parts of our nexus.

Wishing all a beautiful week's end,
SJ


_______________________________________________
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/GSOR2RYGA5OGBMGBCDFFSKKCFJUP4AQR/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

Reply via email to