Last modified: 2014-04-07 18:22:19 UTC
Per consensus at https://meta.wikimedia.org/w/index.php?title=Meta:Babel&oldid=5758769#Enable_CleanChanges The extension is part of the [[mw:MLEB]] maintained by the [[mw:Wikimedia Language engineering]] team.
Change 81678 had a related patch set uploaded by Nemo bis: Enable CleanChanges extension on Meta-Wiki https://gerrit.wikimedia.org/r/81678
Is this extension actually ready to deploy? Have the language team OK'd it?
(In reply to comment #2) > Is this extension actually ready to deploy? Have the language team OK'd it? It's been in use on translatewiki.net for 5 years or so, so should be relatively well tested.
Hello, this is a quasi-automated-but-not-really message: I am reviewing all tracking bugs for extensions to review and deploy to WMF servers. See the list here: https://bugzilla.wikimedia.org/showdependencytree.cgi?id=31235&hide_resolved=1 The [[mw:Review queue]] page lists the steps necessary to complete the review. I have copied them below and done some initial filling out based on what I can easily gleen from this bug and any linked to sources that are obvious. If I miss something/state something false, please do correct me. Also, if you haven't yet done so, please review the information on and linked to from: https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment == TODO/Check list == Extension page on mediawiki.org: yes Bugzilla component: yes Extension in Gerrit: yes Design Review: not WMF specific Archeticecture/Performance Review: not WMF specific Security Review: not WMF specific Screencast (if applicable): no Community support: on meta, yeah
Change 81678 merged by jenkins-bot: Enable CleanChanges extension on Meta-Wiki https://gerrit.wikimedia.org/r/81678
discussion is not yet over (ie not everyone agrees with this new 'feature'): https://meta.wikimedia.org/wiki/Meta:Babel#Enable_CleanChanges
Please either disable the extension or leave it opted out by default. That was NOT consensus to opt in, definitely insufficient considering the number of users affected.
Four people supporting this change doesn't make this community-supported. I'd say four people don't really make a community at all. Such rather major changes on a wiki like meta should be discussed far more and have a wider support.
I've submitted https://gerrit.wikimedia.org/r/#/c/84102/
(In reply to comment #8) > Such rather major changes on a wiki like meta should be discussed far more > and have a wider support. I responded to this on the wiki, but it's unclear what you would have preferred in terms of advertising the discussion. [[Meta:Babel]] was used and there was unanimous support. And countless others (including myself) decided to abstain from voting, particularly as this can be disabled on a per-user basis, meaning that presumably at least a dozen users were consulted and either didn't care or supported the idea.
(In reply to comment #10) > (In reply to comment #8) > > Such rather major changes on a wiki like meta should be discussed far more > > and have a wider support. > > I responded to this on the wiki, but it's unclear what you would have > preferred > in terms of advertising the discussion. [[Meta:Babel]] was used and there was > unanimous support. And countless others (including myself) decided to abstain > from voting, particularly as this can be disabled on a per-user basis, > meaning > that presumably at least a dozen users were consulted and either didn't care > or > supported the idea. I replied on-wiki. This should've been advertised in more forums or even a watchlist notice. There's no getting around the fact that four users' support is not consensus from the wider community.
(In reply to comment #11) > I replied on-wiki. This should've been advertised in more forums or even a > watchlist notice. Looking at [[m:MediaWiki:Watchlist-details]], I don't believe Meta-Wiki has ever had a watchlist notice. If there particular noticeboards or fora you feel should be used to advertise a change of this nature, please explicitly list them somewhere. I'm not sure how anyone is supposed to be able to read your mind to figure out what standards you've created. > There's no getting around the fact that four users' support is not consensus > from the wider community. Most discussions across the Wikimedia universe (probably somewhere above 80%) involve very few users.
(In reply to comment #12) > (In reply to comment #11) > > I replied on-wiki. This should've been advertised in more forums or even a > > watchlist notice. > > Looking at [[m:MediaWiki:Watchlist-details]], I don't believe Meta-Wiki has > ever had a watchlist notice. If there particular noticeboards or fora you > feel > should be used to advertise a change of this nature, please explicitly list > them somewhere. I'm not sure how anyone is supposed to be able to read your > mind to figure out what standards you've created. > > > There's no getting around the fact that four users' support is not consensus > > from the wider community. > > Most discussions across the Wikimedia universe (probably somewhere above 80%) > involve very few users. As discussed on IRC, none of that justifies the inappropriateness of how the proposal was executed. Four users is ''definitely'' not OK for such a big change.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > I replied on-wiki. This should've been advertised in more forums or even a > > > watchlist notice. > > > > Looking at [[m:MediaWiki:Watchlist-details]], I don't believe Meta-Wiki has > > ever had a watchlist notice. If there particular noticeboards or fora you > > feel > > should be used to advertise a change of this nature, please explicitly list > > them somewhere. I'm not sure how anyone is supposed to be able to read your > > mind to figure out what standards you've created. > > > > > There's no getting around the fact that four users' support is not consensus > > > from the wider community. > > > > Most discussions across the Wikimedia universe (probably somewhere above 80%) > > involve very few users. > > As discussed on IRC, none of that justifies the inappropriateness of how the > proposal was executed. Four users is ''definitely'' not OK for such a big > change. You forget that this was actually a discussion and not a vote. In theory, one supporting argument by one user is sufficient (= there is no point in creating huge lists of "per above" comments) if no opposing argument is expressed at all (comment #10 reveals this very well). Anyway, bugzilla is not the right place to discuss Meta-Wiki affairs.
Marked as RESOLVED FIXED as the change was implemented.
(In reply to comment #15) > Marked as RESOLVED FIXED as the change was implemented. correct, but there was enough input from the community and now a lot of people disagree, so I prefer to keep it open
(In reply to comment #15) > Marked as RESOLVED FIXED as the change was implemented. I agree with this, but I'm happy to wait a few days or weeks for everyone to calm down about the change. This change is now better advertised (via [[m:Template:CleanChanges]]) on [[m:Special:Watchlist]] and [[m:Special:RecentChanges]].
To be honest, I'm not convinced that the way this has been introduced represents an improvement. 1) The extension itself clearly still needs UX love. The filter UI is already cluttered, labels like "Users (Sep: |)" and confusing icon choices (magnify icon to expand links) don't help. 2) RecentChanges is a core feature. New extensions/features need to tie into it all the time. Maintaining an extension for some subset of wikis that choose it and ensuring its compatibility with all future code strikes me as needless complication of our core UI. In other words, if these improvements are worthwhile (and I'm not disputing they are! Credit to Niklas and the translatewiki.net folks for fixing issues in their workflow), I would argue that they should be made in MediaWiki core, and consistently applied across all wikis, ideally after some more UX attention.
(In reply to comment #18) > In other words, if these improvements are worthwhile […], I would argue that > they should be made in MediaWiki core, and consistently applied across all > wikis, ideally after some more UX attention. Have created bug 54203 to cover this.
(In reply to comment #18) > To be honest, I'm not convinced that the way this has been introduced > represents an improvement. > > 1) The extension itself clearly still needs UX love. The filter UI is already > cluttered, labels like "Users (Sep: |)" and confusing icon choices (magnify > icon to expand links) don't help. I agree with James' creation of bug 54203. However, I will call out what I see as a double standard here. When it's Meta-Wiki, code in an extension has you eager to pull in the reins; if this were the English Wikipedia, experimental or other one-off changes are _regularly_ deployed in extensions. Hell, the English Wikipedia basically has Wikimedia Foundation development teams devoted to this. Again, I agree that the extension needs work (or rather, Special:RecentChanges needs work). But I think it's also fair to hold CleanChanges to the same standards we hold other extensions to (security check, not out-of-sync with Wikimedia values, a clear enhancement request and/or backed by community consensus, etc.). And in my experience, increased exposure to something, particularly something incorrect or seemingly in need of improvement, increases the likelihood of improvements taking place (cf. [[Linus's Law]] and [[m:Cunningham's Law]]).
So, is this settled or can it be disabled until there is any further development? I don't think this was put up for a vote or anything on meta. As Barras said, 4 people voted for it, most didn't even know what it entailed. Also, I hate this. It looks horrible. But whatever.... (In reply to comment #20) > And in my experience, increased exposure to something, particularly something > incorrect or seemingly in need of improvement, increases the likelihood of > improvements taking place (cf. [[Linus's Law]] and [[m:Cunningham's Law]]). Oh yay more laws! ;)
First of all, I think I mistakenly put "not WMY specific" in my checklist way up there in comment 4 (I honestly don't remember what I was meaning to imply with that). Secondly, I think this extension should either be reviewed and (based on people's comments, improved) by the Design/UX team and/or integrated into MW Core. Lastly, I don't want to speak for Dan Garry, but I don't think we want a feature like this to drift too much between Wikimedia projects (ie: we want consistency). If this is something that is wanted crosswiki/in core, then we should probably devote the Design team's time to that instead of a two step process (of extension first, then core integration (hopefully no changes between the two, but who knows what will change)). I only say this because I know how limited the Design/UX team is right now (my impression is that they're even more limited than potential MW Core code reviewers). WONTFIX'ing for now, but let's put effort into bug 54203.
(In reply to Greg Grossmeier from comment #22) > WONTFIX'ing for now, This supposed decision of not re-enabling CleanChanges was never communicated to the community. To the contrary: https://meta.wikimedia.org/w/index.php?title=Meta:Babel&diff=next&oldid=6143583 Please communicate it. > but let's put effort into bug 54203. Nobody has asked that. I see no reason to believe anyone (other than MatmaRex) is ever going to work on RecentChanges, it was just a boutade on some WMF folks' end. Time has proved so, hence the original community wish for a solution now rather than in the mysterious future needs to be respected. We can clarify the consensus of course, as some users above (not involved in translation work) received and sent mixed messages.
