Last modified: 2013-09-28 00:16:47 UTC
Certain accounts should to be excluded from generating notifications, such as Signbot, Hostbot, etc. There are a few different ways we could solve this, but one would be an on-wiki configurable blacklist.
Related bug: 47910
Any way we could fit pages in as well? We've got some concerns around things like SPI.
(In reply to comment #3) > Certain accounts should to be excluded from generating notifications, such as > Signbot, Hostbot, etc. There are a few different ways we could solve this, > but one would be an on-wiki configurable blacklist. This should be a per-user configurable list. Some people might want to receive notifications when a certain bot uses their name. For example, I would like to know what pages HostBot uses my name on. I also think it would be useful for people to know when sinebot signs for them (unless they've opted out), but the people on who's page sinebot is signing should not be notified of a new message on their talk page every time sinebot signs for someone. I can understand the concern with pages as well for things like SPI and ANI, but am curious how someone knowing they are being investigated could affect the investigation. I mean, either it will be a hint that they need to shape up and apologize and if they really do mean well, they will do that. If it is an SPI investigation for someone that only means to do harm, then seeing they are being investigated won't make them do less harm (although it might make them change IPs causing them to be harder to track).
(In reply to comment #3) > (In reply to comment #3) > > Certain accounts should to be excluded from generating notifications, such as > > Signbot, Hostbot, etc. There are a few different ways we could solve this, > > but one would be an on-wiki configurable blacklist. > > This should be a per-user configurable list. Some people might want to > receive > notifications when a certain bot uses their name. For example, I would like > to > know what pages HostBot uses my name on. Per-user configurable lists dramatically increases the complexity of the use cases that have to be supported. Additionally, implementing it in this fashion makes things very awkward for new users - who presumably start off /without/ a per-user blacklist. > I also think it would be useful for people to know when sinebot signs for > them Can you explain the use case for this? > (unless they've opted out), but the people on who's page sinebot is signing > should not be notified of a new message on their talk page every time sinebot > signs for someone. > I can understand the concern with pages as well for things like SPI and ANI, > but am curious how someone knowing they are being investigated could affect > the > investigation. I mean, either it will be a hint that they need to shape up > and > apologize and if they really do mean well, they will do that. If it is an > SPI > investigation for someone that only means to do harm, then seeing they are > being investigated won't make them do less harm (although it might make them > change IPs causing them to be harder to track). A lot of people who are prominent long-term abusers are, frankly, attention-seeking. Giving them attention is by definition negative for the project.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #3) > > > Certain accounts should to be excluded from generating notifications, > > > such as Signbot, Hostbot, etc. There are a few different ways we could > > > solve this, but one would be an on-wiki configurable blacklist. > > > > This should be a per-user configurable list. Some people might want to > > receive notifications when a certain bot uses their name. For example, > > I would like to know what pages HostBot uses my name on. > > Per-user configurable lists dramatically increases the complexity of the use > cases that have to be supported. I understand this, however, wouldn't it be possible to have the blanket black-list for the site, and then allow people to white-list the ones the want over-riding the blacklist for them? > Additionally, implementing it in this fashion makes things very awkward for > new users - who presumably start off /without/ a per-user blacklist. See response above... Would start with a blanket black-list which removes this concern. > > I also think it would be useful for people to know when sinebot signs for > > them (unless they've opted out), but the people on who's page sinebot is > > signing should not be notified of a new message on their talk page every > > time sinebot signs for someone. > Can you explain the use case for this? It would serve as a reminder for new users to sign their posts if they got a message every time they forgot, making them more likely to remember to sign it in the future. For that matter, if it is not worth it to allow this here, perhaps sinebot itself could be modified to post a reminder on the talk page of the user that forgot everytime it has to sign for them. Of course, if the opt out of automatic signatures with the template, they wouldn't get the reminder. > > I can understand the concern with pages as well for things like SPI and ANI, > > but am curious how someone knowing they are being investigated could affect > > the investigation. I mean, either it will be a hint that they need to > > shape up and apologize and if they really do mean well, they will do that. > > If it is an SPI investigation for someone that only means to do harm, then > > seeing they are being investigated won't make them do less harm > > (although it might make them change IPs causing them to be harder to track). > A lot of people who are prominent long-term abusers are, frankly, > attention-seeking. Giving them attention is by definition negative for the > project. Yes, I entirely agree with this; however, I feel that by not allowing those mentioned on those page to see the mentions would be a complete assumption of bad faith and against the one of the very moral fibers of what Wikipedia is.
Having a blacklist per wiki is much simpler to implement than a blacklist per user. So we may implement the former first. I'm interested in hearing ideas for how a per-user blacklist interface would work.
(In reply to comment #6) > Having a blacklist per wiki is much simpler to implement than a blacklist per > user. So we may implement the former first. I'm interested in hearing ideas > for how a per-user blacklist interface would work. Simply, the system would not show notifications from events from any "User" (because bots are users) that are listed on a page named [[MediaWiki:Echo-blacklist]] UNLESS the "User" is listed on [[Special:MyPage/Echo-whitelist]].
So it's not a blacklist, it's a whitelist?
(In reply to comment #8) > So it's not a blacklist, it's a whitelist? LOL to be honest, I don't care how it is done... I would think that the system checking [[Special:MyPage/Echo-blacklist]] would be easier and be done with it. That would however need to be implemented by every users, so [[MediaWiki/Echo-blacklist]] probably would be better with the option to override it with [[Special:MyPage/Echo-whitelist]]. So, yes, it is either a per-user blacklist, or a site wide blacklist AND a user whitelist that I'm saying.
User-by-user modifications are actually incredibly finnicky. I'll be honest; an active blacklist is probably going to be a high priority, but I can't promise when a whitelist to override it could come in (or even if it will).
(In reply to comment #10) > User-by-user modifications are actually incredibly finnicky. I'll be honest; > an active blacklist is probably going to be a high priority, but I can't promise > when a whitelist to override it could come in (or even if it will). I realize that and I would be willing to write the code myself to incorporate the whitelist if I can. Just point me to the section where the blacklist is incorporated, and I'll amend it to include the whitelist. The easiest way to make sure that people put it in the right place, is to offer a link to their whitelist on the [[Special:Preferences#mw-prefsection-echo]] page similar to all of the skin/common css/js pages linked to from [[Special:Preferences#mw-prefsection-rendering]].
I'm envisioning several small iterations for this: 1. Hard-code a blacklist per wiki in InitializeSettings.php (in cluster configs) + add support for blocking notifications by those blacklisted users 2. Add support for ingesting an on-wiki blacklist (probably at MediaWiki:Echo-blacklist) so that the communities can manage the blacklists themselves 3. Add support for ingesting per-user whitelists and overriding the blacklist Or if someone wants to bite off a bigger chunck they could do 1+2, 3 or 1, 2+3.
Related URL: https://gerrit.wikimedia.org/r/62624 (Gerrit Change I0d7e071067c6974fb90cf6c0ba1bd159f46bd5df)
Change has been merged, echo documentation on mediawiki.org has also been updated.
(In reply to comment #14) > Change has been merged, echo documentation on mediawiki.org has also been > updated. Where? I don't see it updated on http://www.mediawiki.org/wiki/Echo_(Notifications) Nor do I see the documentation at http://etherpad.wikimedia.org/echo-release updated either. I don't see it on http://www.mediawiki.org/wiki/Echo_(Notifications)/History and no mention on http://www.mediawiki.org/wiki/Help:Extension:Echo either. I'm not doubting that documentation was added, I'm just unable to figure out where and would appreciate a link so I can become more informed. Thanks.
I didn't realize all those other places exist, sorry new here :) I put the documentation at http://www.mediawiki.org/w/index.php?title=Extension:Echo, should the others all be updated as well?
Additionally the docs could certainly be clearer, if you could suggest what doesn't read very well or isn't clear i will update as necessary.
I'll handle the enwiki documentation when the code is deployed; I'd avoid touching 'history', but the help:extension page would probably be good to improve.
(In reply to comment #17) > Additionally the docs could certainly be clearer, if you could suggest what > doesn't read very well or isn't clear i will update as necessary. I see no references on any of those pages when I search for "blacklist" which is the topic of this bug report. The only one of them that mentions it is http://etherpad.wikimedia.org/echo-release under a bullet labeled "* Recommended features:" Ahh... I found your link there in your reply... I'm sure "most" users will not know what "An sprintf format of per-user notification agent whitelists." means. "The whitelists must contain one username per line which will always trigger notifications regardless of their existence in the blacklists." is kind of ambiguous and I'm guessing will lead to confusion and trouble. One username per line as in: ---- Bob Fred Sam ---- or ---- User:Bob User:Fred User:Sam ---- or ---- [[User:Bob]] [[User:Fred]] [[User:Sam]] ---- ??? "Set to null to disable." meaning leave the page blank or actually typing "null" on the page? Will deleting the page also disable it? Just some questions I can think of that should be addressed now. ;)
(In reply to comment #19) > I see no references on any of those pages when I search for "blacklist" which > is the topic of this bug report. The only one of them that mentions it is > http://etherpad.wikimedia.org/echo-release under a bullet labeled "* > Recommended features:" Sure; as said, I'm going to build the on-wiki documentation over the next couple of days. Note that this code is not deployed, and so having documentation for it is not urgent. > > Ahh... I found your link there in your reply... I'm sure "most" users will > not > know what "An sprintf format of per-user notification agent whitelists." > means. That's irrelevant. This is documentation for the extension page; it is aimed at developers building for Echo or sysadmins interested in using it on their MediaWiki instances. > "Set to null to disable." meaning leave the page blank or actually typing > "null" on the page? Will deleting the page also disable it? Again, this will be documented on enwiki and on the help page, but it's not something users need to be concerned about.
I apologize, I wasn't trying to rush it. I would like to get more involved in development, and figured what a better place to start than to update all of the relevant documentation? If that would be okay, I just need the information I requested and I would be happy to update all of those document pages I can (not sure if I could update http://etherpad.wikimedia.org/echo-release if I wanted to). Thanks Oliver.
The etherpad is actually largely used for internal tracking. If development's what you're interested in moving into, I recommend https://www.mediawiki.org/wiki/Developer_hub rather than an active extension, I'm afraid :/.
Hi guys, To help us refine specifications for user and page blacklists for Notifications, I have started this feature requirement stub: http://www.mediawiki.org/wiki/Echo_(Notifications)/Feature_requirements#Blacklist I look forward to updating this first feature requirement with more details, once we've had a chance to discuss them with our development team and key stakeholders.
@ShoeMaker: I elaborated the documentation at https://www.mediawiki.org/wiki/Extension:Echo#Notification_blacklist.2Fwhitelist a bit. Cheers!
*** Bug 50148 has been marked as a duplicate of this bug. ***
[[Special:MyPage/Echo-whitelist]] feels really ugly to me. :-/ I'm having difficulty expressing why exactly, but it makes me feel very weird inside.
(In reply to comment #26) > [[Special:MyPage/Echo-whitelist]] feels really ugly to me. :-/ I'm having > difficulty expressing why exactly, but it makes me feel very weird inside. What are you suggesting? I know there is a discussion on enwp at the moment that would quickly be resolved with a [[Special:MyPage/Echo-blacklist]] option, but I'm trying to avoid that by convincing the community to just add the bot to [[MediaWiki:Echo-blacklist]] as I think that is the best option. I mean, this bot is just delivering signpost message and messages to the talk pages of members of specific projects, so there is little reason to get the message on their talk page AND have to get a notification. Those that want the extra notification can always add the bot to their individual whitelist as it is currently set up.
