Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 80.177.125.188 (talk) at 10:56, 18 September 2014 (→Personal Names: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


Should the MediaWiki software be modified to include an option for specialized (such as blacklist / whitelist) blocks?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

There is some support for the idea, but there's no clear consensus, not least because participants are having to imagine how this feature would work and several raise concerns as to whether the work needed to create such a feature would outweigh its potential benefits. If the supporters feel this proposal is worth pursuing, I suggest discussion with developers might be the best way to progress the idea. HJ Mitchell | Penny for your thoughts? 19:49, 6 September 2014 (UTC)[reply]

Would a system of specialized blocks be helpful? Dustin (talk) 02:41, 24 July 2014 (UTC)[reply]

Note: This was partly discussed beforehand at Wikipedia:Village pump (idea lab)/Archive 14#Specialized blocks, and I have decided to bring my proposal here. Please read that page first, though. I have started this as an RfC because I consider it to be of significant importance.

(The following has been copied from the idea lab)

The following is a proposed change to the MediaWiki software.

I don't know if something like this has already been proposed, but a brief search on my part didn't turn up something like this, so I will put forth my ideas. Here is my possible proposal, but I am going to give it here first just so we can discuss it and refine the idea beforehand. I would propose that we modify the MediaWiki software as to allow for specialized blocks. Blocks currently only have two options: a block on editing all pages except for a user's own talk page, or a block on all pages, including the user's own talk page. In my new "specialized" block system, there would be many more options.

  1. An administrator could block a user for disruption from editing either a specific, individual page, or the block could apply to a selection of pages. In cases where a user cannot be trusted to follow a topic-ban or does not feel that he/she can follow his/her restrictions, then an administrator could simply block that user from editing a list of manually selected pages which are "at risk".
  2. An administrator could block a user from editing all pages (minus manually chosen exceptions) that have a certain prefix. For example, if one user was being overly disruptive on SPI pages (and I am not talking about vandalism), then an administrator could block that user from editing all pages starting with "Wikipedia:Sockpuppet investigations/".
  3. If there were situations where it was desired that an editor requesting an unblock edit one page apart from his/her talk page similar to this recent instance (but where the user could not be yet trusted to stay on only his/her talk page and the one exception page), then the block could be modified to ignore that one page.

I do not know how we would implement this because it is necessary that someone would develop this feature, but that is something to consider at a later point. I just want to know the opinions and/or ideas of editors. Dustin (talk) 02:42, 24 July 2014 (UTC)[reply]

  • I support the general idea, though the specifics of what kind of granularity we want is up for grabs. In particular, one thing I definitely would find useful is the ability to block IP ranges (perhaps as large as /8) from specific pages. Currently the only way to do this is with an edit filter, which impairs performance. -- King of ♥ ♦ ♣ ♠ 02:50, 24 July 2014 (UTC)[reply]
    Actually, what Graeme Bartlett said makes a whole lot of sense. And it should be possible to select an IP range as the user to be restricted by the filter. -- King of ♥ ♦ ♣ ♠ 03:43, 26 July 2014 (UTC)[reply]
  • Oppose because it would require development support from the WMF. These are essentially topic-bans with supporting block. Robert McClenon (talk) 02:52, 24 July 2014 (UTC)[reply]
  • Strong oppose The discussions on blocks have been extensive and the community has been pretty clear...no further options are required or needed. No support from me. Sorry.--Mark Miller (talk) 02:59, 24 July 2014 (UTC)[reply]
    • You obviously have neither looked at the previous discussion like I suggested, nor at the links at that discussion. Back in 2005, nine years ago, there was another proposal like this one, and it received over 80% approval. I know that was a long time ago, but why should we not reconsider? Dustin (talk) 03:04, 24 July 2014 (UTC)[reply]
      • I don't give a crap about that as you don't give a crap about other discussions so just stop complaining and let this go to the community now. You said your piece. If that isn't enough, you failed.--Mark Miller (talk) 03:08, 24 July 2014 (UTC)[reply]
  • Having this discussion here somewhat clouds the purpose of the discussion. If the goal is simply to come up with a technical specification of what such a system would look like, mediawiki.org would be a better location. A discussion here will inevitably involve local policy implications and we need to have some concrete idea of what the feature's capabilities are before such a discussion could reasonably proceed. Mr.Z-man 04:20, 24 July 2014 (UTC)[reply]
I would wonder if this is actually a local issue for Wikipedia as proposed by Dustin. I may think that dragging a discussion from 9 years ago, into this discussion isn't even relevant today but hey....lets let this go its course and see what happens.--Mark Miller (talk) 04:27, 24 July 2014 (UTC)[reply]
  • Support As I said on the idea lab this could be an edit filter just applying to one user (or IP). When optimised so that the filter only ran for 1 user there would be no performance impact on the rest. There would be plenty of fine grain here, denying uploads, moves, use of interaction banned users talk pages and so on. Graeme Bartlett (talk) 07:28, 24 July 2014 (UTC)[reply]
  • Support However, like Graeme Bartlett I would suggest to go into the direction of edit filters that apply to individual users or IP ranges. --AFBorchert (talk) 08:41, 24 July 2014 (UTC)[reply]
  • Not persuaded that usefulness outweighs the effort and complexity. For logged-in editors, this idea is a non-starter for me. If a particular user is subject to a topic or interaction ban, then either they stick to the terms of their editing restrictions, or they get blocked entirely. A user who lacks the maturity or restraint to adhere to an editing restriction (and, for that matter, who edited in a manner sufficiently disruptive to earn such a restriction in the first place) doesn't need additional technical constraints, they need to stop editing until they can control themselves.
    For IP addresses, I can see some argument for this as a way to reduce collateral damage (particularly when placing rangeblocks), but I suspect it will be more complicated than it's worth. Semi-protection already exists as a solution, though it does affect all IP editors of an article. (It's a bit blunt as a tool, but we already tolerate even long-term semi-protection of articles where warranted by circumstances.)
    From an admin standpoint, I can see this becoming rather complicated to manage and track. If I block an IP range from editing a particular article, does it show up in the IP's block log, or in the article's logs, or both, or neither? TenOfAllTrades(talk) 17:52, 25 July 2014 (UTC)[reply]
  • Oppose This is a solution looking for a problem. It introduces complexity where none is needed. If a user will not follow restrictions then a conventional block will work. Either a user is willing to follow community expectations or they are not. Specialized blocks would result in gaming of the system. Chillum 18:06, 25 July 2014 (UTC)[reply]
  • I wonder: Could selective whitelisting be used to keep someone blocked, but make it possible for them to clean up their own copyvios on specific, identified pages? That might be desirable. WhatamIdoing (talk) 18:49, 25 July 2014 (UTC)[reply]
    This goes to the point I made above. If we can't trust someone to follow editing restrictions without building a technical wall around their editing, I can't imagine we would trust them to perform a task requiring careful judgement like cleaning up copyvios—especially where they were the ones who introduced the copyright violations or plagiarism in the first place. TenOfAllTrades(talk) 19:03, 25 July 2014 (UTC)[reply]
    It's not unusual to see a request for someone to be fully unblocked so that they can help with copyright cleanup. That requires a lot more babysitting than providing access only to specified pages would. WhatamIdoing (talk) 23:16, 25 July 2014 (UTC)[reply]
  • Support the idea, assuming it is technically possible. This would make more sense than existing practice in a number of areas. In the case of 3RR violations, for instance, if an editor is causing problems by edit warring on an article then our only option for stopping them is to prevent them from editing every single page, anywhere, even though they are only causing problems on one page. It would make more sense to prevent them from editing the one page where the edit warring is taking place. Hut 8.5 10:54, 26 July 2014 (UTC)[reply]
  • Support - this would allow bans to be more-easily enforced, as well as a list of situations where it would be useful regarding blocked users (e.g {{2nd chance}}, unblock discussions in locations other than the user's own talk page). עוד מישהו Od Mishehu 19:56, 27 July 2014 (UTC)[reply]
  • Support Seems like this would be a valuable addition to the admin toolbox. Toohool (talk) 01:18, 31 July 2014 (UTC)[reply]
  • Support, ignoring the technical design requirements of which I know very little, but I think any idea worth implementing is worth doing the technical work. I'm a little concerned about difficulty using this for "broadly-construed" topic bans, but maybe we can implement a way to block users from editing pages in a particular category. It's a good idea, anyway. However, I also agree with what another user said above that if an editor can't play by community rules then full blocks and/or community bans are coming anyway. Ivanvector (talk) 15:41, 5 August 2014 (UTC)[reply]
  • Support. I like the idea behind this, in principle. Calidum Talk To Me 01:31, 18 August 2014 (UTC)[reply]
  • Strong oppose. This is not a good idea at all. Bans exist both to prevent disruptions to the community, and to give infringing editors the opportunity to remain a part of the community. They do this by abiding by the restrictions of their ban. If they are unable to do this, we gave them the WP:ROPE, and they have chosen by their actions to set themselves as being outside the community. Blocks are for those people who chose not to be a part of the community, either by contempt for the bans that the community has imposed on their editing, or by simply breaking obvious rules, eg vandalism. There is no "partial" being a part of this community. You either abide by the rules, or you don't get to participate here. Selective blocks just prevent those people who consider themselves outside of this community to demonstrate to us their decision to stand apart by violating their ban. Selective blocks open up a huge pandora's box of wikilawyering possibilities, and do nothing to promote the community. This is just plain a bad idea. VanIsaacWScont 01:46, 18 August 2014 (UTC)[reply]
    • Using the word "strong" doesn't give your !vote any more weight (I don't see why "strong support" and "strong suppose" are ever used), but that being aside from the point, I don't think you considered proposal #3. Dustin (talk) 16:31, 18 August 2014 (UTC)[reply]
      • The word "strong" indicates that it is a categorical objection or support of the proposal, rather than, say, a preferential or logistical consideration behind a person's position. And since this is a !vote, of course every !vote is weighted; that's the entire point of it being a !vote. Even though I don't understand how situation #3 can even come about - if we can't trust someone whose contribution history is logged in one place (so it's easy to revert) to have access to more than one page, how could their actions on that one page possibly instill enough trust to allow them access to any more of the project? - #3 can still be accomplished with the current permission scheme by simply copying that article content to their talk page, where they can edit away. VanIsaacWScont 18:59, 18 August 2014 (UTC)[reply]

Alternate proposal

Not sure if this is a proper format for an RfC, but here we go. Admins(explicitly not EFMs) are now permitted to make an edit filter that can block a user from editing certain pages while allowing them to edit others. This is to be treated as seriously as a block(admins are explicitly not to use these for TBANs unless a user made a TBAN infraction normally warranting a block.) For example, if a user requests to have their block discussed at ANI, that user would be unblocked and the filter modified so that the appealing user is blocked from editing any page except ANI. (To avoid confusion that would otherwise arise, admins would create one or two filters that would contain the entire system for blocking edits, something like: ((user_name==appeallingeditor) & (article_prefixedtext !='Wikipedia:Administrator's noticeboard/Incidents')) | ((user_name==TBANnededitor) & (article_prefixedtext =='ContentousArticle' | ...)) then block action, which would prevent appeallingeditor from editing any page but Wikipedia:Administrator's noticeboard/Incidents, and prevent TBANnededitor from editing ContentousArticle. (I'm sure someone can come up with some better code, I was just messing around) Cheers and Thanks, L235-Talk Ping when replying 21:31, 8 August 2014 (UTC)[reply]

  • I see that you got more into the code than I ever did... at least from the way it appears, I think I would support this proposal because it would allow for stronger enforcement by administrators, and it would meet some of the goals of my main proposal above. Dustin (talk) 21:44, 8 August 2014 (UTC)[reply]
  • Support in theory, but in practice, this may end up causing more trouble than it's worth if the number of edits which hit the EF condition limit is too hig (right now, it's at 0.77%, but it occasionally gets above 5%). עוד מישהו Od Mishehu 08:19, 13 August 2014 (UTC)[reply]
  • Well the hitting the EF limits is why I suggested getting special support for edit filter per user or IP in the code. This would make it very efficient, as it would only run for the affected user. Graeme Bartlett (talk)
  • This bot keeps on archiving this discussion, which is definitely an issue. What next now? I seem to have received at least some degree of support, so I don't think we should just archive this away. Dustin (talk)
    You could try filing a feature request at bugzilla and see if someone wants to program this functionality. And then perhaps another RFC to see if we want to enable it here if it ever gets programmed. –xenotalk 03:12, 3 September 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I don't know what the best venue for contacting the developers is, but I might try to register a bugzilla account and bring the issue up there as suggested by Xeno. I guess that's about it for this discussion for now. Dustin (talk) 23:02, 11 September 2014 (UTC)[reply]

Distinguishing between New Pages Patrol reviews and AfC reviews

Following a discussion at the idea lab, I would like to propose specifying that New Page Patrols are patrols, not reviews, in user notifications. A common question I see asked at the Teahouse, Help Desk, and IRC help channel is from users who are confused about why their article draft/user page/sandbox has been 'reviewed' and yet they can see no change. This is particularly confusing for new users who have submitted an Article for Creation - their article being reviewed seems to suggest that an accept or decline decision has been made, and they are confused when no such decision is obvious. This stems from both New Page Patrol and AfC reviews being described as 'reviews'; when a page is patrolled the user receives an email and notification informing them that their "page has been reviewed" when in fact it has been patrolled. I suggest changing the following interface messages (thanks to Jackmcbarn for finding them) to specify that the page has been "patrolled" not "reviewed":

Additionally it could be beneficial to include either a brief explanation of what NPP is or some link to WP:NPP in the notification or email. Sam Walton (talk) 22:40, 2 September 2014 (UTC)[reply]

Hear hear, this word "review/reviewed/reviewing" has too many meanings in Wikipedia, as also seen in a recent discussion on user right naming: Noyster (talk), 09:37, 3 September 2014 (UTC)[reply]
Support, this also makes it consistent with the autopatrolled right. BethNaught (talk) 10:05, 3 September 2014 (UTC)[reply]
  • I would certainly support getting the terminology right. As one user who has been extremely concerned about NPP for many years I have never referred to NPP as anything other than 'Patrolling'. As I never create pages as a new user, I was oblivious to the confusion that it causes among the newbies. Kudpung กุดผึ้ง (talk) 10:54, 4 September 2014 (UTC)[reply]
  • What do you think of "checked" rather than "patrolled"? WhatamIdoing (talk) 22:29, 4 September 2014 (UTC)[reply]
    • In harmony with the current usage and the thousands of times the term has been employed around the site and on templates, etc., I think there's nothing broken that needs fixing other than the OP's original suggestion. Besides which, 'checked' evokes a cursory glance while patrolling requires somewhat more action, and carried out by competent users. Kudpung กุดผึ้ง (talk) 05:49, 5 September 2014 (UTC)[reply]
      • "Patrolled" is wikijargon that won't mean anything to new users. It's not even grammatically sensible, since patrolling is the act of going from page to page, not the act of marking this one as being okay. "A passing user said that your page probably didn't qualify for immediate deletion" would be the most accurate, but that's very wordy. "Okayed", "accepted", or "checked" might make sense to a new person. "Checked" has the advantage of evoking the checklist, even though most NPPers don't follow it. Outside the mainspace, pages are often marked as patrolled after only a cursory glance, and not everyone believes that patrolling requires tag bombing, so that would be an accurate implication. WhatamIdoing (talk) 18:56, 8 September 2014 (UTC
WhatamIdoing, 'Patrolled' is the best term we have and as it isn't broken, why fix it? The proposal is to change any confusing terminology to 'patroll/ed' and not to find some other term. "checked" evokes "passed"/"authorised" just as much as "Okayed" or "accepted", which at NPP are most usually not the case - almost all new pages are in need of some attention of one kind or another whether they are rife for deletion of not. We must avoid any suggestions that NPP is a cursory glance - it s not, or it is cerataily not supposed to be. I realise that there are some NPP skeptics out here, but NPP is not only our only firewall against unwanted/unsuitable/inappropriate content, but it should also, if used correctly, encourage those whose articles just scrape through, to do better, while nevertheless, tag-bombing is totally counter productive. KudpungMobile (talk) 08:59, 9 September 2014 (UTC)[reply]
I disagree that it "is the best term we have", and I disagree that it "isn't broken". Patrolled is not understood by new users. It is, therefore, "broken". It is merely the most common term among people who are familiar with wikijargon, which is not the same as "best" or "not broken". WhatamIdoing (talk) 16:02, 9 September 2014 (UTC)[reply]
  • Support - Reviewed is a poor choice as it infers that there is some sort of feedback process involved. Patrolled, although not ideal is consistent with the terms, 'New page patroller' and 'Autopatrolled'.--Ykraps (talk) 12:46, 6 September 2014 (UTC)[reply]
Doesn't the notification say "your page was approved", which is an adequate description of the "this draft or main namespace article has been accepted for main namespace"? Gryllida (talk) 22:15, 11 September 2014 (UTC)[reply]
I'm confused what this has to do with the above - "your page was approved" is a fine description of a draft being accepted. The confusion comes from WP:NPP being referred to as a 'review'. Sam Walton (talk) 22:21, 11 September 2014 (UTC)[reply]
I don't use Echo, but I thought it says 'your page was approved' for NPP, as well... --Gryllida (talk) 23:09, 11 September 2014 (UTC)[reply]
Umm, no, it definitely says reviewed. I have just checked my notifications.--Ykraps (talk) 04:56, 12 September 2014 (UTC)[reply]

Widen usage of Draft-class

Background

The Draft namespace was enabled in December 2013 (see Wikipedia:Drafts) and some WikiProjects (currently 1,485) have opted to use the Draft-class assessment to keep track of draft articles within their scope. The advantage is that it facilitates editors in a project to work on improving draft articles within their knowledge and interest to get them ready for mainspace.

Proposal

This proposal is about whether this usage should be widened by making it one of the default assessment classes used by projects. There are 3 options:

  1. Status quo: projects can opt-in to using Draft-class.
  2. Add Draft-class to FQS: all projects currently using the "Full Quality Scale" (FA, A, GA, B, C, Start, Stub, FL, List, NA, Category, Disambig, File, Portal, Project, Template) (approximately 1300) will automatically have Draft-class enabled, unless they choose to opt-out.
  3. Add Draft-class to all: all projects using the standard quality scale (FA, A, GA, B, C, Start, Stub, FL, List, NA) (approximately 1900) will automatically have Draft-class enabled, unless they choose to opt-out.

For more details (including how this would be done), see Template talk:Class mask#Protected edit request on 1 September 2014

Discussion

Note, Full doesn't include Book either. -- WOSlinker (talk) 11:46, 5 September 2014 (UTC)[reply]
It also doesn't include User, MediaWiki, Help, Education Program, TimedText, Module, Topic. --Redrose64 (talk) 12:10, 5 September 2014 (UTC)[reply]
As those namespaces do not contain articles, draft articles, or components of articles such as templates, they are not actually relevant. Roger (Dodger67) (talk) 09:24, 9 September 2014 (UTC)[reply]
Modules are components of templates (see, for example, Module talk:AUshield); and TimedText pages are components of Files (e.g. TimedText talk:03 Pink Try.ogg.en.srt). --Redrose64 (talk) 11:32, 9 September 2014 (UTC)[reply]
  • I prefer option 2, but I won't be heartbroken by option 1. Protonk (talk) 13:00, 5 September 2014 (UTC)[reply]
  • As a regular AfC reviewer I prefer Option 3 but Option 2 would be acceptable too. The lack of a mechanism to routinely "notify" WikiProjects of the existence of drafts within their scope has been a perennial issue at AfC - thus I support the full implementation of this proposal. Roger (Dodger67) (talk) 09:24, 9 September 2014 (UTC)[reply]
  • I was summoned here via Feedback Request Service, and I'm really not sure what Draft class provides that isn't already catered for by stubs, specifically as draft class seems to be intended to be used in conjunction with the draft namespace, which hides articles from potential contributors. Maybe someone can explain how this is a benefit to the everybody-can-edit model. Samsara (FA • FP) 00:29, 13 September 2014 (UTC)[reply]
    @Samsara: As you surmise, many drafts get created with few people knowing of their existence - the page creator, and those people who routinely check Draft: space for new creations. In order to bring these to wider attention (and hopefully encourage others to assist with bringing the draft up to a suitable standard for mainspace), Draft talk: pages may be tagged with WikiProject banners in the same way as the talk pages of regular articles. For those WikiProject banners which have already opted in to Draft-class, such as {{WikiProject Albums}}, if the banner is given |class=draft, or if the |class= parameter is left blank or is omitted, then the talk page is placed in a category like Category:Draft-Class Album articles. For those WikiProject banners which have not already opted in to Draft-class, such as {{WikiProject Jazz}}, the talk page is placed in a category like Category:NA-Class Jazz articles, even if the banner is explicitly given |class=draft. As I write this, there are two Draft talk: pages tagged for WikiProject Jazz, but Category:NA-Class Jazz articles has 81 members. Segregating the Draft talk: pages into a category of their own - which would be Category:Draft-Class Jazz articles - will help those two to be found more quickly, and shouldn't go unnoticed among the 70+ pages marked with |class=redirect that seem to comprise the bulk of the cat. This segregation may either be done by WikiProject Jazz opting in, in a similar manner to WikiProject Albums; or it may be done by a general change affecting the majority of WikiProjects. --Redrose64 (talk) 10:44, 13 September 2014 (UTC)[reply]
    I see that there's a complaint that the use of Draft space is associated with a growing review backlog. Is it really sensible to further encourage its use? In other words, is the review backlog a net benefit to Wikipedia, compared to allowing the articles to be stubs in regular space? For years, there has been concern that the rate of article creation is in decline. What has the effect of draft space on this been? It would seem possible to collect and publish some relevant data - maybe someone already has? Thanks for any further insights. Samsara (FA • FP) 15:13, 13 September 2014 (UTC)[reply]
    If the WikiProjects are made more aware of the drafts, perhaps some of their members will take up AFC reviewing, and so reduce the backlog. --Redrose64 (talk) 19:36, 13 September 2014 (UTC)[reply]
  • Support Option 2. It fits better in the full list than the cut down standard list. If the draft space is "here to stay" as mentioned above, it needs to included correctly in the pretty WikiProject article counts tables - see my query here. The-Pope (talk) 10:47, 14 September 2014 (UTC)[reply]

Use {{div col}} for categories

At present category listings use a fixed 3-up format. I propose that they should use the HTML equivalent of {{div col|colwidth=16em}} so that people using the wide windows that seem to be so prevalent these days can see more columns. As an example look at list of Pakistani actors and change your window width the while. If you have a decent browser, the number of columns will change in response. I have tried this with four different browsers under Android and they too are happy with it. (The value of 16em is negotiable but that seems about right.) — RHaworth (talk · contribs) 14:47, 10 September 2014 (UTC)[reply]

Note that this would require a software change, specifically to [1]. Jackmcbarn (talk) 14:52, 10 September 2014 (UTC)[reply]
Cat listings are laid out using a one-row three-column table. Each of the three cells is 33.3% width, and contains one or more <h3>...</h3> elements, each of which is followed by a <ul>...</ul> element enclosing one or more <li>...</li>. --Redrose64 (talk) 16:02, 10 September 2014 (UTC)[reply]

IPA tooltips

(I wasn't getting any responses after posting on the template's talk page, so...)

See Template talk:IPA-en#Make like IPAc using Lua?. I propose that Template:IPA-en (and perhaps similar templates) have automatically generated tooltips explaining the sounds represented by the IPA symbols. Example: /Script error: No such module "IPAc"./ --Yair rand (talk) 02:23, 11 September 2014 (UTC)[reply]

Category:Expired editnotice

Resolved

Category:Expired editnotice currently contains two types of editnotices:

  • editnotices which don't have an expiry time set, and
  • editnotices which have an expiry time, which has passed.

At Wikipedia_talk:Editnotice#Category:Expired_editnotice, I have proposed that editnotices which don't have an expiry time set (which are possibly/probably intended to be "permanent") should not be included in this category, in order to better identify editnotices which have an expiry time, which has passed (which are probably obsolete and likely candidates for deletion). In the interests of keeping the discussion in one place, please express any views you may have on the matter at Wikipedia_talk:Editnotice#Category:Expired_editnotice. Thanks. DH85868993 (talk) 03:16, 11 September 2014 (UTC)[reply]

The template error has been fixed. The category is now named Category:Expired editnotices with an "s". -- John of Reading (talk) 06:27, 14 September 2014 (UTC)[reply]

Leading zero

Normal English does not use leading zeroes (e.g., 02 September 2014), so I wish we wouldn't in non-technical places. I am against have publication/birth/death/start/end dates in the right-hand boxes listed with leading zeroes in dates under 10 followed by a month and year. I couldn't find this in perennials. Has this been discussed? Is there a policy? Kdammers (talk) 03:27, 11 September 2014 (UTC)[reply]

Wikipedia:Manual of Style/Dates and numbers doesn't seem to mention anything about it. --NaBUru38 (talk) 03:42, 11 September 2014 (UTC)[reply]
Please link to an article showing the issue. Johnuniq (talk) 03:58, 11 September 2014 (UTC)[reply]
Yes it does, see table at MOS:BADDATEFORMAT, it's in the second column as "09 June"/"June 09" and in the third col as 'Do not "zero-pad" month or day'. --Redrose64 (talk) 07:00, 11 September 2014 (UTC)[reply]
O.K., then I'll start cleaning up sites that don't comply. Kdammers (talk) 07:13, 11 September 2014 (UTC)[reply]
@Kdammers: BattyBot removes the leading zeroes in citation dates where they cause CS1 errors. (e.g. this edit) If you notice places where BattyBot isn't making the fixes, please let me know so I can tweak my script. Thanks! GoingBatty (talk) 02:32, 12 September 2014 (UTC)[reply]

Articles for creation script upgrade

Hi all,

You may be interested in this discussion, concerning changing the script enabled in gadgets to review AfC submissions. Thanks. --Mdann52talk to me! 12:50, 12 September 2014 (UTC)[reply]

new namespace: taskforce...or clubs

I feel that we need a space where people can create loose groupings, i.e. social groups or task-oriented groups, to gather some like-minded editors to help them edit entries in particular topics in areas of relevant interest. I propose that we have a new namespace, to be called "taskforce." alternately, it could be called clubs, but that is my second lesser preference for this idea.

I know we already have portal spaces for this and wikiprojects, but it is not the same. this would be more informal, and group on any topic or set of topics that people might wish.

It would have the benefit of drawing more interest here and generating more energy and activity in editing wikipedia.

comments? --Sm8900 (talk) 13:39, 12 September 2014 (UTC)[reply]

What would the difference betweeen this and WikiProjects be? Sam Walton (talk) 14:09, 12 September 2014 (UTC)[reply]
thanks for your comment. there can only be one WikiProject for a particular topic. this would allow any person or group of people to set up their own club for editing for a topic or for an area within a topic, even if there is already a wikiproject in existence precisely for that area or topic. --Sm8900 (talk) 14:19, 12 September 2014 (UTC)[reply]
Not seeing a difference. Project members will periodically do that now. Is your proposal designed to just add more social interaction into Wikipedia? GenQuest "Talk to Me" 14:24, 12 September 2014 (UTC)[reply]
WikiProjects often have overlapping areas. There can be more than one WikiProject for a particular topic, and these are often associated through the taskforce system. For example, railways come under WikiProject Trains; railways in the UK come under WikiProject UK Railways; railways in Scotland under WikiProject Transport in Scotland; and railway locomotives under WikiProject Trains/Locomotives task force. So a talk page like Talk:NBR 224 and 420 Classes has one WikiProject banner - {{WikiProject Trains}} - but with various parameters |UK=yes|Scotland=yes|locos=yes to bring in all those other projects and taskforces. Moreover, an article's talk page can have more than one WikiProject banner template. --Redrose64 (talk) 15:11, 12 September 2014 (UTC)[reply]
I think that our existing taskforce structure handles these things just fine. bd2412 T 16:33, 12 September 2014 (UTC)[reply]
I am trying to tap into the vast potential for interactive collaboration which exists on the Web. we can generate a lot more input if we give people much more leeway tos et up their own informal groupings of editors who can share interests and activities. I am saying that there should not be just one Wikiproject United States, for example; there should be ten, if people would like that. so this would be more informal, and more interactive. --Sm8900 (talk) 20:52, 12 September 2014 (UTC)[reply]
That sounds like chaos. If the ten groups agree with each other, it's duplication of effort; if five of them disagree with the other five, what happens then? --Redrose64 (talk) 21:07, 12 September 2014 (UTC)[reply]
well, any disagreements would only occur in the editing of the articles themselves. and there's no reason to think that this would generate that much more editing or conflicts on any single article in particular. It is much more likely that this would generate a marginally greater amount of activity on a number of separate articles which each appeal to different interest groups.
so therefore, for example, I would not expect 100 new editors to try to edit United States simultaneously; rather we might get one group which would pay more attention to the Civl War and the Old West, and another one to pay more attention to Theodore Roosevelt and the Progressive Era, and so forth. --Sm8900 (talk) 22:12, 12 September 2014 (UTC)[reply]
I still don't see why the article talk pages are not the most suitable venue for discussions which cover that specific article, nor why WikiProject talk pages are not the most suitable venue for discussions which cover more than one article. --Redrose64 (talk) 22:41, 12 September 2014 (UTC)[reply]
I'm also wary that it might encourage POV-oriented interest groups. Alsee (talk) 02:41, 13 September 2014 (UTC)[reply]
I'm sceptical as well. We already have article and user talk, WikiProjects, taskforces and various more specialized discussion venues. I don't see a use case that's not covered by this. And even if we would want to establish yet another type of discussion pages, why would it need it's own namespace? Even WikiProjects don't have that. — HHHIPPO 11:03, 13 September 2014 (UTC)[reply]
hm, ok. how about implementing this as a new type of item, but without a new namespace? let me know what you think. --Sm8900 (talk) 00:49, 14 September 2014 (UTC)[reply]
I still think the same as yesterday: I don't see a use case that's not covered by the existing types of discussion venues. — HHHIPPO 09:59, 14 September 2014 (UTC)[reply]

hm, ok. anyone else wish to comment? --Sm8900 (talk) 19:08, 15 September 2014 (UTC)[reply]

You wrote above, "there can only be one WikiProject for a particular topic". This is not true. The guideline says, "there is no rule that prohibits two separate groups of editors from being interested in the same articles". We don't recommend it, because it's inefficient, but it's perfectly "legal" to set up a WikiProject that happens to have the same scope as a pre-existing one. WhatamIdoing (talk) 00:08, 16 September 2014 (UTC)[reply]

Call to close

Consensus seems to be "not needed" (per HHHippo above), or it is too unclear/unfocused and needs refinement and resubmission at a later date. Call to close this proposal by lack of consensus. GenQuest "Talk to Me" 18:56, 16 September 2014 (UTC)[reply]

Can we set off in the direction of more Help

I'd like to suggest that we write manual pages for the most-often-linked-to (at personal talk pages) policies, including documentation on frequent mistakes and misunderstandings (which admittedly have no place in policies), so that policy is only used for edge cases (assessing deletion criteria and the like) — not for getting started.

I suppose I could do this by myself, but that'd not be collaborative, and I'm not currently comfortable with the lengthy FAQ pages format or contributing to them (I'd personally have 1 page for each FAQ or perhaps a separate namespace, or really anything close to a structured help section of the site with each help item of small size, focusing on a single point). --Gryllida (talk) 11:34, 13 September 2014 (UTC)[reply]

Proposal concerning scope of verifiability and definition of original research

There is a proposal here that concerns our stance towards local interpretations of verifiability. Currently, most of the responses to the proposal are from members that are closely associated with the WikiProject that gave rise to the discussion. I believe the proposal could benefit from some broader perspectives. Thank you. Samsara (FA • FP) 16:54, 13 September 2014 (UTC)[reply]

This is primarily a discussion about whether you can use an image in an article if there are no published reliable sources that says this photo that looks exactly like the San Francisco skyline really is a photo of the San Francisco skyline (all the way down to far more complicated cases). WhatamIdoing (talk) 00:11, 16 September 2014 (UTC)[reply]

Should we move Editor Retention to the Wikipedia Name Space?

The discussion's initiator has withdrawn the proposal. —David Levy 02:05, 15 September 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I propose we move Wikipedia:WikiProject Editor Retention from the project space to the Wikipedia:Namespace. The reason for the move would be to establish the project as more than just another WikiProject in hopes that we can gain consensus on guidelines for retaining new and old editors in a more structured manner.

  • Support as proposer The project has become one of the few projects that is known for more than just a simple collaboration of a handful of editors to become one the encyclopedias better known attempts at addressing editor retaining issues, similar to the Teahouse.--Mark Miller (talk) 08:25, 14 September 2014 (UTC)[reply]
  • Comment The Wikipedia namespace is the Project namespace, see WP:Project namespace. What you probably mean is dropping the "WikiProject" part from the page title. But what would the new title be? Just "Wikipedia:Editor Retention"? That sounds like a place where you would find the final consensus guidelines, not the project working on them. And what's wrong with being a WikiProject? Just that they come in vastly different sizes and scopes doesn't mean they're all unimportant. — HHHIPPO 08:51, 14 September 2014 (UTC)[reply]
    I ask because you write that you want to establish the project as more than just another WikiProject. That sounds to me like you see a disadvantage of this project being classified as a WikiProject, but I don't see why. I don't claim there is no reason, I just don't see it, that's why I ask.
    Let me use an example: we have a WikiProject on Accessibility. Their project page is at Wikipedia:WikiProject Accessibility and the guidelines they worked out at Wikipedia:Accessibility (in their case behind a redirect). Similarly, I think it would be a good idea to put guidelines regarding editor retention at Wikipedia:Editor Retention, but I don't see why one should move the whole project page with all it's subpages to that name.
    I'm not sure what you mean by name space. Technically, Project: and Wikipedia: are aliases for the same namespace. Try for example Project:Village pump, that points to the same page as Wikipedia:Village pump. So you can't possibly move from the project space to the Wikipedia:Namespace, all you can do is dropping the "WikiProject" part in the pagenames of all the pages belonging to this WikiProject. And all I'm asking is why you want to do this: what's wrong with the old names, and shouldn't the new place hold the results rather than the project pages? I hope I made that a bit clearer now. — HHHIPPO 09:55, 14 September 2014 (UTC)[reply]
    Not really. Jumping to conclusions with me is not the best route. You seem to be taking a leap to accuse me of bad faith with the WikiProjects and that is incorrect. That is your accusation. It is not fact and really just takes a huge leap of bad faith. I get what you are trying to say, but we do have two separate spaces. While a WikiProject is in the Wikiname space it is a project space and my hope is to elevate editor retention to more than just a local consensus of editors and bring it under the wider scope of the general community. Thanks.--Mark Miller (talk) 10:04, 14 September 2014 (UTC)[reply]
    I'm no trying to accuse you of anything, sorry if I wasn't clear enough. I'm just asking you what you're actually proposing and why. I'm a scientist, when I ask a question that doesn't mean I want to insinuate the non-existance of an answer, it simply means I'm interested in what the answer is! So could you please explain what you mean by Wikiname space and what by project space? In your original post you explicitly linked to the technical meaning of "namespace" in the framework of the MediaWiki software, but I'm not sure if that's really what you mean.
    Note that I didn't ask what's wrong with WikiProjects, I asked what's wrong with calling Editor Retention a WikiProject. That doesn't imply anything bad about WikiProjects and it neither implies that you have anything against WikiProjects. It just means that I'm interested in why you want to change the current situation. Is it really so condemnable to ask "why?" when someone proposes something? — HHHIPPO 10:54, 14 September 2014 (UTC)[reply]
    Thank you very much for the above. Wikipedia has two pages for these definitions. While the wording would make one assume they are, together, the same thing... they are, in fact not. The Wikipedia:Namespace is simply the Wikipedia page with no further extension and has been defined as the wider consensus of the general community, while the Wikipedia:Project namespace is the local consensus of a small band of collaborating editors. A local consensus cannot override the broader community consensus. If the two were actually the exact same thing, Wikipedia would not feel inclined to have two, separate pages defining the space. I seek to bring Editor Retention to the broader community to begin forming guidelines that could help improve the Wikipedia project as a whole. How that can be achieved is only through the broader community. It is never condemnable to ask "why?", but only to assume there is something "wrong" with being a WikiProject. But...WikiProjects have their limitations and I truly believe that Editor retention has outgrown the boundaries of the WikiProject space and could be a true improvement to Wikipedia in many ways. Not just by advancing proposed guidelines but by actually taking a more proactive approach to editors learning how the encyclopedia functions and helping to guide both the new editor and the old editor in a direction to make their experience more positive and productive. I do apologize for my taking offense. It was only in the wording of assuming I have an issue with the projects. I do not. I have been very active with the projects in a number of ways, including attempts to revive Project Rome as well as founding a few other projects myself...although Editor retention was founded by Dennis Brown, it is something I have taken to be a vital part of my contributions at Wikipedia. There are many editors who also contribute to the project and it is my hope to bring their work to the forefront of the overall project we call Wikipedia. As always consensus will determine if this should happen. I hope it succeeds but...if it remains a WikiProject, it will simply continue along the same lines, as limited as that may or may not be. Thank you once again!--Mark Miller (talk) 11:41, 14 September 2014 (UTC)[reply]
    @Mark Miller: I think that you may be misinterpreting the page titles.
    • Wikipedia:Namespace is a page which explains what a namespace is, and describes all of the namespaces in general terms. It is itself in the Wikipedia namespace - you can tell this because its name is prefixed with "Wikipedia:". The same page can be reached in two other ways: Project:Namespace and WP:Namespace. If you follow either of those links, you'll find that they end up at exactly the same page
    • Wikipedia:Project namespace is a page which describes one specific namespace: the Wikipedia namespace, which is also called the Project namespace. Its name is prefixed with "Wikipedia:", so like Wikipedia:Namespace, it is also in the Wikipedia namespace; and like that page, it can also be reached in two other ways: Project:Project namespace and WP:Project namespace.
    Any page whose name is prefixed "Wikipedia:" - such as Wikipedia:WikiProject Editor Retention - is in Wikipedia namespace, but it is also in Project: namespace. The two are inseparable.
    So, to take your original proposal, to move Wikipedia:WikiProject Editor Retention from the project space to the Wikipedia: namespace, this cannot be done - because it is already there. What I think you are requesting is that the existing page in Wikipedia: namespace that is called Wikipedia:WikiProject Editor Retention should be renamed Wikipedia:Editor Retention. That is a simple page rename, and does not involve a change of namespace. --Redrose64 (talk) 16:26, 14 September 2014 (UTC)[reply]
    Thanks. I think it is a matter of perspective to me as I do see that the project space is in the name space area but that the project space is still limited as a local consensus.--Mark Miller (talk) 22:14, 14 September 2014 (UTC)[reply]
    Project space = Wikipedia space. Wikipedia space = Project space. There is no difference, no distinction. --Redrose64 (talk) 23:29, 14 September 2014 (UTC)[reply]
  • Oppose, for now, until/unless a more compelling reason is presented. I like the "working group" aspect of the WikiProject, and the list of participants is helpful since not all editors care to work on editor retention. I agree that the plain WP: is currently used more for information, essays, policies, etc.. The Teahouse shows that it can be used for discussion as well, bit it's really a help desk, not a discussion and consensus building forum. There are also the Village Pumps, which draw a lot of general discussion, but have less focus that a WikiProject. I agree, though, that WP:WER has an important role and could use wider participation. —Anne Delong (talk) 11:52, 14 September 2014 (UTC)[reply]
  • Oppose for the same reasons as Anne Delong - it is a project and a good one, and the name fits. Dougweller (talk) 16:54, 14 September 2014 (UTC)[reply]
  • Oppose. Setting aside Mark Miller's misunderstanding of the namespace setup (which has been explained above), I disagree that it would be helpful to drop the "WikiProject" designation in this instance. WikiProject Editor Retention functions exactly as WikiProjects normally do, and I see no reason to change that (or to alter an accurate description). —David Levy 16:57, 14 September 2014 (UTC)[reply]
  • Withdrawn per the advice and comments above, as well of the discussion on my talk page with isaacl I am withdrawing this proposal as not needed for the goals I seek. We don't need to tear down something, to build something else up. Thanks for all the input!--Mark Miller (talk) 00:00, 15 September 2014 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


About the community portal

This portal's section "help out" should have "Create these articles", "Represent a worldwide view" and "Add historical information" as well, since in English Wikipedia there are still plenty of uncreated notable articles and articles requiring globalization or historical information, and these issues are not less important than articles requiring update. By the way, in the past this section has the block "Create" (I forgot its exact name, it refers to uncreated articles).--RekishiEJ (talk) 15:39, 16 September 2014 (UTC)[reply]

And {{Recent changes article requests}} should be transcluded to the block "Create these articles", since the template contains some uncreated notable articles.--RekishiEJ (talk) 15:41, 16 September 2014 (UTC)[reply]

Personal Names

As an encyclopaedia Wikipedia is a force for education, yet in the area of personal names it all too often fails. The particular names that I have in mind are East Asian names. In all parts of China, Japan and Korea surnames, clan names, call them what you will, are placed before given or personal names. Some articles follow this convention, but most don't.

Would it be polite for East Asians to call Jimmy Wales "Wales Jimmy" or Abraham Lincoln "Lincoln Abraham"? If not, shouldn't we use the proper order for other peoples' names?

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=626068470"