Misplaced Pages

:Village pump (proposals): Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 04:41, 5 July 2013 view sourceDGG (talk | contribs)316,874 edits User Council← Previous edit Latest revision as of 15:46, 19 January 2025 view source Lowercase sigmabot III (talk | contribs)Bots, Template editors2,309,086 editsm Archiving 1 discussion(s) to Misplaced Pages:Village pump (proposals)/Archive 216) (bot 
Line 1: Line 1:
<noinclude>{{Village pump page header|Proposals|alpha=yes|start=80| {{redirect|WP:PROPOSE|proposing article deletion|Misplaced Pages:Proposed deletion|and|Misplaced Pages:Deletion requests}}<noinclude>{{short description|Discussion page for new proposals}}{{Village pump page header|Proposals|alpha=yes|
The '''proposals''' section of the ] is used to offer specific changes for discussion. ''Before submitting'':
New ideas and proposals are discussed here. ''Before submitting'':
* Check to see whether your proposal is already described at ''']'''. * Check to see whether your proposal is already described at ''']'''. You may also wish to search the ].
* Consider developing your proposal on ]. * This page is for '''concrete, actionable''' proposals. Consider developing earlier-stage proposals at ].
* Proposed '''software''' changes that have gained consensus should be filed at . * Proposed '''policy''' changes belong at ].
* Proposed '''policy''' changes belong at ]. * Proposed '''speedy deletion criteria''' belong at ].
* Proposed '''WikiProjects''' or '''task forces''' may be submitted at ]. * Proposed '''WikiProjects''' or '''task forces''' may be submitted at ].
* Proposed '''new wikis''' belong at ]. * Proposed '''new wikis''' belong at ].
* Proposed '''new articles''' belong at ]. * Proposed '''new articles''' belong at ].
* Discussions or proposals which warrant the '''attention or involvement of the Wikimedia Foundation''' belong at ].
<!-- Villagepumppages intro end -->|WP:VPR|WP:VP/PR|WP:VPPRO|WP:PROPS}}__NEWSECTIONLINK__<!--
* '''Software''' changes which have consensus should be filed at ].
-->{{User:MiszaBot/config
Discussions are automatically archived after remaining inactive for nine days.<!--
|archiveheader = {{Misplaced Pages:Village pump/Archive header}}
Villagepumppages intro end
|maxarchivesize = 300K
-->|WP:VPR|WP:VP/PR|WP:VPPRO|WP:PROPS}}__NEWSECTIONLINK__
|counter = 103
{{centralized discussion|compact=yes}}
|algo = old(7d)
__TOC__
|archive = Misplaced Pages:Village pump (proposals)/Archive %(counter)d
{{anchor|below_toc}}
}}
]
<!--
]
-->
<table width="100%" style="background: transparent;">
<tr><td valign="top" width="50%"> __TOC__
<td valign="top"> {{cent|width=auto}}
</table>
<span id="below_toc"/>
]
] ]
] ]
{{User:MiszaBot/config
]</noinclude>
| algo = old(9d)
| archive = Misplaced Pages:Village pump (proposals)/Archive %(counter)d
| counter = 216
| maxarchivesize = 300K
| archiveheader = {{Misplaced Pages:Village pump/Archive header}}
| minthreadstoarchive = 1
| minthreadsleft = 5
}}</noinclude>
{{clear}}


== Misplaced Pages is too big. Please make it smaller. == == Transclusion of peer reviews to article talk pages ==


Hello,
{{collapse top|Per suggestion half of all articles will be removed every April 1st. Or not. ] (]) 19:20, 24 June 2013 (UTC)}}
There is way too much to keep track of here. I propose reducing Misplaced Pages's size by at least 50%. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 06:06, 12 Jun 2013 (UTC)</font>
:Well, I suppose we could take out all the vowels. Would that help? ] (]) 06:13, 12 June 2013 (UTC)
::Nt rlly! ] (]) 07:14 12 Jn 2013 (TC)
::: No, because that was only a 30% reduction in size. ] (]) 07:17, 12 June 2013 (UTC)
::::<small>cmbn t wth thr sltns! ] (]) 07:34, 12 June 2013 (UTC)</small>
:::::<small>I’m lost. Sultans? Slutness? Solitons?—]&nbsp;] 10:31, 12 June 2013 (UTC)</small>
::::::<small>Sultanas, clearly. We should bake it and turn it into cookiepedia for easier digestion ] (]) 10:37, 12 June 2013 (UTC) </small>
:Actually, Equazcion has my total admiration for being able to keep track of something 50% the size of Misplaced Pages. ] (]) 07:38, 12 June 2013 (UTC)
::So, just delete all BLP's, and make all articles need at least 40 references? ] (]) 12:15, 12 June 2013 (UTC)
:::50% was just a conservative estimate. I probably couldn't break, say, 45%. But really it's just getting out of hand here. We have to have some limits. Mdann seems to have the right idea. Or maybe if we narrowed the focus, like delete all articles that don't have to do with cat breeds. '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 08:03, 13 Jun 2013 (UTC)</font>
::Let's just remove the letter "e". Big space savings... ] <small><sup>]</sup></small> 00:07, 14 June 2013 (UTC)
::::Or you could just join ] , which only has a few thousand articles and a dozen or so active contributors. It was founded by ], co-founder of Misplaced Pages. ] (]) 13:58, 13 June 2013 (UTC)
:I recommend using a smaller font on your web browser. ]] 14:02, 13 June 2013 (UTC)
::I'm not sure if its just articles or total size you are referring too but here are some suggestions for elimination.
::#Get rid of WikiProjects. There are thousands of them, most with multiple pages, most are inactive or have low activity. Most do nothing but cause more drama and problems than they fix. We are better off without them. The only one I might consider keeping would be Biography because its used to track BLP's, catgorize the names and a few other things.
::#Change the categorization rules so that we don't create a new category unless there are at least 10 articles. The current policy is 3.
::#Get rid of the Book namespace. It doesn't provide anything useful and never really took off.
::#Get rid of the Topics. Another area where we don't get any return for the effort invested.
::#Modify the criteria for sports figures. How many international soccer/football players do we really need to identify.
::#Modify the criteria for films and movies
::#Modify the criteria for actors and acresses.
::This is just a start. ] (]) 14:17, 13 June 2013 (UTC)


First time posting here.
I hope Equazcion is joking, but anyway, no, Misplaced Pages is not too big. Misplaced Pages is ''way too small''. Despite the number of articles may ''look'' impressive, we're far, far from having covered all notable subjects. Knowledge is a big thing. We have no limits, ], we must strive to be ''bigger'', not smaller, in article number and size. Nobody forces you to keep all of WP on your hard drive, so size limits are not a concern. Deletionism is already rampant enough, please let's avoid slashing even more of the knowledge thousands of editors managed to accumulate. --]] 14:34, 13 June 2013 (UTC)
:The bigger it gets, the less accurate the information becomes, at least in my experience. Maybe a from-scratch approach to what might be considered notable? '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 16:04, 13 Jun 2013 (UTC)</font>
::If you ask me a from-scratch approach to what might considered notable, I'd replace notability with mere verifiability (except perhaps for BLPs). About accuracy, well, please provide data on this creeping inaccuracy ''and'' prove it is causated by the increase in the number of articles. Hint: even in case you find an objective measure of inaccuracy rising in time, remember that ]. And even if it was the case, the solution would be to attract more editors (something WP is indeed remarkably inept at), not stomping on valuable content. --]] 18:36, 13 June 2013 (UTC)
::: Hello Cyclopias, when you say "we must strive to be bigger not smaller in article number and size", are you stating a personal opinion or a policy on this encyclopedia? I would be interested to hear. Thank you! ] (]) 19:08, 20 June 2013 (UTC)
Dear Mr. President, There are too many states nowadays. Please eliminate three. I am not a crackpot. --] (]) 16:08, 13 June 2013 (UTC)
:THANK you. Exactly. Many = bad, in most cases. I look at the rising total article count, and I'm like, d'oh! '''<font face="Century Gothic" style="text-shadow:1px 1px 3px #999;">] <small>]</small>''' 16:17, 13 Jun 2013 (UTC)</font>
::It's a pleasant fantasy, isn't it? Let's dump all the articles on people, organizations (businesses, schools, government agencies, etc.), and products unless four or more proper books (not just newspaper articles) have been written about them ''plus'' the articles get at least 100 page views a day. If we maybe add merging settlements containing nothing more than routine bot-added data into lists, then we might have a "manageable" number of articles.


I would like to propose that ] be automatically transcluded to talk pages in the same way as GAN reviews. This would make them more visible to more editors and better preserve their contents in the article/talk history. They often take a considerable amount of time and effort to complete, and the little note near the top of the talk page is very easy to overlook.
::But I don't think we would have actually improved any content in this process. It's fun to think about it as I struggle with my watchlist, but it's not something I'd support doing. ] (]) 18:48, 13 June 2013 (UTC)


This also might (but only might!) raise awareness of the project and lead to more editors making use of this volunteer resource.
The amount of unreliable content almost certainly grows as Misplaced Pages grows, but the amount of reliable content also grows, and, as our systems get more sophisticated, the reliable content should be growing at a faster rate than the unreliable content. This proposal seems to be based on the premise that a single editor should be able to monitor everything, which goes completely against the croudsourcing wiki model, which relies on articles being monitored, but not all by the same person. ] (]) 18:58, 13 June 2013 (UTC)


I posted this suggestion on the project talk page yesterday, but I have since realized it has less than 30 followers and gets an average of 0 views per day.
Too large? Not even close. Most of the storage for Misplaced Pages is probably taken up by the pictures. The actual text ]: I can easily fit it on a corner of my laptop hard drive. ] (]) 03:12, 15 June 2013 (UTC)


Thanks for your consideration, ] (]) 23:07, 2 January 2025 (UTC)
*I personally think that Misplaced Pages will inevitably fork into more than one website at some point, but I don't think the community is ready for that just yet. Something like one site for topics involving history, the sciences, and so forth and another for all the biographies of marginally notable people, Pokemon episodes, and other pop-culture topics. The rules we apply for an article on a topic like, say ] probably don't need to be applied to an article on a topic like ]. ] (]) 21:08, 16 June 2013 (UTC)
:I don't see any downsides here. ] (]/]) 01:55, 4 January 2025 (UTC)
:'''Support'''; I agree with Voorts. Noting for transparency that ] of this discussion by {{noping|Patrick Welsh}}. <span class="nowrap">—]</span> <small>(])</small> 21:04, 6 January 2025 (UTC)
*This is a great idea, it's weird that it isn't done already. ] </span>]] 21:13, 6 January 2025 (UTC)


: So far this proposal has only support, both here and at the ]. Absent objections, is there a place we can request assistance with implementation? I have no idea how to do this. Thanks! --] (]) 17:23, 13 January 2025 (UTC)
*It is hilarious that keeping all cat breed articles is mentioned. I just signed on for WikiProject Fishes. How many articles do we have on fishes? '''17,108.''' I mean, how can we possibly have this quantity of unsupervised fishes swimming through Misplaced Pages? We definitely need more cats. ツ <b>] ]</b> 02:01, 19 June 2013 (UTC)
::It might be useful to have a bot transclude the reviews automatically like ] does for GAN reviews. ] already does some maintenance tasks for PR so, ], would this task be a doable addition to its responsibilities? Apart from that, I don't think any other changes need to be made except to selectively hide or display elements on the review pages with {{tag|noinclude}} or {{tag|includeonly}} tags. <span class="nowrap">—]</span> <small>(])</small> 17:28, 13 January 2025 (UTC)
: My cat regularly tries to eat the fish out of my fish tank. I don't have 17,108 fish, but maybe I'll make an article on my specific cat so that maybe some of the fishy articles will go away. In all seriousness, though, most of the space seems to be taken up by Projects (that are inactive) and images. Text is rather small and the goal of Misplaced Pages is to collect knowledge. Misplaced Pages is overwhelming with the amount of namespace articles, but most editors focus on one thing they're interested in and ignore most of the rest. The only exception is someone who fights vandalism (darn that ClueBot). :P ] <sub>]</sub><sup>]</sup> 14:21, 19 June 2013 (UTC)
::: Since ] already does the exact same thing for GAN reviews, it might be easier for ] to do the same for peer reviews than for me to write AnomieBOT code to do the same thing. If he doesn't want to, then I'll take a look. ]] 22:41, 13 January 2025 (UTC)
When I first saw this I was wondering if I'd missed something, but then what Humioko said made me realise why this was serious. Okay the idea of getting rid of many of the WikiProjects isn't a bad idea. We should have a sweep of deleting pages where the user has been gone for say, 5 years? Just a base idea since I know that at least one user returned after about 3 years or something. (I think ] adopted him so he could find out what was new about the wiki). Deletion of user pages and user talk pages of long gone users would definitely do its bit in cutting things down. ] ] ] 08:21, 28 June 2013 (UTC)
::::I don't have any objection in principle, but I don't think it's anything I could get to soon -- I think it would be months at least. I have a list of things I'd like to do with ChristieBot that I'm already not getting to. ] (] - ] - ]) 22:54, 13 January 2025 (UTC)
{{collapse bottom}}
::::: I took a look and posted some questions at ]. ]] 16:14, 18 January 2025 (UTC)
*'''Support''', I've submitted a couple of articles for peer review and wondered when I first did it why it wasn't done on a sub-page of article's talks the same way GAN is. '']''<sup>]</sup> 02:24, 16 January 2025 (UTC)
'''Support'''''. This would be very, very helpful for drafts, so discussions can be made in the Talk pages to explain a problem with a draft in more detail rather than only showing the generic reason boxes. ] (]) 12:56, 18 January 2025 (UTC)


== Sections ==
== Let's figure out a little bit more about how new editors are signing up ==


I noticed that some sections are written like: == xxxxx ==
Every day we get around 3-4,000 people signing up for Misplaced Pages. The majority of these people (~70%) do absolutely nothing with their accounts. With work like ], ], and others we're trying to change that, but we still know very little about what people who are signing up every day want to do. ] recently just finished the redesign of the signup and login pages, and that includes a tool that has been around in some form before: the ability to ] name to a link, so we know how many people sign up via it. (It only works on the account creation page, and it's not publicly logged anywhere.)
and some are written like ==xxxxx==. Some have gaps and some do not. Won't it be better if it was standardized? I prefer the one without gaps because it should save space.
] (]) 06:47, 10 January 2025 (UTC)


:Such a proposal is infeasible, as we have over 6 million articles in a mix of both styles. Although a script would probably handle 90% of them there'd be heaps of edge cases among the remaining ones to consider. Also that's assuming that editors would actually agree on a single style; given ] I think that's unlikely. &nbsp;] <b style="font-size:0.6em;filter:grayscale(1)">] ]</b> 09:03, 10 January 2025 (UTC)
Anyway, of the many experiments my team might run, some are aimed specifically at the kind of editor who is trying to edit a page but doesn't yet have an account. We'd like to get a handle on this by adding campaigns to the anon edit notice and the view source notice for semi-protected pages. I've dropped notes at both those pages (] and ]) but they're not very high-visibility, so I'm cross-posting. Please comment there if you're interested. If we can learn how many new signups happen because pages they are trying to edit are semi-protected, or because they decide to signup after clicking Edit on any other page, that helps us know how much effort we should be spending on this area, as opposed to say, new article creators.
::Yes, or shall we have an inconclusive discussion that lasts for months and involves hundreds of editors? ] (]) 09:14, 10 January 2025 (UTC)
:::What else is Misplaced Pages for?--] (] &#124; ]) 14:25, 10 January 2025 (UTC)
::That means only 700,000 articles would be left. New editors can fix the others as a beginner's task.
::] (]) 12:20, 10 January 2025 (UTC)
:::So Misplaced Pages adopts a novitiate/apprenticeship system? I like the idea of that, so long as it's not mandated at all but voluntary. I don't think this particular task would be of any help or use, though. It really doesn't matter.--] (] &#124; ]) 14:25, 10 January 2025 (UTC)
:Istruggletothinkofabiggerwasteoftime,thoughofcourseweshouldall].&ndash;&#8239;]&nbsp;<small>(])</small> 09:15, 10 January 2025 (UTC)
::Joe, where should I send the the 0.00000004 cents that it would cost for you to use spaces? ] (]) 09:21, 10 January 2025 (UTC)
:This would fall under ], because the spaces (or lack thereof) has no change in visual output. It's not worth our time to fix something that has no real effect on pages, flooding watchlists and annoying people in the process. Also, ironically, the heading for this thread is written ''with'' spaces. —] <span title="Canadian!" style="color:red">🍁</span> (] · ]) 12:52, 10 January 2025 (UTC)
::That is likely because as far as I've seen most of the software and scripts add spaces. ] (]) 13:59, 10 January 2025 (UTC)
:::It's potentially worth making a call on what's considered ultimate best practice, just so that the software and scripts can be aligned. But agreed that this is far too cosmetic to be worth changing, even within something like the ] set. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 23:03, 10 January 2025 (UTC)


== Good Article visibility ==
Let me know if you have any questions. Campaigns are easy to set up and are potentially something that could be of use to WikiProjects or groups like the Teahouse, so if you're curious please speak up. <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 01:27, 19 June 2013 (UTC)
:Could/should we add campaign links to the various anon-specific ] ? Possibly we're already tracking this? –] (]) 02:05, 19 June 2013 (UTC)
::Not a bad idea. We're not already tracking that, to my knowledge. <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 02:09, 19 June 2013 (UTC)
:::And ] which is linked from quite a few places (including the templates you linked to). —] (] • ]) 13:02, 19 June 2013 (UTC)
::::Where I just a bit of cleanup. —] (] • ]) 13:30, 19 June 2013 (UTC)
:::::Has anyone thought of the possibility that the accounts being signed up and then not used are spam or bot accounts, similar to the accounts that are signed up on forums? I don't know the inner workings of MediaWiki all too well, but bots that invade forums have been able to bypass both their captcha and re-captcha, so I don't doubt the same is possible here. Adversly, I believe it has been discovered that spam "people"/companies are hiring humans to bypass the captcha and then turning the accounts over to a machine to use for malicious purposes. I don't mean to discourage the efforts to introduce potential editors to the encyclopedia, just thinking of all of the possibilities that we have so many accounts being signed up but hardly any used. ] <sub>]</sub><sup>]</sup> 15:41, 19 June 2013 (UTC)
::::::Historically, there have been a lot of spam/vandal throwaway accounts registered. However, before the edit filter it was quite easy to see what proportion of those actually became spam/vandal accounts, since they inevitably went on to do so - but this still left a lot of registered-but-never-edited accounts. ] (]) 20:32, 21 June 2013 (UTC)
:::Not sure how to find out the statistics, but I would surmise that many of these 70% of new users never record and promptly forget their password after changing from the initial random one. A gentle reminder ("Please record or memorize your new password") shortly after password changes would seem like an easy way to avoid much of this. Also, was the 70% figure based on all the connected wikis, or just the English-language Misplaced Pages? ] <small>]</small> 18:01, 19 June 2013 (UTC)
::::::Also consider accounts of readers who never edited, but changed their user preferences. Are they being counted in the 70%? ] (]) 10:57, 20 June 2013 (UTC)
:::::::Yes, I mean all new accounts. <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 21:11, 20 June 2013 (UTC)
:::It's definitely a mix of reasons. Some of the people are actually trying to edit, but wikitext scares them away. Others are trying to upload a file, and find out they need to be autoconfirmed. But yeah, I think some of them are forgetting their password and failed to register an email address. The new signup form still marks it as optional, but we know that more people register with an email address in the new form though, so it helps combat the "I lost my password and have no way to recover it" problem. <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 21:05, 19 June 2013 (UTC)
*It could also be because people may (mistakenly) believe they need an account to read Misplaced Pages, or otherwise may be missing some content by not registering. Many people may just create accounts to every website that allows them to do so, including Misplaced Pages, and they may never have any immediate desire to edit Misplaced Pages. They likely either mistakenly believe they need to to read it, or they simply register for everything, unthinkingly, and semi-automatically. --]''''']''''' 21:26, 20 June 2013 (UTC)
*'''Support''' I understand this proposal as a request to conduct ] on advertisements which would make offers to help new users become engaged to follow through with their motivation for registering an account. I hope that the tests are documented a bit and that you continue to maintain good communication about the research, but this kind of testing and research needs to be done and I support this completely. ]] 05:51, 21 June 2013 (UTC)
* If a username is unused after (say, a year), cancel it and free it for re-use? (How many total usernames are listed for Misplaced Pages?) ] (]) 07:32, 21 June 2013 (UTC)
* {{replyto|Anthony Appleyard}} ] says there are '''19,181,153''' registered accounts, of which only 124,793 have edited in the past 30 days. I make that that only <u>'''0.65%'''</u> of all user accounts are active. I agree something needs to be done about this - a large number of usernames are ties up, that could otherwise be of use. ] (]) 10:09, 21 June 2013 (UTC)
* There is also a number of accounts that will 'automatically' get registered here due to existing on another wiki, I imagine this number is rather high. I am all for adding campaign links to all of the welcome templates! Would be great to be able to see! ''']''' <sup>]</sup> 10:48, 21 June 2013 (UTC)


I think it would be a good idea to workshop a better way to show off our Good, A-class and Featured articles (or even B-class too), and especially in the mobile version, where there is nothing. At present, GA icons appear on the web browser, but this is it. I think we could and should be doing more. Misplaced Pages is an expansive project where page quality varies considerably, but most casual readers who do not venture onto talk pages will likely not even be aware of the granular class-based grading system. The only visible and meaningful distinction for many readers, especially mobile users, will be those articles with maintenance and cleanup tags, and those without. So we prominently and visibly flag our worst content, but do little to distinguish between our best content and more middling content. This seems like a missed opportunity, and poor publicity for the project. Many readers come to the project and can go away with bad impressions about Misplaced Pages if they encounter bad or biased content, or if they read something bad about the project, but we are doing less than we could to flag the good. If a reader frequents 9 C-class articles and one Good Article, they may simply go away without even noticing the better content, and conclude that Misplaced Pages is low quality and rudimentary. By better highlighting our articles that have reached a certain standard, we would actually better raise awareness about A) the work that still needs to be done, and B) the end results of a collaborative editing process. It could even potentially encourage readers who become aware of this distinction to become editors themselves and work on pages that do not carry this distinction when they see them. In this age of AI-augmented misinformation and short-attention spans, better flagging our best content could yield benefits, with little downside. It could also reinject life and vitality into the Good Article process by giving the status more tangible front-end visibility and impact, rather than largely back-end functionality. Maybe this has been suggested before. Maybe I'm barking up the wrong tree. But thoughts? ] (]) 15:09, 11 January 2025 (UTC)
* '''Update:''' TheDJ has gone ahead and added campaigns to the two MediaWiki messages I mentioned before. {{mention|TheDJ}} {{mention|Quiddity}} et al. We haven't yet added any to the anonymous welcome templates. I'm happy to do that whenever, but I have a logistical question... do we want individual campaigns for each template, or one campaign for them all? I would suggest we start with the latter, and get a sense of overall, how many new registered editors signup because of an anonymous welcome template. Once we have that overall baseline, we can talk about whether it's necessary to know which individual templates are most popular. Thoughts? <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 19:02, 21 June 2013 (UTC)
**That sounds good to me. Relatedly, I made some comments about welcome-templates over at ]. We might want to consider updating some of the templates, whilst we're adding links to them? (Though I do like your ], too ;) –] (]) 19:16, 21 June 2013 (UTC)
*** Okay {{Done}} <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 21:31, 22 June 2013 (UTC)


:With the big caveat that I'm very new to the GA system in general and also do not know how much technical labor this would require, this seems like a straightforwardly helpful suggestion. The green + sign on mobile (and/or some additional element) would be a genuinely positive addition to the experience for users - I think a textual element might be better so the average reader understands what the + sign means, but as it stands you're absolutely right, quality is basically impossible to ascertain on mobile for non-experts, even for articles with GA status that would have a status icon on desktop. ] (]) 16:43, 11 January 2025 (UTC)
* I'm not sure the specifics of what this proposal is, but I'm interested. As one of the users involved in testing it, i also make an obligatory canvass for ], which is an interface designed at providing easier looking into and interacting with promising newcomers and dealing with new-account vandals. ] (]) 19:08, 21 June 2013 (UTC)
:While GA articles have been approved by at least one reviewer, there is no system of quality control for B class articles, and no system to prevent an editor from rating an article they favor as B class in order to promote or advertise it. A class articles are rare, as Military History is the only project I know of that uses that rating. ] 17:16, 11 January 2025 (UTC)
*We could try confirming an e-mail address, like a lot of on-line sites do. That would do two things, cut down on the number of usernames, and give them a second chance to retrieve a lost password. Right now it is really a bit too easy for someone to register a hundred new usernames. Whatever we do, though, the real goal is to encourage more people to click edit. As to usernames with no edits, bear in mind that they can be usurped, but that is not an easy process. I would recommend against deleting accounts with no edits in a year, but none in five years might be okay. I see a lot of editors who seem to think about editing, and get as far as creating a username, and their first few edits are years apart. And if to keep an account all you had to do was make one edit, that is pretty easily gamed. ] (]) 19:54, 24 June 2013 (UTC)
:I totally agree we should be doing more. There are userscript that change links to different colours based on quality (the one I have set up shows gold links as featured, green as GA, etc).
** We already do ask that people confirm their email address. <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 21:44, 24 June 2013 (UTC)
:If you aren't logged in and on mobile, you'd have no idea an article has had a review. '''] <sup>(] • ])</sup>''' 20:15, 11 January 2025 (UTC)
***But as far as I remember it is not ''necessary'' to confirm the email address to be able to edit but only recommended? As for cleaning up old accounts I'd propose to remove those that ''never'' did any edits ''and'' were not logged into for over a year. This way probably no harm is done. --] (]) 22:28, 24 June 2013 (UTC)
:A discussion was held on this about two years ago and there was consensus to do ''something''. See ] and ]. ] (]) 04:20, 12 January 2025 (UTC)
****Right, confirming your email address is only required to get emails, not anything else. Regarding clearing out old accounts: we should discuss it, but right now we actually don't have an ability to "delete" or reset accounts as far as I know. <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 03:59, 25 June 2013 (UTC)
::@]: Is that feedback discussion alive, dead, or just lingering in half-life? It's not obviously archived, but has the whole page been mothballed? So basically, there's community consensus to do ''something'', but the implementation is now the sticking point. ] (]) 04:57, 12 January 2025 (UTC)
*****Hehe! Other than rename them to some random name "lskjafjahoiuhfjkn" ''']''' <sup>]</sup> 11:09, 25 June 2013 (UTC)
:::Basically, most of the progress made is listed on that feedback page and the project has moved on from it. There were a few options, like the visibility one, where it was agreed upon and then didn't really go anywhere. So there are some ideas there, but we'd basically need to start fresh in terms of implementation. ] (]) 05:16, 12 January 2025 (UTC)
* If anyone cares, it took me 5 attempts before I was able to register a few days ago. It seem that everything was taken except for random strings, arbitrary numbers, or very long phrases. 20 million is far more than words in the dictionary, probably including all common names. This is exacerbated by the fact that the software considers a pretty wide range of names similar, so the number of actually prohibited user names is probably around 100 million to a billion. ] (]) 13:50, 27 June 2013 (UTC)
*{{tracked|T75299}} You're barking up exactly the right tree, {{u|Iskandar323}}. Regarding showing the icons on mobile, that's a technical issue, which is tracked at ]. I highlighted it to {{u|MMiller (WMF)}} when I last saw him at WCNA, but there's ultimately only so much we can push it.{{parabr}}Regarding desktop, we also know the solution there: Move the GA/FA topicons directly next to the article name, as ]. The barrier there is more achieving consensus — my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (]) that most readers notice/know what the GA/FA symbols mean. The best counterargument to that would be some basic user research, and while ideally that would come from the WMF, anyone could try it themselves by showing a bunch of non-Wikipedian friends GAs/FAs and asking if they notice the symbols and know what they mean. Once we have that, the next step would be running another RfC that'd hopefully have a better chance of passing. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 06:50, 12 January 2025 (UTC)
**One problem with recycled user-names is that a new user can be confused with the previous user. Having said that, it might make sense to derive a formula whereby a username is deleted after {{nowrap|1 + a + b}} years where a = time that the account was active and b = a function of the number of edits made by the person. We do of course have to look at the problems caused by sockpuppets - their names should never be recycled as they are tainted. ] (]) 14:35, 27 June 2013 (UTC)
*: It's great that I've got the right tree, since I think that's a village pump first for me. It seems that the proposer of that original 2021 discussion already did some basic research. Intuitively, it also seems just obvious that an icon tucked away in the corner, often alongside the padlocks indicating permission restrictions, is not a high visibility location. Another good piece of final feedback in the GA project discussion by TBUA is that the tooltip could also been improved, and say something more substantial and explanatory than simply "this is a good article". On the subject of the mobile version and the level of priority we should be assigning to it, we already know that per ], 65% of users access the platform via mobile, which assuming a roughly even spread of editors and non-editors, implies that 2/3 of contemporary casual visitors to the site likely have no idea about the page rating system. ] (]) 07:31, 12 January 2025 (UTC)
***On the other hand, since a majority of them "do absolutely nothing with their accounts", we could reclaim a large number of names simply by releasing the zero-edit/zero-action accounts after a year or two (or five, if you want to be conservative). An account that has never been used is not going to be an account that was used for socking. ] (]) 15:21, 27 June 2013 (UTC)
*:{{tq|my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean}} This is not my reading of the discussion. To me it looks as though a major concern among opposers is that making GA/FA status more prominent for readers is likely to mislead them, either by making them think that GAs/FAs are uniformly high-quality even for those which were assessed many years ago when our standards were lower and have neither been maintained or reassessed, or by making them more doubtful about the quality of articles which have never gone through the GA/FA process but are nonetheless high quality. By my count at least ten of the 15 oppose !voters cite this reason either explicitly or "per X" where X is someone else who had made this point. ] (]) 16:18, 12 January 2025 (UTC)
***We should ''not'' delete Accounts with edits (even if only few were made). I think by deleting accounts ''without'' edits we would already free a large enough amount of usernames, without the need for any controversial formulas or the problems of "recycled user-names" Martinvl mentioned. --] (]) 15:40, 27 June 2013 (UTC)
*::I've also encountered a fair few instances of older, lower standard GA articles. But I also think greater visibility (effectively also transparency) could also benefit in that area as well. If GA status is more prominent, it provides greater cause to review and reassess older GAs for possible quality issues. Also, most of the worst GAs I have seen have come from around 2007, so it seems like one sensible solution would be for GA status to come with a sunset clause whereby a GA review is automatically required after a decade. Maybe I'm getting a little sidetracked there, but this sort of concern is also exactly what I mean by greater visibility potentially reinjecting life and vitality into the process. ] (]) 17:15, 12 January 2025 (UTC)
*** I agree with the "{{nowrap|1 + a + b}}" formula, but I disagree with the "...sockpuppets - their names should never be recycled as they are tainted." ] (]) 16:04, 27 June 2013 (UTC)
*::I think you're right about that being the most major source of opposition, but most major is different than determining — I don't think those !voters will be open to persuasion unless the quality of GAs/FAs improves (which, to be fair, it definitely has somewhat since 2021). But the "they already know" !voters might be more persuadable swing !voters, and it would have passed with their support. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 19:02, 12 January 2025 (UTC)
*::I think that's a fair reading of the discussion. But, I suppose the best way to be more transparent is to tell a user that it has been rated GA after a peer review, but that doesn't mean that the article is perfect... Which is what GA (and FAs) also say. '''] <sup>(] • ])</sup>''' 19:54, 12 January 2025 (UTC)
* My radical proposal would be to get rid of the whole ] system (which always came across to me as a watered-down version of ]). ] (]) 16:31, 12 January 2025 (UTC)
*:Why? ] (]) 16:38, 12 January 2025 (UTC)
*:It ''is'' a watered-down process from an FA, but it is also the first rung on the ladder for some form of peer-review and a basic indicator of quality. Not every subject has the quality sources, let alone a volunteer dedicated enough, to take it straight from B-class to Featured Article. ] (]) 17:17, 12 January 2025 (UTC)
*:That's literally the point of it. '''] <sup>(] • ])</sup>''' 19:52, 12 January 2025 (UTC)


== RSS feed for Portal:Current events ==
== Add ability to delete usernames / inactive accounts ==


An admin suggested that I make this a proposal here so here it is:
Could anyone on the WMF Team actually implement a username deletion system into the MediaWiki software? This is my take on the second part of this conversation (the amount of usernames taken), as for the first part (welcoming new users) as a guy who watches ] yes there are an overabundance of usernames being made per minute and only a few of them are blue in contributions after a few minutes when they drop off the list. I don't really have anything else to add to that part of the conversation :|


Unlike other Main page sections such as On this day () or Featured article (), daily entries from ] do not yet have an RSS feed. This has been requested several times on the Portal's talk page over the years, but never gained traction: ], ], ], ].
So yeah, I think a username deletion tool is the way to go. ] ] ] 13:42, 25 June 2013 (UTC)
:How about ]? &mdash;&thinsp;] 16:52, 25 June 2013 (UTC)
::So let me get this straight, since 2008 we have been able to delete all usernames by just merging them to {{User|Unused}}? ] (]) 18:14, 25 June 2013 (UTC)
:::The extension is not installed here. And if it was, normal users would hardly have the right to use it. And one should probably not merge to what seems to be a real user. So to answer your question: no. &mdash;&thinsp;] 19:00, 25 June 2013 (UTC)
::::Right. Well I would support activating the feature, with appropriate restrictions on how it was used. I chose that name, though any similar one could be used, and that name could be renamed to free it up. The assumption was that only usernames with no edits would be deleted, and thus would never add to the three edits made in 2006 by "Unused". All three of those edits were immediately reverted. ] (]) 19:44, 25 June 2013 (UTC)
:::::Remember that bureaucrats are soon to be losing the right to rename users (it's all going to be done on Meta, apparently by stewards), since WMF want to expand our unified login thing. If we were to install this extension, I expect that it would be usable only by stewards as well. ] (]) 21:11, 25 June 2013 (UTC)
::::::Well, since soon only SUL will be available I think we need a solution that works globally anyway. At the same time I think the changes around SUL are a perfect occasion to also think about some cleanup strategies. When everything is unified there will be even more unusable (and probably unused) usernames needlessly blocked for new editors. --] (]) 21:32, 25 June 2013 (UTC)
:::::::] do renaming, and I would expect they would be deleting accounts as well, although to delete a million accounts will require a bot. For non SUL accounts there is the sticky issue of requiring a local bureaucrat to do the renaming/deleting, which though, might just be overlooked. I would suggest pursuing this topic at ] or ]. ] (]) 00:54, 26 June 2013 (UTC)
::::::::There will be no non SUL accounts after ]. After that, ] (and possibly their delegates) will handle global renaming requests. There will be no more local renaming by bureaucrats on public WMF wikis. ] (] • ]) 02:33, 3 July 2013 (UTC)


Adding a feed via ] extension should be relatively straightforward (for an admin with access to extension settings):
== Generic images ==


# Create the feed page under ] ("currentevents" would be the feed's name). Requires admin access.
We currently have tons of generic images, such as ], ], and ]. They're all the same image (purely a little text, "Please don't upload files with this title. Use a more precise name."), and they're all protected to prevent people from uploading other images on top of them, which is good. However, having lots of them clogs up the list of identical images. What if we chose one as the "official" name and redirected all of the others to it? This is basically what they do at Commons; ] is the "official" name, and as you can see at http://commons.wikimedia.org/search/?title=Special:WhatLinksHere/File:Name.jpg&hidelinks=1, most or all of the other generic image names are redirected to it. Of course I'm not suggesting that we unprotect anything or change the way we decide what to regard as generic; this is simply a housekeeping proposal. ] (]) 03:33, 19 June 2013 (UTC)
# Add the following as the page's source: <code><nowiki>Portal:Current events/{{#time:Y F j|-1 day}}</nowiki></code> (This should set ] to today's feed entry.)
:Seems reasonable, though I'm unaware of any other reason not to do it. --] (]) 03:55, 19 June 2013 (UTC)
# Configure the new feed in Misplaced Pages's ] (adapting from extsting settings from other existing feeds like On this day). I'm not sure exactly what access is required here, or whether this can only be done by a WMF staff member.
:Sure. I don't see a problem. ] <sub>]</sub><sup>]</sup> 21:29, 19 June 2013 (UTC)
:: Unlike Commons, however, we should protect those files that have redirects. It seems that commons does not do this for every file. :P Case in point: http://commons.wikimedia.org/search/?title=File:Photo003.jpg&action=edit ] <sub>]</sub><sup>]</sup> 21:32, 19 June 2013 (UTC)
:::They have no need to do it — the point of the protection is simply to prevent uploads, and at Commons I don't believe that it's possible to upload on top of redirects. It's definitely not possible with that image: I tried to upload a one-pixel image (complete with a speedy-deletion tag) at File:Photo003.jpg and got a big warning message from ]. No real need to protect what's already been uploaded, since nothing can be uploaded on top of it. ] (]) 04:53, 20 June 2013 (UTC)
*'''Support''' There are no added benefits and multiple drawbacks to the current practices as compared to your proposal. Nyttend, what you propose is exactly how things should be. ]] 05:46, 21 June 2013 (UTC)
*'''Support''' See Blue Rasberry above. ]<sup>]</sup> 03:33, 22 June 2013 (UTC)
'''Support''' It reduces how much unneccessary text Misplaced Pages holds. It's only a speck of it granted but it ''is'' a part of it and even a part of it can make a difference. ] ] ] 13:19, 25 June 2013 (UTC)
: '''Comment''' If this goes through and consensus is reached (I don't see a reason why it wouldn't), we should construct a list of what needs to be redirected. I'd be glad to help with adding redirects to those files in accordance with your proposal. ] <sub>]</sub><sup>]</sup>
::You can't do the actual redirect adding — MediaWiki's page-protection setup makes it impossible to prevent uploads without preventing editing, so these files are unredirectable except by admins. List-constructing help would be appreciated, of course. ] (]) 21:09, 26 June 2013 (UTC)
:::Aw, sad day. I'd be happy to help with lists, though :). ] <sub>]</sub><sup>]</sup> 21:26, 28 June 2013 (UTC)


I may be biased, but I&nbsp;don't see any good reason ''not'' to provide Current events as an RSS feed: it simply gives users another way to access this fantastic content using their favorite feed reader. Thoughts? ] (]) 08:09, 12 January 2025 (UTC)
== Proposal to add a template to medical article talk page ==


:Makes a lot of sense to me. Feels like it should be doable but ] gives me pause. I would drop a link here at ] to get some technical eyes on this that can make sense of exactly how to implement. ] (]) 01:56, 14 January 2025 (UTC)
] has discussed and reached consensus on a plan to add a template, {{t|Reliable sources for medical articles}} near the top of the talk pages of many medicine related articles. Discussion ].
::Thank you for the ref to ]! I agree that it might make more sense to move this over to ] by now, since there doesn't seem to be anyone opposing this in principle. I just reached out on the ticket thread to see if anyone involved in this at the time still remembers what happened. If there doesn't seem to be any technical blockers, I'll move this proposal to WPT to hopefully find someone who can implement it. ] (]) 04:03, 14 January 2025 (UTC)


== Update image of ] ==
The template provides links to search results to help editors find ]. ] has agreed to add this template to about 12000 article talk pages via his bot, but we would first like to get broader community input.


Proposal to update image used in ]:
Some precedents for this kind of template are:
#] - This bot went to biographies and if ] had an authority control identifier for the subject of the article, then it put a template linking the article to their library listing
#] - a project to apply templates which link out to ] videos on art and culture
#] - ]'s proposal to add a link to all Misplaced Pages articles which could connect any user to resources in their local library


Currently it looks like this:
Comments? ] (]) 02:34, 21 June 2013‎ (UTC)
{{Suppress categories|{{Template category}}}}


I propose we change the image to:
*'''Support''', same as I did when the idea was floated at ]. <code>]]</code> 02:45, 21 June 2013 (UTC)
{{Suppress categories|{{Template category/sandbox}}}}
*'''Support''', given the importance of ], this seems similar to {{tl|BLP}} to me, and should be equally prominent. ] (]) 03:03, 21 June 2013 (UTC)
*'''Support''' These are great links to high quality sources. Should help fellow editors improve Misplaced Pages. ] (] · ] · ]) (if I write on your page reply on mine) 03:08, 21 June 2013 (UTC)
*'''Support''' per ], ], etc. --]''''']''''' 03:10, 21 June 2013 (UTC)
*'''Support''' I am from ] and while I do not believe that standardized infoboxes would work for most fields, in medicine there are a small number of repositories which contain copies of the majority of published articles. Linking to these sources on the talk page does not directly modify Misplaced Pages articles themselves, but will give talk page visitors the option to automatically perform searches based on an article's title in document repositories. Guidance for users to find the research in those repositories is critical the development of articles and these repositories are irreplaceable as catalogs of the best available publications. ]] 05:41, 21 June 2013 (UTC)
*'''Support''' Opens the door for more improvement in articles! ]<sup>]</sup> 03:38, 22 June 2013 (UTC)
*'''Comment''' Pointing people to good sources is a good thing. However, WP:MEDRS is an overbearing policy used to exclude interesting research and ideas from articles, and anything that helps it therefore does a lot of harm. I am also quite skeptical of the "review article" filter in NCBI - my feeling is that it points you to a lot of obscure little commercialistic journals with odd POVs that are not accessible in your university library, while typically missing the "good stuff". It would be better to find or build a NCBI results filter that points people to the big guns (everything from Nature to PLOS), though selecting them is quite subjective. ] (]) 18:12, 22 June 2013 (UTC)
*'''Support'''. This template won't be a panacea. No combination of policies, guidelines, templates, and search filters can substitute for cautious, contemplative, informed editorial judgement, nor supplant the role of competent subject-matter experts in building some of our most technical content. Nevertheless, this looks like it provides some useful tools for our content builders, and equally importantly offers a constructive reminder of how we should approach writing medical articles. Well done. ](]) 02:23, 23 June 2013 (UTC)
*'''Support''' the general idea, but the template shouldn't use ] links. Unfortunately I can't think of an elegant solution to this problem at the moment. ''']'''<font color="green">]</font> 12:53, 26 June 2013 (UTC)
*'''Support'''. Could help. Can't hurt. --]<sup> ] ]</sup> 00:43, 28 June 2013 (UTC)


-- <span style="color:#CD0000">] ★ (])</span> 22:26, 13 January 2025 (UTC)
== RFR "reclaiming rights from old account" problem: ==


:This is too big a venue for this discussion. In any case, I don't think it's an improvement — better to keep it simple. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 03:06, 14 January 2025 (UTC)
Hello all,
I have noticed that many users go into RFR claiming that they are requesting rights for a new account either because their account was vanished (]) or they could not retrieve the password for that account, like this case: I suggest adding a new rule on the top of every "add request" page, like in the box on the top (e.g. "If you are requesting rights for an account that has been vanished by an administrator or one that you have forgotten the password to, it will most likely not be entertained" or alternatively "...will not be entertained"), because these requests are denied 99% of the time because of lack of concrete evidence that the requesting user is in fact the user that they say they were. ]<sup>]</sup> 03:30, 22 June 2013 (UTC)


== Replace abbreviated forms of ] with full name ==
:If your account was vanished you have already agreed you will never edit Misplaced Pages again under any identity, so they are breaking that agreement, which they would already be aware of, by even making such a request. If they are claiming ] it's the same deal, it's not a clean start if you want permissions based on who you used to be. The present instructions already indicate that you must make an edit with ''both'' accounts if you are requesting rights for an alternate, so that pretty much covers all those cases. ] (]) 20:11, 24 June 2013 (UTC)


I propose that most{{efn|I would probably leave alone the redirects that differ only in case, namely {{tl|Use MDY dates}} and {{tl|Use DMY dates}}, which are sufficiently readable for my concerns.}} transclusions of redirects to {{tl|Use mdy dates}} and {{tl|Use dmy dates}} be replaced by bots with the full template name.
::I was simply proposing a "do not attempt" notice. :) ]<sup>]</sup> 22:53, 1 July 2013 (UTC)


Part of the purpose of {{tl|Use mdy dates}} is to indicate to editors what they should do. Thus, readability is important. I propose all of these redirects be replaced with their target which is:
:::Yet I do understand policy. I'm relatively experienced at NAO ({{nao}}) on RFR, and some users come in claiming they have 15000+ edits. If you have 15000+ edits, you should understand policy quite well already, but it's impossible to tell (well, nearly) who's telling the truth and who's not. ]<sup>]</sup> 22:55, 1 July 2013 (UTC)
# More easily understood even the first time you see it.
# Standardized, and thus easier to quickly scan and read.


The specific existing redirects that I suggest replacing are:
== Mass removal of old indefinite rangeblocks ==
* {{tl|Mdy}} → {{tl|Use mdy dates}}
* {{tl|MDY}} → {{tl|Use mdy dates}}
* {{tl|Usemdy}} → {{tl|Use mdy dates}}
* {{tl|Usemdydates}} → {{tl|Use mdy dates}}
* {{tl|Use MDY}} → {{tl|Use mdy dates}}
* {{tl|Use mdy}} → {{tl|Use mdy dates}}
* {{tl|Dmy}} → {{tl|Use dmy dates}}
* {{tl|DMY}} → {{tl|Use dmy dates}}
* {{tl|Usedmy}} → {{tl|Use dmy dates}}
* {{tl|Use dmy}} → {{tl|Use dmy dates}}
* {{tl|Use DMY}} → {{tl|Use dmy dates}}
* {{tl|Usedmydates}} → {{tl|Use dmy dates}}


{{notelist}}
{{rfc|prop|policy|rfcid=35FC69B}}


] (]) 20:30, 18 January 2025 (UTC)
Currently, there are about 200 indefinite rangeblocks on various IPs, most of which are non-required now. A previous proposal on this Village Pump, which sought to remove these old rangeblocks under controlled conditions passed successfully. This proposal is to finalize all the various details on that proposal, and to carry forward with it.
:In principle I like this idea (noting ] to bring it here). My only concern would be about watchlist spam, given that, while this may not technically be a ], it's only a hair above one. But there's only a few thousand transclusions of these redirects, so if the bot goes at a rate of, say, one per minute, it'd be done in a few days. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]]</sup> <small>(])</small> 21:09, 18 January 2025 (UTC)
] (]) 06:37, 25 June 2013 (UTC)
::It looks like most or all of these are already listed at ], so whenever anyone edits an article with AWB, they'll already be replaced. No strong view about doing so preemptively.

::However, if our goal is to ensure that these templates are actually meaningfully used, then we have some bigger fish to fry. First of all, even the written-out form isn't sufficiently readable/noticeable — many newcomers may not know what it means, and many experienced editors may miss it if they aren't happening to look at the top of the article. Ideally, we would either offer to correct the date format if anyone enters the incorrect one via ] (]) or we'd include it in an editnotice of some sort.
Links -
::Second of all, roughly 2/3 of all articles still don't have a date tag, so we need to figure out better strategies for tagging en masse. There are surely some definable groups of articles that are best suited to a particular format (e.g. all U.S. municipality articles I'd think would want to use MDY) that we could agree on and then bulk tag. <span style="border:3px outset;border-radius:8pt 0;padding:1px 5px;background:linear-gradient(6rad,#86c,#2b9)">]</span> <sup>]</sup> 21:50, 18 January 2025 (UTC)
* ]
:: It's definitely a cosmetic edit, in that it only changes the wikitext without changing anything readers see. But consensus can decide that any particular cosmetic edit should be done by bots. As proposed, there are currently 2089 transclusions of these redirects, 1983 in mainspace. ]] 14:21, 19 January 2025 (UTC)
* ]

The general agreement in the previous discussion was -
# All rangeblocks beyond a certain time period will be reviewed.
# The rangeblock is reverted unless there is strong reasons not to.
# All reverted rangeblocks are placed in a special category for monitoring
# After sufficient time of activity,
#* If the IPs are good faith, they are removed from the monitored list
#* If they continue with their vandal behaviour, they can be reblocked as the blocking admins see fit. If they get indefinite rangeblocked again, the rangeblock could again be reviewed after the time period in Step 1.

If there is any confusion or disagreement regarding the above "general agreement" steps, please start a new discussion section below on the same so that we can discuss them, and other possible alternatives.
] (]) 06:37, 25 June 2013 (UTC)

===Discussion===

The sections below are for finalising and having discussion on the other ambiguous details that have been left out in the original discussion. Please feel free to add more sections, or more options to the ones already given, or to support, or have discussion on any of the options already mentioned.
] (]) 06:37, 25 June 2013 (UTC)
*In my opinion, indefinite rangeblocks should simply be prohibited entirely. Even for the most abusive sockpuppeteers or the widest open proxies, chances are, the IP's been reassigned. I would support a '''2 year max''' for most cases, and a strict '''5 year max''' in the most extreme cases. -- ] ] ] ] &spades; 00:57, 26 June 2013 (UTC)
**I agree that indefs shouldn't be used. I've never blocked any IP more than a year myself. ]&nbsp;&#124;&nbsp;]&nbsp;&#124;&nbsp;]&nbsp;&#124;&nbsp;] 01:00, 26 June 2013 (UTC)
is the list of all indefinite IP rangeblocks. With the exception of the Toolserver soft blocks, all will need to be reviewed. A couple of them seem to have been requested by the administrators of the IP ranges in question - perhaps we need a better process for documenting such requests in greater detail. — <span style="border:dashed #666;border-width:1px 0 0 1px">]</span> and <span style="border:dashed #666;border-width:0 1px 1px 0">]</span> 07:28, 29 June 2013 (UTC)

===Time period before review===
How much time should it be before the previous rangeblock is reviewed?
# 3 months
# 6 months
# 9 months
# 1 year
# 2 years

* '''6-12 months''' - If the range is rotten it won't take long for problems to show up. In a /16-/18 or so i seem to recall seeing proxies popping up at about 6 month intervals. ] (]) 09:31, 25 June 2013 (UTC)
::Wait, is this rangeblocks in general (I was originally thinking this was just the old indefs which should be lifted and then reviewed after 6-12 months)? If so, I would distinguish strongly between hosting and ISP blocks. ISP blocks should rarely longer than a few months before they should be reviewed. If we're talking hosting providers, a year or two for review after a first block, five years for repeat offenders. Rotten hosts tend to stay rotten hosts, and the useful to useless ratio for those ranges tends to be exceptionally unfavorable with very little activity. ] (]) 13:31, 25 June 2013 (UTC)
* '''6 Months''' if it's their first review. '''1 Year''' afterwards. ] ] ] 12:58, 25 June 2013 (UTC)
* '''3 months''' on first review. 6 months on second review and yearly after that. ] (]) 13:35, 25 June 2013 (UTC)
*Basically I do not think we should be creating a list of 200 mostly unneeded range blocks, but I am not sure how a rangeblock can be reviewed without releasing it and seeing if any edits ensue. I would personally prefer an emphasis on helping rogue editors learn how to contribute positively instead of just blocking the IPs used, but I would opt for a standard 3 month review of all range blocks, so that unneeded ones did not accumulate. ] (]) 18:45, 25 June 2013 (UTC)
*Both ninjapirate and apteva are in the ballpark, I'm going to say 3 months on the first review and six months thereafter, with broad discretion given to whoever does the unblocking.] (]) 19:50, 25 June 2013 (UTC)
* '''12-18 months''' Sure, some will be free before then, but all should be reassigned within 12-18 months... Very few should "still" be an issue. I'd rather see less frequent and more thorough passes. ] (]) 22:33, 25 June 2013 (UTC)
*:Why do you believe that all IPs are reassigned within 12–18 months? I know of some that haven't been reassigned for 18 ''years''. ] (]) 07:14, 26 June 2013 (UTC)
*'''1 year''' or so before any mandatory review is required. This is not at all to say the current review process/procedures are affected by this either. This is just an ''additional'' review that should have no bearing, implied or otherwise, on current rangeblock procedure. ] (]) 22:59, 25 June 2013 (UTC)
*'''1 year''', since a 1-year block on a highly abusive IP range is standard. -- ] ] ] ] &spades; 00:51, 26 June 2013 (UTC)
*'''1 year''', per King of hearts above. ] (]) 05:47, 26 June 2013 (UTC)
*'''1 year''', also per King of Hearts ''']''' <sup>]</sup> 09:42, 26 June 2013 (UTC)
*'''1 year''' was my favoured time period too. Sounds best. ] (]) 12:09, 4 July 2013 (UTC)

===Who participate in the reviews===
Which group of users will participate in the reviews before the old rangeblock is lifted?
# Bureaucrats only
# A specialised elected/selected group of trusted editors (may be chosen along with one of the other options)
# Administrators only
# Administrators + Rollbackers
# Administrators + Reviewers
# Autoconfirmed
# Everyone
# One of the other categories + a group of trusted users

* '''Specialised/ selected groups''' - Checking the range involves proxy-checking skills, which some users have and some admins have. That's the main source of rotten ranges requiring long term rangeblocks Or I could run for admin, since I'm not aware of any other specialised non-admin users. ] (]) 09:31, 25 June 2013 (UTC)
* '''Specialised Group:''' Namely I say we give ArbCom a bit more to do. The Arbs are bound to have a CU on the team if it's needed or they can just ping one. I mean a CU is hardly going to refuse to help our top line of <s>nitwits</s> editors now are they? ] ] ] 13:00, 25 June 2013 (UTC)
* <s>'''Specialized group'''. I'm not too concerned with this detail. Elected/selected volunteers, arbcom, or admins.</s> I'm switching to '''Everyone'''. We could also put up regular, recurring RfCs and invite comments by Autoconfirmed users. Could be fun. ] (]) 13:39, 25 June 2013 (UTC) (update: 13:28, 26 June 2013 (UTC))
* '''Everyone'''. The person reviewing the IP should be the person responsible for monitoring that IP. If you can take responsibility for the monitoring, you should have the authority to decide the review (within reason and policy)] (]) 19:53, 25 June 2013 (UTC)
* '''Specialised/selected group of trusted users''' that should be given a smaller package of the admin tools. Rights that should be included are the ability to (un)block (single|range), check-user, override title blacklist, noratelimit, at least to start. These are the minimum tools needed to complete these tasks, and if the users are trusted/elected, it shouldn't be an issue. ] (]) 22:42, 25 June 2013 (UTC)
*'''Everyone''', but of course more weight should be given to the opinions of '''checkusers and skilled proxy checkers'''. -- ] ] ] ] &spades; 00:52, 26 June 2013 (UTC)
:: This is an eminently reasonable option as well. ] (]) 09:57, 26 June 2013 (UTC)
:: Yeah, this seems like a good solution. ] (]) 13:23, 26 June 2013 (UTC)
*'''Everyone''' of course. Seems like a nobrainer. I can't believe there's even a suggestion that an appeal process like this would exclude outside input wholesale. ] (]) 05:27, 26 June 2013 (UTC)
*'''Everyone''' , because reviews will be decided on the weight of the arguments and not on a tally of the !votes. ] (]) 06:07, 26 June 2013 (UTC)
*'''Checkusers''', because checkusers are the only people that can actually monitor the behaviour of an IP range. All the rest of us can judge is the quality of the anonymous edits inside the range.&mdash;](]) 23:37, 29 June 2013 (UTC)

===Who monitors the activity===
Which group of users will monitor the activity after the old rangeblock is lifted?
# Administrators only
# Administrators + Rollbackers
# Administrators + Reviewers
# Autoconfirmed
# Everyone
# One of the other categories + a group of trusted users

* '''Everyone''' - Problems can be reported to ], ] and/or ] like any normal disruption. The same group involved in reviewing the blocks above can then look for complaints that resulted from monitored ranges. ] (]) 09:31, 25 June 2013 (UTC)
* '''Everyone:''' Same process as with any old IP. If they're acting up then drop em off at AIV. ] ] ] 13:02, 25 June 2013 (UTC)
* '''Everyone'''. Agree with previous users. ] (]) 13:40, 25 June 2013 (UTC)
* '''Everyone''' should pitch in, but the responsibility ultimately lies with '''the reviewers of the specific range unblock''' here. </br> Just a point to mention. I am working under the assumption that we will be monitoring the activity of the recently unblocked users at a particular location so we can keep an eye out for the ones who might be going back to bad faith edits If not monitoring them (specially) is what others have in mind, we can clarify that with a discussion. ] (]) 22:14, 25 June 2013 (UTC)
* '''Everyone''' - Problems can be reported to ], ] and/or ] like any normal disruption. The same group involved in reviewing the blocks above can then look for complaints that resulted from monitored ranges. ] (]) 22:43, 25 June 2013 (UTC)
* '''Everyone''' - the more eyes the better. ] (]) 06:25, 26 June 2013 (UTC)
*'''Everyone''' - admins will need to make the ultimate decision, but most of the monitering work can be done even by anons who regularly edit without creating an account. ] ] 21:44, 2 July 2013 (UTC)

===How are the changes monitored?===
How should the changes be monitored? Through a WikiProject, something similar to the pending changes (a special category), or a bot? Discuss below ] (]) 06:37, 25 June 2013 (UTC)

* '''Bot''' existing tools are a bit of a pain in the tuchus for checking this sort of thing, it would be nice to have a page listing contributions from these ranges. ] (]) 09:33, 25 June 2013 (UTC)
* '''Bot''' if someone can make such a bot then why not? All the rangeblocks that WP has to deal with would be painful for a group of people to handle. ] ] ] 13:07, 25 June 2013 (UTC)
* '''Bot'''. Makes sense to me. ] (]) 13:41, 25 June 2013 (UTC)
* '''A Bot''' does indeed seem like the logical path to follow! ''']''' <sup>]</sup> 17:20, 25 June 2013 (UTC)
* Agree, a '''bot''' is the correct course. ] (]) 19:57, 25 June 2013 (UTC)
* '''Unsure''' I'm not convinced that using a bot for this is the appropriate course of action. Let me think about it some more and see if there may not be a better alternative. ] (]) 22:44, 25 June 2013 (UTC)
*'''Bot''' - Seems like an easy answer. It should be mentioned that most of the load would be offline anyway. Simple monitoring of the block log would be enough. ] (]) 05:19, 26 June 2013 (UTC)
*'''Bot''' sounds like a good idea. ] (]) 06:26, 26 June 2013 (UTC)

===Blacklist?===
What should be done with the worst case rangeblocks? Should we have a blacklist for them, or give them a little ] and reblock after bad-faith edits after every review?

* Some combination of the above. Blocks shouldn't be permanent (in case ranges change hands), but certain repeat offenders (e.g. theplanet hosting) should be named, shamed, and blocked at the slightest hint of trouble. ] (]) 09:31, 25 June 2013 (UTC)
* '''WP:ROPE''' as this rule states that you can give them so long before you hang them. If they still don't get the picture after a 2 year block on the situation then they're just not going to get it ever. ] ] ] 13:11, 25 June 2013 (UTC)
* 3/6/12 month review period, as above. Open to supporting longer periods, too. Permanent blacklists seem too punitive. IP blocks can and do change ownership. ] (]) 13:44, 25 June 2013 (UTC)
:: ] but then there will be some proxy-offering websites, or permanent troubles who would better be handled with a blacklist. ] (]) 13:51, 25 June 2013 (UTC)
::: Repeat offenders can go on a separate list that has no probationary period. At that point, the only problem becomes workload. If reviewed yearly or biennially, workload should be manageable. I dislike the idea of a permanent block for an entire IP range. If we all get an IPv6 address tattooed to us at birth, this may change, but, for now, IP addresses are not people. ] (]) 15:32, 25 June 2013 (UTC)
:::: I don't think permablocks are the answer either, but for bad hosting providers, they seem fairly stable over periods much longer than 12 months. The amount of workload involved is quite extensive. A thorough and proper check of an IP range can easily take an hour. I don't know our total number of rangeblocks, but I'd guess it's in the thousands. For annual reviewing, it would be equivalent to one or more full-time real job. ] (]) 15:44, 25 June 2013 (UTC)
::::: ], it is 200 indefinite ones. ] (]) 16:47, 25 June 2013 (UTC)
:::::: ''']''' <sup>]</sup> 17:18, 25 June 2013 (UTC)
::::::So ] could you clarify if you mean for all of the subpoints of this proposal apply to all IPs, or just the ones that currently are under an indef block? If so, I agree that checking the 200 or so wouldn't be a huge problem. ] (]) 19:21, 25 June 2013 (UTC)
:::::::Yeah. That's my understanding. Some of them are easy. Voluntary blocks, commercial proxies, etc don't require much effort to validate. Professional spammers and determined vandals (GNAA/4chan) will be where most of our efforts go, I think. They may actively try to hide their nefarious intent. For something like The Anonymizer, you just make sure it's still running and at the specified IP range. ] (]) 19:48, 25 June 2013 (UTC)
::::::: Just the indefinite ones. I thought it was clear from my header. Also, if there was no indef-block, the block would go away anyways. (Assuming no admins block for a very long period of time, in which case, we might have to check all blocks larger than our review period too) ] (]) 20:04, 25 June 2013 (UTC)
::::::::Well, yes, but the current practice has moved to 2-5 year rangeblocks for disruptive hosting ranges. Hence why I'm a little hesitant about some of the proposed remedies if they would make review more frequently. This practice seems to have been fairly successful, but it would be nice if it had endorsement from the broader community. ] (]) 21:08, 25 June 2013 (UTC)
*Blacklists should be extremely rare, and probably limited to stuff like outstanding legal threats, and ''maybe'' gross intentional violations on a BLP beyond petty vandalism. (e.g. Joe Shmoe is a rapist...) ] (]) 20:01, 25 June 2013 (UTC)
* '''ROPE''' them... Plain and simple... ] (]) 22:44, 25 June 2013 (UTC)
*'''ROPE'''. Eventully, the guilty user(s) will be gone and it should then be unblocked. ] ] 21:42, 2 July 2013 (UTC)

===Additional Proposal===
Following Sailsbystars' concerns at the above section, I propose that '''After the expiration of the said review period for definite rangeblocks, they will be undergoing a the same (review) process that other indefinite rangeblocks have.''' So if the review time is decided to be 6 months, then ordinarily, all definite-blocks older than 6 months will also get reviewed under the same rationale as the indef blocks. ] (]) 22:20, 25 June 2013 (UTC)

* As proposer, '''Aye''' ] (]) 22:20, 25 June 2013 (UTC)
* Meh, I see this as more of an on-going process and not a circular thing. It's either going to be the same person on the other end of the IP or it's not... After 12-18 months, "most" IPs should have changed hands at least a few times. I don't see any reason not to assume good faith and let the IP start with a clean slate for each pass. ] (]) 22:47, 25 June 2013 (UTC)
*'''Comment''' - I'm not thrilled about the idea of complicating this specific question with additional issues like this. The question of if a definite rangeblock of 3 years is worse than an indefinite one is unclear. My gut instinct is to leave it aside, although after some thought I think that erasing the distinction between indefinite (which always seems like a cop out to me) and definite but long, is a good thing. ] (]) 05:25, 26 June 2013 (UTC)
* This seems eminently logical. I can't really see any reason why it wouldn't work like this, except for workload. Considering that, we might need to re-think the frequency of reviews. ] (]) 17:50, 26 June 2013 (UTC)
:Let ArbCom do it? XD ] ] ] 08:08, 28 June 2013 (UTC)
*'''Comment''' My concerns would be allayed if we distinguished between hosting IPs and ISP IPs. For the ISP IPs (or corporate filter webhosts or really, most IPs), I have no problems whatsoever with limiting those to 3-6 months. Web hosts, however, tend to be rather static, and have a.) much lower IP contribution rate than ISP IPs (I did a little experiment once and came up with a ratio of either 10 or 100x more edits from the ISP range) and b.) low helpful to harmful contribution ratio and c.) never NEED to be edited from. Based on experience, certain hosting ranges have earned 2-5 year blocks, and nothing of value was lost. An aside, I realize this is a bit of instruction creep and would be difficult to manage due to the fact that blocks can't be sorted by the block log notes (at least as far as I'm aware). ] (]) 21:11, 26 June 2013 (UTC)
:: I have no idea what these two are. Could you please explain in a simple way too? Thanks. ] (]) 21:37, 26 June 2013 (UTC)
::: Examples of an ISP IP would be ones from ] or ] in the USA, ] in the UK, or ] in France. Cell providers, government or uni IPs would fall under this category as well. Examples of hosting providers would be ], ] Hosting, or ]. Basically, under normal circumstances, all of us edit from an ISP of one sort or another. All of these involve a computer sitting on a desk somewhere connected to the internet. With hosting providers, the computers are all sitting in a data center somewhere with no human at them. Under normal circumstances, most edits from webhosts are from people trying to escape scrutiny or evade a block/ban as they involve an extra effort beyond what one normally uses to connect to the web(e.g. anonymizing services, proxies, some ], on the rare occasion one own's server). Hope this helps? ] (]) 05:13, 27 June 2013 (UTC)
: '''I Like This.''' I think we should. ] ] ] 08:08, 28 June 2013 (UTC)
* '''Final Note''' - If there are further topics of discussion, please add them as a section above this line.

== Discussion about spacing between lists (refs/ELs) and navboxes ==

There seems to be a protracted, site-wide style war between editors who prefer more and those who prefer less vertical space above the first navbox. This mostly involved edit warring by manually adding and removing blank lines and similar devices. Luckily, it seems that a uniform technical solution exists for this issue. Unfortunately, participation in the discussion at ] has been rather low and took a turn for personalization recently. Perhaps people watching this page have an opinion on how much spacing looks good? If so, please contribute at WT:MOS, for the sake of keeping the discussion in one place. Thanks, ] (]) 13:44, 27 June 2013 (UTC)
:Don't remember ever running into this kind of thing. Could you provide a diff so I can understand better? ] (]) 17:16, 27 June 2013 (UTC)
: Perhaps I'm missing something but this issue seems to be of no importance. ] (]) 00:57, 29 June 2013 (UTC)

== Talk page archival with automatic redirects to former discussions ==

Can the system be made to automatically create a redirect when a talk page discussion is archived? Such a feature would make talk page wikilinks always work, rather than having them break upon archival. For instance, ] might be placed on someone's talk page or in an edit summary, but when it is archived, the wikilink breaks to become something new: ]. I propose having a redirect automatically written to bring the reader to the archived discussion when they click on ].

To make this work, identically named threads must be differentiated in some way, perhaps by time stamp. ] (]) 02:15, 1 July 2013 (UTC)
:] does this automatically. ''']'''<font color="green">]</font> 02:33, 1 July 2013 (UTC)

:That's one of a few hundred things that ] will solve completely. We'll have to wait until that's written and released, though.
:Otherwise/currently, Cluebot III is our only hope. (Afaik Cluebot III and the 3 Miszabots are the only functioning archivebots?) –] (]) 03:09, 1 July 2013 (UTC)

::I looked at the contribution history of Cluebot III and I could not find it doing any redirects. How does it work? Looking forward to Flow... ] (]) 05:22, 1 July 2013 (UTC)
::: of cluebot III fixing a link.
:::I'm not sure what its parameters/methods are though - does it check every page on "What links here", or something? Possibly need to ask at its talkpage. –] (]) 05:46, 1 July 2013 (UTC)

== With regard to Article editing interface ==

At the very least, I move that we should ''always'' keep good old fashioned source editing available alongside the new what-you-see-is-what-you-get mode. This may be counterintuitive, but it is actually easier to edit Infoboxes and other tables in source. That seems like reason enough to me. :-) ] (]) 14:10, 2 July 2013 (UTC)
:We hope that it will not always be easier to edit templates and tables in the source, but at this point, VisualEditor still needs some features added or expanded. I can assure you that there are '''no plans to turn off wikitext source editing'''. (Who knows what will happen years from now, of course, but no current plans at all to remove the old editor.) ] (]) 16:05, 2 July 2013 (UTC)
::It is effectively removed for many editors, because the "edit source" link on sections is HIDDEN. --] (]) 20:44, 2 July 2013 (UTC)
:::Hi Timeshifter, I know you don't like the section edit links. Last I checked (which was a couple of days ago), I believe that only you and one other user had complained about them, and many editors had praised the design. If you believe that most editors are unhappy about that particular detail, you might brainstorm some alternatives and request that the most popular be considered as a replacement. ] (]) 08:29, 3 July 2013 (UTC)
::::It is funny to see you get stuck with one reply in spite of the barrage of new comments agreeing with me at ], and in spite of my previous direct replies to you days before pointing out others agreeing with me. --] (]) 08:48, 3 July 2013 (UTC)
:::::I totally agree with Timeshifter. This is one of the issues that bug me most with VisualEditor and will be a reason to deactivate it for me (I'll might keep VE activated in parallel if it really seamlessly melds into the UI but not as long as it hides the button I'm probably using most on Misplaced Pages).
:::::You want an example? Here it is! <span class="mw-editsection">&#91;]&thinsp;|&thinsp;]&#93;</span> Simple as hell, without the need for any hovering effects.
:::::And for the bug itself: There's even a bug for it, see ]. --] (]) 09:40, 3 July 2013 (UTC)
:://Who knows what will happen years from now, of course//
::Exactly, who knows what will happen years from now if anything could happen in principle. That's why I'd rather see a keep-source-editing policy set in stone ''now'' instead of leaving the future to chance and whim. ] (]) 13:05, 4 July 2013 (UTC)
:::How many years are you looking at? Do you want "keep the 2002 source editing system" to be true next century, regardless of how computing has changed during that time? The Wikimedia Foundation is hopeful that Misplaced Pages will still exist then. ] (]) 14:28, 4 July 2013 (UTC)

(unindent). It only took a few days for my prediction to be proven right concerning the hidden "edit source" links on sections. It has already been reverted due to the barrage of complaints about it. The only link now on article sections is an "edit" link that goes to the wikitext source editor for that section. It would be nice if there were a preference on the edit tab of preferences for having both links ("edit" and "edit source") on sections. 2 simple direct links without hover effects. --] (]) 01:38, 5 July 2013 (UTC)
:I'm sorry to be the one to tell you, but: according to the e-mail messages I received today, the sudden disappearance of the section edit links for VisualEditor was an unintentional bug that will be fixed on Monday. They'd fix it now, but they are trying not to make changes just before the weekend. ] (]) 03:37, 5 July 2013 (UTC)

== User Council ==

I've been irked into proposing this by issues around the introduction of the ]. However, the issue itself is age old. I feel that there is an disconnect between the Foundation and users of Misplaced Pages when it comes to rolling out software changes.

When I say "users" here, I mean users in the software sense (i.e. ]s) and not in the way we often mean it here (as a synonym for "editor"). And when I say "Misplaced Pages", I mean the software hosted on this website (not the encyclopaedia or its content).

I can appreciate the desires and challenges the Foundation faces (as a software developer I face them too). In industry, a common way to resolve problems like this is by involving users formally in the process of developing and rolling out new software. One technique is to establish "user councils" that represent the end users of a product.

I propose we establish a user council for the English-language Misplaced Pages. I'm going to keep the details of this proposal very high-level so as to first gauge consensus around the basic idea.

The council, I believe, should:

* Be independent of the Foundation
* Be elected for a fixed term from Misplaced Pages users
* Have both rights and responsibilities

Rights may include:

* To be kept informed about Foundation road-maps and plans for software roll outs
* To have sign-off on software changes affecting end users before they are rolled out

Responsibilities may include:

* To ensure Misplaced Pages users are adequately informed about up-coming software
* To provide a forum for user feedback and represent user feedback to the Foundation

--] (]) 20:19, 2 July 2013 (UTC)

:This might actually be useful. At present there are people claiming that years and months and weeks and days of talking about it, weeks of watchlist/recent changes notices and a banner on literally every logged-in page in article space constitutes not informing people; it might be useful to have one point of contact who telling officially constitutes notice - ] (]) 20:38, 2 July 2013 (UTC)

:Thanks for writing a clear and succinct proposal RA. Regarding, "To be kept informed about Foundation road-maps and plans for software roll outs"... the Foundation's roadmap and planning are already public. The trouble is trying to keep the correct subset of 80,000+ active editors informed about what's in them to avoid surprise and anger. We've kicked around the idea of a special advisory body of users regarding product/engineering work at the WMF as well. However, honestly after seeing how hard Philippe, Oliver, Maggie, and others employed to "ensure Misplaced Pages users are adequately informed about up-coming software" work, I don't think it's fair to put that job in the lap of volunteers. Immediately pre and post deployment of a new feature, the effort to keep the community updated and respond to feedback is not only a full time job, it's a grueling and often stressful one. Also, to be frank I doubt users surprised by a change will accept the response of "Well, we didn't tell you, but we told this tiny select group of users. It was their job to let you know, so go yell at them." When the WMF makes changes to the software, the responsibility ultimately rests with us to keep people informed. <font style="font-family:Georgia, serif;">]&nbsp;&bull;&nbsp;]</font> 20:40, 2 July 2013 (UTC)
::I do not envision a user council as a vehicle for the Foundation to shirk its own responsibilities. The Foundation has a responsibility to ensure users are properly and adequately informed about up-coming changes IMO. A responsibility of a user council would include making sure (ensuring) the Foundation lives up to that responsibility. --] (]) 20:46, 2 July 2013 (UTC)
:::Is this an achievable goal, though? Note my example above, which is not in fact exaggerated in any degree whatsoever - that's literally what's happened. What would constitute reasonably informing people, to your mind? - ] (]) 21:10, 2 July 2013 (UTC)
::::Example: I currently (finally?) have notice of the roll-out of the Visual Editor in my watchlist notices. I also have notice of a meet-up in the UK. The roll-out notice is in a small font and the UK meet-up is advertised is in a large font. Needless to say, the roll out of major changes the editor is much more important to the vast majority of editors compared to a meet up they are not going to attend.
::::The WMF guys have a lot on their plate and it's easy to make simply mistakes like this. A user council is focused and one of their roles can be to remind the WMF guys not to make mistakes like that at another roll out. --] (]) 21:24, 2 July 2013 (UTC)
:::::::There were at least three separate watchlist notices: , , . The two most common explanations for failing to see notices that were deployed to everyone are ] (e.g., failing to pay attention) and ]s (e.g., some interaction between your browser's settings and Mediawiki's software). BTW, that's just watchlist notices. That doesn't include the CentralNotices, messages to dozens of high-traffic discussion pages, or other announcements that were made. ] (]) 08:40, 3 July 2013 (UTC)
::::::::Notices are good, but notices are not discussion on English Misplaced Pages. There has been very little alpha or beta discussion on English Misplaced Pages until recently. All of a sudden there is substantive discussion on English Misplaced Pages about the visual editor. It is too little too late. There are many serious design flaws that could have been avoided if earlier substantive discussion had occurred on English Misplaced Pages, or if an experienced, elected, accountable user council had been involved early on. A user council that reported back often to English Misplaced Pages. --] (]) 11:03, 3 July 2013 (UTC)
:::::... and to ensure there are "How to turn it off"-options. --] (]) 21:27, 2 July 2013 (UTC)
::::::You mean, like the one that's still there from before? - ] (]) 21:37, 2 July 2013 (UTC)
:::::::It was recently moved out of the logical location of the edit tab in preferences, and buried in the gadgets tab. --] (]) 21:45, 2 July 2013 (UTC)
:::::::I mean, like the one that's not there at all... (But should be per ]). Also, a User Council is not only necessary for the VE-case. There was a very aggressive roll-out of the ] which certainly did not had consensus the first time. --] (]) 21:54, 2 July 2013 (UTC)
:::::No, I think I can reasonably state that if the ''barrage'' of notices about the impending VE were not adequate, then ''nothing'' would be adequate. You cannot, in fact, demand an arbitrary magical flying unicornetto pony - ] (]) 21:37, 2 July 2013 (UTC)
::::::Not a "an arbitrary magical flying unicornetto pony". A pretty straight-forward industry technique for resolving the kinds of issues raised. Including the ones you have. --] (]) 22:15, 2 July 2013 (UTC)

: RA, thanks for thinking about this issue. Regarding the item "To be kept informed about Foundation road-maps and plans for software roll outs": people like you might like to ]. Monitoring and understanding all the technical activity happening across the Wikimedia movement is definitely a difficult and time-consuming task. By subscribing to Tech News, you can help monitor recent software changes likely to impact Wikimedians, and receive a weekly summary on your talk page, without technical jargon. And if some Wikipedians would like to have more resources for informing other onwiki users and helping technical folks get user feedback, it would be great if they'd check out ]; the Tech ambassadors are technically-minded volunteers who help other Wikimedians with technical issues, and act as a bridge between developers and local Wikimedia wikis. I know this does not address the whole of your proposal, but I thought I would mention it for those who are interested. Thanks. ] (]) 22:20, 2 July 2013 (UTC)
::Tech News is great. I get it on my talk page. --] (]) 10:55, 3 July 2013 (UTC)
*'''Support.''' Long overdue. See my user page for more info. --] (]) 20:42, 2 July 2013 (UTC)
*'''Support'''. We should definitely have a say on what software is rolled out to us, because after all, we are the ones that will be using it. ] (<sup>]</sup>/<sub>]</sub>) 20:48, 2 July 2013 (UTC)
*'''Support''' Great idea. <span style="font-family:Trebuchet MS">] <small>(])</small></span> 21:03, 2 July 2013 (UTC)
*'''Oppose.''' We've had this discussion before in various forms over the years now, and I think it boils down to a single thing: people want to have input without participating. MediaWiki, deployed extensions, and nearly every aspect of WMF development is carried out in public on mailing lists, Bugzilla, Gerrit, MediaWiki.org/Wikitech, any of which people are more than welcome to participate in. Problem is: nobody wants to participate. If enwiki wants to come up with a group of users who do want to contribute with developers and report back to the community, that's perfectly fine (and I've always encouraged people who *are* interested to jump in). However, I adamantly oppose a self-appointed council on enwiki having effective veto power over software changes that affect people other than enwiki--that's simply not how we develop MediaWiki, nor has it ever been. <b style="color:#c22">^</b>]</sup>]]&nbsp;<em style="font-size:10px;">21:10, 2 July 2013 (UTC)</em>
*:Not self appointed. They should be elected IMO. And only EN-wiki. --] (]) 21:15, 2 July 2013 (UTC)
*:: Point taken. But my main point remains the same: we develop software using consensus as well, it's just not done via an elected committee. Software changes are proposed in Bugzilla or Gerrit where they are debated/revised and (if they're good) merged. And "affecting end users" is far too vague...nearly everything effects end users to some degree or another. <b style="color:#c22">^</b>]</sup>]]&nbsp;<em style="font-size:10px;">21:31, 2 July 2013 (UTC)</em>
*:::I appreciate that. But, I'm not talking about MediaWiki. That is a separate project(s). I'm only taking about deployments to the live EN-Misplaced Pages environment.
*:::But take bugzilla (and similarly, wikitech-l) as an example: must users couldn't understand what's discussed in tickets. A user council represents users in "user terms", not "developer terms". And it represents the "receiver" of a product, not the "producer" of it. That can involve liaising with developers but it doesn't take away anyone's job or duplicate it. --] (]) 21:56, 2 July 2013 (UTC)
*:::: But aren't the two inherently intertwined? We deploy new versions of MediaWiki on a rolling weekly basis--for which there are detailed release notes. Having a committee to review those changes and approve them prior to deployment either A) makes us slow down deployments (something we've been trying to get better at) or B) makes deployments a mess (having to back out changes that aren't "approved"). Again, I'm all for having a group of people who liaison with developers, but the proposal as it stands doesn't jive with how we develop MediaWiki or consequently deploy it. The proper time for discussion is when changes are being proposed or written, not before they're deployed. I appreciate that most people aren't able to understand technical discussions--but isn't that the point of this committee? <b style="color:#c22">^</b>]</sup>]]&nbsp;<em style="font-size:10px;">22:28, 2 July 2013 (UTC)</em>
*:::::This is the kind of detail I wanted to avoid (I'd preferred to have left it for later) - but it is important. I presume you're talking about day-to-day patches, updates, etc. not roll-outs of major new user-facing functionality, changes, plugins, etc.. I'm not going to say that a user council wouldn't be interested in those but I don't think it's in anyone's interest to have a committee rubber stamp those kinds of things. There are some things where developers know best and it's not in the users interest to go sticking their heads into it. But it's informative to know about them and have them explained to you in terms you understand.
*:::::I agree that "the proper time for discussion is when changes are being proposed or written, not before they're deployed." And that's when a user council should liase (and translate "developer talk" to "user talk") so that when software gets delivered everyone knows what to expect.
*:::::TBH that kind of thing doesn't need a formal council and should happen anyway. (I'd be willing to put some effort in around that, if you'd assist.) A formal council (with "rights") would only be needed when things go bad. --] (]) 23:11, 2 July 2013 (UTC)
:::::demon, you wrote: "The proper time for discussion is when changes are being proposed or written, not before they're deployed." Discussion needs to occur at all stages. It is unrealistic to expect this continuous discussion to occur between developers and users when the discussion occurs mainly on smaller wikis. This is due to the lack of cross-wiki watchlists. Developers hang out on their wikis and mailing lists and Gerrit, Bugzilla, etc.. Users hang out on their main Wikipedias. Few developers make much effort to maintain longterm discussion on software issues on English Misplaced Pages. Users may try to go to the developer wikis but then soon tire of looking at multiple watchlists waiting for an eventual answer, and give and take. An elected user council puts an accountable group between users and developers. Its advice does not have to be binding to be very useful to all. --] (]) 08:42, 3 July 2013 (UTC)

**'''+1''' - do any of the people here ''e.g.'' bother following wikitech-l? I do - ] (]) 21:15, 2 July 2013 (UTC)
*'''Oppose''' - I honestly feel this is a solution in search of a problem. In my opinion, the Philippe, Maggie, Oliver, the E3 team and the rest of the Foundation is doing a fine job of informing and involving the community in software and strategy changes. Short of spamming every single users talk page with a notice on every change, I don't think there really is anything else they can do to ensure everyone is notified, and I don't see what creating another body will do that is not already being done. <font face="Verdana">] ] <sup>]</sup></font> 21:13, 2 July 2013 (UTC)
**Apparently it's intended as a vehicle to make staffers' jobs more painful: "The Foundation has a responsibility to ensure users are properly and adequately informed about up-coming changes IMO. A responsibility of a user council would include making sure (ensuring) the Foundation lives up to that responsibility." Note nothing there about what would actually be sufficient (apparently, banners on every logged in page aren't) nor about said concerned users getting off their backsides to find anything out themselves. RA, what do you do to keep yourself informed? - ] (]) 21:18, 2 July 2013 (UTC)
*'''Comment.''' Do we really need this if WMF starts communicating ''all'' details of a new software? In the latest example we had the chance to look at the VisualEditor for weeks and it was OK. Nobody told us that the option to turn VE on/off would be gone with the "final" release, though. Although all at WMF did a good job to communicate with us, the just missed a key fact. That should (must) be avoided in future!
:Additionally I think there should be a better channel from the users back to the developers at WMF. If I'm informed about a change I don't like but have no ability to communicate this back (or am only getting reassured that "everything will be fine") the whole point of communication has failed.
:I don't know if adding a small group of volunteers in between can really solve this fundamental problem or if it will only shift the point at which communication is failing to fewer shoulders. --] (]) 21:21, 2 July 2013 (UTC)
** What on earth are you talking about? The option to switch it off is right there in your preferences, precisely where it was before - ] (]) 21:34, 2 July 2013 (UTC)
:::It has been moved out of the logical location of the edit tab in preferences, and buried in the gadgets tab. --] (]) 21:41, 2 July 2013 (UTC)
*'''Support.''' Existence of a User Council would not mean WMF is relieved of its responsibilities to involve users in software development or build consensus before implementing them. Personally I see the need for a User Council so it can ensure WMF lives up to the requirement of consensus building we set for every user of the Wikimedia projects. User Council should do its best to determine what the consensus of the user community is and not allow WMF to implement changes (software or other) without it. --] (]) 21:24, 2 July 2013 (UTC)
*: MediaWiki development does operate on consensus building--changes aren't just made by fiat. <b style="color:#c22">^</b>]</sup>]]&nbsp;<em style="font-size:10px;">21:35, 2 July 2013 (UTC)</em>
::::Article feedback tool did ''not'' have consensus at the first roll-out. It was aggressively pushed by WMF with little consideration to the user community. --] (]) 21:58, 2 July 2013 (UTC)
*'''Comment. A user council is a good interim solution to the lack of ].''' Here is the medium-term communication solution until ] are implemented: Some of the leaders at the level of the ] board and staff have been promoted beyond their level of current competence (per the ]), since some of them are fairly inexperienced at editing Misplaced Pages, or dealing with the intricacies of Misplaced Pages. Some of them hang out at '''], where ideas go to die.''' Or they create '''other small wikis''' such as the ''', , ,''' etc.. To get more in-depth participation in projects, move projects to the ], or better yet, back to English Misplaced Pages. English Misplaced Pages has far less ] than in the past. The Commons gets a lot of participation from editors worldwide. For more info see: ], "Op-ed. Meta, where innovative ideas die", especially the comments. See also this article and comments: ]. "Meta: 'a specific kind of mess'?"

:'''Commons has a huge number of active editors (registered users who have performed an action in the last 30 days'''). Compare the number to English Misplaced Pages. Here are the numbers as of June 2013:
:*''']''' - over '''30,000''' active registered users on the '''Commons''' in the last month. '''272''' administrators.
:*''']''' - over '''124,000''' active registered users on '''English Misplaced Pages''' in the last month. '''1,446''' administrators.

:'''Meta, Strategy, Outreach, Usability,''' etc. would still exist if they were moved to the Commons. '''They would be independent projects on the Commons.''' All the documents would still exist. For Meta, everything would continue on: board elections, steward elections, chapter documentation, translations, Wikimania bidding, policy drafting, committee work, GAC/FDC, etc.. The only difference would be that they occur on the Commons where there are far more active editors from around the world. Until there is an ''']''' this is the best way for such projects to get '''broad participation.'''

:One way is to do it with folders. As on Mediawiki.org at ] where there is a folder for Technical communications subdivided by sub-project. There are many such folders for various projects on MediaWiki.org. It would be easy to do this via ] on Meta, and ] on the Commons. One uses "Destination root page" in the Special:Import form on the Commons, and enters "Meta". So all pages moved from Meta to the Commons would start with '''commons.wikimedia.org/Meta''' - I have tested this on another wiki when importing stuff between wikis. It works. If small wikis were moved to the Commons, then templates would no longer have to be duplicated on all those wikis. --] (]) 21:37, 2 July 2013 (UTC)

* '''Support''' After the whole thing with the Link Wizard]] and the Quest for the Magical Hidden Off Switch, I am convinced that the WMF people have no clue how encyclopedia editors (or website users in general) work.—Love, ''']''' ] 22:04, 2 July 2013 (UTC)
*'''Support'''. The intentions are good with the VE and similar, but they get rolled out when the devs think they are ready from a technical point of view, not when the end users think they are ready from an editor's or reader's point of view. See also the ] that was launched following the change to notifications (which still have not been fixed). ] (]) 23:00, 2 July 2013 (UTC)
*'''Oppose''' per Steven and Analogdemon. Just sign up for ] and you'll know about everything. --''']]]''' 23:04, 2 July 2013 (UTC)
*:Ummm. I signed up for that. Not a word about this going live on that mailing list. In fact, one of the reasons I signed up for it was to know when there would be significant software changes, but most of them aren't discussed there. Nor are they discussed on Wikitech-L. And every time I complain, I'm told to sign up to another mailing list, or to post on another project. Communication is an ongoing problem that has never really been solved. ] (]) 01:24, 3 July 2013 (UTC)
*::{{Ping|Risker}} The link above is actually an on-wiki newsletter, not a mailing list (which I am also subscribed to). It's actually quite interesting, I've been able to follow ULS and Wikidata stuff. --''']]]''' 01:31, 3 July 2013 (UTC)
*:::BTW, on the latest Tech newletter, "VisualEditor will be enabled for all logged-in English Misplaced Pages users on July 1, and for all users on July 8." ] (] • ]) 01:35, 3 July 2013 (UTC)
*::::RE: Risker. For the record, viz editor was mentioned on wikitech-l - http://lists.wikimedia.org/pipermail/wikitech-l/2013-June/070141.html. However, I would not recommend wikitech-l as a good way to keep abreast of upcoming changes, since its a list for internal development, and the majority of its contents is not about what's going to change tomorrow, but how are we going to go about making feature X which might be done 6 months from now (Which could also be interesting to average users, but is a different use case). ] (]) 02:33, 3 July 2013 (UTC)
*:Agreed. Anyway, I don't understand the scope of this. Will they block changes to all Wikimedia sites because one wiki (enwiki) isn't happy? Or will this just affect deployments here? ] (] • ]) 01:18, 3 July 2013 (UTC)
*::Just here. But if a council got into the game of just blocking releases then it would have failed IMO. I would imagine the right to block a release as being a big stick (if that power was given to such a council, at all). Really, the focus of a group of this sort should be on ensuring that it never has to use the big stick (i.e. that releases go smoothly and are communicated well, from an end-user point of view). --] (]) 06:31, 3 July 2013 (UTC)
*:{{ping|Rschen}}, it's not merely about advance notice but the nature of notices. I first became aware of the plans for the VisualEditor from an announcement on the Admin Noticeboard on June 18 (). There, I was informed, an A/B trial was planned involving a percentage of new accounts. I asked a few simple questions (e.g. how long will the trial run, how will the data inform future decisions, etc.), which went unanswered. I was then informed that the trail would be postponed.
*:On the 24th of June another thread opened () informing me that A/B testing was back on. Again, the talk is about A/B testing on new accounts. Next thing, a week later, and apparently without notice, the VisualEditor is live for all logged-in accounts and planned to be rolled out for all other users a week later again. Gone is A/B testing, gone is a trial just on newbies, and the basic questions I asked on June 18th are still unanswered.
*:I appreciate that the WMF guys are enthusiastic (and possibly under pressure). A responsibility a user council could have is to ensure that no release of such major significance and proportions goes ahead backed by such poor communication. That doesn't necessarily mean blocking a release (which is a big stick) as much as simply ensuring that there is clarity and good communication ahead of releases and trials (which is what is needed most of all). --] (]) 06:17, 3 July 2013 (UTC)

*'''Support'''. This is an excellent idea. As a volunteer project, it seems only natural that we should have something like this. ] (]) 23:41, 2 July 2013 (UTC)
*'''Half-way Support'''. I definitely support the spirit of this proposal, although I suspect that similar goals could be accomplished with less bureaucracy if (1) interested users would watchlist wherever development is being discussed, and provide input there, and (2) the WMF folks would pay attention to those discussions and take community concerns seriously. Above, someone pointed out several WMF staff people who are highly responsive to community concerns. I agree that there are a bunch of staff people who are truly a pleasure to work with. Unfortunately, some other WMF staff seem to have an attitude that they know better than experienced editors what is good for us. The very fact that this discussion and others like it exist is evidence that the WMF needs to do better at working to support the editing community, rather than talking down to us. --] (]) 23:47, 2 July 2013 (UTC)
*'''Support.''' This is getting out of hand; the WMF has (especially recently) been levying changes upon the entire user interface and technology without bothering to make sure that we know or respect our existing user preferences or comments. About half the time, this works out nicely and everybody is happy. The other half, there can be incredible backlash (as is the case now with VE), including among practically every editor who actually opted into the alpha period before now, and the WMF doesn't bother to even try to fix it. They just tell us, "Well, we told you that it was going to happen in an unnoticeable box at the top of the watchlist you might rarely check, didn't listen to what anyone had to say about it, and deployed it when we said we would in the roadmap buried deep in a proposal discussion. If you don't like it, go away." This isn't really helpful to the community. &nbsp;&mdash;&nbsp;<span name="TortoiseWrath">]]</span> 01:00, 3 July 2013 (UTC)

*'''Oppose''' I applaud the intent, but when push comes to shove, "To have sign-off on software changes affecting end users before they are rolled out" is never going to hold if the Foundation and the community disagree on a question, and that's the core of the reason I'd support the proposal. As a result, I believe this particular exercise will, in the end, not actually solve the problem. Ask yourself: Would the user council have gotten ] off the ground? I doubt it. --]] 01:21, 3 July 2013 (UTC)
*Too grandiose a title. Call them "editor representatives for software developments". --] (]) 01:47, 3 July 2013 (UTC)
*:Other terms used for groups like combine "user advocacy" or "user representative" and "group", "committee", "panel", etc. --] (]) 06:20, 3 July 2013 (UTC)
*'''comment''': I don't think it would be a bad thing to require community consensus when enabling new features (read: extensions), particularly in cases where they are only being enabled on a single project. Honestly it seems like community consensus is sought when enabling features on projects that aren't enwikipedia, I'm not sure why enwikipedia should be different (To be clear: Only talking about changes aimed at a single community. Things that get enabled on all ] tend to be less controversial and it would be impractical to seek consensus for all of them). I don't see the benefit of a representational council, when things can just happen publicly anyways. ] (]) 02:22, 3 July 2013 (UTC)
*'''Comment'''—The en.WP community's lack of organisation in this area really shows us up against the German-speakers, who've had the benefit of a well-run noticeboard for years. I applaud this proposal. ''But'', can one of its mission statements be to foster greater community awareness of the developers' tasks and challenges? It's a two-way thing. ] ] 02:34, 3 July 2013 (UTC)
*:I entirely agree. It is a two-way thing. It's about listening as well as being heard. Communication goes both ways. Involving user more closely in development, I would hope, would help demystify some aspects of it. --] (]) 08:41, 3 July 2013 (UTC)
*'''Support in principle'''. The Foundation has been well aware for several years of my concerns, most recently again at ] where ] has provided some valuable background, but still does not address ''how'' the WMF arrives at its priorities for software development. IHMO, the Foundation creates new tools in good faith, but does not sufficiently examine whether or not they are a genuine priority for the ''community''. I think such a council or something on those lines would be a good idea, especially so that the WMF does not allocate funds and developer time on gadgets, and focuses more on the bigger issues such as, just to cite two examples, new page quality control, and better information for new users. Most of us could probably live for a while longer without article feedback tools, WikiLove, thank buttons, visual editors, liquid threads, and notifications systems (actually quite good) that replace the orange banner. ] was a good example of how the community has brought pressure to bear on the Foundation, but there is no regulatory body to find out who is right and who is wrong. The overall impression left from ACTRIAL was that the Foundation owns the servers, and if they don't like a community consensus, they just won't implement the request, even for just a trial whose objective was to clearly measure the effect of a community suggestion that had been agreed by no small participation and a healthy consensus. Another example is the Page Curation tool set - a truly brilliant piece of software (in the right hands), and developed with a lot of editor participation and well coordinated by a Foundation contractor, but the community didn't directly ask for it, and it didn't address the core issues with new page patrolling that still persist to this day. ] (]) 03:37, 3 July 2013 (UTC)
* '''Support''' - There clearly needs to be a countervailing force to the cavalier and uncritical attitude of the Foundation about change. ] (]) 04:37, 3 July 2013 (UTC)
* '''Oppose'''. This idea seems to have arisen only because the proposer ignored ''years'' of very prominent and conspicuous requests for comment, discussions, and site notifications on Misplaced Pages and other Wikimedia websites, and, if they have a life outside Misplaced Pages, possibly also a good deal of third-party coverage in magazines, blogs, and social media. "Visual Editor is coming; your input is solicited!" has been plastered ''all over the place'' for a very long time now, and it looks like the WMF has been duly diligent in monitoring and collecting feedback from the ensuing discussions. It's not their fault if some people consistently failed to participate despite a plethora of ''very'' well-advertised opportunities. I'm all for officially designating one or more venues where the WMF ''must'' give notice and monitor discussion of technical and UI changes (which of course would not preclude further advertisement and discussion of such changes elsewhere) but given how admirably the latest change was publicized I see no need for this process to be overseen by an independent body. —] (]) 07:33, 3 July 2013 (UTC)
*:People are busy, and separate wikis currently require separate watchlists. So people may try to join discussions on the smaller wikis that WMF, staff, and developers favor, but soon stop regularly checking the watchlists for those smaller wikis. See my long comment higher up where I explain this in detail, and propose various long, medium, and short-term solutions. A user council changes our participation from direct democracy to indirect, representative democracy. It is an improvement on the current anarchy. --] (]) 08:24, 3 July 2013 (UTC)
*:Blaming the intended receiver of communication for not receiving the message (no matter whose fault it is) doesn't resolve the matter. There should not have been any major surprises around this (or any other) roll out. That break down in communication, irrespective of who is to blame, needs to be addressed. If the solution is that users need to participate more, then that is what this proposal is about. --] (]) 08:47, 3 July 2013 (UTC)
*::That claim doesn't match what people are writing above: they're going "Why wasn't I consulted?!" and flatly ignoring the stupendous efforts to do so. As you are - ] (]) 09:14, 3 July 2013 (UTC)
::::David Gerard. It is you who are ignoring the various replies to you. And inviting people to discussions on small wikis with separate watchlists is not a stupendous effort. It is an inadequate effort which has been pointed out numerous times by many people over the years concerning communication between the WMF board/staff/developers and Misplaced Pages editors. --] (]) 10:48, 3 July 2013 (UTC)

*'''Oppose''' Don't fix what ain't broken. I feel, Misplaced Pages has some kind of "Just complain about anything & everything" culture. We have more that enough onsite & offsite forums for doing that. The VE and WMF guys have done a wonderful job creating and communicating their stuff, and if some guys failed to notice, it must be due to their lack of curiosity. A council of this sort would only produce endless, pointless hairsplitting and only create hurdles in progressive work. Cheers.] (]) 10:58, 3 July 2013 (UTC)
::"ain't broken"? You are kidding. See ]. Onsite forums with substantive discussion only started relatively recently on English Misplaced Pages concerning the visual editor. And substantive discussion connected with an alpha/beta version of VE working with articles on English Misplaced Pages is what counts. It is better to have the hairsplitting earlier in the design process before major, costly mistakes are made. A user council might have helped in that area, and can help now too. We need dedicated users in it for the longterm. That is an elected user council. Average users can only check small-wiki watchlists for a few months at the most before they tire of having to check multiple watchlists. A user council is in it longterm. --] (]) 11:16, 3 July 2013 (UTC)

:::Of course it "ain't broken". It works. It has bugs, and this is only to be expected for any new software. I trust the VE team can and will fix them. Even Microsoft created Windows OS systems always come with bugs and they keep fixing them all the time. Nothing unusual or unexpected there. The VE is going to revolutionize our falling ed numbers and we should all support it. In the meantime, anyone who is unsatisfied can easily use the old edit interface. Since the old interface is readily available, I see no possibly of any major damage. I still do not see any valid reason for hairsplitting or usercouncil. Users who want to help out with testing or discussions can also do so without being elected to do so. They can self elect to do so.] (]) 13:31, 3 July 2013 (UTC)
::::Something can be barely usable, ''and'' broken. It's funny that you bring up Microsoft and its operating systems. --] (]) 21:12, 3 July 2013 (UTC)
* '''Not as proposed''' A "user council" would probably be a nice idea, but I'm skeptical it would actually change the sort of things being complained about here. It would be good to get more editor input into the development process (and hopefully the new WMF-hired community liaisons will be able to help with this too). But "sign-off on software changes", if that means "veto power" as some of the above supports are implying, no. I remember too well the reactionary site-wide CSS change that still prevents new users from having watchlist bolding until they discover gadgets, and the complaints about the diff color scheme change that thankfully resulted in a "old color scheme" gadget rather than an "override it for everyone because I don't like it!" mess.<br>As for the problems most people here seem to be complaining of, I doubt a user council would have much effect. The people who missed all the various notices that VE was coming will still miss all the notices. And the people who don't like something will still complain that their input somehow wasn't considered, no matter that this user council exists. As for the council itself, it could go both ways: it could be a useful resource to get more community-focused feedback in development, or it could be populated by "Oh noes! Change!" reactionaries who would obstruct rather than help guide development. ]] 12:30, 3 July 2013 (UTC)
::Yes, this is problematic: "To have sign-off on software changes affecting end users before they are rolled out." That should be changed to "ongoing consultation". The real sign-off occurs when something is deployed. If enough people dislike something they will edit less. They have effectively not signed on. WMF then either pays attention, or there is a further slide in the total number of monthly edits on Misplaced Pages. WMF can then pay attention and fix the problem. Or the WMF gets developers to develop gadgets and preferences to ameliorate the problem for some people. A user council might prevent some problems from occurring at all. --] (]) 21:26, 3 July 2013 (UTC)
:::"''If enough people dislike something they will edit less.''"<sup>]</sup>
:::I've not seen any research indicating that this is likely. I've seen evidence that contradicts this claim when "dislike" is measured within the first few weeks after a major change, rather than after the established users have had enough time to explore the new system: it's normal for power users to dislike change to "their" website, no matter what the website is or what the change is. ] (]) 11:34, 4 July 2013 (UTC)
]
::::It only took a few days for my prediction to be proven right concerning the hidden "edit source" links on sections. It has already been reverted due to the barrage of complaints about it. It is not a matter of just getting used to something in many cases. If people continue to dislike something enough, or if it continues to hinder their editing enough, or if it continues to slow them down enough, then many of those people will edit less. Since Misplaced Pages is a volunteer effort this is more true than for employees at a company using software. They have to tolerate the software if that is what their boss wants. According to the chart on the right there are twice as many edits by registered users as anonymous users. It would be a bad idea to believe that we can afford to slow down editing by registered users in the hope that providing any visual editor (no matter how buggy) will cause the number of anonymous IP editors to increase enough to create a net increase in the number of monthly edits. See ] The WMF needs to think more clearly about the net effects of changes to editing. They would be able to do that better if there were a user council. --] (]) 01:42, 5 July 2013 (UTC)
::::::As I said above, the edit section links will be restored on Monday.
::::::You seem to believe that sheer number of edits is proof that registered users write the articles. Have you read any of the research on that point, like ? Registered editors revert a lot, and they do a lot of gmoning and copyediting, but IPs are responsible for providing a lot of the content. ] (]) 03:42, 5 July 2013 (UTC)
* '''Oppose'''. I think that more a cooperative relationship between the WMF and its wikis is a good idea, but I would rather have it done using the existing community input processes (e.g. RfC) rather than add bureaucracy. <span style="font-family: Georgia, Garamond, serif;">]&nbsp;]</span> 15:11, 3 July 2013 (UTC)
* '''Reluctant support'''. Things like that should be handled informally, with developers (and/or related non-developers) doing proper ] and collaborating with the users (the Community). After all, that's just how ] is supposed to work. Then the final decision before deployment would be a mere formality that would not need additional bureaucracy. But, unfortunately, instead of that we get complaints that "''The proper time for discussion is when changes are being proposed or written, not before they're deployed.''". Sorry, but that is exactly when discussion is vital. Since someone mentioned buggy pre-Service Pack versions of Windows - well, the whole point is that then it's the ''user'' (not Microsoft) that makes the decision if he wants to install the new version or not. (It is only natural that this decision should be done when we know what exactly has been created - not until development is finished.) How comes that it is the "supplier" that makes this decision in our case? Something related to ]..? (But, I hope, the pay of developers does not get postponed until deployments..?) So, if that is the way in which the users (in this case - the Community) can make decision to deploy something or to refuse to deploy it, that probably should be done... Though still, informal approach with developers (and/or related non-developers) actively looking for friendly but harsh criticism and engaging it in good faith would be far more preferable... --] (]) 18:48, 3 July 2013 (UTC)
* Seems rather useless. The people who want to be involved in these things find out and get involved. Others just don't bother to get involved until deployment. That will not change. And what the council "likes" in your user interface and what others like will still be two (or more likely many) different things. Then you will get conversations, like the council trying to explain to others all the great work they did, and others arguing back that they did terrible work and should resign, etc. etc. and on and on. ] (]) 19:46, 3 July 2013 (UTC)
* '''Oppose'''. Some fancy scheme to elevate representatives distracts from the main point that WMF developers need a more visible central announcement board that users can easily check to know about everything coming down the pipe whatever it is. If they do their job to notify a council they can do their job to notify a central announcement board, and conversely... (To be clear, I think that users ''as a whole'' should enjoy the "rights" of the proposed council above) ] (]) 22:27, 3 July 2013 (UTC)
::The WMF and developers have been "announcing" the visual editor for years. Notices and announcements are not the problem. Notifying a council is not enough either. What is needed are easy ways of substantive engagement. That did not occur until recently. --] (]) 23:10, 3 July 2013 (UTC)
:::This is fatuous. We have just conclusively demonstrated that there exists no place to notify that no editor will claim they did not see and that it's an outrage - ] (]) 23:13, 3 July 2013 (UTC)
::::Why the frequent drama in your comments, O David Gerard? Notifying is not the problem in my opinion. We need a longterm place for easy discussion, and give-and-take, at an earlier stage of a specific software project. "Easy" means via an English Misplaced Pages watchlist, or a ]. "Easy" means not using ] for discussion. "Easy" means a separate discussion page for each project. --] (]) 23:35, 3 July 2013 (UTC)
:::: Sorry, but there is a simple process to inform and "survey" a significant part of users when you ''really'' need it. It is described in "]". Make a "prototype" - perhaps a "release candidate". Enable it for, let's say, a day (with announcements before that). Then roll it back and ask if the users like that change. The problem with current announcements is that, well, there is an impression that it does not really matter if we will read them. Let's say, everyone will read an announcement "Change C will happen on day D.". What difference does it make, if there is a perception that the change (perhaps with minor modifications) will happen no matter what..? After all, it is really just an announcement, not a request for harsh criticism. For example, ] says: "''VisualEditor will be enabled for all logged-in English Misplaced Pages users on July 1, and for all users on July 8.''". Well, if it ''will'' happen and the user can do nothing about it, why should he care before it gets enabled..? For that matter... When ''is'' the last moment when opposition of users can actually ''stop'' major UI changes..? --] (]) 00:33, 4 July 2013 (UTC)
::::: My emphasis above was meant to be on the ''visible''. It may be fatuous, but I'm not sure if I've even heard of ] before, though it certainly does look like a good effort. I don't see it linked anywhere obvious at the top of the various village pump pages or the community portal. ] (]) 01:16, 4 July 2013 (UTC)
*'''Support'''. Something seems to have broken down in the relationship between editors and the Foundation, and this might help to get it back on track. ] <small><sup>]</sup></small> 00:04, 4 July 2013 (UTC)
*'''Somewhat support'''. I think there could be real value in creating a more formal consultation process between the WMF and the community to discuss technical issues, especially those surrounding new features. It could help to set priorities and communicate community concerns. However, I think anyone who imagines that the "User Council" (or whatever one wants to call it) could have a veto over the WMF is pretty much dreaming. ] (]) 01:22, 4 July 2013 (UTC)
*I '''support''' the establishment of a group of volunteers to work with software developers on software changes. I do not necessarily support an elected body of representatives, nor do I think it realistic to propose that our representatives have any veto power over the changes.—] <small>]/]</small> 18:54, 4 July 2013 (UTC)
*'''Oppose''' in part, primarily the idea of giving any sort of veto power or a consensus model for technical enhancements. Doing it that way is the surest way to ensure nothing ever changes or improves. Better to come up with ideas that improve visibility of the notices and discussions that do go out, and allow for better consultation with editors. ]] 01:49, 5 July 2013 (UTC)
*'''Support''' if necessary, There are two reasons why we must do something. ''first'', the WMF is responsible for the development of the software, but on any particular WP, the community of editors there is responsible for how to use it. There will be occasions when the wmf will judge something the community wants as not practical, or where the WMF finds that maintaining a reasonable degree of consistency mandates something the community does not really like, and these will have to be resolved by discussion. (As I see it, the use of notifications was one where the decision should have been left to the community entirely. On the other hand, a visual editor should be a general feature of editing across all WPedias, though practical considerations may require slightly different implementations.) If the developers are of the opinion that the community is being unduly resist to reasonable modernization, the proper way is to convince us, just as any other group or individual who wants to introduce changes. I do not think the wmf accepts this principle, and I think we in the community would be right in doing whatever we can to convince them to accept it,a the only basis for collaboration. ''second'', the WMF has shown itself not very competent at communication to the community, and probably the community is not much better. The WMF tends to think meta and other discussion media under its control are sufficient, and that notices will do for implied consent. Neither is realistic, and the response to their trials indicates it. None of us can be everywhere, and the place to discuss the English WP is the English WP, which is where the people working on it primarily work. . The overall development of MediaWiki is another matter, but the implementation on enWP must be discussed on enWP. The community here, for its part, tends to solve problems by multiplying the number of forums, delaying decisions, and letting steadfast opposition prevail over rationality. ''therefore'' once it is accepted that these matters must be discussed, we need a <u>single</u> centralized place on enWP to do so, where things will be discussed and rfcs conducted according to our accustomed manner. But this will only work if the WMF accepts the first part, that the community will be the responsible body for deciding, just as they are for content and working procedures. I doubt they will, and in that case, the community needs some countervailing power. If so, a council of this sort is the best solution. Since the WMF by and large finds its manner of work requires it to speak in a single voice according to its own consensus, the community will need some way also., and a council of this sort can be an effect intermediary, if it is necessary to see this as different groups vying for power. ''']''' (]) 04:41, 5 July 2013 (UTC)

=== ] ===

I believe the taking the first step if you want to see change, so I'm going to be bold.

I think there's consensus above that something be done, but I don't think there is consensus at this time for something as formal as what I proposed. In all, I think a consensus position can be summed up by ]'s comment at 02:34:

{{quote|The en.WP community's lack of organisation in this area really shows us up against the German-speakers, who've had the benefit of a well-run noticeboard for years. I applaud this proposal. ''But'', can one of its mission statements be to foster greater community awareness of the developers' tasks and challenges? It's a two-way thing.}}

I've created a project page at ]. The purpose of that page, I hope, will be to act as meeting point between EN wiki users, developers and the Foundation. I believe there is consensus above for a step like that.

I'm deliberately not creating a WikiProject because I don't believe this should be a matter of special interest to a few users. The tools we use is something that affects the project as a whole. The page does not create a committee, or council, or cabal of any kind. However, the phrase "user advocacy" is often used in describing the kinds of committees that the proposal above is based upon.

I hope that it will facilitate discussion, knowledge sharing and exchange of ideas. I hope too that it will act as a venue for those advocating greater user engagement to engage themselves in that area and spread the word. I hope too it will draw in the imagination, expertise and knowledge of developers and Foundation staff in support of their efforts.

The page is deliberately in a brain-storming state. I've just created a few headers for now. So, please, everyone is welcome and invited to contribute and participate. --] (]) 23:13, 3 July 2013 (UTC)
:I've written an '''extensive''' reply with notes and pointers and thoughts, but I didn't want to overwhelm your description here, so I've placed it at ]. Hopefully that will help both this discussion, and that advocacy page, move forward. –] (]) 05:35, 4 July 2013 (UTC)

== Modern Tables ==

Hi,

I wold like to suggest you to implement the following. For every table in wikipedia, can you keep the first Row on top, so that one does not need to go up for checking what each column stands for. (Just like in Google spreadsheet )..

Cheers

Latest revision as of 15:46, 19 January 2025

"WP:PROPOSE" redirects here. For proposing article deletion, see Misplaced Pages:Proposed deletion and Misplaced Pages:Deletion requests.Discussion page for new proposals
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216
Centralized discussion For a listing of ongoing discussions, see the dashboard.

Transclusion of peer reviews to article talk pages

Hello,

First time posting here.

I would like to propose that peer reviews be automatically transcluded to talk pages in the same way as GAN reviews. This would make them more visible to more editors and better preserve their contents in the article/talk history. They often take a considerable amount of time and effort to complete, and the little note near the top of the talk page is very easy to overlook.

This also might (but only might!) raise awareness of the project and lead to more editors making use of this volunteer resource.

I posted this suggestion on the project talk page yesterday, but I have since realized it has less than 30 followers and gets an average of 0 views per day.

Thanks for your consideration, Patrick (talk) 23:07, 2 January 2025 (UTC)

I don't see any downsides here. voorts (talk/contributions) 01:55, 4 January 2025 (UTC)
Support; I agree with Voorts. Noting for transparency that I was neutrally notified of this discussion by Patrick Welsh. —TechnoSquirrel69 (sigh) 21:04, 6 January 2025 (UTC)
So far this proposal has only support, both here and at the Peer review talk. Absent objections, is there a place we can request assistance with implementation? I have no idea how to do this. Thanks! --Patrick (talk) 17:23, 13 January 2025 (UTC)
It might be useful to have a bot transclude the reviews automatically like ChristieBot does for GAN reviews. AnomieBOT already does some maintenance tasks for PR so, Anomie, would this task be a doable addition to its responsibilities? Apart from that, I don't think any other changes need to be made except to selectively hide or display elements on the review pages with <noinclude>...</noinclude> or <includeonly>...</includeonly> tags. —TechnoSquirrel69 (sigh) 17:28, 13 January 2025 (UTC)
Since ChristieBot already does the exact same thing for GAN reviews, it might be easier for Mike Christie to do the same for peer reviews than for me to write AnomieBOT code to do the same thing. If he doesn't want to, then I'll take a look. Anomie 22:41, 13 January 2025 (UTC)
I don't have any objection in principle, but I don't think it's anything I could get to soon -- I think it would be months at least. I have a list of things I'd like to do with ChristieBot that I'm already not getting to. Mike Christie (talk - contribs - library) 22:54, 13 January 2025 (UTC)
I took a look and posted some questions at Misplaced Pages talk:Peer review. Anomie 16:14, 18 January 2025 (UTC)
  • Support, I've submitted a couple of articles for peer review and wondered when I first did it why it wasn't done on a sub-page of article's talks the same way GAN is. TarnishedPath 02:24, 16 January 2025 (UTC)

Support. This would be very, very helpful for drafts, so discussions can be made in the Talk pages to explain a problem with a draft in more detail rather than only showing the generic reason boxes. Hinothi1 (talk) 12:56, 18 January 2025 (UTC)

Sections

I noticed that some sections are written like: == xxxxx == and some are written like ==xxxxx==. Some have gaps and some do not. Won't it be better if it was standardized? I prefer the one without gaps because it should save space. TrueMoriarty (talk) 06:47, 10 January 2025 (UTC)

Such a proposal is infeasible, as we have over 6 million articles in a mix of both styles. Although a script would probably handle 90% of them there'd be heaps of edge cases among the remaining ones to consider. Also that's assuming that editors would actually agree on a single style; given our track record with such things I think that's unlikely.  novov talk edits 09:03, 10 January 2025 (UTC)
Yes, or shall we have an inconclusive discussion that lasts for months and involves hundreds of editors? Phil Bridger (talk) 09:14, 10 January 2025 (UTC)
What else is Misplaced Pages for?--3family6 (Talk to me | See what I have done) 14:25, 10 January 2025 (UTC)
That means only 700,000 articles would be left. New editors can fix the others as a beginner's task.
TrueMoriarty (talk) 12:20, 10 January 2025 (UTC)
So Misplaced Pages adopts a novitiate/apprenticeship system? I like the idea of that, so long as it's not mandated at all but voluntary. I don't think this particular task would be of any help or use, though. It really doesn't matter.--3family6 (Talk to me | See what I have done) 14:25, 10 January 2025 (UTC)
Istruggletothinkofabiggerwasteoftime,thoughofcourseweshouldalldoourparttosavespace.– Joe (talk) 09:15, 10 January 2025 (UTC)
Joe, where should I send the the 0.00000004 cents that it would cost for you to use spaces? Phil Bridger (talk) 09:21, 10 January 2025 (UTC)
This would fall under WP:COSMETICEDIT, because the spaces (or lack thereof) has no change in visual output. It's not worth our time to fix something that has no real effect on pages, flooding watchlists and annoying people in the process. Also, ironically, the heading for this thread is written with spaces. —k6ka 🍁 (Talk · Contributions) 12:52, 10 January 2025 (UTC)
That is likely because as far as I've seen most of the software and scripts add spaces. CMD (talk) 13:59, 10 January 2025 (UTC)
It's potentially worth making a call on what's considered ultimate best practice, just so that the software and scripts can be aligned. But agreed that this is far too cosmetic to be worth changing, even within something like the GENFIX set. Sdkb23:03, 10 January 2025 (UTC)

Good Article visibility

I think it would be a good idea to workshop a better way to show off our Good, A-class and Featured articles (or even B-class too), and especially in the mobile version, where there is nothing. At present, GA icons appear on the web browser, but this is it. I think we could and should be doing more. Misplaced Pages is an expansive project where page quality varies considerably, but most casual readers who do not venture onto talk pages will likely not even be aware of the granular class-based grading system. The only visible and meaningful distinction for many readers, especially mobile users, will be those articles with maintenance and cleanup tags, and those without. So we prominently and visibly flag our worst content, but do little to distinguish between our best content and more middling content. This seems like a missed opportunity, and poor publicity for the project. Many readers come to the project and can go away with bad impressions about Misplaced Pages if they encounter bad or biased content, or if they read something bad about the project, but we are doing less than we could to flag the good. If a reader frequents 9 C-class articles and one Good Article, they may simply go away without even noticing the better content, and conclude that Misplaced Pages is low quality and rudimentary. By better highlighting our articles that have reached a certain standard, we would actually better raise awareness about A) the work that still needs to be done, and B) the end results of a collaborative editing process. It could even potentially encourage readers who become aware of this distinction to become editors themselves and work on pages that do not carry this distinction when they see them. In this age of AI-augmented misinformation and short-attention spans, better flagging our best content could yield benefits, with little downside. It could also reinject life and vitality into the Good Article process by giving the status more tangible front-end visibility and impact, rather than largely back-end functionality. Maybe this has been suggested before. Maybe I'm barking up the wrong tree. But thoughts? Iskandar323 (talk) 15:09, 11 January 2025 (UTC)

With the big caveat that I'm very new to the GA system in general and also do not know how much technical labor this would require, this seems like a straightforwardly helpful suggestion. The green + sign on mobile (and/or some additional element) would be a genuinely positive addition to the experience for users - I think a textual element might be better so the average reader understands what the + sign means, but as it stands you're absolutely right, quality is basically impossible to ascertain on mobile for non-experts, even for articles with GA status that would have a status icon on desktop. 19h00s (talk) 16:43, 11 January 2025 (UTC)
While GA articles have been approved by at least one reviewer, there is no system of quality control for B class articles, and no system to prevent an editor from rating an article they favor as B class in order to promote or advertise it. A class articles are rare, as Military History is the only project I know of that uses that rating. Donald Albury 17:16, 11 January 2025 (UTC)
I totally agree we should be doing more. There are userscript that change links to different colours based on quality (the one I have set up shows gold links as featured, green as GA, etc).
If you aren't logged in and on mobile, you'd have no idea an article has had a review. Lee Vilenski 20:15, 11 January 2025 (UTC)
A discussion was held on this about two years ago and there was consensus to do something. See Misplaced Pages talk:Good Article proposal drive 2023#Proposal 21: Make GA status more prominent in mainspace and Misplaced Pages:Good Article proposal drive 2023/Feedback#Proposal 21: Make GA status more prominent in mainspace. Thebiguglyalien (talk) 04:20, 12 January 2025 (UTC)
@Thebiguglyalien: Is that feedback discussion alive, dead, or just lingering in half-life? It's not obviously archived, but has the whole page been mothballed? So basically, there's community consensus to do something, but the implementation is now the sticking point. Iskandar323 (talk) 04:57, 12 January 2025 (UTC)
Basically, most of the progress made is listed on that feedback page and the project has moved on from it. There were a few options, like the visibility one, where it was agreed upon and then didn't really go anywhere. So there are some ideas there, but we'd basically need to start fresh in terms of implementation. Thebiguglyalien (talk) 05:16, 12 January 2025 (UTC)
  • Tracked in Phabricator
    Task T75299
    You're barking up exactly the right tree, Iskandar323. Regarding showing the icons on mobile, that's a technical issue, which is tracked at phab:T75299. I highlighted it to MMiller (WMF) when I last saw him at WCNA, but there's ultimately only so much we can push it.Regarding desktop, we also know the solution there: Move the GA/FA topicons directly next to the article name, as was proposed in 2021. The barrier there is more achieving consensus — my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean. The best counterargument to that would be some basic user research, and while ideally that would come from the WMF, anyone could try it themselves by showing a bunch of non-Wikipedian friends GAs/FAs and asking if they notice the symbols and know what they mean. Once we have that, the next step would be running another RfC that'd hopefully have a better chance of passing. Sdkb06:50, 12 January 2025 (UTC)
    It's great that I've got the right tree, since I think that's a village pump first for me. It seems that the proposer of that original 2021 discussion already did some basic research. Intuitively, it also seems just obvious that an icon tucked away in the corner, often alongside the padlocks indicating permission restrictions, is not a high visibility location. Another good piece of final feedback in the GA project discussion mentioned earlier up this thread by TBUA is that the tooltip could also been improved, and say something more substantial and explanatory than simply "this is a good article". On the subject of the mobile version and the level of priority we should be assigning to it, we already know that per WP:MOBILE, 65% of users access the platform via mobile, which assuming a roughly even spread of editors and non-editors, implies that 2/3 of contemporary casual visitors to the site likely have no idea about the page rating system. Iskandar323 (talk) 07:31, 12 January 2025 (UTC)
    my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean This is not my reading of the discussion. To me it looks as though a major concern among opposers is that making GA/FA status more prominent for readers is likely to mislead them, either by making them think that GAs/FAs are uniformly high-quality even for those which were assessed many years ago when our standards were lower and have neither been maintained or reassessed, or by making them more doubtful about the quality of articles which have never gone through the GA/FA process but are nonetheless high quality. By my count at least ten of the 15 oppose !voters cite this reason either explicitly or "per X" where X is someone else who had made this point. Caeciliusinhorto (talk) 16:18, 12 January 2025 (UTC)
    I've also encountered a fair few instances of older, lower standard GA articles. But I also think greater visibility (effectively also transparency) could also benefit in that area as well. If GA status is more prominent, it provides greater cause to review and reassess older GAs for possible quality issues. Also, most of the worst GAs I have seen have come from around 2007, so it seems like one sensible solution would be for GA status to come with a sunset clause whereby a GA review is automatically required after a decade. Maybe I'm getting a little sidetracked there, but this sort of concern is also exactly what I mean by greater visibility potentially reinjecting life and vitality into the process. Iskandar323 (talk) 17:15, 12 January 2025 (UTC)
    I think you're right about that being the most major source of opposition, but most major is different than determining — I don't think those !voters will be open to persuasion unless the quality of GAs/FAs improves (which, to be fair, it definitely has somewhat since 2021). But the "they already know" !voters might be more persuadable swing !voters, and it would have passed with their support. Sdkb19:02, 12 January 2025 (UTC)
    I think that's a fair reading of the discussion. But, I suppose the best way to be more transparent is to tell a user that it has been rated GA after a peer review, but that doesn't mean that the article is perfect... Which is what GA (and FAs) also say. Lee Vilenski 19:54, 12 January 2025 (UTC)
  • My radical proposal would be to get rid of the whole WP:GA system (which always came across to me as a watered-down version of WP:FA). Some1 (talk) 16:31, 12 January 2025 (UTC)
    Why? TompaDompa (talk) 16:38, 12 January 2025 (UTC)
    It is a watered-down process from an FA, but it is also the first rung on the ladder for some form of peer-review and a basic indicator of quality. Not every subject has the quality sources, let alone a volunteer dedicated enough, to take it straight from B-class to Featured Article. Iskandar323 (talk) 17:17, 12 January 2025 (UTC)
    That's literally the point of it. Lee Vilenski 19:52, 12 January 2025 (UTC)

RSS feed for Portal:Current events

An admin suggested that I make this a proposal here so here it is:

Unlike other Main page sections such as On this day (RSS) or Featured article (RSS), daily entries from Portal:Current events do not yet have an RSS feed. This has been requested several times on the Portal's talk page over the years, but never gained traction: 2006, 2010, 2013, 2020.

Adding a feed via MediaWiki's FeaturedFeeds extension should be relatively straightforward (for an admin with access to extension settings):

  1. Create the feed page under MediaWiki:Ffeed-currentevents-page ("currentevents" would be the feed's name). Requires admin access.
  2. Add the following as the page's source: Portal:Current events/{{#time:Y F j|-1 day}} (This should set yesterday's current events to today's feed entry.)
  3. Configure the new feed in Misplaced Pages's FeaturedFeeds settings (adapting from extsting settings from other existing feeds like On this day). I'm not sure exactly what access is required here, or whether this can only be done by a WMF staff member.

I may be biased, but I don't see any good reason not to provide Current events as an RSS feed: it simply gives users another way to access this fantastic content using their favorite feed reader. Thoughts? Robinmetral (talk) 08:09, 12 January 2025 (UTC)

Makes a lot of sense to me. Feels like it should be doable but phab:T160561 gives me pause. I would drop a link here at WP:VPT to get some technical eyes on this that can make sense of exactly how to implement. Trialpears (talk) 01:56, 14 January 2025 (UTC)
Thank you for the ref to phab:T160561! I agree that it might make more sense to move this over to WP:VPT by now, since there doesn't seem to be anyone opposing this in principle. I just reached out on the ticket thread to see if anyone involved in this at the time still remembers what happened. If there doesn't seem to be any technical blockers, I'll move this proposal to WPT to hopefully find someone who can implement it. Robinmetral (talk) 04:03, 14 January 2025 (UTC)

Update image of Template:Template category

Proposal to update image used in Template:Template category:

Currently it looks like this:

The pages listed in this category are templates. This page is part of Misplaced Pages's administration and not part of the encyclopedia. Further template category notes This category contains pages in the template namespace. It should not be used to categorize articles or pages in other namespaces.
To add a template to this category:
  • If the template has a separate documentation page (usually called "Template:template name/doc"), add
  •  ]
  • to the <includeonly> section at the bottom of that page. Otherwise, add
  •  <noinclude>]</noinclude>
  • to the end of the template code, making sure it starts on the same line as the code's last character.

I propose we change the image to:

The pages listed in this category are templates. This page is part of Misplaced Pages's administration and not part of the encyclopedia. Further template category notes This category contains pages in the template namespace. It should not be used to categorize articles or pages in other namespaces.
To add a template to this category:
  • If the template has a separate documentation page (usually called "Template:template name/doc"), add
  •  ]
  • to the <includeonly> section at the bottom of that page. Otherwise, add
  •  <noinclude>]</noinclude>
  • to the end of the template code, making sure it starts on the same line as the code's last character.

-- waddie96 ★ (talk) 22:26, 13 January 2025 (UTC)

This is too big a venue for this discussion. In any case, I don't think it's an improvement — better to keep it simple. Sdkb03:06, 14 January 2025 (UTC)

Replace abbreviated forms of Template:Use mdy dates with full name

I propose that most transclusions of redirects to {{Use mdy dates}} and {{Use dmy dates}} be replaced by bots with the full template name.

Part of the purpose of {{Use mdy dates}} is to indicate to editors what they should do. Thus, readability is important. I propose all of these redirects be replaced with their target which is:

  1. More easily understood even the first time you see it.
  2. Standardized, and thus easier to quickly scan and read.

The specific existing redirects that I suggest replacing are:

  1. I would probably leave alone the redirects that differ only in case, namely {{Use MDY dates}} and {{Use DMY dates}}, which are sufficiently readable for my concerns.

Daask (talk) 20:30, 18 January 2025 (UTC)

In principle I like this idea (noting my suggestion to bring it here). My only concern would be about watchlist spam, given that, while this may not technically be a cosmetic edit, it's only a hair above one. But there's only a few thousand transclusions of these redirects, so if the bot goes at a rate of, say, one per minute, it'd be done in a few days. -- Tamzin (they|xe|🤷) 21:09, 18 January 2025 (UTC)
It looks like most or all of these are already listed at Misplaced Pages:AutoWikiBrowser/Template redirects, so whenever anyone edits an article with AWB, they'll already be replaced. No strong view about doing so preemptively.
However, if our goal is to ensure that these templates are actually meaningfully used, then we have some bigger fish to fry. First of all, even the written-out form isn't sufficiently readable/noticeable — many newcomers may not know what it means, and many experienced editors may miss it if they aren't happening to look at the top of the article. Ideally, we would either offer to correct the date format if anyone enters the incorrect one via mw:Edit check (task) or we'd include it in an editnotice of some sort.
Second of all, roughly 2/3 of all articles still don't have a date tag, so we need to figure out better strategies for tagging en masse. There are surely some definable groups of articles that are best suited to a particular format (e.g. all U.S. municipality articles I'd think would want to use MDY) that we could agree on and then bulk tag. Sdkb21:50, 18 January 2025 (UTC)
It's definitely a cosmetic edit, in that it only changes the wikitext without changing anything readers see. But consensus can decide that any particular cosmetic edit should be done by bots. As proposed, there are currently 2089 transclusions of these redirects, 1983 in mainspace. Anomie 14:21, 19 January 2025 (UTC)
Categories:
Misplaced Pages:Village pump (proposals): Difference between revisions Add topic