Yeah, newly created accounts are not responsible, remove all preferences to let him not make any choose ...

Third parties will love this, too.

I support a INVALID/WONTFIX.

Community consensus for this is where?

No, no, this is a good bug. It's just the wrong time of year - normally we bring up things like this around the beginning of April. Or perhaps that would be the time to actually announce it?

Nevermind, carry on.

db, p858snake,

Please discuss the bug here, no one is being assigned this work right away, I logged in order to start getting feedback.

(In reply to comment #4)

Please discuss the bug here, no one is being assigned this work right away, I
logged in order to start getting feedback.

FYI, [[mw:Bug management/Bugzilla etiquette]] seems to strongly discourage such very broad discussions from happening on bugzilla. If you disagree, you may want to comment on its talk page.

(In reply to comment #5)

(In reply to comment #4)

Please discuss the bug here, no one is being assigned this work right away, I
logged in order to start getting feedback.

FYI, [[mw:Bug management/Bugzilla etiquette]] seems to strongly discourage
such
very broad discussions from happening on bugzilla. If you disagree, you may
want to comment on its talk page.

Hi Nemo,

I helped Andre draft the Bugzilla etiquette document so I am aware of it. Not sure exactly what part of it you feel is in opposition to those guidelines. This is a "real bug" not just a discussion about possible options. I just wanted to make it clear that the exact implementation hasn't been finalized and that comments are welcome.

(In reply to comment #5)

(In reply to comment #4)

Please discuss the bug here, no one is being assigned this work right away, I
logged in order to start getting feedback.

FYI, [[mw:Bug management/Bugzilla etiquette]] seems to strongly discourage
such
very broad discussions from happening on bugzilla. If you disagree, you may
want to comment on its talk page.

Hi Nemo,

I helped Andre draft the Bugzilla etiquette document so I am aware of it. Not sure exactly what part of it you feel is in opposition to those guidelines. This is a "real bug" not just a discussion about possible options. I just wanted to make it clear that the exact implementation hasn't been finalized and that comments are welcome.

Then, please, explain to us why you think it is a real bug, why you want to remove the ability to change skins for new users, and where you sought community consensus for this change.

I might be mistaken, but from what I see, you haven't asked the community a single question about this. Until you do, this bug should be left in peace and quiet.

Oh, and by community, I mean the global Wikimedia community, not just the English Wikipedia.

(In reply to comment #0)

To reduce the support burden on foundation developers and designers when
creating new features or improving existing ones, skin selection and related
preferences should be removed for newly created accounts and the default skin
(currently vector) used for all new accounts.

Are you aware that most power users use Monobook? Dropping support for Monobook is not an option. If anything, Wikimedia Foundation developers and designers should be doing _more_ testing in Monobook, not less.

I can't see an implementation path for this bug; tentatively recommend resolved/wontfix. For example, a new local account could easily be part of an established global account. It wouldn't make any sense to hide skin selection preferences for a new local account while allowing older local accounts the ability to select a skin.

And selectively hiding user preferences based on account creation date seems like it would only make the overall user experience more confusing and inconsistent.

Finally, MediaWiki needs better skin support, not a reduction to a single skin. We should be moving in exactly the opposite direction: finding ways to have many skins, not just a single skin.

Feedback from a Commons user, Okki, who offer an alternative way (I'm translating from French):

"For the skin, it's sufficient to precise which is official and which are community-supported, so users can knowingly choose it, and developers don't need to test every skin, but can let the community maintain them".

In this solution, the removal is not needed, I agree with Okki the information is enough.

So I also support to close the bug as invalid, as it offer not an issue but a solution, and then try to make this solution the bug, where other solutions exist.

swalling wrote:

(In reply to comment #10)

Feedback from a Commons user, Okki, who offer an alternative way (I'm
translating from French):

"For the skin, it's sufficient to precise which is official and which are
community-supported, so users can knowingly choose it, and developers don't
need to test every skin, but can let the community maintain them".

That's a really interesting idea.

For this case, I think the hue and cry about consensus is misleading. Why would we ask existing users about whether they want something that we'd only do for new users? If new users were only given one skin, the change would not impact anyone currently using an alternative skin currently.

(In reply to comment #11)

That's a really interesting idea.

For this case, I think the hue and cry about consensus is misleading. Why
would
we ask existing users about whether they want something that we'd only do for
new users? If new users were only given one skin, the change would not impact
anyone currently using an alternative skin currently.

FWIW, the current user preference system does not support anything like this, and there are already huge issues with trying to set different defaults for new users like bug 47895.

(In reply to comment #11)

For this case, I think the hue and cry about consensus is misleading. Why
would we ask existing users about whether they want something that we'd only do
for new users? If new users were only given one skin, the change would not
impact anyone currently using an alternative skin currently.

Who is a new user? I'd suggest reading comment 9 (regarding global accounts v. local accounts) and also consider that an account that has a recent registration (or account creation) date does not always correspond to a new user, even though I agree it would make life much easier if this were the case.

(In reply to comment #9)

Are you aware that most power users use Monobook? Dropping support for
Monobook
is not an option. If anything, Wikimedia Foundation developers and designers
should be doing _more_ testing in Monobook, not less.

Some developers use Monobook too, not all of us got sold on Vector ;-)

I can't see an implementation path for this bug; tentatively recommend
resolved/wontfix. For example, a new local account could easily be part of an
established global account. It wouldn't make any sense to hide skin selection
preferences for a new local account while allowing older local accounts the
ability to select a skin.

Implantation details; it could be done. But you're right, it is messy.

And selectively hiding user preferences based on account creation date seems
like it would only make the overall user experience more confusing and
inconsistent.

+1

Finally, MediaWiki needs better skin support, not a reduction to a single
skin.
We should be moving in exactly the opposite direction: finding ways to have
many skins, not just a single skin.

I don't think the two are opposites. You can have better skin support while also only shipping one default skin. You can also have crappy skin support but ship multiple skins (ahem, what we do now). Anyway, that's outside the scope of this bug I think.

This bug is about hiding non-Vector skins from new users, which I don't think has consensus if I'm reading this bug right...

(In reply to comment #11)

For this case, I think the hue and cry about consensus is misleading. Why
would
we ask existing users about whether they want something that we'd only do for
new users? If new users were only given one skin, the change would not impact
anyone currently using an alternative skin currently.

...and to clarify, I'm talking about consensus amongst developers, not amongst power users

(In reply to comment #0)

To reduce the support burden on foundation developers and designers when
creating new features or improving existing ones, skin selection and related
preferences should be removed for newly created accounts and the default skin
(currently vector) used for all new accounts.

Stopping new users from choosing skins other than Vector doesn't eliminate the existing userbase already using skins other than Vector. So either way features still need to support skins other than Vector. I don't see how this simplifies anything at all.

a few points of clarification:

I am not suggesting removal of skin selection for existing user accounts.

This has no effect on mediawiki in general, the bug was written for wikimedia wikis only.

@MZMcBride, interesting point, what are some of the use cases where existing users who use alternate skins will be creating new accounts where the skin is relevant (e.g. non-bot accounts)

What are other if any instances where making this change to newly created accounts would have an effect on existing users.

To @Steven's point it is ideal to figure out how this would affect existing users, but the target is new users, so getting consensus from people who are not currently users is a rather confusing request.

(In reply to comment #16)

a few points of clarification:

I am not suggesting removal of skin selection for existing user accounts.

This has no effect on mediawiki in general, the bug was written for wikimedia
wikis only.

@MZMcBride, interesting point, what are some of the use cases where existing
users who use alternate skins will be creating new accounts where the skin is
relevant (e.g. non-bot accounts)

New users become older users by time, mote experienced, maybe running for admin and want to work with some of the Monobook scripts existing on dewiki.

Sorry, but this bug has to be closed as WONTFIX too.

(In reply to comment #16)

This has no effect on mediawiki in general, the bug was written for wikimedia
wikis only.

The two are pretty tightly linked. :-)

@MZMcBride, interesting point, what are some of the use cases where existing
users who use alternate skins will be creating new accounts where the skin is
relevant (e.g. non-bot accounts)

What are other if any instances where making this change to newly created
accounts would have an effect on existing users.

If we look at [[m:Special:CentralAuth/JZimmerman (WMF)]], we can see that you have a local account on about 39 Wikimedia wikis that are attached to your (singular) global account.

This means that if you visit any of the other 700-plus Wikimedia wikis where you currently do not have a local account, you will have a new local account auto-created for you. If you set your skin to Monobook on zh.wikipedia.org (where you currently have a local account) and then a new account was auto-created for you on zh.wikinews.org (where you currently _do not_ have a local account), you would not be able to change your skin on zh.wikinews.org if this bug is implemented.

Yowza!

I'm going ahead and WONTFIXing this. There's obviously no consensus amongst developers here for anything actionable to happen right now, and a pretty strong sentiment to not do this as presented.

Comment 15 is important. Read that.

Take this to an RFC where it belongs, it's obviously too contentious for BZ yet :)

or maybe making my staff account? maybe want monobook there? :)

and there are various other legitimate reasons for creating new accounts (in addition to new accounts when visiting other wikis)

https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet#Legitimate_uses