Talk:Editing team/Community Conversations

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