Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Superzoulou (talk | contribs) at 09:46, 28 July 2014 (→‎Oppose (Persondata removal): re Periglio). 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:


RFC: Naming of one and two digit numbers and years

See box. Formerip (talk) 11:14, 25 July 2014 (UTC)[reply]

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.

Result: Consensus is against the proposal.

6 editors supported the proposal, of which 2 only supported one aspect of the proposal (pagemoving pages related to years) and opposed the rest of the proposal. 15 editors opposed the proposal.

The mains reasons for the opposes were (1) that the proposal was likely to run into trouble and drama over oldschool vs newschool year-naming and (2) that the proposal would cause inconsistency in the naming of articles about years. These are fair arguments. The case for support was that, for one and two digit numbers, the number, not the date, was likely to be the primary topic. This is also a fair argument.

On balance, though, I don't see anything in the discussion that would warrant not recognising the numerical victory of the opposes.

Background

For the longest time, it was necessary to link dates (e.g. January 1, 1970) so the wiki software could format them automatically. Because this was often used in mainspace, it was desirable to keep those links blue and relevant, so four-digit number articles, by convention, are about years (if it existed, the corresponding natural number would be at 1970 (number)). Since people write about lots of different time periods on Wikipedia, this also extends to three-, two- and one-digit numbers (but not five and larger, because we are (apparently) not the Long Now Foundation); 5 is the year 5, not the number 5.

However, this linking is no longer necessary. We had a nice long edit war over whether it should still happen, of course, but I digress. Currently, fewer than 50 pages link to 5,[1] while many more link to its numerical counterpart.[2] One wonders whether the year is truly the primary topic for the numeral.

Question

Should we rename 1 through 99 to 1 AD through 99 AD (the precise naming scheme here is negotiable), then rename 1 (number) through 99 (number) to 1 through 99, and finally amend WP:NCNUM to account for the change?

NB: This intentionally only extends to one- and two-digit years, because larger numbers are less important while more recent years are more important. We may later revisit this discussion for three-digit years, but they are not part of this proposal. --NYKevin 21:51, 21 June 2014 (UTC)[reply]

Threaded Discussion

Shouldn't the relevant WikiProjects be informed of this RfC? As I have a particular opinion, I don't think I can create a neutral pointer, but at least Numbers, Mathematics, Years, and possibly its parent Time, should be notified. — Arthur Rubin (talk) 09:32, 27 June 2014 (UTC)[reply]

Done, also Disambiguation. So minimal as to raise no question of neutrality. PamD 14:24, 27 June 2014 (UTC)[reply]

Support

  1. Support as proposer. --NYKevin 21:51, 21 June 2014 (UTC)[reply]
  2. Semi-support (first renaming only, i.e. years to include an indication such as AD or CE) – including up to three digits. But oppose renaming of articles on the numbers to remove the disambiguator: that would be unnecessary. However, I support that the freed up number like 5 become redirects to the correspond 5 (number) etc. On matters like this, a uniform convention should be the objective. —Quondum 23:49, 21 June 2014 (UTC)[reply]
  3. Support first half per Quondum. The current situation is truly awkward and needs to be solved. --cyclopiaspeak! 22:05, 22 June 2014 (UTC)[reply]
  4. The number is the primary topic at least for numbers up to a couple hundred. For consistency's sake, numbers and years should not be treated differently than chemical elements or countries: they occupy the un-disambiguated top spot only if they are the clear primary topic. —Kusma (t·c) 09:34, 27 June 2014 (UTC)[reply]
  5. Strong support I don't think of natural numbers below 1000 as years without an explicit AD/CE or BC/BCE. The number is clearly the primary topic until about then (rounding to an order of magnitude to be somewhat consistent and not have to decide on a case-by-case basis). Double sharp (talk) 10:38, 1 July 2014 (UTC)[reply]
  6. Strong support and people who will be upset will need to build a bridge and get over the AD/CE thing. Red Slash 05:46, 9 July 2014 (UTC)[reply]

Oppose

  1. Oppose for consistency's sake. --AmaryllisGardener talk 23:37, 21 June 2014 (UTC)[reply]
  2. . A year is not a number. A year is a space of time conventionally designated by a number, conventionally written as an cardinal number, but actually meaning the first [etc] year of the particular era. DGG ( talk ) 05:47, 22 June 2014 (UTC)[reply]
  3. Oppose for now. To much drama creation potential. You first need to solve the harder problem of AD vs. CE. --Stephan Schulz (talk) 22:07, 22 June 2014 (UTC)[reply]
    We already have a precedent: 1 BC, 50 BC etc. Given this, do you anticipate it to be the source of a holdup? —Quondum 23:07, 22 June 2014 (UTC)[reply]
    AD vs CE provokes quite deep feelings on both sides. I wouldn't be surprised if the BC precedent were challenged if this proposal moves forward. And AD's meaning is potentially more offensive than BC. The present approach is an effective way to avoid a conundrum with no right answer. Add me to the Oppose count.--agr (talk) 01:44, 30 June 2014 (UTC)[reply]
    Couldn't the AD-vs-CE debate be sidestepped entirely by using "(year)" as a disambiguator, as in "43 (year)"? — Jaydiem (talk) 22:27, 21 July 2014 (UTC)[reply]
  4. On balance, Oppose. I do see the point you're making, but we need to consider what people are likely to be thinking when they type a number into the search box. My suspicion is that people who are able to type '5' or '99' probably have an idea what these characters represent as numbers. When I look at 5 (number) I certainly see a lot of stuff, but it's of the form "the third prime number" or "there are five Exceptional Lie Groups" or "the atomic number of Boron", and so on. These sorts of things are certainly true, but I imagine they're more likely to be encountered as part of searches for prime number, Exceptional Lie Groups, Boron, and so on. The only interesting stuff that is not "accidentally" true of "5" is the history of the glyph. I might be persuadable, but I'm not persuaded so far. RomanSpa (talk) 06:39, 23 June 2014 (UTC)[reply]
    Of course you see mathematical information when you look up a mathematical object. How is that unhelpful or unreasonable? I just don't understand this objection. --NYKevin 01:51, 24 June 2014 (UTC)[reply]
    I think you've missed my point. Certainly the information that is presented is true, and, as you say, when you look up a mathematical object you see mathematical information. My point is that it's not interesting information. By this I mean that there is no particular reason why "the number of Exceptional Lie Groups" should be the same as "the third prime number" (or, at least, I'm not aware of such a claim). That the two have the same value is just coincidental, so the fact that they do is uninteresting. If it could be proven, knowing only the definition of a prime number, but not knowing that the third one is 5 that the number of exceptional Lie Groups should be the third member of the class of primes, then this would be an interesting result, but even then it would belong in the article on Lie Groups. What I'm trying to say is that most of the stuff about "5" is just a list of unrelated facts that only coincidentally apply to the same number. There's nothing deeper going on. RomanSpa (talk) 07:50, 1 July 2014 (UTC)[reply]
    This is an argument to not have articles on numbers at all. I don't believe it's germane to the discussion. If you'd like to do a mass-listing on AfD, feel free. --NYKevin 00:39, 2 July 2014 (UTC)[reply]
    It is indeed such an argument. However, we have the precedent that such pages exist, and I currently have no intention of proposing that such a precedent be reversed, as I don't believe that an AfD of the kind you suggest would succeed at the present time. I prefer to reserve my energies for matters of the possible, not the presently impossible. RomanSpa (talk) 04:56, 5 July 2014 (UTC)[reply]
  5. Oppose; the benefit from consistency seems to outweigh the benefit of a change (though both seem reasonably marginal). Andrew Gray (talk) 18:38, 23 June 2014 (UTC)[reply]
  6. Oppose; discussion on various WikiProjects (Numbers, Years, Mathematics) have lead to no consensus, I think the consistency argument dominates, but the newly created 2719 seems to have developed a local consensus that it shouldn't necessarily be done. — Arthur Rubin (talk) 03:38, 27 June 2014 (UTC)[reply]
  7. Oppose, for consistency sake. The benefit of the proposal is marginal (if any), while the drama potential and, more importantly, maintenance efforts (both initial and ongoing) are going to be high.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); June 27, 2014; 13:23 (UTC)
  8. Oppose: consistency is too useful here to overthrow, but we must be sure that every year page has a crystal-clear hatnote pointing directly to the number as well as the dab page. I think it's standard: I just picked 73 as a non-scientific sample and it looks fine. PamD 14:30, 27 June 2014 (UTC)[reply]
  9. Oppose. Consistency for me trumps other considerations. And anyway, this proposal would seem to exacerbate the whole AD versus CE business. Sławomir Biały (talk) 16:10, 27 June 2014 (UTC)[reply]
  10. Oppose; in this case, the consistency achieved by having years at all of the undisambiguated titles is more useful than not. Powers T 20:39, 29 June 2014 (UTC)[reply]
  11. Oppose at this time because AD vs. CE is not settled. Were that not an issue, I would support adding AD/CE/BC[E] to year articles. However, in any case I oppose dropping (number) from number articles. All bare numbers (1, 25, 308, 1904, 22545 etc.) should be dab pages given the vast possible selection of topics for each number, unless there really is only a single topic in which case the bare number should be a redirect (because they're cheap). This ensures consistency throughout the project, is simple, and avoids pointless conflicts over which article is the primary topic. Ivanvector (talk) 20:36, 4 July 2014 (UTC)[reply]
  12. Oppose Going through the archives, if they had decided to remove such they were correct. It is pretty obvious, anyone can understand the year. OccultZone (Talk • Contributions • Log) 10:19, 10 July 2014 (UTC)[reply]
  13. Oppose – The value of consistency sways me to oppose, and the dramah potential sways me even further. Mojoworker (talk) 15:33, 15 July 2014 (UTC)[reply]
  14. Oppose "A.D." is presumed when there is no A.D. / B.C. I don't think such a generally accepted rule has to be amended. For the disambiguation issue, almost everyone seeing "5" in most articles (that is, non-mathematical articles) would expect a link to the year, as no one links "5" in those articles to the number, but there are people linking it to the year.Forbidden User (talk) 16:09, 17 July 2014 (UTC)[reply]
  15. Oppose, the drama potential with this change just screams "what could possibly go wrong"... Titoxd(?!? - cool stuff) 22:54, 21 July 2014 (UTC)[reply]

Polls are evil

  1. I'm going to hang out here on the Group W bench and watch for a bit. — {{U|Technical 13}} (e • t • c) 22:42, 21 June 2014 (UTC)[reply]
    How is this related to the topic?Forbidden User (talk) 09:35, 13 July 2014 (UTC)[reply]
    There is something to be said for listening first and deciding second. =) — Jaydiem (talk) 22:49, 21 July 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.

Satpal Maharaj/ Devine Light Mission

Details mentioned regarding Devine Light Mission should not be the part of Satpal Maharaj.

In any of the record in Govt. of Indian Department , This organization was not headed by Satpal Maharaj.

Satpal Mahraj is founder of Manav Utthan Sewa Samiti - A Non-profitable organization registered as per Society Registration act of India, 1961.

Manav Utthan Sewa Samiti's registration no is S/7341/1974

Devine Light Mission was headed by Prem Rawat.

Mentioning of Devine light Mission under this article is again to vandalize the image of a person.

Wikipedia:Contributing to Wikipedia is a new article (revamped to be honest) that I believe would be a great asset to many potential editors. I have a simple proposal to add the link Contributing under the "Interaction" section on the main left hand-side navigational links. lots of work has gone into the article with videos and all. We currently have links to info about Wikipedia its self, where people can help (Community portal) and a link to "Help:Contents". I believe a direct link to our MAIN "how to page" is a good idea over having to read over the "Help:Contents" to find the how to pages. I am not sure if this is the right place or not - but nevertheless I am trying to get a feel for this idea. -- Moxy (talk) 07:48, 18 July 2014 (UTC)[reply]

Make article titles case-preserving, not case-sensitive

Currently, the title of a Wikipedia article is case-sensitive except for the first character. This means allows articles like Gentleman's Agreement and gentleman's agreement to exist side by side. (If there is more than one place where a letter after the first might be capitalized, there can be more than two similarly titled articles.)

I submit that:

  • Instances where this is actually useful are quite rare.
  • Most computer searches, including Google's, treat words and phrases case-insensitively, so that's what most people will find obvious.
  • Library catalogs likewise access titles case-insensitively (indeed, the ones I'm familiar with don't even preserve the case of the original title).
  • The idea that in Wikipedia the first character is treated differently is additional level of non-obviousness, but does not cause any major problems.

On the other hand:

  • Disambiguation of similar article titles by suffixes like "(film)" or "(aviation)" or "(politician)" is common on Wikipedia and easily understood, and could easily be applied to cases like the example by renaming to "Gentleman's Agreement (film)" or "gentleman's agreement (concept)".
  • Indeed, in a number of cases the lower-case article is a disambiguation page that might as well have been named using the standard suffix "(disambiguation)".
  • In cases where such similarly titled articles exist, there is generally a hatnote pointing from each to the other. If the reader who opened gentleman's agreement wanted Gentleman's Agreement, their experience by following the hatnote will be no different if it points to "Gentleman's Agreement (film)".

I therefore propose that article titles should become case-preserving but no longer case-sensitive. Obviously this transition can't be done in a single step, but I propose the following sequence of steps to achieve it (note: I've edited this from my original posting, where I did not quite get it right).

  1. By "canonical name" I mean the lower-case form of an article title. Change the software that interprets URLs and implements the search blank so that if there is no hit on an article name as given, then the canonical name is tried.
  2. By "special redirect" I mean a redirect from the canonical name of an article to its actual name, e.g. from "william lyon mackenzie king" to William Lyon Mackenzie King. Change the article-creation software so that (1) when an article is created or retitled, if its title is not already in canonical form and there is no existing article with the canonical form of the title, then a corresponding special redirect is also automatically created; and (2) no further articles with the same canonical name as an existing article can be created, except for special redirects. Simultaneously change the editing software so that if an article is already a special redirect, it cannot be edited.
  3. Using a one-time bot, find all cases where the article title contains a capital letter and the canonical name is not already used for an article, and create a special redirect. If there are multiple articles whose canonical name would be the same, but no existing article whose name is the canonical one, the bot should create only one special redirect, making an arbitrary but sensible choice as to which one it redirects to: perhaps to the largest of the existing articles, or the one with the longest version history, or the one with the fewest capital letters in the title.
  4. Start a project where people would identify articles whose titles differ only in case, and retitle at least one of each such pair (or group), adding or cleaning up hatnotes as necessary. Redirects to other capitalizations of the same name, except for special redirects, can be deleted during this process. Once the process is complete as well as the above technical changes, the desired effect has been achieved.
  5. When this is complete, the final optional step is to clean up the article database to eliminate the special redirects. To do this, the database would be changed to make the canonical name the primary key for accessing each article, with the actual (case-preserving) title stored as an additional data item.

In writing all this, I primarily have English in mind, but of course the same would apply to titles in other languages that have the concept of case—and I guess to Wikipedias in all languages.

That's all I have to say. I don't plan to get involved in any way with the project I'm proposing, and if the Powers That Be think the whole idea is a non-starter, that's their prerogative. But I think it's a clear win, and I think the sequence I've set out should avoid situations where "you can't do that". Given that case-sensitive titling has always been kind of unexpected, I was actually a bit surprised that I didn't find it on the "perennial proposals" page; but I didn't, so I'm proposing it now.

--50.100.189.160 (talk) 06:09, 20 July 2014 (UTC)[reply]

  • Support! In principle, I think this is a fantastic idea. Imagine all the redirect-cruft from variant capitalizations that could be swept away forever!
⋮
I do have a quibble or two with the proposed implementation. For example: for the same reason that the "eBay" article is technically at "EBay", the "canonical" version of an article title should be the "display" title rendered entirely in lowercase, except for the first character, which, if a letter, should be in uppercase. This would not only accommodate the existing technical requirements of the MediaWiki software, but would also have the additional benefit that the vast majority of articles' "canonical" and "display" titles would be identical, in which case no "special redirect" would be necessary. Also, it would be worth considering that if a URL containing the name of an article incorrectly capitalized were followed, then MediaWiki would respond with an HTTP redirect, using either status code 301 (Moved permanently) or 303 (See other), to the URL with the article name capitalized correctly (i.e., matching the article's "display" title)—rather than accepting the misspelled URL and presenting the article page with a "(redirected from …… )" hatnote.
⋮
One hurdle to overcome will be the fact that usernames are case-sensitive, and it would not be feasible to make the "User:" and "User talk:" namespaces case-insensitive—at least, not to the left of the first "/" character. I also anticipate some grumbling about the special role of ALL-CAPS titles as shortcuts to things in namespaces such as "Help:" and "Wikipedia:". I'm not sure how much of a "collision" problem there would be if these namespaces were rendered case-insensitive, but my guess is that the number of WP:SHORTCUTS that share a spelling with a non-shortcut page to which they don't redirect (or both don't redirect to the same target) is very, very small.
⋮
In sum, while the implementation would be non-trivial from a technical standpoint, much of it could be automated, and my intuitive impression is that this change would be warmly welcomed by our readers and editors. — Jaydiem (talk) 22:14, 21 July 2014 (UTC)[reply]
  • Just to amplify what I said earlier about "redirect-cruft": A quick look at Category:Redirects from other capitalisations finds that it contains a mind-boggling 397,446 redirects, of which I'll bet at least 99% are completely pointless. And that number doesn't include what must be many more such redirects that exist but aren't linked to the category. We are talking about something on the order of half a million redirects that could be completely done away with by adopting case-insensitivity. It's a beautiful thing! — Jaydiem (talk) 07:19, 22 July 2014 (UTC)[reply]
  • Support These seems like it could solve several conflicts as well. I believe one of the reasons why sentence case article names makes sense is because when articles are linked in sentences it goes to the case linked. If we made them all equivalent it could mean that we could use title case for article names without requiring redirects or pipes in the links. This would allow some of the recent capitalization style differences of opinions to be less important. I think in addition to folding letters, certain symbols should be folded together as well. For example treat "-", "/", "–", and "—" as interchangeable when resolving the page. This means that the correct hyphen, or dash can be used in a title but that it could be found with the standard hyphen-minus character. It could also solve the upper vs lower case first character issue. I'm not sure we need to use 301 or 303 codes. I might suggest making the canonical URL always be the lowercase forum ( etc. ), and just store the preferred capitalization along with the article either internally as a separate data field, or similar to how article names are handled inline for lowercase letters. In which case all interwiki links should always then go to the canonical forum. PaleAqua (talk) 03:20, 22 July 2014 (UTC)[reply]
  • Oppose. Instances where disambiguation can be provided entirely via capitalization are not rare - they generally occur when a common noun is appropriated by an organization or creative work as its name. No need to add extra bulk (which also makes wikilinks to those articles more annoying to create as they must be piped). -- King of ♥ ♦ ♣ ♠ 03:49, 26 July 2014 (UTC)[reply]

RfC: Should Persondata template be removed from articles?

Background (Persondata)

The question keeps arising on Wikipedia talk:Persondata and other forums on whether we should drop persondata now that Wikidata provides the same or similar information. I usually state eventually that is the goal, but I haven't heard anything else about it. I decided this time to be more proactive about it.

From Wikipedia:Persondata, "Persondata is a special set of metadata that can and should be added to biographical articles only. It consists of standardized data fields with basic information about the person (name, short description, birth and death days, and places of birth and death) that, unlike conventional Wikipedia content, can be extracted automatically and processed by cataloging tools and then used for a variety of purposes, such as providing advanced search capabilities, statistical analysis, automated categorization, and birthday lists."

At this time, I'm not aware of anyone using the data. DBpedia does gather the information and offers it for download. However, I'm not aware that they use it. Wikidata did have two bots running, which copied |SHORT DESCRIPTION= from persondata and put it into Wikidata. One bot worked only on dewiki. SamoaBot did work on enwiki. SamoaBot's operator stated that he doesn't "...recall having run that task in these months. However, tons of data have already been imported, and now it is up to the English Wikipedia community to decide whether they still want those data within articles." I did ask Wikidata about persondata.

{{Persondata}} does have many drawbacks. Some of which are:

  1. It is hidden, therefore it is often out of sync with the article text or infobox, with no current mechanism to keep it in sync.
  2. If an infobox is present, persondata becomes redundant.
  3. It is currently not being used by anybody (to my knowledge).
  4. |NAME= and |ALTERNATIVE NAME= parameters have no standard format. Format should be surname, firstname, but this isn't always followed. When a person as a stage/pen name, there is not standard on which parameter parameter gets what name.

Positives:

  1. If the article doesn't have an infobox, persondata can become a source of info.
  2. |SHORT DESCRIPTION= is of use to Wikidata.
  3. From Periglio's talk page, "Wikipedia has an easy accessible database of over 1 million people. It is data available for serious research projects. Why delete it?"

Question: Should the {{persondata}} template be removed from all articles and no longer be used?

Proposed by Bgwhite 21:21, 20 July 2014 (UTC)[reply]

Discussion (Persondata)

  • Have a comment?
Before implementing this change all the gadgets and tools that create or use this template must also be changed. Otherwise we will get them being created when others are trying to get rid of them. A comparable situation where the cite gadget creates "deprecated" cite template parameters that bot(s) go around undoing. So this should be done as a proper release, where wikidata, gadgets and tools are all synchronised with the policy implementation to stop wasted effort. Graeme Bartlett (talk) 22:08, 20 July 2014 (UTC)[reply]
Graeme Bartlett, Wikidata is currently not ingesting anything from Persondata. I'm aware of two tools that create Persondata, Persondata-o-matic and AWB. An AWB developer is aware of this proposal. Persondata-o-matic currently doesn't work. There are some scripts/gadgets that do allow for easy viewing persondata. Bgwhite (talk) 22:17, 20 July 2014 (UTC)[reply]
So I think that Wikidata should ingest this. It will be harder to harvest from history as it may not be possible to tell the "correct" version. AFC reviewer tool currently adds persondata. Graeme Bartlett (talk) 06:02, 21 July 2014 (UTC)[reply]
If this goes ahead, someone (I'm willing to help) will need to close up the Persondata and WikiProject Persondata and related pages. Also maybe notify members of the project (and places like WP:BIOG) that persondata is going to be removed. Is there a way of setting up an ongoing bot to send messages to users who add new persondata?—Msmarmalade (talk) 08:09, 21 July 2014 (UTC)[reply]

User:Rjwilmsi's bot occasionally adds/updates Persondata using AWB but it should be very easy to diactivate AWB's after we agree to stop adding/remove Persondata. -- Magioladitis (talk) 08:24, 21 July 2014 (UTC)[reply]

Wikipedia:WikiProject Biography and Wikipedia:WikiProject Infoboxes about this discussion. -- Magioladitis (talk) 08:27, 21 July 2014 (UTC)[reply]

My main concern is Category:Biography articles without infoboxes. This means we have 20,000+ that may have Persondata and not an infobox. -- Magioladitis (talk) 08:40, 21 July 2014 (UTC)[reply]

Maybe it would be a good idea to add infoboxes to most of these pages so that we reserve the information in the article and in a visible place? -- Magioladitis (talk) 16:40, 23 July 2014 (UTC)[reply]
@Magioladitis: do you mean automatically create infoboxes and transfer Persondata to them? One consideration in that case then, is articles where there isn't enough information to justify an infobox (Although I'd like to see almost every page with an infobox anyway, I think the general consensus is that infoboxes without enough info are an eyesore). For example, if only |NAME= is available, the infobox is unnecessary as you can (usually) get that info from the article title. Perhaps these sorts of persondata can be deleted early on.—Msmarmalade (talk) 02:34, 24 July 2014 (UTC)[reply]
@Msmarmalade: we can select some rules (size of page, at least 3 fields are filled, etc.) and create infoboxes using a bot only for these cases. Still much better than now. -- Magioladitis (talk) 05:02, 24 July 2014 (UTC)[reply]

How reliable is Persondata anyway? in this edit a malformed article title was used to create a malformed NAME, and DATE OF BIRTH was copied from the completely unsourced infobox (it's not present in the body of the article). Where does that leave Persondata - or Wikidata if it scrapes up "information" using the same rules? PamD 10:40, 21 July 2014 (UTC)[reply]

  1. Questions - Perhaps it's just me, but there seems to be a failure of communications at work here. Even now, many WP editors remain in the dark about what Wikidata is doing, and how it will affect WP articles. In this example, for instance, would the supplantation of persondata by corresponding wikidata yield better WP articles? Will it, for instance, automatically populate WP infoboxes? What would the differences look like? How would they be made compliant with BLP, V, and other WP policies? Would WP editors still be able to correct errors, without having to learn their way around Wikidata? Are there some examples in place to show how these things will operate? LeadSongDog come howl! 20:40, 21 July 2014 (UTC)[reply]
    @LeadSongDog:. Some data in the infoboxes could be fetched from Wikidata, but that does not seeem to be the matter at hand here. {{Persondata}} is not meant to be used to populate infoboxes. -Superzoulou
    Thanks, but that really doesn't clear much up. The content of {{Persondata}}, {{Infobox person}}, etc should reasonably be automagically verifiable against the categories the article is put into. References supporting the assertions that cause those categories to be applied must be maintained if we are to avoid finding Koffi Annan in Category:Bollywood stars or something equally absurd. Will/does wikidata support checks to see that the categories are supported in the article, with references? Does it have a mechanism to support variances in sourcing policies between the different WP languages, or at least to attribute the sourcing to the WP language and article where the assertion originates? Vandalism isn't going to be disappearing anytime soon, after all. LeadSongDog come howl! 21:53, 21 July 2014 (UTC)[reply]
    I do not really understand what you are talking about. This proposal is not about deleting {{Infobox person}} and afaik, there is no consistency check between persondata and categories. Actually, I do not see how a bot could use Persondata in their current form to know that Koffi Annan should not be categorized as a Bollywood star.
    Many bots have added from which Wikipedia the data originated in the source part of the statement. One has added the actual reference that was used in the article (but this is more difficult so less widely implemented at the moment). --07:16, 22 July 2014 (UTC)

 Comment: There actually appears to be actually two issues:

  1. should we work toward removing Persondata now ?
  2. should we delete data from Persondata wtihout checkign with have their data in Wikidata first ?~

I am certainly in favour of 1), not of 2): if data in persondata match those in Wikidata, they can be deleted. It is a bit pointless that when we want to correct some data, we need to do it in two pages instead of one. But when there are gaps in Wikidata/mismatch with persondata, it should be checked before deleting anything. --Superzoulou (talk) 07:16, 22 July 2014 (UTC)[reply]

In that case, perhaps we should have a {{persondata moved to Wikdiata}} which can be applied (by humans or bots) once the data is verified as being in Wikidata. It should prevent further addition of Persondata, and enable us to check progress statistics. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:27, 22 July 2014 (UTC)[reply]
Once the data is in Wikidata, I think we can simply delete it, so we would rather need {{Persondata inconsistent with Wikidata}}. At the same time, we should obviously stop creating new persondata here. That means, among other things, updating scripts like User talk:Dr pda/persondata.js by user:Dr pda so that they add the data to Wikidata instead of Wikipedia. -Superzoulou (talk) 13:23, 22 July 2014 (UTC)[reply]
The one question that no one is answering is how Wikidata is being maintained? Another example I have just come across is Ed Vokes. Someone updated his birth and death dates on Wikipedia two months ago (16 May 2014). Although the editor updated Persondata but Wikidata still shows the old information. Periglio (talk) 17:21, 26 July 2014 (UTC)[reply]

Support (Persondata removal)

  1. Support, unless anyone shows a temporary need to retain the data while it is copied to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 20 July 2014 (UTC)[reply]
  2. Support as redundant, --Gerda Arendt (talk) 22:07, 20 July 2014 (UTC)[reply]
  3. Support as redundant. I've never added it to an article, never understood why. Sometimes have to fix work of others who insert inconsistent data. Montanabw(talk) 02:48, 21 July 2014 (UTC)[reply]
  4. Support per others. --AmaryllisGardener talk 03:27, 21 July 2014 (UTC)[reply]
  5. Support as long as it is implemented cleanly, (see discussion above) and the information therein is not lost. This sort of data should appear in Wikidata instead, and is not really "encyclopedic" in itself. But it could be a tool to populate indexes, categories, or add to author records - more the thing for Wikidata. Graeme Bartlett (talk) 06:05, 21 July 2014 (UTC)[reply]
  6. Support as reduntant. Perhaps afterwards, focus should move to cleaning up infoboxes, and standardizing the dates, data, etc within them.—Msmarmalade (talk) 07:47, 21 July 2014 (UTC)[reply]
  7. Support as redundant. The use to which this data is potentially put is dubious, and the fact that it isn't sync'd seems to make the whole thing pointless. I'd like to see the automated insertion by AWB switched off immediately, and its complete reversal (into 'systematically remove' mode and not just neutral) if the RfC goes through. -- Ohc ¡digame! 09:10, 21 July 2014 (UTC)[reply]
  8. Qualified support remove data that are identical on to those on Wikidata so that we do not need to maintain them at two places. Check and then remove the other ones. --Superzoulou (talk) 10:11, 21 July 2014 (UTC) + Superzoulou (talk) 11:01, 22 July 2014 (UTC)[reply]
  9. Support Finally the time has come. You always had the highlights and details in infobox, there was no need of persondata like others may have thought as well. OccultZone (Talk • Contributions • Log) 10:44, 21 July 2014 (UTC)[reply]
  10. Support as redundant, and an annoyance to maintain. These can also be a pain to fix when disambiguating links because the link is there, but invisible. bd2412 T 13:33, 21 July 2014 (UTC)[reply]
  11. Support I like the idea of using a tool designed to keep track of this sort of data to keep track of this sort of data. Zell Faze (talk) 14:04, 21 July 2014 (UTC)[reply]
  12. Support, though make sure that the data we are removing already exists in Wikidata first. Cbrown1023 talk 17:45, 21 July 2014 (UTC)[reply]
  13. Support eventual removal - as and when we are confident it's been migrated to Wikidata. Removal on a case-by-case basis when migrated would be reasonable, and then deprecating the system. Andrew Gray (talk) 19:53, 21 July 2014 (UTC)[reply]
    Andrew Gray, Wikidata will not import anything but |SHORT DESCRIPTION=. A bot has already imported this data and will run again before Persondata's removal. Bgwhite (talk) 19:59, 21 July 2014 (UTC)[reply]
  14. Support The only reason I include persondata in my new stubs is because they otherwise got inserted with incorrect or incomplete data. I have never used the persondata and I believe it is redundant now with Wikidata - maybe someone could run some numbers on the accuracy of persondata vs Wikidata for 100 random biographies? depending on the results we could just rip them all out. Alternatively, we could agree to no longer insert persondata and manually delete whenever we check Wikidata and see the data exists on Wikidata. Jane (talk) 09:10, 22 July 2014 (UTC)[reply]
Comment: I first create a stub on English Wikipedia, then I create the Wikidata item (if it doesn't already exist). When I create a new Wikidata item it imports the persondata so I don't need to type it over. I would not want to see persondata disappear before my workflow changes (i.e. first make improve WD item, then create stub from that). Now WD lets me import the stub, but so far I can't import the WD item to WP. Jane (talk) 13:04, 26 July 2014 (UTC)[reply]
  1. Support as redundant, Since I don't use WikiData I find PersonalData to be absolutely useless anyway. –Davey2010 • (talk) 18:58, 25 July 2014 (UTC)[reply]

Oppose (Persondata removal)

  1. Oppose: First of all, the claim that Persondata are currently not being used by anybody is wrong. Tools that evaluate Persondata exist and are being used. Secondly, Wikidata cannot be taken seriously at this stage as its data (beyond the interwiki links) are simply not reliable. As elaborated in this discussion, Wikidata looks like a Wikipedia from 2003 without any references. A Wikipedia article, however, combines both, literature and references that backup the data given in the Persondata template. At the current state of affairs, the Wikipedia articles and their Persondata records should be considered as a source, not as a target for Wikidata. --AFBorchert (talk) 08:32, 21 July 2014 (UTC)[reply]
    And another observation: I just took a first look at one of the dumps of wikidata. They are as ugly as hell as they are embedding JSON within XML. To extract person data from Wikipedia dumps is pretty simple (and frequently done). This fun will be all gone when you have to turn to Wikidata dumps. --AFBorchert (talk) 08:43, 21 July 2014 (UTC)[reply]
    AFBorchert:
    Wikidata does not contain enough references, but English Persondata do not contain any, so I do not really understand what your point is. The real question would be which is more reliable between birth/death place/date in Wikidata and in English Persondata. I see no argument one way or the other.
    German Persondata appear to be more used than the English ones, but the discussion for removing them should be done in Wikipedia in German. Does any German tool use English Persondata ? --Superzoulou (talk) 09:56, 21 July 2014 (UTC)[reply]
    @Superzoulou: Persondata are embedded in articles that (hopefully) provide references to backup this data. Hence, you have both, data and references in one place very close to each other. If the article is updated in this regard, the persondata can be easily adapted in one edit. At Wikidata we have mostly a heap of data without any references. This does not help us and is surely no replacement for the current Persondata. I refered to the German discussions as de-wp as this was debated there half a year ago. I think it is always worthwile to look into other similar projects and their discussions. And indeed the Persondata were introduced at de-wp and later imported to en-wp. It is surely a predecessor to Wikidata and at some time it may be envisioned to deprecate it but currently I would see it as a great tool that helps in the transition to Wikidata which is not yet sufficiently mature to replace it in my opinion. --AFBorchert (talk) 11:54, 21 July 2014 (UTC)[reply]
    @AFBorchert: English Persondata are mostly meant for bots that are not smart enough to read the rest of the article, and for them references elsewhere in the page are not really useful. It is true that people who maintain the template can check the consistency between Persondata and the rest of the article, but I wonder how many people do it by hands. Bots can also check the consistency of the data between Wikidata and Wikipedia. --Superzoulou (talk) 13:17, 21 July 2014 (UTC)[reply]
    @Superzoulou: I do it “by hand” at en-wp as well as de-wp. And indeed the consistency check between Wikidata and Wikipedia is an important advantage that would get lost if we would give up Persondata too early. With very few exceptions, I do not edit data records corresponding to Persondata at Wikidata as it is no fun for me to click through all the Javascript-based forms. Wikitext can be edited far more conveniently (and if necessary even by an editor of my choice like Vim), I do not want to waste my time with clicking through a myriad of forms. --AFBorchert (talk) 13:28, 21 July 2014 (UTC)[reply]
    @AFBorchert: Consistency of Wikidata can also be checked against infoboxes, and even against the article's lead (Wikidata items about people are marked as such so which avoids the occasional topic mismatch between the infobox and the article proper). --Superzoulou (talk) 14:44, 21 July 2014 (UTC)[reply]
    @Superzoulou: Many biographic articles do not have infoboxes but Persondata (example). --AFBorchert (talk) 20:05, 21 July 2014 (UTC)[reply]
    @AFBorchert: I know, and I would suggest that we should start the removal with pages with infoboxes. But the data can also be parsed from the article's lead (admittedly, only as an occasional bot task, not like permanent check thourgh templates). Superzoulou
    @AFBorchert: concerning the ugly dumps, the new JSON version will hopefully make things easier [3]. --Superzoulou (talk) 15:28, 23 July 2014 (UTC)[reply]
  2. Oppose (from wikiproject templates): until wikidata is brought online, persondata needs to stay in order to populate wikidata with the largest source we have of data on article subjects. I know that AWB automatically copies information from infoboxes to persondata, so there is obviously significant overlap on those two, and I am absolutely convinced that persondata's usefulness will soon expire. But we need to keep this on enwiki, up until a bot goes through and copies the persondata entries to wikidata (just like they did with interwiki links), and no later; nobody else has nearly the comprehensive coverage of biographies that would facilitate that transfer. VanIsaacWScont 09:28, 21 July 2014 (UTC)[reply]
    @Vanisaac: In what way is Wikidata not "online"? Are we confident that Persondata is reliable (accurate and up-to-date) enough to be copied to Wikidata? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:58, 22 July 2014 (UTC)[reply]
    It's not online in the same way that Obamacare is not online: Yeah, there's a lot of the substantive stuff that's there now, and the different features are getting implemented roughly when they are supposed to, but there's still more to come as time progresses, and it's going to take some effort by people to get to the level of coverage that the system was designed to have. VanIsaacWScont 10:04, 22 July 2014 (UTC)[reply]
    @Vanisaac: So you object to deprecating persondata in favour of Wikidata, even though Wikidata does everything that persondata does, and much more besides, because Wikdiata will do even yet more in the future? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 22 July 2014 (UTC)[reply]
    Please go back and actually read what I wrote. I object to removing persondata before it's been copied over to wikidata, since enwiki's persondata is likely to be one of the most robust and comprehensive sources for wikidata. That's what "we need to keep this... until a bot goes through and copies the persondata to wikidata" means. Since that has not yet happened, I oppose deprecating persondata at this time. There might also be an argument for keeping it supported after that time, if the transfer bot remains in operation, so that it can be used as a backdoor wikidata upload. But without any details about the wikidata transfer bot, that's merely speculation. VanIsaacWScont 13:03, 22 July 2014 (UTC)[reply]
    Yes, I understood that from your original comment, but in the light of it, and of your more recent comments, I cannot make sense of your "until wikidata is brought online" clause. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:23, 22 July 2014 (UTC)[reply]
  3. Oppose — this seems slightly premature, and the linked discussion from Wikidata seems to indicate that they would not like to see Persondata nuked just yet. Titoxd(?!? - cool stuff) 18:26, 21 July 2014 (UTC)[reply]
  4. Oppose. The proposer has not provided any English-language documentation demonstrating that Wikidata is, or soon will be, a fit successor to Persondata. Jc3s5h (talk) 19:47, 21 July 2014 (UTC)[reply]
    • Jc3s5h, Nobody currently uses the data contained in Persondata. How can there be a successor to something nobody uses? People do use Wikidata and DBpedia. Bgwhite (talk) 20:26, 21 July 2014 (UTC)[reply]
      • The proposal uses Wikidata as partial justification for the removal, but there is no link to any documentation about the part of Wikidata that would cover people. As for nobody using Persondata, there seems to be some disagreement about that. Jc3s5h (talk) 20:51, 21 July 2014 (UTC)[reply]
    • @Jc3s5h: Wikidata entries for people include a |label= property, which is the equivalent of |SHORTDESCRIPTION=, but also multilingual. They also have |Also known as=, |date of birth=, |date of death=, |place of birth= and |place of death=. Not to mention dozens and dozens of other properties, not available in Persondata, such as |gender= and |VIAF identifier=. See, for example d:Q17279725. Each property can be programatically displayed in Wikipedia templates such as infoboxes, succession boxes, etc. - unlike Persondata. In short, Wikidata does everything that persondata does, and much more besides. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)[reply]
  5. Oppose. I am just using Persondata to populate some missing birth/death dates in Wikidata; there are hundreds of thousands of statements that can be used on Wikidata. And if Wikidata were fully "populated", there is no reason to run bots to sync; the template can automatically show Wikidata information if no local data is set, and even add the page to a maintenance category if both is the case, so the information can be merged on Wikidata, and the local data can be removed. Once that is done everywhere, we can think about removing Persondata. Not before. --Magnus Manske (talk) 22:44, 21 July 2014 (UTC)[reply]
    1. @Magnus Manske: I fear a misunderstanding; Persondata is not displayed in this wiki. When do you anticipate finishing your bot run? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:42, 22 July 2014 (UTC)[reply]
      1. I am aware that it is not displayed here. I have only just started with the bot; there are many cases (e.g. "fuzzy" dates) that I am not sure how to handle yet. IMO it would be beyond strange to destroy data in the Persondata template unless we can be sure it has been properly synchronized with Wikidata. --Magnus Manske (talk) 09:13, 22 July 2014 (UTC)[reply]
        1. @Magnus Manske: Thanks for the prompt response; I was referring to your "the template can automatically show Wikidata information" comment. Are you confident that the persondata you are importing is accurate and up-to-date? Do you check it against visible values in the infobox, or lede? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)[reply]
          1. @Pigsonthewing: Probably the wrong place to discuss my bot's internals, but I also use the Infobox, and the German Personendaten template; I import the highest precision value into Wikidata, with "source". --Magnus Manske (talk) 12:18, 22 July 2014 (UTC)[reply]
  6. Oppose People do use persondata. I am using the data extracted from Persondata on my own website to generate facts eg "Who is 50 years old today". Although my use may be regarded as trivial,it shows that Persondata is available for serious research - births and deaths of over a million notable people. A lot of people are stating that Persondata is not used, but on what evidence? Extraction tools exist, who knows what people do with the article they download?
    My second reason for opposing is that based on my own experience, Wikidata does not provide a reliable alternative for birth and death dates. Admittedly, there appears to be an editor who updates Wikidata death dates as soon as they happen, but new articles and fixes to old articles do not get onto Wikidata. Someone editing an article would not necessarily think that they need to fix Wikidata as well.
    Finally, again from my experience, Persondata is pretty accurate. I expanded my own software to validate the extract, comparing dates against categories for example. There were only two or three thousand entries, from 1.1 million articles, where persondata had vandalised or out of date data and I am currently fixing those! Periglio (talk) 23:38, 21 July 2014 (UTC)[reply]
    @Periglio: Why are the results of a "Who is 50 years old today" query on Wikidata not acceptable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:39, 22 July 2014 (UTC)[reply]
    @Pigsonthewing:Because I would miss Joe Gulla who is 50 tomorrow (at time of writing in my time zone). My point is that no one has explained how Wikidata gets updated when an average editor adds a date to an article. I remain opposed until I know Wikidata is not just a snapshot at the time the original bot ran. Periglio (talk) 21:12, 22 July 2014 (UTC)[reply]
  • @Periglio:. At the moment, I do not think this sort of update is done systematically. But again, is it done for Persondata ? If so, it should be possible to update the system so that it updates Wikidata instead. --Superzoulou (talk) 09:46, 28 July 2014 (UTC)[reply]

Wibe | Surf Wikipedia with the Power of YouTube

Hi,

I am Akshit (Co-Founder of Wibe), we have made a Chrome Extension by which anyone will be able to watch relevant YouTube videos corresponding to the Wiki Article they are reading.

It is the deadly combination of Wikipedia and YouTube, it can really become a great new feature of Wikipedia. We developed it to solve our problem of switching to YouTube from Wiki to understand a particular thing.

I would be very thankful if you please try and review it. Then if you like Wibe, consider it to integrate as a functionality in Wikipedia for some days so that user can use and review this new feature.

Install the Extension and then try out "http://en.wikipedia.org/wiki/Wikipedia:About" page to see how it changes the original wiki page by integrating relevant videos from YouTube.

Cheers,

Akshit Agarwal (Co-Founder, Wibe)

Cool, But What Happens if Youtube is inaccessable? Wibe Messes up Chrome. Maybe we could integrate it into Wiki by having a <Youtube> Tag

Example:

Text Text Text <Youtube HTML= "https://www.youtube.com/watch?v=98uDPo7ZjVI">

Appears Like;

Text text Text [Youtube Video]

Just a Thought, TitusFox'Tribs 15:58, 21 July 2014 (UTC)[reply]

This cannot work with Wikipedia. First, you cannot embed external videos in a wiki article, unless they are explicitly published under a free license. 99% of the videos on YouTube are copyrighted and unsuitable for inclusion in Wikipedia. Second, even linking to such videos in the External links section of an article would not work without direct user supervision. Per WP:YT "Many videos hosted on YouTube or similar sites do not meet the standards for inclusion in External links sections, and copyright is of particular concern. Many YouTube videos of newscasts, shows or other content of interest to Wikipedia visitors are copyright violations and should not be linked. Links should be evaluated for inclusion with due care on a case-by-case basis." (emphasis mine) This means you cannot just automatically link to a bot-generated collection of videos in an article - they will be most likely either not completely relevant or possible copyright violations. 2Flows (talk) 16:53, 21 July 2014 (UTC)[reply]

It would be a pleasant notion for me and the Dell XPS-10 with Win 8.1 RT that I'm using today. Its built in browser cannot see Wikipedia's OGG videos and it cannot install other browsers. Sending a copy to a video site that allows ordinary video formats would be a somewhat clumsy solution if Wikipedia policy allowed linking to such a video. It makes me wonder why allow video at all, and yet so restrict it as to make it unworkable. Jim.henderson (talk) 18:19, 23 July 2014 (UTC)[reply]

Assuming that you were to manually evaluate the relevance and copyright status of a YouTube video and decide that it was worthy of inclusion, I wouldn't be too opposed to the superscript-form link. Dustin (talk) 18:34, 23 July 2014 (UTC)[reply]
Some time back I noticed another Wiki that did something similar to the above but didn't seem to last. I have always thought video was the one area that Wikipedia needs to grow in leaps and bounds but to do so might mean a project related to those editors that wish to create videos for Wikipedia and guidelines would need to be established to be sure copyright was being respected and adhered to. It could be opening a can of worms but I think the idea is sound. Sometime ago I made a video for an article I am a major contributor on. I did make a mistake and used an image that did have a copyright. I was lucky because the copyright holder liked the video and contacted me twice. Once in regards to attribution that I mistook for a take down request and so, removed the video. They contacted me after I removed the video and said I could use the images as along as I attributed the company and person who created it, so now the copyright has been granted (I reproduced the video to add the credit and not just drop it in the video summary on Youtube). Now...if we produced videos and ONLY used content from Wikipedia and Wikimedia commons, all that would be required is attribution. I wish we had a project where editors could produce videos for pages that are copyright free. I think it might be a good way to improve some of our articles.--Mark Miller (talk) 19:45, 23 July 2014 (UTC)[reply]
Just how would production of videos improve any articles? Is this an echo of the recent proposal of having video summaries? ~ J. Johnson (JJ) (talk) 20:17, 23 July 2014 (UTC)[reply]
That is a legitimate question and can only be answered with opinion I suppose but I know nothing about the "video Summaries" issue. In my opinion a video could be watched to enhance one's understanding of the topic or additional content could be provided to add to the article itself and not just summarize what is already written.--Mark Miller (talk) 20:41, 23 July 2014 (UTC)[reply]
Most tools and most sports ought to have video. Bark hack and Curling and many, many others. Jim.henderson (talk) 20:53, 23 July 2014 (UTC)[reply]

Automating mergers

I hope it's okay to post here to draw a bit of attention to WT:Merging#Automating the perform. Anna Frodesiak (talk) 00:43, 23 July 2014 (UTC)[reply]

I tweaked your link to head to Wikipedia Talk space, hope you don't mind. Monty845 00:49, 23 July 2014 (UTC)[reply]
Thank you for catching that. :) Anna Frodesiak (talk) 05:30, 23 July 2014 (UTC)[reply]

Quality review for policy pages, guidelines, and high-impact essays

Would the project benefit if we had a semi-formal mechanism for submitting policy pages, guidelines, and high-impact essays to some sort of semi-formal assessment, from a quality and clarity of writing point of view? If that is of interest, as part of its execution I'd especially like to see a form of Usability testing where eds were asked to read and then say back what they think the text of these pages means. This is a way to

  • Identify matters where such pages have fallen behind the evolution of consensus, and
  • Sniff out technical writing that needs to be improved for clarity.

A semi-formal process would also help bring fresh eyes and new vigor to efforts at improvement, where the status quo is too strong for editors who stop by one-at-a-time to really market improvement ideas.

If this is a perennial topic, I apologize for not spotting the thread and would be grateful for a link. NewsAndEventsGuy (talk) 00:26, 24 July 2014 (UTC)[reply]

I actually have just had this put on my talk page and frankly ...I have no clue what this editor is attempting but is quacks too loud for me.--Mark Miller (talk) 04:30, 24 July 2014 (UTC)[reply]
Goal is to discuss an idea that could lead to even better technical writing to describe current consensus, in the belief this could reduce misunderstandings. That would have the following benefits
  • Lighten the load on administrators and DR volunteers,
  • Increase editor enjoyment, and
  • Make such pages more newbie-friendly thereby contributing to editor retention.
NewsAndEventsGuy (talk) 09:09, 24 July 2014 (UTC)[reply]
We already have a review process for new articles. How is this different?--Mark Miller (talk) 17:10, 24 July 2014 (UTC)[reply]
Sounds like you mean AFC for new articles as described at Wikipedia:So_you_made_a_userspace_draft#Ready!. This is different in that it pertains to things other than "articles" and it is about existing things instead of just new ones. NewsAndEventsGuy (talk) 17:27, 24 July 2014 (UTC)[reply]
No, I mean new articles as well as articles that have existed for a limited amount of time (in the main space), are all reviewed by editors to check if they are legitimate articles. AFC is for reviewing only drafts. So your proposal is to go back through every article (or, I guess a nomination process) and re-review it under new standards that, while your proposal states this to be akin to Usability testing sound more like Usability inspection because you are not testing the "product" (the article) on real users but asking for experts to evaluate the article. Giving you the benefit of doubt could you detail exactly how this would improve the load for the DR volunteers, increase editor enjoyment and contribute to editor retention? As an editor that volunteers at the DR/N and very much concerned with editor retention, I just don't see how this would improve those areas.--Mark Miller (talk) 18:04, 24 July 2014 (UTC)[reply]
It's a good but premature question about the mechanics, but the question is whether the community perceives a partially unmet need. If there is no need, then no one needs to spend brancells on suggesting possible mechanics.

For articles, we did decide that the "regular editing process" was good, but could be improved by creation of the Wikipedia:Version 1.0 Editorial Team/Assessment process. What about these other pages? The "regular editing process" is good for Policies/Guidelines/HelpPages/HighImpactEssays, no question about that. The question I'm asking is whether those pages could be even better with some sort of quality assessment process... not designed to alter their operation, but to provide another perspective on the presentation. NewsAndEventsGuy (talk) 18:38, 24 July 2014 (UTC)[reply]
We already have a quality assessment process. But I would like to understand your position on how any of this would effect the areas you mention. They are too important to me not to have those answered, since you brought it up as the reasoning for the change or addition of a new process.--Mark Miller (talk) 19:46, 24 July 2014 (UTC)[reply]
Are you referring to BRD, normal editing, and VPump discussions or something else? If the latter, and there is a link to a specific process please tell me what it is, because I don't know it. NewsAndEventsGuy (talk) 20:29, 24 July 2014 (UTC)[reply]
If you say so. A better assessment is that the "proposals" pump probably wasn't the best location for this question. NewsAndEventsGuy (talk) 06:37, 25 July 2014 (UTC)[reply]
Could be...or it could be that you are not answering questions and don't know the processes that are already in place. I really tried to give you the benefit of the doubt here. I tried to give you the opportunity to explain yourself better than you did on my page before I deleted it as nonsense. You are clearly showing your competency here. I suggest you stop, take time to get to know Wikipedia and regroup. Just lacking competence is not something that will hold you back forever. All one need do is...research. Its what we do here. Try it. But, I also feel you don't fully understand the article link you left and that doesn't give me a lot of faith in your ability to understand what you are attempting.--Mark Miller (talk) 06:56, 25 July 2014 (UTC)[reply]
Whatever you say Mark. NewsAndEventsGuy (talk) 07:02, 25 July 2014 (UTC)[reply]
No. I am just one editor.....but the only one who has responded. It isn't as if this page has no editors viewing it. Seriously dude...if you have to have Wikipedia's quality assessment explained to you and are truly unaware of it.....I don't know what to say but....do you even read the article talk pages before you come to the village pump to make a proposal?--Mark Miller (talk) 07:44, 25 July 2014 (UTC)[reply]
The closest thing to this is probably Wikipedia:WikiProject Policy and Guidelines, which you could try to WP:REVIVE. There's also one for the Manual of Style and another WikiProject specifically for Essays. WhatamIdoing (talk) 18:47, 25 July 2014 (UTC)[reply]
Thanks, I may followup with one or more of those one day. NewsAndEventsGuy (talk) 19:15, 25 July 2014 (UTC)[reply]

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

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)#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]

Allow "suppressredirect" and "move-subpages" within userspace

I would like to request that autoconfirmed users be granted the suppressredirect and move-subpages permissions for moving pages entirely within the subpage hierarchy of their own User: and User talk: pages.

I am aware of WP:Perennial proposals#Grant non-admins admin functions within their user space, but the main objections highlighted there appear to relate to the potential for vandalism committed through nefarious page deletion. This proposal does not have that problem, because (a) it does not grant the ability to delete any pages, and (b) its scope is limited to moves that both originate and terminate within the user's own userspace. This change would significantly benefit those who do a lot of page development in their userspace, and I can't think of any collateral damage that it would cause.

Respectfully submitted, — Jaydiem (talk) 16:00, 24 July 2014 (UTC)[reply]

  • Support if it wouldn't require much dev time to implement. Doesn't seem very prone to abuse, trying to imagine how this could be used nefariously, this is the best I can do: Move page you want to hide to userspace, then move it with suppressed redirect to another userspace name, then create a new page where you first moved it, so that the automatic redirect from mainspace would lead to a normal looking page, with no indication of what happened in the page history. The record of the 2nd move would still be fully visible to anyone who bothered to look at the logs for the page, though the log wouldn't be displayed by default once the new page was created. Also, it would be very obvious what happened to anyone with the original page watchlisted. All in all, I think the convenience factor outweighs the rather minimal risks. Monty845 16:30, 24 July 2014 (UTC)[reply]
  • Unless there are dev issues, no reason not to do this. Writ Keeper ⚇♔ 16:32, 24 July 2014 (UTC)[reply]
  • Support if not too much work for the devs. Also, I presume that these rights would also be enabled in the User talk: space? I.e. to move talk pages of moved articles, to clean up talk page archives etc? BethNaught (talk) 16:09, 25 July 2014 (UTC)[reply]
  • Yes, absolutely, the intention here is for the same rules to apply in the "User:" and "User talk:" namespaces. I'm adding this to the proposal statement for clarity, thanks. — Jaydiem (talk) 17:13, 25 July 2014 (UTC)[reply]

pathfinder

> Good day, > > I am a professional librarian who always recommends wikipedia to my > customers as a great place to start their research obtaining ideas, up to > date entries, search terms they might not have considered, and so forth. > > I woul like to propose that you start a new project area, "Pathfinders" > that provide an additional first stop for these same customers, or > incorporate a pathfinder section in each wikipedia page. > > A disclaimer that every effort is made to provide all sides to an issue if > it is currently the realm of hyperbole, hyperpartisanship, reactionaries, > as well as scholarly research and writing. > > Here is an example of a pathfinder that I co-wrote with some librarian > colleagues a few years ago and provides a basic structural outline that > could be used: > http://odhitech.net/rose/womensciencepathfinder/index.htm > > There are many, many professional librarians who would probably like to > contribute the pathfinders they have aggregated for their various customer > bases (public, academic, special library, etc). > > Melissa V Rentchler > www.linkedin.com/in/melissarentchler/ > Los Alamitos, CA USA

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