Page MenuHomePhabricator

Please remove the Preference setting to "Mark all edits minor by default" from en.wiki
Closed, ResolvedPublic

Description

Per a proposal that is current carrying by a snowstorm, please remove the Preference setting in "Editing" tab that allows one to "Mark all edits minor by default" from the English Wikipedia (also clearing the flag for anyone has it set, if necessary).

( [[Help talk:Minor edit#Should we remove the Preference setting to "Mark all edits minor by default"?]] )


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Help_talk:Minor_edit#Should_we_remove_the_Preference_setting_to_.22Mark_all_edits_minor_by_default.22_.3F

Details

Reference
bz24313

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:03 PM
bzimport set Reference to bz24313.

Can do this by setting $wgHiddenPrefs. Will also need to run the maintenance script to turn it off for people who have it on already.

edfitzgerald wrote:

This is an excellent idea.

edfitzgerald wrote:

This is an excellent idea.

ayg wrote:

Is it better to use $wgHiddenPrefs, or just remove the feature entirely? Is there any legitimate use for this? We should try to cut out bad preferences where we can.

(In reply to comment #4)

Is it better to use $wgHiddenPrefs, or just remove the feature entirely? Is
there any legitimate use for this? We should try to cut out bad preferences
where we can.

Ditto. I glanced at this bug earlier and forgot to commit. Excessive customizing is a bad work around for poor UI, we should reconsider its entire existence.

ayg wrote:

Setting removed entirely in r69337. I've set the 1.16-wmf4 tag so someone can sync it and fix this bug.

I suppose a legitimate use would be someone who is exceeding gnomish, but also judiciously unchecks the box when making a non-minor edit.

I have no strong opinion on whether it should be killed altogether or just hidden on en.wiki.

ayg wrote:

You could do it with a JavaScript hack pretty easily. Hitting Alt-I (or Alt-Shift-I or whatever) before you save is pretty easy too, especially if you use Alt-S to save.

overlordq wrote:

Or could have just hid the option, so people who actually use the option on their own wiki will still have it and not be forced to implement javascript hacks because some site called English Wikipedia got pissy again.

ayg wrote:

I don't care what the English Wikipedia thinks. I removed the feature because *I* think we should be cutting down on not-very-useful preferences -- this is exactly the sort of niche thing that we permit user scripts for. We can't just add more and more preferences forever without removing any; that's not reasonable.

As the filer of this bug, I did not expect it to be removed from Mediawiki entirely.

I could see how it would be useful if social issues weren't a factor.

mathsmart9 wrote:

Agreed, it may be of some use for others on other wikis.

Please hide the setting only on en.wiki if they wish so; folks will be very upset if it will be removed also on other wikis, because there are lots of users who use this and lots of wikis which don't find it troublesome.

ayg wrote:

Those users can use about one line of user JavaScript instead. We don't need an actual preference for this.

I don't see why lots users should have to use a JavaScript for such a useful preference. en.wiki wants it removed, ok, I don't mind much (even if I'm a bit annoyed and I don't see an overwhelming consensus for that), but leave other wikis alone: the reasons mentioned in en.wiki's VP don't apply to other wikis.
For other wikis, if you want to reduce useless preferences, start with "Use external editor by default (for experts only, needs special settings on your computer)" and "Use external diff by default (for experts only, needs special settings on your computer)".

This preference is very useful because we have lots of users who make almost only minor edits; minor edits not marked as such are very annoying in histories if you're looking for something; false minor edits are not many in the wikis I know (also because people prefer to say that their edits are important, unless they're vandals, but when you fight vandalism you don't care of minor/not minor, obviously).

ayg wrote:

Having more preferences imposes a lot of non-obvious costs, so the number of preferences should be kept to a minimum. We have way too many as it stands. For things like this that are not terribly useful -- this saves one Shift-Alt-I or click or whatever at best, and few users use it (about 30,000 on enwiki, ~0.25%) -- we have general extensibility mechanisms like user JavaScript, and we should not provide specific preferences.

If a button must be in the prefs and enough people on a wiki use it, can't a local gadget be used instead?

There are many other settings, you can replace by javascript, but not all user have activ javascript.

The preload of a checkbox is a very simple setting. Please make that consistent, and remove all other settings, which are preload of a checkbox. Thanks.

(In reply to comment #16)

For other wikis, if you want to reduce useless preferences, start with "Use
external editor by default (for experts only, needs special settings on your
computer)" and "Use external diff by default (for experts only, needs special
settings on your computer)".

Yes, that are very complex settings and better candiate to remove.

(In reply to comment #17)

and few users use it (about 30,000 on enwiki,
~0.25%)

Why not count the active users?
30000 / 135231 = 22.18% vs. 30000 / 12931782 = 0.23%

(In reply to comment #17)

Having more preferences imposes a lot of non-obvious costs, so the number of
preferences should be kept to a minimum. We have way too many as it stands.
For things like this that are not terribly useful -- this saves one Shift-Alt-I
or click or whatever at best, and few users use it (about 30,000 on enwiki,
~0.25%) -- we have general extensibility mechanisms like user JavaScript, and
we should not provide specific preferences.

Did you check also how many users use the other preferences?
And, if there are so few users who use this, how can it be a harm, as was stated?
Anyway, as of July 2010, according to http://stats.wikimedia.org/EN/TablesWikipediaEN.htm , there are 615526 actual users, so that would be 4,9 %, and there are 99699 users with more than 100 edits (these are far more likely to use this preference), so that would be 30 %.

(In reply to comment #18)

If a button must be in the prefs and enough people on a wiki use it, can't a
local gadget be used instead?

Not every wiki has the gadget extension, and if your aim is to reduce clutter I don't see how this could be an improvement, given that we have already lots of preferences for gadgets in several wikis which use that, and those preferences are far less used that this.

ayg wrote:

(In reply to comment #19)

The preload of a checkbox is a very simple setting. Please make that
consistent, and remove all other settings, which are preload of a checkbox.

I intend to, if I ever get around to it, but it's not especially high-priority.

Why not count the active users?

Because it's more complicated to write the database query.

30000 / 135231 = 22.18% vs. 30000 / 12931782 = 0.23%

The first figure is extremely misleading, because you're counting both inactive and active users who have the preference set, and dividing by only the total active users. If 27,000 inactive users have the preference set, it would really be about 2% of active users, for example. The latter figure (mine) almost certainly understates the practical impact of the change, but at least it's a meaningful comparison.

I think this is going to annoy a lot of people, unless the people who use this feature can be notified in advance with a user talk page edit or some notification extension.

There was a question from one of the editors (https://secure.wikimedia.org/wikipedia/pl/wiki/Wikipedia:Kawiarenka/Kwestie_techniczne#Drobne_edycje) that he is unable to have his changes marked automatically marked as minor automatically (he wanted to have his box ticked by JavaScript by some means).

I have advised him to used this very feature...

ayg wrote:

(In reply to comment #22)

I think this is going to annoy a lot of people, unless the people who use this
feature can be notified in advance with a user talk page edit or some
notification extension.

I do tend to systematically underestimate annoyance to users. What do you suggest, then? Revert and WONTFIX? Revert, use $wgHiddenPrefs for enwiki, and tell anyone who complains to complain at the enwikians who asked for this? Maybe at some point in the future, we can make a more coordinated effort to cut down on needless prefs, and institute a proper transition plan.

(In reply to comment #24)

Revert, use $wgHiddenPrefs for enwiki, and tell anyone who complains to
complain at the enwikians who asked for this?

This. The consensus at enwiki is unanimous among those who commented.

Don't forget to also run the maintenance script mentioned in comment #1 to turn it off for those who currently have it on.

etdp01 wrote:

Yes, please at least fulfill the original request for en.wikipedia. This has been waiting for a while, and the consensus there is that this is not wanted as a preference.

ssonik wrote:

Guys, this is not a bug and should not be fixed. Plain and simple. Allow the preference to be enabled or disabled, do not remove it completely. 99% of the changes I make on my company wiki are legitimate *and* minor. Selecting the minor box every single time, and remembering that the setting has now been removed makes my life a lot harder.

FYI: No one searches for articles on a feature that already exists and is so self-explanatory, just in case someone might motion to have it removed.

(In reply to comment #27)

Guys, this is not a bug and should not be fixed. Plain and simple. Allow the
preference to be enabled or disabled, do not remove it completely. 99% of the
changes I make on my company wiki are legitimate *and* minor. Selecting the
minor box every single time, and remembering that the setting has now been
removed makes my life a lot harder.

The original site request simply wants it turned off on en.wiki.

ssonik wrote:

(In reply to comment #28)

The original site request simply wants it turned off on en.wiki.

I have no issue with turning it off on en.wiki, just the issue with it being removed from mediawiki all together. The version I'm running here for testing is 1.17alpha (r73191) - retrieved from SVN, and this feature is gone. Looks like it's been removed from the entire project, not just the en.wiki instance of mediawiki.

Please disable it at en.wiki, I'm tired of wasting time dealing with editors who have it enabled and make major changes in articles leaving it as M. Thanks.

mathsmart9 wrote:

And please, _just_ en.wiki, not from MediaWiki completely.

(In reply to comment #29)

(In reply to comment #28)

The original site request simply wants it turned off on en.wiki.

I have no issue with turning it off on en.wiki, just the issue with it being
removed from mediawiki all together. The version I'm running here for testing
is 1.17alpha (r73191) - retrieved from SVN, and this feature is gone. Looks
like it's been removed from the entire project, not just the en.wiki instance
of mediawiki.

r69337 by Aryeh Gregor still needs to be reverted...

overlordq wrote:

Reverted by r75815

etdp01 wrote:

Is there any chance that the original request that could have been fulfilled four months ago will ever be fulfilled?

ayg wrote:

Yes, there's a chance. Shell requests apparently aren't being done systematically right now, though, or so I've heard, so I can't say what timeframe it might happen in.

I don't think it's a shell request unless someone writes the notification script that I asked for in comment 22.

(In reply to comment #36)

I don't think it's a shell request unless someone writes the notification
script that I asked for in comment 22.

Bah. Provide a list of users to be notified and we'll have a bot do it.

(In reply to comment #36)

I don't think it's a shell request unless someone writes the notification
script that I asked for in comment 22.

There was a unanimous Village Pump discussion that was advertised via the Central discussions template.

It will be no more annoying than any other number of interface changes that have happened without notification (like the one that swapped the location of diff and hist, for example).

overlordq wrote:

  1. By 'Village Pump' are you referring to the discussion on the talk page of Help:Minor Edit? I really wouldn't call that consensus.
  1. Apples and oranges, one is a minor change to make all pages consistent, the other is completely removing functionality.

(In reply to comment #39)

  1. By 'Village Pump' are you referring to the discussion on the talk page of

Help:Minor Edit? I really wouldn't call that consensus.

What would you call consensus then? There were a couple of dozens of supporters, and not a single oppose. That's more than consensus, that's a unanimous decision.

So what exactly is the holdup here? The decision was unanimous on enwiki, it was advertised in the appropriate places, and if someone would just provide the list of users to notify we could have a bot post the notices today. Or someone could just cut the knot and do it.

Changed made to live site:

Index: CommonSettings.php

  • CommonSettings.php (revision 1616)

+++ CommonSettings.php (working copy)
@@ -2134,6 +2134,9 @@

	} else {
		$wgHiddenPrefs[] = 'vector-collapsiblenav';
	}

+ if( $wgDBname == 'enwiki' ) {
+ $wgHiddenPrefs[] = 'minordefault';
+ }

On enwiki:

  • 33625 users have minordefault enabled
  • 7965 users have been active for the period ranging from December 2010 to March 13 2011.

(In reply to comment #15)

Javascript to restore the functionality may be found here:
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_78#Preference_to_mark_all_edits_minor_by_default_asked_to_be_removed_in_bugzilla:24313

For the record, I am one of the people who preferred to have the Minor box autocheckmarked. Having lost that battle, I added the above Java to my vector.js file, and it worked for awhile. Now it has stopped working. I would have opened a new bug, but (1) I wanted to express my dismay at the loss of this pref. and (2) I figured I'd give the devs a break.

Update:
Last notifications were sent to the users. The preference will be overwritten soon.

Paine> open a different bug please. I am not a javascript guru :(

A bug report should not be needed; post to [[WP:VPT]] and someone should be able to debug the javascript.

(In reply to comment #47)

Update:
Last notifications were sent to the users. The preference will be overwritten
soon.
Paine> open a different bug please. I am not a javascript guru :(

A new bug's not necessary at this point, as I've been testing the first of the two Java scripts that were given. While, as I noted, the second script with the cookie worked only sporadically (probably because I regularly wipe out my cookies), the first script seems to be working fine, thus far. So thank you very much, Ashar Voultoiz and xenocidic, for your responses. If that first-choice script stops working, then I'll take it to the next level.

Okay, that first js works fine. Haven't had any problems with it. I read the comments made that prompted this bug. It seems that this has brought out some good conversations about what is and what isn't a "major" or a "minor" edit. It was a pity that some comments prompted an editor to respond, "I am rather put off by the number of Support comments above suggesting that mostly minor edits can never be a valid editor's style." Lot's of apologies ensued, so maybe this was a good thing. At any rate, you devs have better things to do than to get involved with these controversies. I personally would like to see the pref. restored, but heck, I have the js, so I'm okay with the deletion. It's so much easier for the gnomes, who shy away from code like js, to just check a box, though. Best of everything to you all!

bugzillawikimedia42763 wrote:

Re "Last notifications were sent to the users. The preference will be overwritten
soon" (posted 2011-03-20), is there an estimate on when this will be completed?

(In reply to comment #51)

Re "Last notifications were sent to the users. The preference will be
overwritten
soon" (posted 2011-03-20), is there an estimate on when this will be completed?

I do believe it already was.

11:51 logmsgbot: hashar synchronized php-1.17/wmf-config/CommonSettings.php 'bug 24313 - hide preference minordefault for enwiki'

March 13: 11:51 logmsgbot: hashar synchronized php-1.17/wmf-config/CommonSettings.php
'bug 24313 - hide preference minordefault for enwiki'

Sorry, I think I forgot about this bug :(

Although the configuration setting is hidden, I still have to update enwiki database to disable it for user that had it before the change.

Will try to get it done this week.

LantzR wrote:

Hiya,

For the record, I am one of the people on en-Wiki who had minordefault enabled.

Thank you very much for just putting this in $wgHiddenPrefs for en-Wiki , It is not a "useless preferences" in MediaWiki.

(In Comment 7)

I suppose a legitimate use would be someone who is exceeding gnomish,
but also judiciously unchecks the box when making a non-minor edit.

Yep.

I do not consider that I was invited to the battle. Perhaps if there had been a Bot notification to the set of 33,625 users that had minordefault enabled, advertising an open discussion on Help talk:Minor Edit about removing the feature they were using, the debate would have been larger and less one sided.

The Village Pump Proposals one line ad did not attract many of that set, while Village Pump Technical discussion seems to be still trying figure out how to replace the now hidden simple check box with script that works.

Since I had no intent of ever changing my minordefault, it is the change from Bugzilla Comment 55 that most directly affected me. --- Perhaps Ashar would consider another Update Where 'LantzR' setting me back to enabled. ;^)

Cheers,
Lantz

http://en.wikipedia.org/wiki/User_talk:LantzR

(In reply to comment #56)

Bot notification to the set of 33,625 users that had minordefault enabled,
advertising an open discussion on Help talk:Minor Edit about removing the
feature they were using, the debate would have been larger and less one sided.

It's quite true that "wikignomish users" are not likely to have taken part in such a discussion, but [[Help talk:Minor edit]] is not protected, so I expected them to complain, after the notification; still, nobody did, apparently. :)

LantzR wrote:

(In reply to comment #57)
Thanks for the references.

I'd picked up on the Village Pump Technical thread from (Comment 7) above.
I installed the 1st (and 3rd) script (same code as the Mark snippet ) from the
instructions there and added a comment to the end of the thread.

It is working fine.

I'll switch to the Mark_minor_edit snippet you point out, it's the same code
but I prefer Marks comments and if style.

Cheers,
Lantz

LantzR wrote:

(In reply to comment #58)

(In reply to comment #56)
... , but [[Help talk:Minor edit]] is not protected, so I expected
them to complain, after the notification; still, nobody did, apparently. :)

I know the bright red "Please do not modify it." certainly slowed me down.

] "The following discussion is closed. Please do not modify it.
] Subsequent comments should be made in a new section.
] A summary of the conclusions reached follows."

I was using the Vector skin normally by preference and have switched
to Mark_minor_edit snippet per (Comment #57) for it's script.

Thanks all for your help.

Cheers,
Lantz

bugzillawikimedia42763 wrote:

I am currently assisting a non-technical user who is stuck with having every edit marked as minor with no way to turn it off. That hidden box needs to be turned off for all users by a 'bot. Giving the users a way to turn it back on seams reasonable, but the hidden box needs to be unchecked for users who don't do something special to keep it turned on. I am sure that there are many other users who, like mine, have been spending years inadvertently marking all edits - including major changes - as minor without really knowing what a minor edit is or why there is an m next the every edit. There is a larger issue as well: when a user interface option is hidden, careful thought needs to be given to setting a sane default for users who now have an unchangeable user preference. I sometimes try different user configuration settings to see if I like them. Having the ability to change it back suddenly disappear is not something I would allow from the software developers who work for me, and neither should Wikimedia allow it. ~~~~

bugs wrote:

Ashar said in comment 55 that he will be doing that soon.

(In reply to comment #62)

Ashar said in comment 55 that he will be doing that soon.

I wrote a script for this and ran it just now. 32,640 users were affected. All of them have now had their minordefault preference removed from the preferences table; this should fix the issue.

Because I interrupted the script at some point, it's possible that the preference will come back for up to 100 users. If this happens, post a comment on this bug and I'll rerun the script. Unfortunately, the identity of these users is unknown, so I can't fix this problem before it happens, only after.