https://lists.wikimedia.org/pipermail/wikitech-l/2018-February/089493.html
Talk:Code stewardship reviews/Feedback solicitation/AbuseFilter
Our communities are critically dependent on AbuseFilter. It goes without saying that we're not going to disable it.
So I guess the point of this is to try and get more resources for AbuseFilter. Fair enough, it should probably have them. But having a "sunsetting" committe which is really used as a place to try and convince foundation to invest in critical components as opposed to figuring out what to do with forgotten software thats not worth the maintenance drag, seems kind of disingenuous to me, if I'm being honest.
[This comment also applies to TimedMediaHandler]
@Bawolff, I'm trying to figure out how to respond to this effectively. As you can see in the other topic I just resolved the process is not only (or even primarily! it's only one of a multitude of options) about sunsetting, which is why it's not called that. This is a process for reviewing the current reality of stewardship for a project/component/whatever and determining what the best course of action should be. I would assume many would call that a healthy thing to do on a periodic basis.
I'm not sure which part you are calling disingenuous, honestly.
"disingenuous" was much too strong a word. I apologize.
I'm concerned much of this was structured similar to how community processes around deletion work. In a way it felt like this was AFD for extensions. I think this unnessarily paniced many people in our community.
I am also somewhat doubtful what resolution this process can bring. AbuseFilter has been unmaintained (or at least under-maintained) for a long time. Will management see this and suddenly dedicate resources? If so, why not earlier? Its not like it has been a secret it is under maintained.
My initial reaction to this was it felt like it was intentionally riling up community members in order to "prove" that we should invest in this feature, in a rather machiavellian way (This was where the word "disingenuous" came from). This however was a distinct lack of AGF on my part (In fact I was assuming paranoid conspiracy theories).
This was wrong of me. I'm sorry for the tone of my previous post. It was based on bad faith assumptions which I should not make.
I think the initial perception many of us got was that this process was mostly focusing on "sunset or not". The group is called the "Sunsetting working group". And on Code stewardship reviews, it focuses mostly on sunset and barely seems to mention "re-invest" as one of the options - even though that's likely the best option here.
Let's work to rephrase some of that then!
The process came out of the "Sunsetting Working Group" but that group quickly decided that the process would not be a "sunsetting process" but instead a "review with multiple options: re-invest, sunset, something in between".
I am not sure I understand well this process. Is the abusefilter really subject to removal as an unmaintained extension? If so, that was the worst idea of the century (yes, I know, it's only 2018). We need it. We use it.
As @Bináris I'd like a clarification here. I think AbuseFilter needs more maintenance, yes; but I don't think we should remove it from our sites. I don't think you intend to do so, right? Just to be sure.
I'm 99% sure it isn't going to be sunset. If anything, it may be superseded by something more robust, or a complete rewrite. The reason why we're undergoing this review is because we don't have a responsible team or even a single devoted developer to respond to bug reports. I created one "Unbreak Now!" bug and it stayed open for over a month! So in others words, do not worry :) Only good will come out of this, but speaking up about the importance of the extension will further ensure it is in good hands moving forward, and that it gets the attention it deserves.
Yes, the situation is not optimal. I feel that either way WMF should fund a team to maintain and develop this kind of critical extensions so bugs are addressed, new features can be added and more work can be done. I do not think it'd be a bad idea at all, and I think WMF has enough funds to invest in this. Regards.
To help clarify, the Stewardship review process is meant to bring to light those items deployed to production that don't currently have any explicitly defined stewards. Although sunsetting may be a recommended outcome, it is not the only outcome or even the default. In the case of AbuseFilter, the ultimate desire is to get it the support that it needs, as it is clearly an important extension. Thanks.
While it might be true that AbuseFilter can benefit from more and more active maintenance, removing the feature from our sites would be a total disaster with regards to anti vandalism and anti abuse prevention. As steward, not only I can vouch for its effectiveness on local wikis but also elsewhere with the global AbuseFilters. I'd like to join @MusikAnimal @Xaosflux and @Bawolff on their statements that AbuseFilter is a critical tool. On the other hand, yes, this tool coud use some more love, and I'd like to propose that internally WMF creates a team to maintain and improve this extension. Sorry if it sounds disrespectful but this is a much much more needed feature than Flow/Structured Discussions or other kinds of projects which have received funds and time from WMF and its staff. WMF should be funding a team of developers to take care of extensions such as AbuseFilter and CheckUser. Thanks.
As I said above, I don't think we should be worried about it being removed, rather establishing sufficient resources for it in the long-term.
But anyway I wanted to say that I 100% agree that AbuseFilter is more important than Structured Discussions, or frankly many of the highly-funded projects. AbuseFilter is very much behind-the-scenes, so people don't realize how critical it is. If it were removed (again I don't think it will be), I firmly believe the wiki would be reduced to garbage, probably within a matter of weeks.
+1 and piling on that this software component should be treated as a critical service for WMF hosted wiki's, having volunteers trying to clean up mess client-side (such as via running bots) would not be able to keep up with issues that the edit filter can handle server-side.
AbuseFilter has become quite critical for maintaining projects, local hits on enwiki alone can hit 1 edit/second during peaks, and edit filters have been leveraged to enforce community policies and standards not otherwise possible. I recommend WMF allocate funding to ensure this is maintained.
+1
Abusefilter is definitely something money must be spent upon. It's pointless to talk about user retention and anti-harassment while removing the most effective counter-vandalism weapon.
I'll repeat what I wrote on the Phabricator task:
It probably goes without saying that AbuseFilter is indispensable. Especially on larger wikis, it automates a great deal of work for us, and I hear horror stories of what the patrollers went through before AbuseFilter was a thing. Ongoing maintenance and support of this extension should be paramount.
By design there's always potential for performance implications, but I would argue that under the current or a similar system, the primary responsibility of keeping it efficient lies with the filter author. The issue here is that often the author is unaware they are slowing anything down. T177017 and T161059 helped us on enwiki, but the this profiling is still absent on many other wikis. Ideas for further improvements can be found at T176895, T102903, T179604, and T175954.
I would like to also stress that the extension seems to be slowly degrading, or has had regressions introduced over time. On enwiki at least, we've found malfunctions are more common these days, and nearly something we've come to expect. See T175933 for a parent task.
+1
I couldn't believe my eyes when I saw Abuse Filter on the list of features without maintenance. This shows there is a serious problem with maintaining critical legacy software within WMF. Abuse Filtering is used not only for fighting vandalism, but also to enforce different policies, for instance preventing users from using deprecated tags. Please allocate sufficient resources for it to be not only maintained, but also improved as much as possible.