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.

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

This new Village pump page

This is the newly proposed "Village pump (development)" page. Its aim is to encourage the preliminary incubation of new ideas in a "non-polling" environment. When you have a new idea, it is not mandatory that you post it here first. However, doing so can be useful if you only have a general conception of what you want to see implemented, and would like the community's assistance in devising the specifics. Once ideas have been developed, they can be presented to the community for consensus discussion at Wikipedia:Village pump (proposals).

The formation of this page, and the question of its purpose and existence, are the subjects of discussion on the talk page. Direct all comments on those topics there.

• This comment is purposely left unsigned so that it can be edited by multiple parties, and won't be automatically archived.

Different colored links for stubs.

You should make it so the links throughout the whole site will be of a different color if they direct to a stub article. That way you can avoid the stubs if you prefer. —Preceding unsigned comment added by 173.19.86.40 (talk) 14:23, 13 August 2010 (UTC)

Probably difficult to code. Stubs are tagged by using a template, so the software would have to check all links first to check whether a specific page contains a stub template. On pages with hundreds of links it would mean an additional hundreds of pages loaded in the background, which would probably be very taxing on the server while not really be of any benefit to the project. After all, we want people to expand stubs they stumble upon, not avoid them. If anything, it could be done as an userscript but that would mean you have to load all those pages in the background, thus making page loading very slow. Regards SoWhy 11:42, 21 August 2010 (UTC)

There is a preference that colors links to pages that have less than n bytes (you can set that number) in a different color. You would have to create an account to do that, though. Also, it may make loading of huge pages slow. Svick (talk) 19:43, 21 August 2010 (UTC)

Expandable links from public domain encyclopedias

I have done some work at getting the Catholic Encyclopedia articles on line. One thing I'd like to do is then move on to the "stub" articles. I personally think that they should be set free and have a category assigned to them, perhaps in a talk page saying that there is more information in the Catholic Encyclopedia rather than keeping some sort of listing going.

What sort of thing can be done on the expandable artcles?

JASpencer (talk) 22:18, 13 August 2010 (UTC)

I'm sorry but you've used terms which are unfamiliar to me and I wasn't able to make any overall sense of what you were saying. Are you saying you work on a website which is devoted to the Catholic Encyclopedia? Are the stub articles you refer to ones on Wikipedia that refer to things in the Catholic Encyclopedia? In what way are the stubs bound or unfree, is the source copyright and you can't rephrase it properly or what? Why are you unable to decide on a category name or set up a new one? Why would you want to put the category onto the talk page instead of the article page? What is the listing and does it not exist since it is 'some kind' of listing? What is it that makes an article unable to expand, how does one distinguish between ones that can't be expanded and expandable articles? Dmcq (talk) 08:41, 14 August 2010 (UTC)

And the title, what is an expandable link and is the Catholic Encyclopaedia public domain? Wikipedia is not public domain though it is free, see WP:COPYRIGHT. Dmcq (talk) 08:44, 14 August 2010 (UTC)

Bumpbot

I've had this idea and it seems to need to get out. We know that Wikipedia has a strong bias to recentism, driven by people being exposed to news media. Watchlists further reinforce this, because recently edited pages show up in it, and remind other editors of the existence of the page or topic; we've all seen pages go through cycles of obscurity and heightened editing activity purely because somebody made a minor change and "bumped" the page onto people's watchlists. So why not have a "bumpbot" which goes around making constructive minor edits in order to "bump" obscure, rarely edited pages? I know we have bots (and AWB users) doing this already, so it might be entirely unnecessary; but I'm thinking these work more on recent changes or subsets of Wikipedia, and I'm thinking there may be a long tail of neglected pages out there.

To be clear: it's obvious the bot would need to edit at a rate designed not to flood watchlists (and figuring that out might be tricky, but it could be adjusted over time). I also know that watchlists can filter out bot edits, but I'm thinking many people don't bother (and in theory, if a big problem, this could be overcome eg by marking it as a special bot with an extra preference to hid its edits, or whatever). And of course there are endless potential refinements in terms of targeting the bot (eg a rarely-edited BLP could need bumping once a year, a rarely-edited article on a 15th century map rather less). So - initial thoughts? Anything in it? I think we need more ideas like this which help the maintenance aspect of Wikipedia, which is becoming ever-more important compared to creating new articles. Rd232 ^talk 11:04, 17 August 2010 (UTC)

I like the idea a lot, as long as they are CONSTRUCTIVE edits (like what Smackbot does). I can see a lot of people not liking the idea, though. ♫ Melodia Chaconne ♫ (talk) 14:00, 17 August 2010 (UTC)

Wouldn't it be easier to make a change to the Watchlist function? So it displays all changes, and any item on your watchlist that hasn't been edited in n days (user selected). Let n=365, and you are sure to see every item in your watchlist at least once a year. For people who don't want it, they can turn it off, or set n very high.--SPhilbrickT 18:09, 17 August 2010 (UTC)

How would that work? The watchlist lists things by when they were edited. You could have a parallel Reverse Watchlist (list of My Watched Articles By Date Last Edited, reverse order) - that would be useful, and can be an independent thing of the bumpbot concept. But I don't see how you'd put the rarely edited articles into the watchlist itself; or if some way is find, I imagine it would be confusing. In short, I think you'd want both things. Rd232 ^talk 19:33, 17 August 2010 (UTC)

I don't use the watchlist as is, which may color my thinking. I use Svick's Wikipedia Desktop Watcher, which I presume populates its screen from my watchlist. Sometimes I look at the entries sorted by time, but usually an alpha sort, which puts all Talk page and all Wikipedia page results together. I'm assuming that it would be relatively simply to tweak the code to add a page from my watchlist to the displayed list, even if it didn't have an edit.

Making this work through the existing watchlist might be a little tougher, as it would require code changes, perhaps to the MediaWiki Code, but I envision that the displayed list would be all items in my watchlist with an edit in the last n days, plus any entry in the watchlist that hasn't been displayed in m days. I'm not familiar enough with the MediaWiki code to know whether this is easy or hard, but Svick could tell you whether it would be easy to add into his tool (which is much better than the built-in watchlist).--SPhilbrickT 21:32, 17 August 2010 (UTC)

Well that approach might be fine for some people, but I don't know how popular it would be. Fine of course to add it to a tool like that (never heard of that one, it's at User:Svick/DW if anyone's interested), but a separate tool, especially one that needs installing, means a much more limited audience. On a general point: I'm assuming that (minor, I suppose) MediaWiki code changes would be required, but sometimes these things turn out to be doable in Javascript. Rd232 ^talk 22:35, 17 August 2010 (UTC)

I'm not really sure about the utility of such feature (or rather whether it would be worth my time coding it). There is already lots of cleanup categories (many of them have backlogs, going back to 2002 in extreme cases), WikiProjets' todo-lists, and a list of articles that haven't been edited the longest (currently that means since 2006). None of those are exactly what you want, and you are probably aware that such lists exist, but I think working on them could achieve the goal of bumping long inactive pages to people's watchlists.

By the way, I'm glad to see that someone other than me actually uses Desktop Watchlist and likes it. Svick (talk) 23:05, 17 August 2010 (UTC)

Ignoring the technical issues of coding either option, it's a pull approach versus a push approach. Your approach will push the article page onto the watchlist of everyone who watches it. Some will appreciate it, others will be annoyed. My suggestion will pull the article onto the watchlist of everyone who opts in. By definition, everyone who sees it will be happy, so you've eliminated the annoyance factor. on the other hand, maybe only a few per cent will opt in, and the annoyance factor is small enough to be negligible. It's not immediately obvious which is better. (I'm worried that my posts will sounds like I'm fighting the idea. I'm not - I'm just wondering if there's a better way to accomplish your goal. If the alternative isn't feasible, I think it is worth further discussion of bumpbot.) @Svick (are you kidding, I'm so used to it, that when I read this proposal, I had to go find my watchlist to see what it looked like - I had forgotten.)--SPhilbrickT 23:50, 17 August 2010 (UTC)

Well I had in the back of my mind that (a) pull is useful, but push is essential to have an impact - you can have both of course; (b) annoyance is a critical issue, which is where the rate limiting comes in, along with a possible opt-out (if the bot edits are marked as such, you can hide bot edits at present anyway). Rd232 ^talk 01:31, 18 August 2010 (UTC)

A script request, that only affect the end user would be my first option for such a function. While this can be useful for some, for others it would be seen as annoyingly cluttering their watchlists with insignificant edits. Sole Soul (talk) 02:29, 18 August 2010 (UTC)

You mean for the Reverse Watchlist idea? Sure, good start. But I discussed above the ability of users to opt out of the "bumps" (you can hide bot edits), plus finding a reasonable bump rate (target could be maybe 1 per day on the average watchlist - figuring out how to achieve that would be an interesting challenge). Rd232 ^talk 08:14, 19 August 2010 (UTC)

Update: I asked at User Scripts and was told the software will currently only give you data for watchlist pages changed in the last 7 days. You could reverse sort that but it wouldn't be much use! So, the idea would need a MediaWiki software change. That's an obstacle, but not an insurmountable one. Back to the drawing board, then: do we think it's worth pursuing, and elaborating into a proposal? Rd232 ^talk 20:57, 20 August 2010 (UTC)

You're saying it's impossible with current MediaWiki? Challenge accepted! :-) Svick (talk) 22:53, 20 August 2010 (UTC)

I have finished the proof-of-concept. You can use it by adding importScript('User:Svick/reverseWatchlist.js'); to your skin.js. It just adds the article from one's watchlist that hasn't been edited the longest to Special:Watchlist. It would be quite simple to add a cookie-based “ignore this one” button. Also, it currently won't work correctly for users that have more than 500 articles (not pages) in their watchlist. Also, it doesn't work in IE. Svick (talk) 00:37, 21 August 2010 (UTC)

Cool - the proof-of-concept works, albeit with a very slight delay (I have 3000 pages on my watchlist, but I tried it on my public alternate account). Now, is it possible to make it really usable? Is there a lot of delay or server strain involved in constructing a full Reverse Watchlist? Is the 500-article limit because of this (and is this insurmountable)? Rd232 ^talk 10:20, 21 August 2010 (UTC)

The limit is because I can get data for at most 500 pages in one request, modifying it so that it makes more of them is quite simple. Of course, more requests means longer delay. And what exactly do you mean by Reverse Watchlist? The idea mentioned above to list all articles from Watchlist that haven't been changed in n days? Svick (talk) 17:52, 21 August 2010 (UTC)

I mean the current watchlist lists edited pages in chronological order (up to last 7 days). Reverse Watchlist lists edited pages in reverse chronological order, starting with the oldest edit to a watchlisted page and working forwards in time. This could be done in chunks of X (eg 100?) pages, so you can page forwards in time. And in terms of access, the Reverse Watchlist should somehow replace the current Watchlist, when you click a button on the page to do that (so the normal and the Reverse data aren't displayed together). Rd232 ^talk 18:06, 21 August 2010 (UTC)

Hmm, that would be quite impossible to do as a script. Also, I don't see much utility in that. This whole thread is about dealing with articles that are abandoned, i.e. weren't edited for a long time. Your Reverse Watchlist would just show (old) edits to old articles.

My take on the Reverse Watchlist is at Wikipedia:Reverse Watchlist. Svick (talk) 19:26, 21 August 2010 (UTC)

I don't understand your criticism; the idea was always to give a way to answer the question "what pages on my watchlist have not been edited the longest?" Also right now your script is doing nothing for me - maybe it's taking absolutely ages to load? What's supposed to happen? Rd232 ^talk 20:00, 21 August 2010 (UTC)

I have probably misunderstood what you meant. It didn't work, because you are using monobook and I didn't test that. It should be working now. Svick (talk) 20:54, 21 August 2010 (UTC)

No, my alt account is on Vector, and I've still got nothing with either account (and yes I'm bypassing the cache). :( Rd232 ^talk 21:03, 21 August 2010 (UTC)

Then maybe it's that there is nothing to show. Try lowering the threshold to e.g. 180 days by adding reverseWatchlistLimit = 180; to your skin.js. Or maybe it's a browser problem, which one are you using? Svick (talk) 00:33, 22 August 2010 (UTC)

There was something to show before, when I first tried your script and said "the proof-of-concept works". There were articles last edited in 2009 then. I'm using Firefox for my alt account and Chrome for my main. It would be helpful if I knew what was supposed to happen! Rd232 ^talk 09:03, 22 August 2010 (UTC)

You should see “Loading” and after a short while, the list should appear [1]. Also, 2009 may not mean more than a year ago, but I'm sure you realize that. Svick (talk) 10:13, 22 August 2010 (UTC)

Thanks for the screenshot - that's very helpful; but I can't get anything out of the script (no "Loading", nothing). On my alt account I ditched all other javascript and tried it on both Vector and Monobook in both Chrome and Firefox. Nada! :( Rd232 ^talk 10:31, 22 August 2010 (UTC)

"Share this article"

Just an idea that occurred to me about five seconds ago: Why isn't there a simple way to share Wikipedia articles? I mean, increasing reach is pretty important, as it's basically what brings increased participation and thus increased quality and thus increased reach (strategy:File:VirtCirc3.png), so why isn't this a priority? A way to share articles, something like what Wikinews has, might accomplish this immensely. Any ideas about the best way to go about doing this? --Yair rand (talk) 06:16, 19 August 2010 (UTC)

I think that's probably a good idea. The link could easily be added to the Toolbox at the left, and I expect the actual sharing bit can be done in Javascript. Lots of websites have this, and I see no reason why we shouldn't. Rd232 ^talk 10:27, 21 August 2010 (UTC)

I agree. There are on-line services for this (addthis for example) but I don't know if they would appreciate it if we add up to 3 million new entries to their database or if the Foundation would be happy to use any third-party service for this. You might want to propose this at the strategy-wiki. Regards SoWhy 11:52, 21 August 2010 (UTC)

most needed translations

de:Kyrill von Saloniki exists in 18 other languages, and many are quite detailed articles, but there doesnt appear to be an English edition. I haven't seen that for quite a while; usually enWP ends up with at least a stub after the fourth or fifth language has an article about a topic. Does this also seem anomalous to other contributors? I'm wondering if it would be useful to have a tool compile a list of pages on other languages that don't exist on enWP, ordered by the number of other languages which have the topic, or is something similar has already been created. John Vandenberg ^(chat) 08:37, 24 August 2010 (UTC)

I'd expect that to exist already, it seems quite obvious and useful! But I don't know of any such tool. Rd232 ^talk 09:08, 24 August 2010 (UTC)

Yes, it exists already, if only in another form. The article John mentioned is about one of the Saints Cyril and Methodius brothers, so the topic is already covered but apparently not as detailed as in a standalone article. So if we split it up we'd also have to translate de:Method von Saloniki. De728631 (talk) 15:59, 24 August 2010 (UTC)

• We have these 3 lists as part of the Missing encyclopedic articles WikiProject, but they are old and not comprehensive. I suggest making a request at Wikipedia_talk:Database_reports. Sole Soul (talk) 18:48, 24 August 2010 (UTC)

Watchlists of banned users

The thought has occurred to me that blocked/banned users remain able to log in, and remain able to access their watchlists. For short-term blocks/bans, that's fine. But for indefinite-banned users or long-term banned users, it seems likely that this would encourage socking. Of course they can duplicate watchlist behaviour in a number of ways, but a big part of the socks-of-banned-users problem has to be habit: so blocking their watchlist would seem helpful. What if, just as admins can revoke talk page access when blocking, if required, there was an option to block access to the watchlist? This ought to be very easy to implement in the software (he says), and potentially quite useful (in a way that's probably hard to quantify ...) Rd232 ^talk 09:08, 24 August 2010 (UTC)

Just because someone is banned from contributing to WP doesn't mean they should be banned from reading it. I have many pages on my Watchlist that are there because I'm always interested in potential updates to info about the subject. ♫ Melodia Chaconne ♫ (talk) 13:55, 24 August 2010 (UTC)

There's something to that point, but it has to be noted that the idea wouldn't prevent anyone from reading Wikipedia; it merely makes it harder to identify recent changes to articles (which is primarily about editing). In addition, there are other ways to keep up with updates to existing articles (which is both a weakness and a strength of the idea) - for example, every article has RSS feeds for recent changes. And to clarify, I imagine that policy on removal of watchlist privileges would limit it to indefinite-banned or long-term banned users (eg >30 days block, or even >3 months). Or even restrict it to cases of proven socking by blocked editors - which would have the distinct merit of providing an additional sanction for people who engage in it! Rd232 ^talk 14:13, 24 August 2010 (UTC)

You're right, watchlists of banned users do help them with their socking. Fences&Windows 23:01, 26 August 2010 (UTC)

Proposal for interface innovations for copy editors

Hi folks. I put this idea to the Guild of Copyeditors; I had just one response to it but it was positive. That was two weeks ago, so I want to move on to the next step, which is to get feedback here.

The problem I want to solve is that of the copy-edited article where no edits were required. I will sometimes read through an entire article and find no problems with it. Since I have made no changes, there is no record that anyone has had a meaningful interaction with the article. Yet something palpable did just happen - the article was proofread and found to be fine; wouldn't it be good if that were recorded?

I notice that the Guild has templates that can be placed on talk pages. That would be one way of signalling that a proof-read has been done in the absence of any edits being made. However, I hope my proposal will be more powerful than that.

My idea is to have a button or link (I'll use the term prooflink from here on in to refer to the concept but please don't think that I have given nomenclature much thought) that can be clicked and will then leave a record in the article history. Clicking prooflink should have an associated edit summary. The exact wording of what such an edit summary should say we can discuss and I'm open to all suggestions. Let's say it could be "Article has been proofread - no issues discovered" or "Proofreading complete - no edits".

The location and availability of prooflink can also be discussed. At the moment we have access to a number of "gadgets" via our preferences. This could be one of them so that it doesn't appear on a user's interface by default. I feel the most sensible home for it would be a tab near the 'edit' tab or similar in nature to the 'watch/unwatch' icon (I use the Vector skin, if you are using a different one your user experience may be very different, perhaps not even showing tabs).

Does this sound like a desirable innovation? If so, I have more ideas which would increase its power...

Caption=Friendly's dialog box

We all have different skills. Some of us will be all-rounders but some of us may not be anywhere near as confident with grammar as we are with spelling. So we could consider having prooflink not just as a button/link that one either presses or does not press but gives you a range of options as a dialog box (see example of a dialog box used by another gadget, right); the user ticks all the boxes that apply.

Everything is up for grabs, but to get the ball rolling, here's a rough first pass at what the dialog box could offer:

• Spelling checked.
• Grammar checked.
• Readability checked.
• Wikifications checked.
• ...?

You check the boxes of everything that applies and then an automated edit summary will appear in the article history; eg "proofread: spelling, wikifications checked" or "proofread: spelling, grammar checked" or perhaps even "proofread: spelling checked. But wikifications, readability, grammar NOT checked".

Looking even further ahead it would then be possible to extract dates of the last use of prooflink on an article and generate reports of articles that have not been given a once over.

What do you guys think? --bodnotbod (talk) 10:43, 26 August 2010 (UTC)

In summary - a sort of WP:Twinkle for Dummy edits? From the description above, sounds like it would be useful. Problem is finding someone to code it... Rd232 ^talk 11:45, 26 August 2010 (UTC)

Ah! I didn't know we already had a term for it. "Dummy edit". Thank you. As for coding, well, if we get consensus that it's a good idea I'm willing to do all the legwork and go around trying to push things forwards. The people behind Twinkle and Friendly etc would be good to approach. Obviously I shan't if the consensus is that this is a non-starter, so I'll see how this goes first. --bodnotbod (talk) 16:17, 26 August 2010 (UTC)