Talk:Editing team/Community Conversations/Flow

This page is an archive. Do not add new topics here.

Please ask new questions at Talk:Editing team/Community Conversations instead.

In a future conversation, we might consider reflecting on the current state of the default, full-page mobile editing experience(s).

What are they like to use? What do they require in order for you to use them constructively? In what ways might the assumptions these experiences implicitly make be misaligned with what people who are arriving to them need/expect?

The above was prompted by @Sj who entered this idea on wikimedia-l.

In the time between now an when the synchronous conversation the task description is describing, I wonder if it could be useful to use this thread to share mobile editing/contribution experiences (on- and off-wiki!) we've individually found to be effective and potentially instructive in the context of Wikipedia.

A thread can be a good place for that. Here are a few quick examples from recent experiences:

Effective:

• When on mobile I often have a sentence or two that I want to add or change. Anything that makes this easier is helpful: from section-editing links, to "add section" links on talk pages, to auto-fill options for edit summaries.
• Being able to quickly get to the browser view for any page, in any namespace. The app view is always slightly incomplete or limited. (The less complete the app's implementation of a namespace [like categories], the less likely it is to make it possible to switch to the browser)

Ineffective:

• Anything that greatly increases the number of clicks to get to the page I want to edit. For instance, right now every link followed requires me to choose "open in new tab" or "read article". That makes finding something via browsing take twice as long. Unlike popups-on-hover this doesn't fit smoothly into a reading workflow that invovles lots of link-following. :)
• Anything that is different from browser or desktop editing for no obvious reason. (buttons or interface features not available, text from the default site hidden, &c.) This failure mode is not specific to mobile, but the mobile app interface has a large number of these "spot the difference" changes in one interface. (A non-mobile example of the genre: edits on this talk page, because it is broken up into Topics, cannot receive "thanks" -- in the page + personal edit histories, those edits have a slightly different set of interface links as a result.)

Buggy: slightly more flies in the ointment.

• When trying to edit a protected page, the default error message has a repeated phrase (both branches of an if function in a template appearing as text). When trying to edit the talk page of that template, the wikitext overflows the textarea making it hard to move to the end of the section. (task T367849)

@Sj: a quick note to say...

Might you be available to join the next Editing Team Community Conversation scheduled for Wednesday's (3 July)? The conversation will take place from 17:30 - 18:50 UTC.

I'm thinking this could be a good venue to talk more about mobile editing and the points you're raising above.

I have some morning meetings but will try to join for part of it. I think the recent email thread from people in mobile-heavy countries describing how mobile, and particularly app editing don't work for them because they are stripped of so many functions, also offered a good summary. I also think our energies around this are spread pretty thinly; we still have different feature sets and product focus on clients for different platforms; we should look again at how other web/app ecosystems manage to streamline updating a variety of clients.

Understood! If you can make it, wonderful. If you can't, no worries...the input you've shared here and elsewhere (I owe you a response!) continues to be helpful.

Regarding the mobile-editing focused wikimedia-l thread, I agree with you in seeing that as a tremendous resource for helping us to better understand where/how existing mobile editing experiences are falling short. And falling short in particular for people – if the 2021 Community Insights Survey findings continue to hold true – who are, "...dramatically underrepresented among Wikimedia contributors."

Please see Editing team/Community Conversations#20 January 2023 for the details. You are invited!

This meeting will happen in French and English, with a live interpreter for French speakers. We will use w:en:Zoom (software) to support the translation.

Bachounda, Ngoudechi, Obedmakolo, Joris Darlington Quarshie, Timzy D'Great, Jemima2019, Zeemahgan, Prince1g4, Yaw tuba, Bukky658, Charity00, Agbalagba, AC Krah, Mbaidoo, Macocobovi, Kumi Haymondabutu, Bolanle Adeleye, Olugold, Dera xoxo, Iwuala Lucy, Senator Choko, Lotinoh, Spadeex, Valentine_Badu, Aliyu shaba: You all planned to attend last time, and I wanted to make sure that you saw this message, too.

I know there are other things happening on Friday. It will be similar to December, and there will be another meeting in March. If this week doesn't work, perhaps we will see you another time.

Alright noted with thanks.

Noted with thanks. Looking forward to it.

Noted with thanks. Looking forward to it.

Apology for missing the January 20 meeting. Please give us a heads up for the forthcoming March meeting. Thank you.

Alright, only get me notified

please what time does it starts??

Thanks for the heads-up. Looking forward to it.

Thank you! Please what’s the password to the meeting?

Thank you! Please what’s the password to the meeting?

Thanks a lot for the notification! I will be attending this meeting.

Let me get the password.

Passcode: 234152

The meeting is starting now.

CapitainAfrika, Waltercolor, other editors:

The next meeting is tentatively scheduled for Wednesday, June 14th, a little later in the day. It will be French only. Please invite your friends.

DeepL dit : "La prochaine réunion est provisoirement prévue pour le mercredi 14 juin, un peu plus tard dans la journée. Elle se déroulera uniquement en français. Merci d'inviter vos amis."

Thx for the mention. I have one other meeting for Wikimedia the 14, so not sure I can attend yours. Waltercolor (talk) 06:52, 25 May 2023 (UTC)

Thx

T324730: Create the heuristic that will [initially] trigger the reference check

T327959: Create a way for volunteers to audit and configure Edit Check

Following up from invite. I'd suggest at the minimum if a new paragraph is created that has no citation included.

@Xaosflux, a follow up message to say: thank you for sharing the above.

The criteria you shared (new paragraph + no citations) is precisely how we're planning to configure the "Should Edit Check get activated?" logic, initially.

Over time, we're thinking that projects will be able to make this logic more "robust" (read: minimize false negatives) by configuring Edit Check in ways similar to what you described below.

Note: the project page contains a bit more context about how we converged on the above which I suspect will look familiar seeing as we (you and the Editing Team) seemed to have "landed" in the same place.

Excellent – thank you for sharing this idea, @Xaosflux. I've added it to the ticket where we're defining the initial heuristic.

I've emphasized "initial" in the sentence I wrote above because we (the Editing Team, and folks like @Sdkb, @Mathglot, @Phlsph7, @Elmidae, and others) have been thinking of it being crucial^[1][3] that we be able to iterate upon the heuristic this initial "reference check" will depend on (and potentially others in the future) together.

With this in mind, what information/abilities can you imagine yourself needing to have access to in order to evaluate the effectiveness of this "reference check"?

A couple of ideas that we've been thinking about...

On a per-project basis, volunteers ought to be able to: (1) see the rules that determine when "edit check" is initiated, (2) see the edits the current configuration of "edit check" rules would cause the system to flag, and in the future, (3) adjust the rules mentioned in (1).

Having rules live on-wiki (like at MediaWiki:EditCheckRules.json or the like) would help projects adjust to their needs in a lighter weight format than the abusefilter (inspired by the newcomer tasks setup). That would satisfy 1 and 3; as far as 2 - not sure. Actual edits with it should get identified (a revision tag would prob suffice). It seems like edit-check is going to interfere in the publish workflow - this should be carefully considered with how it overlaps or times with ORES and AF - there are certainly edit types that could trigger all 3 of these things.

Having rules live on-wiki (like at MediaWiki:EditCheckRules.json or the like) would help projects adjust to their needs in a lighter weight format than the abusefilter (inspired by the newcomer tasks setup)

@Xaosflux: well put and agreed. I've added what you've suggested above to T327959#8725987. This is the task where we'll need to work together to figure out how to go about implementing Edit Check's on-wiki configuration.

...as far as 2 - not sure. Actual edits with it should get identified (a revision tag would prob suffice).

Noted. It sounds like we're on the same page...

The Editing Team is planning to do as you suggested above: introducing a hidden revision tag (T324733) that will enable us (volunteers and members of the Editing Team) to review the edits (T324734) the Edit Check heuristic (T324730), as currently implemented, would identify as needing references.

It seems like edit-check is going to interfere in the publish workflow - this should be carefully considered with how it overlaps or times with ORES and AF - there are certainly edit types that could trigger all 3 of these things.

Great spot...

Do you happen to have a scenario in mind where you think what you described above could come to fruition? I'd like to make sure I have a clear image of what you're seeing in mind so that we can account for it and if possible, ensure people do not experience a deluge of potentially redundant messages.

Xaosflux, in practice, how many of the Wikipedias do you think would be able to manage a JSON file locally?

Any if it was guided such as this one: testwiki:Special:EditGrowthConfig --> testwiki:MediaWiki:GrowthExperimentsConfig.json

That would limit the tool to "pre-built" modules. You couldn't have one that says, e.g., that the local community has decided on a particular style for writing about Covid/covid/COVID/COVID-19. I think that would probably be okay, but it would be a limitation.

So instead someone is going to write this in to php for every topic a community wants? Being able to empower self-service somehow seems better; if some sort of "trigger" needs to happen that could also be in a config file, no?

Hmm. On the one hand, implementing a very flexible, AbuseFIlter-like system inside the editing environment would maximize local customizability. On the other hand, the existing AbuseFilter can't be used in practice at most Wikipedias (too complicated for average admins), and its use at some wikis, especially the wikis that have only one or two people who can write regex, can cause problems. Poorly tested filters can have unintended consequences, even when the intention is noble.

c.f. Talk:Edit_check#Where_will_this_sit_in_the_publish_process?

Hello, all talk-page watchers: Please see Editing team/Community Conversations#3 March 2023 and consider joining us. Please share this with your friends, too. This meeting will be in English only.

Pinging folks: Bachounda, Ngoudechi, Obedmakolo, Joris Darlington Quarshie, Timzy D'Great, Jemima2019, Zeemahgan, Prince1g4, Yaw tuba, Bukky658, Charity00, Agbalagba, AC Krah, Mbaidoo, Macocobovi, Kumi Haymondabutu, Bolanle Adeleye, Olugold, Dera xoxo, Iwuala Lucy, Senator Choko, Lotinoh, Spadeex, Valentine_Badu, Aliyu shaba, Owula kpakpo

If you'd like to contribute to and/or receive updates about the work the Editing Team presented during the 16 December community meeting, please comment the following in this thread:

1. Your username
2. What you'd like to be notified about. E.g. when new designs are ready for review, when new features are available for testing, when we need help, etc.

Macocobovi

when new features are available for testing