Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

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

• Discussions of technical issues belong at Wikipedia:Village pump (technical).
• Discussions of policy belong at Wikipedia:Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Wikipedia:Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals, and Wikipedia:Village pump (proposals)/Persistent proposals.

« Archives, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60

Require an edit summary for edits by IPs and non-autoconfirmed users?

Since it is considered good practice to provide edit summaries, would it be a good idea to require IPs and non-autoconfirmed users to supply an edit summary when making edits to the article namespace? This would help prevent misunderstandings and make it easier to patrol edits, and encourage using edit summaries in general. Currently, many new users/IPs do not use edit summaries, even when making constructive edits. Tony Z. Tan · talk 22:55, 12 April 2015 (UTC)

It's an attractive idea, but my experience with developers who are paid to put summaries on source code checkins is that there will always be some who won't give a meaningful edit summary. If you introduce a mechanism to force a summary, they'll enter a single '.'. If you put a filter in requiring at least six characters, they'll put 'aaaaaa'. If, after a long-running battle, you implement a mechanism that somehow requires a meaningful English sentence in the summary, you'll end up with abuse directed towards the admin who implemented the mechanism. You can lead a horse to water, but you can't make him drink. GoldenRing (talk) 06:11, 13 April 2015 (UTC)

I also think that this would end up being a deterent from users to start editing here - and the same users who don't know about edit summeries probably need their edits to get extra scrutiny. עוד מישהו Od Mishehu 04:14, 14 April 2015 (UTC)

Why limit it to "IPs and non-autoconfirmed users"? I think having the edit summary as a required field for all would serve a useful purpose. While some may 'game the system' with glib entries many others will be nudged to take notice and give thought. And as 'required fields' are fairly ubiquitous in interfaces on many sites I don't see it as any sort of surprising impediment to new editors. Some sort of 'what is this' icon/link/hover-text/pop-up/etc.—such as the present "Edit summary (Briefly describe your changes)"—should suffice to aid those who may be particularly naive.

Hmm, a pop-up message with a link to the talk page when the edit summary field character count gets maxed out might be a complementary feature as well ... --Kevjonesin (talk) 10:31, 3 May 2015 (UTC)

Possible new namespaces, maybe "News" and "Almanac"

I think we all here have, well, reservations, about the effectiveness of wikinews, including even some of its bigger contributors. And, unfortunately, as can be seen about the recent creation of a WikiProject devoted to a single candidate in the upcoming US Presidential election, there is a real chance that we are going to get a lot more "news"-y editing and information about all the candidates, which we are going to have to, of course, try to insert in our comparatively few overview articles in an NPOV way which doesn't violate WEIGHT, which is, let's be honest, all but impossible.

So, maybe, and possibly even as a provisional matter to deal exclusively with matters of elections, maybe we might be better off effectively allowing some of the people who want to add "news" material to wikipedia, not wikinews, to do so here. In a separate namespace for news articles particularly. I expect we are going to get pretty much daily changes to some of these articles as is shortly, creating any number of problems and sinking the time of lots of people which could be better spent elsewhere.

That's why I'm thinking, maybe, to create a separate namespace for "news" pieces, which would still have to meet the same basic notability requirements, which could then have a link to the category or news portal for the election, or the race or the candidate or whatever, and then, on a fairly regular basis, maybe once a week or month or whatever, updating the main articles to reflect the lesser news updates. If this news site were also used to include information on other matters, like, say, developments in the Catholic Church, or the UK, Russia, or China, or the UN, or any other large entity with an article that gets a lot of coverage in the news, we could do pretty much the same thing.

Alternately, for the latter point, maybe we might institute a second namespace, an "Almanac:" or similar, which could be used to summarize the news stories on a weekly or monthly basis, which could then itself be used to allow for regular, scheduled, updates to the relevant main articles on, maybe, an annual basis for "smaller" items, unlike say natural or man-made disasters, wars, or similar things whose impact generally does reasonably get recorded in articles quickly.

Anyway, any ideas? John Carter (talk) 14:48, 18 April 2015 (UTC)

Two new namespaces seem a lot of overkill. We need more editors, not more content for our existing pool of editors to curate. Ironholds (talk) 00:56, 22 April 2015 (UTC)

Knowledge, Objectivity, Neutrality, Facts, and Truth

proto-proposal

This one is rather a large body of suggestions, and written in a rather stern and esoteric prose, so I ask that you try to tolerate it as best that you can. The form it would take as a Proposal would be much simpler, and not some kind of discourse like it is now.

My apologizes to those with smaller displays.

There are some ways in which Wikipedia must be limited, and consequently deficient. It will never be a true compendium of truth, but merely a collection of knowledge, and even then impaired by the need for consensus. Consensus, of course, is neither good or evil alone, as are all things.
However, consensus is derived from a source, the same as any opinion, and in the interest of all users of Wikipedia that source must be chosen so as to provide the maximum appeal.
Fortunately, Wikipedia is not attempting to exclude beliefs in the process of consensus, but only to find the foundation upon which describe those variant beliefs in a way which is accurate for all involved parties. (Here the word 'beliefs' is to be read sans any religious or moral connotations, and is used merely because 'opinions' has other denotations.)

Thus, Wikipedia serves as a documentation of reputed knowledge moreso than as an authority deeming evaluation for it. I.e., in the interest of so-called neutrality, notability is more significant than any pretenses at correctness.

Enough with the musings. Well, not so much, alas, but I'll consider implications to some examples:

• Science and Pseudoscience

Bias inherent in any appellations aside, these are two broad groups which mostly agree on recognition and definition of their own ideals as well as on the ideals of the other, yet they disagree on the evaluations of those ideals, both of themselves and of the other.

This is a concern when documenting or reporting opinions. Applied to concepts such as science, it must be remembered first what the word 'science' means, and secondly that it is merely a collection of opinions, albeit determined by criteria attempting a nearest-match to facts in a mutual experience.

Certain groups may not use the same approach to their POV as others. Neutrality in the interest of documentation, in this situation, is to avoid bias by favoring any specific groups, even if it seems obvious which is more correct.

That's what this place is all about, really: a collection of human knowledge, not truth, and certainly not ideal facts as such but optimistically the nearest approximation possible.

• Fact or "Opinion"?

Here I dissent from the guidance seen here, and will use one of those examples to illustrate. It may seem to be a fact that the capital of France is Paris, or that Mars is a planet, but really these are merely descriptions given by people.

What if the definition of the word 'planet' was changed? What if the seat of French decision-making was in actuality an underground cabal, and Paris was merely a front for their influence? One of these sounds absurd, and one certainly is much further removed from the accepted knowledge than the other, but both share a logical basis: some people say that Mars is a planet, and some people say that Paris is the capital city of France. That body of people must be recognized, at least once but in such a way that is consistent.

I am not arguing that all such statements must reference a source, as mentioned in the aforementioned guidance; but, to avoid delving too much into philosophic considerations here, I will re-iterate that Wikipedia must develop some consistent approach to reporting the facts of beliefs, as best it can, rather than the facts of some objective reality. Besides, once you get into the scope of experience and its significance with regards to knowledge, you can either accept something like Wikipedia for what it's worth or you can dismiss it entirely.

• Descriptive versus Authoritative

This is seen in some of the disambiguatory templates used as hatnotes for pages, and is a milder recommendation regarding the tone of writing to be used in Wikipedia.

Compare this, as seen in the extant version of {{disamb-term}},

The term "{{{1}}}" may refer to:

with these phrases:

The term "{{{1}}}" may be referring to:

The term "{{{1}}}" could be referring to:

I could go on about unconscious traditions regarding encyclopedia, and whether it is important, and whether it is imparts anything besides a minor irritation to the concept of Wikipedia, but I'll stop here.

I suppose that I should thank you for reading.

JamesEG (talk) 01:13, 22 April 2015 (UTC)

I...don't understand what your point is, with any of this. That Wikipedia represents reliable sources and not "objective truth"? Yes. That's...the very premise of Wikipedia. Ironholds (talk) 16:15, 22 April 2015 (UTC)

I also can't make out any sort of proposal here. What, specifically, ought Wikipedia to implement, change, or remove? What particular problem ought we to address? While this Village Pump is certainly dedicated to developing incomplete ideas … this thought seems so incomplete that others can't build on it. JamesEG, can you clarify things for us? {{Nihiltres|talk|edits}} 18:21, 22 April 2015 (UTC)

Isolating format elements of an included page

Providing some means of limiting the scope of format elements for an included page would be beneficial. For example, on the WP:AfD sub-pages, I keep finding that basic layout errors (such as not including a closing 'div' tag) will propagate downward to the succeeding sections. Thank you. Praemonitus (talk) 17:01, 22 April 2015 (UTC)

Suppressing redirects

Currently, global rollbackers have the permission suppressredirect. This allows for a page to be removed without creating a redirect. The purpose of rollbackers on enwiki is to combat vandalism, and sometimes page move vandalism occurs. In the past the permission has been proposed on this wiki, but was shot down because of the fear of page move vandalism. I want to gauge the general opinion on giving suppressredirect to rollbackers here. Just like with the normal rollback, this would be only to combat vandalism and using it otherwise would result in sanctions, including but not limited to removal of the tool. What does everybody think? Kharkiv07^Talk 02:44, 23 April 2015 (UTC)

I have issues with administrators using it (since there should be two log entries, why was it moved and why was redirect deleted), so certainly not to rollbackers. It's not that hard to put the speedy delete tag on it. Oiyarbepsy (talk) 04:40, 27 April 2015 (UTC)

Detect wikilinks from mainspace to Draft: namespace

I believe that namespace articles should not link to Draft: articles. Am I wrong?

But I have spotted such links (example) so how about a bot/script/something that would detect them? And either remove such links or create a backlog.

Cheers! Syced (talk) 06:45, 23 April 2015 (UTC)

• Support requesting a bot operator to add a check for article links to Draft space (and maybe other inappropriate namespaces). I checked a few relevant policies and I couldn't find anything prohibiting such links, but it's pretty obvious. We don't want readers unknowingly landing at a draft thinking it's an article, and we don't want promotional/non-notable/POV pages deliberately buried in draft space and stealth-linked from articles. Alsee (talk) 10:45, 23 April 2015 (UTC)

Revised to Support toollabs, or any other method to hunt down Article-space links to Draft-space, after noting Technical 13's comment below. Alsee (talk) 22:52, 24 April 2015 (UTC)

• Oppose as a bot operator having a bot to do this task. There is nothing really here for a bot to do except to "find" these links, and that task is much more suited to being a tool on toollabs where user's can be taken to a page with the issue or be given a list of pages where there are such links. So, I don't oppose the idea, just the suggested method. Give me a set of criteria and I'll get started by the end of May (it's finals week in school right now and next semester I have a 3 week summer class that is going to beat the poo out of me). — {{U|Technical 13}} (e • t • c) 11:33, 23 April 2015 (UTC)

Any method is better than nothing :-) As for the set of criteria, it is really simple, just find mainspace wikilinks to "Draft:". Thanks a lot! Syced (talk) 03:11, 27 April 2015 (UTC)

Analytics and socking

Should we have an analytics tool that objectively rates the likelihood that two or more accounts are actually the same person based on linguistic queues in their contribution history.

For example, say there is an SPI investigation that involves 30 alleged socks. The analytics tool may say that user:Notasock has different syntax patterns in their editing than the other accounts. This may lead to exonerating that editor, whereas otherwise a good faith editor would have been blocked. CorporateM (Talk) 04:23, 25 April 2015 (UTC)

A smart user may "create" various oddities, and forget to use them in one account; this test would be unreliable. עוד מישהו Od Mishehu 03:46, 26 April 2015 (UTC)

This presupposes that such a tool could be created. I have my doubts that it could, at least to the extent that it was reliable enough to use - and I can't think of any way to test its reliability. AndyTheGrump (talk) 04:01, 26 April 2015 (UTC)

You could test it by asking users to create a bunch of socks - which, of course, is a very disruptive way to test. Oiyarbepsy (talk) 04:37, 27 April 2015 (UTC)

A few notes:

• Feasibility: The first step would be a grant request to do a feasibility study and see how possible it is
• Accuracy: I think this is essentially already done by humans and could be done more accurately by an objective machine in seconds instead of hours.
• Testing: The way to test it would be to use it on pre-existing SPI cases. See if it comes up with different results than SPI investigators than look more closely at those cases, or, use it on obvious socking cases and see if it correctly identifies socks already identified by checkuser.

CorporateM (Talk) 14:47, 27 April 2015 (UTC)

I found a couple papers[1][2] where an academic already used 200+ writing style indicators to evaluate whether two accounts were the same person using analytics, and found the same results as SPI in almost 75% of cases. I pinged them on Facebook to see if there is some way we can make the tool he already developed available online and take a closer look at it. CorporateM (Talk) 15:00, 27 April 2015 (UTC)

Why can't protection icons be part of the UI directly?

Right now, templates are used to generate notices and icons indicating that particular pages are protected. My only major problem with them is that they are manually added and are not specifically tied to the article's protection status (meaning that they do not necessarily "disappear" upon the expiration of the page's protection. Some, uneducated editors also believe that adding or removing said templates can change the article's protection status. Plus, it would also make a bit more sense to display the protection status in a location that is contextually

My idea is to replace the inline protection templates with a variation of them that is implemented directly in the software and MediaWiki skin. What I envisioned was a sort of minimalistic padlock icon next to the relevant function that is protected, accompanied by an indication of whether the user can edit the page. So for instance, a page that is semi-protected would show a faded grey padlock next to the Edit button; if the user is eligible to edit the page, the lock will still appear, but it will shop up as opened. A different icon could be used for pending revisions, mainly because I do not feel the padlock is an accurate symbol to signify this process.

Any thoughts? ViperSnake151  Talk  00:29, 26 April 2015 (UTC)

This may be technically possible, unless you wish to have different colors for diffferent reasons of protection - which I think I remember it did. עוד מישהו Od Mishehu 03:45, 26 April 2015 (UTC)

It's not like it's impossible to have different sprite graphics for the different states, or use an icon font. ViperSnake151  Talk  06:35, 26 April 2015 (UTC)

• I suppose I should finish up development of User:Technical 13/Scripts/Gadget-pageProtectionLevels.js which will put the appropriate icons for the current protection level at the ver top of the page next to the user's name. Currently it uses words instead of icons. I'll move it up in my todo list soon™. — {{U|Technical 13}} (e • t • c) 13:49, 26 April 2015 (UTC)

I really like this idea - it's similar to implementations of access levels on other websites I've seen. ViperSnake151, why don't you try VPPR? APerson (talk!) 13:32, 28 April 2015 (UTC)

WikiDesign

Proposal for WikiDesign - a cloud based open source design tool. WikiDesign would incorporate all of the tools to design modern devices and processes in a web based application similar to Wikipedia as well as an intellectual property conservancy user's agreement. Some tools to consider would be autocad and gis applications such as Arcview. There would need to be the other tools for the entire design process. For example a package for economic analysis, a tool for modeling process/controls, and a mechanism to pursue patents on any new intellectual property collaboratively developed by users. The intellectual property user's agreement would state that any design and intellectual property is open source and available to any user who follows the user's terms of agreement free of charge. — Preceding unsigned comment added by RBenn38486 (talk • contribs) 12:21, 26 April 2015 (UTC)

@RBenn38486: Are you suggesting a project that would create opensource versions of Autocad and ArcGIS? These are copyrighted software programs, so they are inherently not compatible with a wiki concept. Oiyarbepsy (talk) 04:35, 27 April 2015 (UTC)

@Oiyarbepsy: It depends on how their licensing agreement works in an open source platform. Can one purchased license allow multiple users? Are there any alternatives that would enable a WikiDesign platform? RBenn38486 (talk) 05:04, 27 April 2015 (UTC)

A pretty cool idea, but probably years ahead of its time (like WikiData was in 2005). One can easily imagine though that as 3D printers' user base increases, implementing something like WikiDesign will start making total sense...—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); April 27, 2015; 17:43 (UTC)

Inquiry - Are there any existing open source design tools? Google Earth has rudimentary GIS tools, but very useful. If there are governmental applications free for download, that could work. The only other alternative is to start each of the components as open source applications.RBenn38486 (talk) 12:33, 28 April 2015 (UTC)

Good Lists

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.

---

A new class of article to be introduced. it will be a good list. It would be similar to a good article but in a list format. We need this because the step from list to FL is too great and we need something in the middle. TheMagikCow (talk) 17:34, 27 April 2015 (UTC)

Sounds like a good idea to me. If we can come up with a reasonable set of criteria which is applicable to almost any list, and which would tend to be similar to GA, then we can make those be the GL criteria. עוד מישהו Od Mishehu 16:33, 30 April 2015 (UTC)

Here they are TheMagikCow (talk) 17:06, 3 May 2015 (UTC)

It covers a topic that lends itself to list format (see WP:List) and, in addition to meeting the requirements for all Wikipedia content (particularly naming conventions, neutrality, no original research, verifiability, citations, reliable sources, living persons, non-free content and what Wikipedia is not) a good list has the following attributes:

1. Prose. It features a good standard of writing, with no copyedit issues,
2. Lead. It has a lead that introduces the subject and defines the scope and inclusion criteria.
3. Comprehensiveness.
   • (a) It comprehensively covers the defined scope, providing all of the major items and.
   • (b) In length and/or topic, it meets all of the requirements for stand-alone lists; does not violate the content-forking guideline, does not largely duplicate material from another article, and could not reasonably be included as part of a related article.
4. Structure. It is easy to navigate and includes, where helpful, section headings and table sort facilities.
5. Style. It complies with the Manual of Style and its supplementary pages.
   • (a) Visual appeal. It makes suitable use of text layout, formatting, tables, and colour; and a minimal proportion of items are redlinked.
   • (b) Media files. It has images and other media, if appropriate to the topic, that follow Wikipedia's usage policies, with succinct captions. Non-free images and other media satisfy the criteria for the inclusion of non-free content and are labeled accordingly.
6. Stability. It is not the subject of ongoing edit wars and its content does not change significantly from day to day, except in response to the good list process.

This has been discussed before, though I don't have any links handy. Personally, I do not believe there is much value in creating another review process that is ultimately redundant to the Featured List process. There will not be enough difference between a "good" list and a "featured" list to make the process worthwhile. Resolute 17:11, 3 May 2015 (UTC)

• How does this proposal compare to FL? What are the similarities and differences? — {{U|Technical 13}} (e • t • c) 17:32, 3 May 2015 (UTC)
• Please see parallel discussion on Wikipedia:Village pump (proposals)#Good Lists. — {{U|Technical 13}} (e • t • c) 14:01, 4 May 2015 (UTC)

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.

Good Wikipedians

Does anybody have any ideas about how Wikipedia could change to be very efficient at enabling most newcomers who want to become a good Wikipedian to be able to easily get trained to do so? I don't know how to create a WikiProject that does that. Blackbombchu (talk) 22:01, 28 April 2015 (UTC)

Hi Timothy. We have the Adopt a User program, and more recently, the Co-op, which matches newcomers based upon their area of interest (i.e., content creation, technical, policy, etc.) to a mentor who is familiar with that area of editing. Do you have ideas on how these systems can be improved? --Biblioworm 22:16, 28 April 2015 (UTC)

YouTube Wikiproject Proposal and How Bold can I be?

So I've got a proposal on the go for a YouTube Wikiproject (Not blatant advertising) and I'm wondering how bold can I be with such an endeavour. I want to create a Template header and WP: project space to get the infrastructure going and an audit of all the articles. While WP:BOLD is a policy I don't want to find someone getting upset for some unforeseen reason.

--- :D Derry Adama (talk) 23:37, 28 April 2015 (UTC)

• I would consider that generally not a good idea. Very little of what goes on on YouTube is supported by Independent Reliable Sources (by Wikipedia standards, anyway), and pages on people's YouTube accounts are often deleted as not being notable or verifiable enough. Even linking to YouTube is generally discouraged for spam and copyright reasons (and it can't be used as a source anyway). There is a YouTube specific wiki on Wikia here which might be a better fit for documenting YouTube stuff. Andrew Lenahan - Starblind 23:37, 29 April 2015 (UTC)

Add link to latest revision in Talk page signatures?

I've just opened a discussion here around a possible idea for adding a default signature link to more easily access the revision of the page a person was likely talking about when they made their talk page post.

Per instructions there, I'm putting a note here. What do folks think?

If somebody believes the idea is worth putting up for consensus polling, perhaps after some further development, please go for it (and crosslink to that discussion!) :-).

--WBTtheFROG (talk) 23:37, 28 April 2015 (UTC)

External Links should be embedded in Wiki page content

What about external links which open up actual websites of what is referenced or of the subject. For example if I am seeing a Wiki of list of USA newspapers, all the papers open up their own wiki pages. Well, I would expect to be taken directly to the paper website, right. So how about like two links or option to go visit the actual website.

I interacted with Wikipedia Contact-us representative who mentioned this embedding within content is not found because it would be open to a lot of spamming. This is perfectly a valid reason. But could we find a way around this. Wordpress seems to have a way in preventing spamming on their blogs which are the maximum around the world.

So ive put this in the IDEA LAB to generate a feasible proposal if possible. I am not such a techie person but this handicap of not having external links sure does put one off on researching new subjects. It means again I got to go and google out the actual website. — Preceding unsigned comment added by Tb kol (talk • contribs) 08:44, 6 May 2015 (UTC)

@Tb kol: Please see WP:LINKFARM also WP:ELPOINTS item 2 specifically, and the rest of WP:EL in general. --Redrose64 (talk) 16:31, 6 May 2015 (UTC)

User_talk:Tb_kol