Thank you for tagging this task with good first task for Wikimedia newcomers!

Newcomers often may not be aware of things that may seem obvious to seasoned contributors, so please take a moment to reflect on how this task might look to somebody who has never contributed to Wikimedia projects.

A good first task is a self-contained, non-controversial task with a clear approach. It should be well-described with pointers to help a completely new contributor, for example it should clearly point to the codebase URL and provide clear steps to help a contributor get set up for success. We've included some guidelines at https://phabricator.wikimedia.org/tag/good_first_task/ !

Thank you for helping us drive new contributions to our projects <3

I'm interested in writing patches for this ticket and/or T420600, but will hold off since it's assigned to aranyap.

In T420601#11734476, @Novem_Linguae wrote:

I'm interested in writing patches for this ticket and/or T420600, but will hold off since it's assigned to aranyap.

If you wanted to get a patch started, I think that's completely fine in this case. @aranyap can likely collaborate with you on that.

Some food for thought for this one:

• Do we want to throttle the # of notifications somehow to maximum X per day?
  • Does a mechanism to throttle already exist, or would we have to build one?
• Should we give users a preference to turn off this type of notification in Special:Preferences -> Notifications tab?
  • Probably yes. For example, on enwiki, we have an interface administrator bot that keeps GitHub repos in sync with user scripts. I imagine if a user script developer such as myself had a bunch of these set up and was making lots of edits to user scripts, the notifications would get annoying.

Hi @Novem_Linguae, I would prefer the discussion to take place in T419623. A related question has already been asked there.

This ticket has the perfect scope though. Perhaps the discussion in the other ticket should be happening here. You will want whatever engineer that works on this ticket to be able to see these comments easily so they are not overlooked.

In T419623#11729244, @A_smart_kitten wrote:

Out of interest, would this sort of logging/alerting be intended to cover JS files that get automatically loaded by MW itself (e.g. common.js, <skin>.js), or would it also e.g. be intended to cover any .js files in a given user's userspace (e.g. User:A smart kitten/userscripts/fancy-userscript-name.js)?

I would assume both, although I don't feel strongly about it. A good argument for only notifying for edits to common/vector/mobile/global/etc would be noise reduction. A good argument for notifying for user scripts would be that common/vector/mobile/global/etc is usually only loaded by 1 user (small effect), but user scripts may be loaded by dozens/hundreds of users (big effect).

In T420601#11735952, @Novem_Linguae wrote:

This ticket has the perfect scope though. Perhaps the discussion in the other ticket should be happening here.

(FWIW, I commented on the parent task rather than this one as I guess it seemed like the criteria for both the proposed additional edit tag & the proposed Echo notification would be the same. Assuming that the plan is for the criteria for both the tag & for the notif to be the same, IMO the parent task seems like it'd be more suitable for that specific conversation (at least). But I don't have a particularly strong opinion about it, and I'll comment in both other tasks now to add pointers to the other two.)

IMO
If the GitHub bot is adding a commit that was created by or merged by the same user as the user that owns the JS page, then he should not be notified as he is allready aware of the change.
A GitHub repo can have multiple users capable of merging commits, so in that case it is a matter of the trust of the co-maintiners. An edit straight to an user owned js page would be by the user himself/herself or an interface administrator that is trusted by the community. If this was a matter of trust, then the approach of this bug is not that good to begin with.
The GitHub bot could minimize the notifications by editing less, after all, MediaWiki javascript breakages are not common as seen in MediaWiki release notes.
User scripts invoked on a user owned js page, especially <user>/common.js and <user>/<skin>.js, should get notifications of that user script. It is more tempting for an bad actor to edit an user script used by multiple people than an single <user>/common.js page, because the damage caused would be higher.

In T420601#11735901, @Novem_Linguae wrote:

• Should we give users a preference to turn off this type of notification in Special:Preferences -> Notifications tab?

Maybe it's worth preference notifications for all page types as the default, while allowing separate preferences to be defined for each type. It might also be worth defining that notifications on common/vector/global cannot be disabled, similar to edits on the personal talk page.

In T420601#11735952, @Novem_Linguae wrote:

I would assume both, although I don't feel strongly about it. A good argument for only notifying for edits to common/vector/mobile/global/etc would be noise reduction. A good argument for notifying for user scripts would be that common/vector/mobile/global/etc is usually only loaded by 1 user (small effect), but user scripts may be loaded by dozens/hundreds of users (big effect).

Yes, I meant for it to apply to both. The motivation here is that editing another user's .js pages is a highly restricted action which only a few users have the right to do, and should happen rarely. When it does happen, the owner should be notified.

Change #1286171 had a related patch set uploaded (by Aranyap; author: Aranyap):

[mediawiki/extensions/Echo@master] T420601: Notify the owner of a user JS page when someone else edits it

https://gerrit.wikimedia.org/r/1286171

Change #1286171 had a related patch set uploaded (by Aranyap; author: Aranyap):

[mediawiki/extensions/Echo@master] PageEventIngress: Notify the owner of a user JS page when someone else edits it

https://gerrit.wikimedia.org/r/1286171

In T420601#11735901, @Novem_Linguae wrote:

Some food for thought for this one:

• Do we want to throttle the # of notifications somehow to maximum X per day?
  • Does a mechanism to throttle already exist, or would we have to build one?
• Should we give users a preference to turn off this type of notification in Special:Preferences -> Notifications tab?
  • Probably yes. For example, on enwiki, we have an interface administrator bot that keeps GitHub repos in sync with user scripts. I imagine if a user script developer such as myself had a bunch of these set up and was making lots of edits to user scripts, the notifications would get annoying.

After discussing with the Product Safety & Integrity team, we've decided that a notification feature is not a high priority as work being done in T197160 will involve reauthentication whenever a user edits another user's JS page. If this feature were to be implemented, notifications should be disabled by default and users should have the ability to enable/disable the notifications.