This page uses content from Wikipedia and is licensed under CC BY-SA.

Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab Miscellaneous 
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.
« Older discussions, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26


Redesigned page-protection padlock icons

Redesigned icons (right) compared to the existing icons and descriptions (left)
Protection redesign - XYZt.png

I redesigned the page-protection padlock icons for a more minimalist and intuitive look. The redesigned icons use solid colors, since the shiny reflections off of the current ones make the edge hard to distinguish from the background. Some less-used protection icons now have symbols on them for clarity. For example, a create-protected page has a plus sign, and a cascade-protected page — where all pages transcluded onto the page are also protected — has a chain symbol.

Changes from original
  • One solid color instead of colored metallic texture
  • No shadows
  • No glow
  • Minimum 3:1 contrast ratio (WCAG AA 2.0 compliant)
  • Thicker shackle that matches the color of the main body
  • Rounded rectangle main body
  • Embedded white symbol for some padlocks

Posted by XYZt (talk) at 00:17, 29 September 2018 (UTC) — Updating over time — Thank you for your feedback and suggestions! I think I'll have a proposal posted by next weekend. Due to school projects, I won't be able to post the proposal and respond to questions from Monday to Wednesday.

The edges on the padlocks have a glow that make them appear to be fading into the background

Looks nice. I don't think really need to change the locks though. funplussmart (talk) 00:38, 29 September 2018 (UTC)

Thanks! In my opinion, the main problem that the current locks have is that they have parts that blend in with the white background (e.g. the white glow at the edges, a thin shackle). I think having a solid colored version is easier to see. The embedded icons are another idea that I think would help people identify the locks' different purposes. XYZt (talk) 00:49, 29 September 2018 (UTC)

These look great! The addition of icons to some of the less common locks is really helpful, I'm not sure how anyone can remember them from colour alone. the wub "?!" 16:43, 29 September 2018 (UTC)

I agree, these look great and are a clear improvement.Tazerdadog (talk) 18:58, 29 September 2018 (UTC)

Hmm, I think the current set looks a little "smarter", however these are significantly clearer and more useful when it comes to easily knowing what each padlock indicates. Given that clarity is key, I'd happily support these as better. They would require alteration of some of the most used templates, so I imagine there might be some opposition just on those grounds, rightly or not. Nosebagbear (talk) 22:53, 29 September 2018 (UTC)

Support implementation. The fade into background was a particular problem on mobile and for us editors with Corrected vision. I like the symbols int he middle as well. Thanks for doing this. Thanks, L3X1 ◊distænt write◊ 00:03, 30 September 2018 (UTC)

Support implementation, seems like they could be usable in mobile view. @XYZtSpace: Side note, if these were actually implemented, would these images be new files or replace the old ones? SemiHypercube 01:01, 30 September 2018 (UTC)

I'd advocate making them with new names so the old ones would stay around for archival purposes. Thanks, L3X1 ◊distænt write◊ 01:03, 30 September 2018 (UTC)
The old ones will still be visible on each file's revision history (note that for files, the image history is available on the same page as the main image). Posted by XYZt (talk  |  contribs) on 01:12, 30 September 2018 (UTC)
Thanks. These images would probably be uploaded as an revision on the old files' pages, as these icons are linked by about 30 protection templates combined. Changing the file link on each template would be time-consuming. Posted by XYZt (talk  |  contribs) on 01:12, 30 September 2018 (UTC)
XYZtSpace, all the templates use one module - the images are defined in one place, Module:Protection_banner/config Galobtter (pingó mió) 14:18, 30 September 2018 (UTC)
@Galobtter: Got it, thanks! I guess that eliminates the need to upload the redesigns to the same file names then. -- XYZt (talk  |  contribs) 23:04, 30 September 2018 (UTC)

I believe all wikis use the locks, so I think any change like this should probably be proposed on meta. I'm not sure though. funplussmart (talk) 01:03, 30 September 2018 (UTC)

@Funplussmart: we can change these locally without impacting any other project. The "default" is nothing; we shadow the commons file names (e.g. File:Padlock.svg) to maintain local protection and control of the image. — xaosflux Talk 01:53, 30 September 2018 (UTC)
That's why I said "I'm not sure". funplussmart (talk) 01:54, 30 September 2018 (UTC)
If you want to propose these globally, the template one shouldn't rely on the English "T" as it's interior markup. — xaosflux Talk 01:56, 30 September 2018 (UTC)
Perhaps having "{{}}" instead of "T" would do it. funplussmart (talk) 02:03, 30 September 2018 (UTC)
Someone else suggested that too. I'm not sure if it would fit though. Will test it out later. Posted by XYZt (talk  |  contribs) on 02:25, 30 September 2018 (UTC)
Update: I'm not sure if it's as eligible as the "T". Posted by XYZt (talk  |  contribs) on 02:31, 30 September 2018 (UTC) Lock-bracket-protection-test.png
The two brackets on the right are too close together. Can you try to make them equidistant? funplussmart (talk) 02:36, 30 September 2018 (UTC)
They are actually the same distance apart as the left pair. I made the distance between them farther now Bracket-protection-magenta-test2.png
Instead of {{}} try just {}. — xaosflux Talk 02:48, 30 September 2018 (UTC)
I think the last one looks okay. funplussmart (talk) 02:50, 30 September 2018 (UTC)
() I would say that { is probably sufficient, even, if we didn't want to use a T. The T has the advantage that there are less curves and points to render relatively. --Izno (talk) 23:28, 30 September 2018 (UTC)
It seems that Wikidata uses a lock design similar to this already, though the color appears to be somewhat different. For example, check the lock on the top-right of Wikidata's main page. Does this have any relation to you, XYZt? —Nøkkenbuer (talkcontribs) 15:25, 30 September 2018 (UTC)
That's cool! I don't use WikiData often and didn't notice it. No relation whatsoever. -- XYZt (talk  |  contribs) 16:23, 30 September 2018 (UTC)

Pale colors, especially yellow but also pale blue, do not stand out well on white background. They need a black border or other detail. Jim.henderson (talk) 02:34, 30 September 2018 (UTC)

Thanks for the feedback. I made the yellow, teal, and light blue locks a bit darker. Posted by XYZt (talk  |  contribs) on 02:56, 30 September 2018 (UTC)
In general, please ensure these are WCAG AA if not AAA compliant against the background. --Izno (talk) 06:24, 30 September 2018 (UTC)
Well, they're certainly better than the current locks. Create and Pending Changes were always the hardest to spot, for me. Thanks, L3X1 ◊distænt write◊ 13:45, 30 September 2018 (UTC)
I make no judgement of the current locks; just asking that WP:Accessibility#Color be observed. --Izno (talk) 14:25, 30 September 2018 (UTC)
For an aesthetic point of view the originals look like padlocks whereas the new ones look like so many handbags. Tinky Winky anyone? Martin of Sheffield (talk) 16:21, 30 September 2018 (UTC)
I thought that the similar lock designs currently used at Wikidata also somewhat resembled handbags. However, the padlock icon is deeply embedded in Wikipedia symbolism, so I doubt anyone will be confused about it and newcomers can easily figure it out. It will, at worst, be a potential accessibility improvement at the cost of creating an obscure running joke in the commmunity. As far as I am concerned, being able to better see the icons and distinguish them without referring to the documentation is worth the unending terror of administrators saying that "protection of article X is now in the bag" and that they "bagged the article". —Nøkkenbuer (talkcontribs) 17:49, 30 September 2018 (UTC); edited at 17:53, 30 September 2018 (UTC)
Do not awaken my ability to rant for hours on locks and lock types… :P Thanks, L3X1 ◊distænt write◊ 01:11, 1 October 2018 (UTC)

I'll be honest I do prefer the current ones only because I hate change and because it's what I've been used to seeing for the last 5-6 years, That being said I do like these and I also like the little symbols on the locks which helps to differentiate between locks, Somewhat unrelated but touching on Nøkkenbuer's comment I also like the fact they're near-identical to the ones used on Wikidata, (Never used WikiData but just liked the locks).

All in all I think they look great although I do wonder if having a black border around the padlock and lock may be better?, Dunno but anyway I like these :). –Davey2010Talk 16:53, 30 September 2018 (UTC)
I guess when it comes to minimalism, even divergent designing tends to converge due to the constraints of minimalist aesthetics. In any case, I have no opposition to the new designs. Like Davey2010, I also like the internal icons, which help with decoding the padlocks and reinforce the meaning of the color scheme.
My only suggestions would be to check for color accessibility and ensure AAA-level contrast, which may be achievable by simply darkening the colors if they are not already compliant; and to consider disambiguating all the padlocks with icons so that they are useful even when stripped of their color. For the latter, the semi-protection symbol can be a shield icon with the left half filled and the other, empty half given a dotted outline; full protection can be a full shield; and extended confirmed protection can be something like a shield outline with a smaller shield filling it. —Nøkkenbuer (talkcontribs) 17:26, 30 September 2018 (UTC)
An addendum: I want to note that the additional icons suggestion is just that and I understand multiple reasons why including icons on those three may be undesirable. Even without any internal icons, I am still not opposed to the change, if only because the new design is more visually accessible. —Nøkkenbuer (talkcontribs) 17:36, 30 September 2018 (UTC)
I was able to make them meet AA-large standards, but meeting AAA would turn the gold lock into a (frankly disgusting) shade of brown, and make Pending Changes darker than what Semi is now. However, black outlines is a viable solution to this. XYZt (talk  |  contribs) – 07:52, 1 October 2018 (UTC)
I am fine with that and understand it entirely. The prior colors were no issue for me; I just want to encourage accessibility considerations as a matter of principle. The fact that it's even AA-compliant is already far more accessible than is often the case in the Internet, nevermind the fact that the design itself improves accessibility over the current one. Whether AAA-level compliance is reached is probably not an issue; and the demographic for which AA and AAA compliance is a determinative difference is probably very, very small. None may even use Wikipedia, at least not in ways that are relevant to this proposal, and I frankly doubt Wikipedia is generally AAA-compliant. If I recall correctly, our wikilink colors aren't.
Regardless, I don't think it will be ground for anyone to oppose your proposals, myself included. Thanks for being so responsive to the feedback. —Nøkkenbuer (talkcontribs) 14:41, 1 October 2018 (UTC)
By the way, XYZt, it seems your design is indeed at the vanguard of contemporary web aesthetic, since Mozilla Firefox and Google Chrome also use a similar padlock to indicate valid HTTPS connections. If these are "handbags", as has been alleged, then it seems the movers and shakers of the Internet are into handbags, too. —Nøkkenbuer (talkcontribs) 14:51, 1 October 2018 (UTC)

@XYZtSpace: Even though the black lock is hardly used (but probably since Office actions are very rare), do you think you could change the black lock so that it has a silhouette of the WMF logo on it to emphasize that it is done by the WMF Office? SemiHypercube 23:22, 30 September 2018 (UTC)

Good idea. XYZt (talk  |  contribs) – 23:26, 30 September 2018 (UTC)
@SemiHypercube: I tried it out and it isn't quite as legible as the "O" even after increasing the thicknesses of the lines.
Semi tesseract suggestion.png
XYZt (talk  |  contribs) – 02:30, 1 October 2018 (UTC)
@XYZtSpace: Have you tried making the lock, and the others, SVG files instead of PNG? The current locks are SVG files, so making the new ones SVG might make them legible. SemiHypercube 12:24, 1 October 2018 (UTC)
That's not how svg files work. My graphics software rendering a vector shape at 15x20px is the same quality as Wikipedia rendering an svg at 15x20px. And at this scale, file size doesn't matter much anyway. XYZt (talk  |  contribs) – 14:57, 1 October 2018 (UTC)
I assume all present understand that this will require a consensus at WP:VPR, and we're just deciding the specifics of that proposal. In my opinion that should be an RfC, considering the very high visibility of the change. Thanks, just making sure. ―Mandruss  16:07, 1 October 2018 (UTC)
I think I'll divide the proposal into two parts — One for changing the locks into solid colors, and one for the embedded symbols. XYZt (talk  |  contribs) – 17:06, 1 October 2018 (UTC)
Gray shackles
I like the concept, but I would make the shackels a standard gray color on all the locks to make them look less like shopping bags (#949494 is the lightest gray that meets accessibility requirements). I've seen lots of colorful locks, but almost all have silvery shackles. Also, while the PNGs are fine as a concept, I would like to see these as SVGs before implementation. --Ahecht (TALK
PAGE
) 21:38, 1 October 2018 (UTC)
I think the idea is to be very symbolic, not realistic. Also, I care less than none about resembling a handbag. I remember significant opposition to the "Your notices" icon now in use at the top of each page, because it would look like a bra to some. The predicted outcry did not materialize. I also note that the handle of a handbag often has a different color from the body. ―Mandruss  21:53, 1 October 2018 (UTC)
I'll upload all the SVGs in a few hours. XYZt (talk  |  contribs) – 00:29, 2 October 2018 (UTC)
@Ahecht: Here are the SVGs. XYZt (talk  |  contribs) – 21:43, 2 October 2018 (UTC)
@XYZtSpace: Could you upload a template-protect padlock with curly braces as you said? And could you also try making the office protect lock with the WMF logo on it? (Though the licensing might(?) have to be different because it uses a logo? Or is a licensing change not needed?) SemiHypercube 21:23, 2 October 2018 (UTC)
@SemiHypercube: The WMF logo is in the public domain. XYZt (talk  |  contribs) – 21:42, 2 October 2018 (UTC)

As the one who first commented about the new designs looking like hand/shopping bags, may I say that the grey shackle design is much clearer and they do look like padlocks now. Martin of Sheffield (talk) 22:01, 2 October 2018 (UTC)

  • Given that comments seem to have stalled out, I'd say once @XYZtSpace: is free (hopefully on Thursday (11th Oct)) they should shift this to Wikipedia:Village pump (proposals) - it should also be requested to be placed on centralised discussions Nosebagbear (talk) 19:13, 7 October 2018 (UTC)

These are great. A lot easier to understand than the old locks, too. MoonyTheDwarf (BN) (talk) 19:35, 10 October 2018 (UTC)

The new locks are easier to understand and more noticeable than the older ones. I support changing the locks, as long as all the locks are changed to have a grey shackle. 344917661X (talk) 00:47, 11 October 2018 (UTC)

@XYZtSpace: I like the new icons. Are they based on the ones used at Wikidata? I think the two sets should probably use consistent colours (except maybe where the older set doesn't have enough colour contrast). Jc86035's alternate account (talk) 06:10, 14 October 2018 (UTC)

Semi-protected suggestion

@XYZtSpace: These are very good icons, and I support the change. I have one suggestion, though: a different one for "semi-protected"; something that emphasizes the semi aspect.    → Michael J    14:20, 17 October 2018 (UTC)

i like the gray shackle versions  pythoncoder  (talk | contribs) 02:27, 19 October 2018 (UTC)

That's a good suggested change by @Michael J:, I like it. Not sure which school system @XYZtSpace: is on, but next week is half term in a lot of places, so that might offer a chance to move this great set of work to Proposals for the full RfC. I think the key bit we really need to hear now is from the template experts who can tell us of how much difficulty a change on this scale may have. Nosebagbear (talk) 22:50, 19 October 2018 (UTC)

Temporary non-admin page protection

Will it be a good idea to have a new permission where a non-admin can temporarily protect a page to stop heavy Vandalism? For example, sometimes there are pages which get vandalised at a very fast rate and due to a very large backlog, an admin might take some long time. An example is this article, which was vandalised so heavily by different users and IPs that it not only took a lot of time, but also confusion. The page protection took some time due to the backlog. The permissions of this protection can be made strict, and only trusted users who are active in RC patrolling can be given it. What do you people think? Knightrises10 (talk) 12:21, 1 October 2018 (UTC)

@Knightrises10: Actually, there was an RfC on this not too long ago. Reading this might be helpful for developing this, if it will pass. SemiHypercube 12:31, 1 October 2018 (UTC)
@SemiHypercube: I'm going through that discussion and think that it's correct to say that an admin can take away the right in case of abuse, just like they do on rollback. Also, the page can be protected just for like 15 minutes or less. Need some suggestions. Should I take this to proposals? Knightrises10 (talk) 12:46, 1 October 2018 (UTC)
Probably dead on arrival. This is proposed about every six months and no formulation has come close to reaching a broad consensus in favor of implimentation. GMGtalk 13:42, 1 October 2018 (UTC)
So it should rather be forgotten it means? Knightrises10 (talk) 13:53, 1 October 2018 (UTC)
At least in my opinion, it's almost guaranteed to be a non-productive use of time, at least until some future date when the feelings of the community at large shift toward more radical unbundling of sysop rights. No idea when or if that might actually happen. GMGtalk 14:40, 1 October 2018 (UTC)

─────────────────────────I'm not often in disagreement with GMG (And to be fair that editor isn't opposing this idea, just opining that it is unlikely to be successful).

I could be in support of a proposal to give very limited protection capability to some class of users. My proposed class would be extended confirmed (I wouldn't mind a somewhat more stringent criteria but this one is easy and creating a new class sounds like a lot of work). The capabilities would be semi-protecting only (not full protection) and limited to 15 minutes. The harm that could come to the encyclopedia if someone incorrectly semi'd an article for 15 minutes is absurdly small, while the benefit is meaningful. Abusers, after a first warning, could have the right removed. If even this small proposal seems too much, make it a six-month trial and see how it works. Seems to me that an immediate semi on an article being repeatedly vandalized to give time to post to AIV to request more substantial measures (longer semi, blocking offending party) is a pretty reasonable step.--S Philbrick(Talk) 14:51, 1 October 2018 (UTC)

Oh yes. To clarify, I would personally support such a proposal, and I even drafted one myself last year at User:GreenMeansGo/Page protector. I simply don't think the community will support it, and more to the real problem, the opposition isn't on one or two central issues that can be fixed by amending the proposal itself. Opposition has always been broad and based on a half-dozen or more issues that can't be easily reconciled. GMGtalk 14:56, 1 October 2018 (UTC)
Unfortunately, the last time it was proposed, most of the community opposed it with the reason it will lead to abuse. Rollback also has same concern, but isn't it working pretty well - users who abuse the rollback have their rights taken away. Knightrises10 (talk) 15:21, 1 October 2018 (UTC)
Looking over it broadly, the opposes include all the following:
  • Potential for abuse/protection warring
  • Conflict with having a protect button but not a block button, and/or not a delete button, and/or not an unprotect button, and/or not able to see deleted edits
  • Users who can be trusted to protect should just become admins anyway/users who can't become admins shouldn't be given this right to begin with
  • How this tool might interact with the ability to unprotect, to unprotect pages protected by another non-admin, or to unprotect pages protected by an admin
  • Potential degradation of status as “the encyclopedia anyone can edit”
  • Solution looking for a problem/ RFPP works well enough to render the right unnecessary
  • Concern that it is easier to grant an unbundled right than it is to remove it
  • Concern that this would add an unofficial prerequisite to RfA
  • Semiprotection is already overused
I don't see a way to adjust a proposal to account for the majority of those oppose rationales. GMGtalk 15:35, 1 October 2018 (UTC)
  • As told before, permissions can be taken away.
  • Protecting button should be considered different from deleting button. I don't think they should be compared, as block and deletion are something more sensitive.
  • Rollbackers, reviewers are also trusted users but not admins. A user can be trusted and yet not an admin.
  • The pages will only be protected on case of heavy Vandalism, so it will remain an encyclopedia that anyone can edit. Admins also protect pages, but we don't call it degradation of encyclopedia because it's necessary at that time.
  • Again users shouldn't be allowed to unprotect pages protect by others.
I can answer some. But as Sphilbrick said, we can at least try this for some months, giving this right at the moment to only a few very trustworthy users. Knightrises10 (talk) 15:47, 1 October 2018 (UTC)
One idea that could be considered is NeilN's proposal that was suggested in the RfC, which many people thought was good. SemiHypercube 15:58, 1 October 2018 (UTC)
Read his idea and I think that should have no concern - Knightrises10 (talk) 16:05, 1 October 2018 (UTC)
So guys, I'm taking this to proposals as I think it can have another debate. :| Knightrises10 (talk) 18:53, 1 October 2018 (UTC)
  • Just a tech note: Adding new "access groups" is EASY, adding a new technical workflow is not - for one it would require that there are developers that want to work on it (in this case a new tech process to build this protection workflow). — xaosflux Talk 19:58, 1 October 2018 (UTC)
  • @Knightrises10: - as well as the full, recent, RFC there was a also a discussion following on to specifically consider shorter protection. In a sense it was a discussion of NeilN's proposal that garnered more support during the RFC. I was unsure enough both of the level of support and of my own personal views to take it onto proposals, but it's worth a read, I feel.
I've also cut out a rough summary of points that were agreed as a good starting basis:
  1. Protection would be limited to semi-protect.
  2. Protection duration would be limited to between 45m-3 hours (TBD).
  3. Right holders ("RHs") could only protect the same page once within 24 hours.
  4. RHs could only protect 2 pages within one hour.
  5. There would be stringent requirements at WP:PERM to acquire this right. At a minimum: 2000 posts (or 1500 mainspace?), a clean 6 month block record, registered user for 150 days, proven track record in Counter-vandalism, proven track record in Requests for Page Protection.
  6. The right could only be used in Main or Talk (not including User Talk) namespaces.
  7. Right could only be used in instances of vandalism from multiple IPs/newly registered accounts. Alternate uses of protection (such as against unsourced details etc) would not be permitted
There was some specific dispute on this point:
8. Use of the right must be accompanied by a full request for some form of page protection at WP:RFPP. Failure to do so would be deemed a mis-use of the right.

Nosebagbear (talk) 14:53, 6 October 2018 (UTC)

I would support any attempts to create a non-admin page protection right given that RPP is one of the most frustrating parts of the site given the current admin shortage, the criteria listed above were created in a discussion I participated in but feel that they are far too stringent.The harm 1 or 2 innaporitate semi-protects can do is minimal compared to the amount of vandalsim granting this ability could prevent.Zubin12 (talk) 15:13, 6 October 2018 (UTC)
Hi @Zubin12: - The harm of some inappropriate semi-protects could do bigger than some missed vandalism - on some active pages it could prevent dozens of individuals from editing, it also grants certain users significant power in any potential editing dispute without them having gone through the full RfA rigmarole. Additionally, you need to look at the maximum size the RFPP backlog gets to - the issue is usually some remaining on the list for extensive periods of time, rather than dozens at once overwhelming present admins. Thus a fairly small additional core of users with limited abilities would at least reduce the issues. Finally, on a bluntly pragmatic front, strict criteria improve the chances of agreement that one of the triple-prong of core admin rights isn't being challenged. Nosebagbear (talk)
I do think a time in point 2 could be higher, but I don't think longer than 4-6 hours could be justified, however a time of 3 hours seemed a rough compromise of the points up to the point when I scribbled the above down Nosebagbear (talk)

Accounts without email addresses

Background:

Many editors forget their passwords. If they have an email address associated with their account, they can request a password reset, but if they don't have an email address associated with their account they are out of luck. This is understandably upsetting and disappointing to such editors. Wikipedia's policy is that registered users are not required to maintain a working email address, but many editors are unaware that there is no provision to reset a password without such an address.

If you've worked at the helpdesk, you've seen occasional such requests. If you are an OTRS agent, you've seen hundreds of such requests over the last few years. It's never fun to explain to someone with an active account that they have to discard it and start over. I'd like to cut those down considerably, and I'd like to be in a position that if it happens ever again, I can politely point out that they affirmatively chose this option knowing the consequences.

Proposal: I suspect that there will be resistance to requiring that registered editors have a working email address, so I don't propose to change that. However, I think it would be worth making it clearer to editors that lack of an associated email address means that in the case of a lost password, their only option is to create a new account.

At present, if you create an account through the ACC tool found at: Wikipedia:Request an account, you will have to initially supply a working email address. In contrast, if you create an account here: Special:CreateAccount, The request for an email addressed is marked optional. There is nothing on that page informing editors of the severe consequences of failing to provide an email address.

One option is to change that page to make it clear that while optional failure to include the address could lead to severe consequences if you forget your password. I know we want that page as simple as possible, but we could let people create an account without an address only if they affirmatively check a box indicating that they understand the consequences.

A second option is to make it mandatory on that page but let them know that they could remove the email address if they choose at a later time.

Removing the address can be done through preferences which does indicate some of the consequences but I'd like to see it more explicit. I wouldn't uglify that page with bold red text, But if an editor chooses the option to remove their email address they are to receive a pop up box with ugly bold red text informing them of the consequences of this action and insisting that they click a checkbox indicating that they understand.--S Philbrick(Talk) 18:18, 1 October 2018 (UTC)

I support the principle of having a huge "do you understand the risks?" warning box before allowing account creation without an email address. I totally oppose making it mandatory; the WMF has notoriously lax security, and as someone who themselves has had their email address leaked by them, I can entirely empathise with someone not wanting the WMF to get their paws on any personally identifying information, particularly if they're working on something politically or culturally sensitive. If we do go down the mandatory email route, at the very least we need to point out the risks of sharing information with the WMF, and ideally to talk signups through the mechanics of creating a burner account on a free email site. ‑ Iridescent 18:30, 1 October 2018 (UTC)
  • As an admin, when I'm about to move a page over another page that already exists, when I click the move button, the dialog reloads with an informational message informing me of what I'm about to do, and includes a new check box forcing me to acknowledge that I'm about to delete the other page. It's an extra-step nag screen that forces me to acknowledge my action, you know, in case I didn't understand what I was about to do and might be about to break something. I don't see any reason why we wouldn't do something similar for a user about to create an account with no email address, currently our only password recovery method, just an extra confirmation step that they really want to create an account they'll never be able to recover if they lose access. However, like Iridescent said, I strongly oppose forcing users to supply a working email. Ivanvector (Talk/Edits) 18:58, 1 October 2018 (UTC)
  • We can easily change the prompt at MediaWiki:Createacct-emailoptional, I'll have to check if we can add wikitext there - perhaps to a page about why it is so important? — xaosflux Talk 19:50, 1 October 2018 (UTC)
    Wikitext breaks there due to the special load on the right panel; but it can easily be changed from "optional" to "required for password recovery" or the like. — xaosflux Talk 19:54, 1 October 2018 (UTC)
  • Support the required for password recovery language offered by xaosflux. Best, Barkeep49 (talk) 22:41, 1 October 2018 (UTC)
  • Support/Oppose per Iri. I didn't start off with a password. Thanks, L3X1 ◊distænt write◊ 21:32, 2 October 2018 (UTC)
  • Support this is basically what I suggested a while ago in phab:T159837. Though I move the 'consequence' into an additional confirmation step, instead of into the main interface. —TheDJ (talkcontribs) 07:53, 3 October 2018 (UTC)
  • Support (though this is the idea lab!) language as indicated by Xaosflux. I would be against any mandatory requirement. Nosebagbear (talk) 18:37, 8 October 2018 (UTC)

Why isn't mobile number and / or email required for new User Creation?

A lot of time is wasted in sockpuppet investigations and still they seem to have infested Wiki.My suggestion is to require email and / or mobile validation to create new accounts on Wiki. Existing users should also provide them to continue using their IDs. Email authentication is free of cost and easiest to set up, while mobile number verification may require sending an OTP to the number which can have a minuscule cost involved of sending an SMS. Email verification would be sufficient since to create new email IDs, the companies send OTPs to the mobile and user cannot register multiple email IDs linked to a single mobile number. Even small websites have these type of validations then why can't Wiki? Since sockpuppetry is becoming a nuisance on Wiki. Hopefully something gets done in this regard, if this is not the place for suggestion kindly let me know where to write it. Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 13:21, 8 October 2018 (UTC)

For the reasons I've already explained to you in detail last time you asked this, and as also given in detail literally immediately above this post. When you don't like the reply you've been given in one place, the solution is rarely to ask exactly the same question somewhere else. ‑ Iridescent 15:37, 8 October 2018 (UTC)
This is the first time I have brought this issue up myself. That may be someone else you are talking about. Anyways, so wwhat was your opinion back then? Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 16:53, 8 October 2018 (UTC)
O RLY? You are aware that this is a wiki and we can see the three other occasions you've asked this, right? ‑ Iridescent 01:13, 9 October 2018 (UTC)
Seems like an SPA except it's an IP, also it was a diffrent person just above that proposed it but still. Remagoxer (talk) 11:23, 12 October 2018 (UTC)

2 grades of watchlist

I find that there are 2 types of article that I have in my watchlist. The first are those that I have edited and have some general interest in any changes/developments. It is not a big problem if I miss something or if there is no activity on the article for a long while. The second category is where I (or another editor) have flagged a problem and am awaiting a response. This could be a {{Citation needed}} tag, or a comment on a talk page. For some "low traffic" articles, it seems to me appropriate to leave these alerts in place for some time before acting on them if there is no response. (I have had another editor get upset when I have acted after flagging an issue 2 weeks previously - so a longer delay seems to avoid dispute.) Relying on memory and a filtered contributions page do not seem to be 100% reliable in picking up any article that I intend to watch in this way.

The solution would be to have an "enhanced watchlist" - just an extra flag you can put on an article where you do not want to miss any activity - and perhaps a facility to show only those enhanced watchlist articles/talk pages with no edits since switching to the enhanced status. (It is this last category that seem most difficult to track effectively.) I would be interested to see if anyone else felt there was value in this change - or if there is an existing solution of which I am not aware.
ThoughtIdRetired (talk) 07:44, 3 October 2018 (UTC)

Yeah, this is a good feature. You can approximate this with MusikAnimal's awesome script User:MusikAnimal/customWatchlists, by creating a "high-priority" custom watchlist. I don't think that last feature is supported, but I pinged Musik to check. Enterprisey (talk!) 07:55, 3 October 2018 (UTC)
That script badly needs rewriting! But it should mostly work :) You can view the "raw list" of pages, not just ones with recent changes, if that helps. By the way this proposal is basically Wikipedia:Perennial proposals#Multiple watchlists. I think we're still a long ways away before we have native support for it. But I can improve customWatchlists, it's been on my to-dos for some time MusikAnimal talk 17:02, 3 October 2018 (UTC)
Thanks. I think my requirement for spotting cases of no activity (after tagging or talk page comment) on certain watchlist articles is different from the archived discussions. It is an editing methodology that seems to work with apparent "fossils" that may or may not have a following with strong opinions. (Some of these fossils are full of the most amazing nonsense, sometimes referenced with sources whose content has little similarity to the article.)
Being more of an "article content" editor, rather than someone who is into the nuts and bolts of Wikipedia, I only have a passing understanding of the technical issues. Bearing in mind that I might have only about 10 articles where I am waiting to see if anyone reacts to a tag or a talk page comment, I might start cutting and pasting a handful of selected article names into a corner of my sandbox. (Or perhaps I could put a section on my user page: "waiting for answers on...") It is only one step better than using a post-it note, but at least it is simple.
ThoughtIdRetired (talk) 19:12, 3 October 2018 (UTC)
Because I didn't see a mention yet in this thread, I wondered if you knew about Special:RecentChangesLinked? This works using pages including custom watchlists, an example: Special:RecentChangesLinked/Wikipedia:WikiProject Skepticism/Skeptic watchlists which shows changes to pages linked in Wikipedia:WikiProject Skepticism/Skeptic watchlists. —PaleoNeonate – 20:54, 3 October 2018 (UTC)
That's a good idea, PaleoNeonate. I think it would work for a lot of people.
MusikAnimal, do you remember whether multiple watchlists has been in the m:Community Wishlist in the past? I think that the maps item last year proved that a little organization can go a long way towards getting what editors need, and I believe that nominations begin soon. WhatamIdoing (talk) 18:10, 4 October 2018 (UTC)
I use a cruder "top and bottom" method. I first look at the top of my watchlist. Most changes are on articles that are not urgent for me, and I don't check them until they approach the bottom of my five days watchlist (recently re-preferenced from six). This has the advantage of keeping me aware of boring, raging content disputes on an interesting topic, without being tempted to stick my nose too deeply into them. On some pages, such as VP, I look into each change when it arrives at the top of the page, at least if the section header and edit summary give a hint that it will interest me. Jim.henderson (talk) 09:58, 5 October 2018 (UTC)
A few years back, I talked with an editor who skipped the first week of her watchlist. This allowed her to skip nearly all contentious discussions and focus on adding content. It seemed like a good idea (only I can't see myself doing it). WhatamIdoing (talk) 03:17, 10 October 2018 (UTC)
We specialize based on our talents. I lack the discipline to cut my watchlist below 5,500 pages, but have the power to detach myself from reaction and take a longer view. So, having left the necessary pig-wrestling to those who have the stomach for it, I come along after the battle to kill the crippled sentences, plug the leaking modifiers, rearrange the disordered paragraphs and so forth. Jim.henderson (talk) 10:43, 13 October 2018 (UTC)

Idea: Watchlist page flagging

I think I've pitched this before, but with the recent changes to the watchlist I figured I'd bring it up again. I have close to 15,000 pages on my watchlist and I'd love to be able to flag certain pages in my watchlist with color-coded labels, to make it easier to get to articles that have been recently problematic. Example: If a sock operator is known for editing at Vijay (actor), I would flag the article with the sockmaster's name to make it easier to spot recent flare-ups. Another example: If a film article has seen a lot of users perniciously inflate or deflate box office figures, I might flag the article with a green label so I could get a quick reminder to check it out.

I deal with many Indian film articles, about films in the many languages of India (Hindi, Tamil, Malayalam, etc.) A lot of the titles are meaningless to me, so I might gloss over them in my watchlist. The flagging would be helpful. Thanks for listening! Cyphoidbomb (talk) 13:50, 8 October 2018 (UTC)

That sounds like another idea for the m:Community Wishlist. WhatamIdoing (talk) 03:14, 10 October 2018 (UTC)
@WhatamIdoing: Hmm, seems like that's closed... Cyphoidbomb (talk) 02:00, 12 October 2018 (UTC)
@Cyphoidbomb: The poll is run each year. The next one starts accepting new wishlist items pretty soon. --Izno (talk) 02:06, 12 October 2018 (UTC)

Change "Publish changes" button in Draft Space

Apologies if this has been suggested before - I looked in the archives and didn't see anything - but I think the "Publish changes" button is confusing to many newer editors who are working in draft space. I would like to suggest that in draft space the "Publish changes" button read "Save draft". I don't know how feasible in the mediawiki software this would be to do but think it would help make clearer that what the user's doing by pressing the button. Best, Barkeep49 (talk) 15:50, 8 October 2018 (UTC)

Yes, please. This seems to confuse many new editors that are working on drafts at AfC. Natureium (talk) 15:51, 8 October 2018 (UTC)
@Whatamidoing (WMF): Since I'm pretty sure you have the history/know the people for the last time this button was changed. --Izno (talk) 16:38, 8 October 2018 (UTC)
"Publish changes" was decided by the community, is being implemented by the WMF Editing team, and has the backing of the Legal team. It cannot be changed without the approval of the Legal team.
That being said, back then, it was determined that "some editors worried that this change would confuse new editors. There have been no indications so far that this is the case." That perception may have changed. – Finnusertop (talkcontribs) 16:47, 8 October 2018 (UTC)
I say this only based on my experience trying to help people on IRC who are confused about how to save their drafts. I figured this was not a "easy change" and am glad to know now that it's even more involved than I had realized. Best, Barkeep49 (talk) 22:47, 8 October 2018 (UTC)
As barkeep49 said, this confuses a number of people that come to #wikipedia-en-help and can't figure out how to save their draft to keep working on later, without "publishing" it. Natureium (talk) 22:49, 8 October 2018 (UTC)
I have also seen it repeatedly, coaching at edit-athons, though more often it's a Talk Page that confuses. I would prefer "send" but if that is thought to create an expectation of privacy, then "send public". Jim.henderson (talk) 22:59, 8 October 2018 (UTC)
IMO "Post" might be more appropriate (in English) for talk pages, but there's a fundamental problem: In MediaWiki, all pages get the same button, regardless of namespace.
Barkeep49, would you do me a favor, the next time you get this question? Would you please ask the person if they're looking for a way to privately save their drafts? My impression is that when people ask for a way to save their drafts, they're correctly recognizing that "Publish" is going to make the draft public, and that's not what they want to do. So "Where's the save button?" doesn't mean they can't figure out what the Publish button does; it means they know exactly what the Publish button does, and what that button actually does is not what the users want to do. They want to save the draft privately, until they think it's good enough to post on the internet – which, of course, can't be done. Whatamidoing (WMF) (talk) 20:56, 9 October 2018 (UTC)
I am happy to do that Whatamidoing (WMF). Best, Barkeep49 (talk) 21:44, 9 October 2018 (UTC)
It's been quiet on this front for the last week. I did have someone tonight with this question. They reported that they were looking to save privately but if the button had said "Save draft" they would not have been confused. So mixed result from a sample size of 1. Best, Barkeep49 (talk) 04:01, 16 October 2018 (UTC)
I think one consideration is that even Draft space is not entirely private; stuff posted there can still be found by anyone who gets there through other Wikipedia categories/project pages or through search engines which don't exclude Draft space. Jo-Jo Eumerus (talk, contributions) 09:06, 16 October 2018 (UTC)

Poor articles

Is there a place to list and draw attraction to poor articles, particularly articles which are of high-importance? -Inowen (nlfte) 04:32, 14 October 2018 (UTC)

On your personal "to-do" list perhaps? Failing that the article's talk page, or a related project's talk page. Martin of Sheffield (talk) 07:56, 14 October 2018 (UTC)
I think I found it: WP:AFI. But it seems to need improvements itself. -Inowen (nlfte) 18:51, 14 October 2018 (UTC)

Minor canned edit summaries

For convenience, I think that when a user selects a minor canned edit summary, the minor edit check box should be automatically checked if it hasn't been checked already. Care to differ or discuss with me? The Nth User 23:51, 15 October 2018 (UTC)

@The Nth User: But what if an IP is using it (unregistered users cannot mark edits as minor)? Also, I don't think this is such a good idea, since vandals could use auto-minor edits to further evade vandalism, (in fact, seeing "canned edit summary" tagged onto an edit only attracts my attention when I am recent changes patrolling) so this isn't a good idea even if unregistered users cannot mark edits as minor. SemiHypercube 00:03, 16 October 2018 (UTC)
@SemiHypercube: The first point is easy to fix; just code it so it only checks the checkbox if there is one. The second point may or may not be a problem depending on how most users search for vandalism. I use a personal filter setup at Special:Recent changes, and I doubt that the filters pay attention to the edit summary for the reason that you pointed out: Vandals might use edit summaries like "fixed typos" to mask disruptive edits. However, if most users pay attention to edit summaries when searching for vandalism, then your point is valid, and my change should not be enacted. Care to differ or discuss with me? The Nth User 00:13, 16 October 2018 (UTC)

Let a Bot delete user subpages

Since you cannot directly delete your own subpages, how about we let a bot – who is Administrator – delete user subpages that have been requested to be (speedy) deleted by their user? Colonestarrice (talk) 23:00, 21 October 2018 (UTC)

Of anything in CAT:CSD Category:Candidates_for_speedy_deletion_by_user is almost never backlogged. — xaosflux Talk 23:14, 21 October 2018 (UTC)
Similar rejected proposals: Wikipedia:Village pump (proposals)/Archive 77#Allow users to delete subpages with their Userspace, Wikipedia:Village pump (proposals)/Archive 126#Allow users to delete pages within their own userspace. PrimeHunter (talk) 23:28, 21 October 2018 (UTC)