Wikipedia:Village pump (idea lab)

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, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60

The aim of the Village pump (idea lab) 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.

Edit Suggestion

I have an idea that often users want to suggest rather than actually put a live edit to a page, so I would propose that some system, whether it be an actual action with a log or a page devoted to this purpose be established. Possibly a system similar to that of pending revisions on certain pages, but this time voluntary and with users endorsing them? This is a raw idea.--ForgottenHistory (talk) 22:57, 20 December 2010 (UTC)[reply]

Can't that be done on the Talk page? - J. Johnson (JJ) (talk) 21:39, 31 December 2010 (UTC)[reply]

Of course. But not all talk pages are watched and not all editors know how to use talk pages, and this would provide another venue for improving articles. Fences&Windows 21:27, 7 January 2011 (UTC)[reply]

I agree with J. Johnson. This is pretty much the entire purpose of the talk page. And the pending revisions feature was only put in place because of vandalism. Users can endorse or oppose ideas with regular comments. Creating what I'm guessing you want is a points system will only take the human aspect out of it. --vgmddg (look | talk | do) 21:14, 11 January 2011 (UTC)[reply]

View dif In-Article

Often when viewing "dif" pages it can be hard to exactly find where the changes took place in-article, so I'd generally suggest a change around this, although not replacing the current dif.--ForgottenHistory (talk) 23:02, 20 December 2010 (UTC)[reply]

Try WikiBlame to find when a change occurred. —Pengo 04:19, 22 December 2010 (UTC)[reply]

I don't think that's what FH is asking about. I noticed this problem some time ago. If someone makes a single change to a long article, the diff gives the surrounding text and a line number. This may still make it quite hard to find where in the article the chnaged text is. Peter jackson (talk) 12:20, 5 January 2011 (UTC)[reply]

users with lots of edits / artciles should be able to opt out of fundraising

look its getting a little old. Jimmy begging me for money.

i give hundreds of hours of labor. i think that's enough.

if someone has >1000 edits for the year or whatever, they should be able to opt out of the fundraising drive.

Decora (talk) 06:06, 24 December 2010 (UTC)[reply]

The banners were taken down for all logged-in users four days ago. --Yair rand (talk) 08:26, 24 December 2010 (UTC)[reply]

My Preferences → Gadgets → Suppress display of the fundraiser banner. Problem solved permanently. --Morn (talk) 13:28, 24 December 2010 (UTC)[reply]

I'd like an opt-out from the endless whining about the fundraising banners. Can someone develop a script to do this, please? Fences&Windows 23:13, 27 December 2010 (UTC)[reply]

You might like to read User:WhatamIdoing/Fundraising. WhatamIdoing (talk) 19:42, 1 January 2011 (UTC)[reply]

Nice FAQ. Fences&Windows 18:29, 2 January 2011 (UTC)[reply]

"Come back to" watchlist

I would like to have Wikipedia track a watchlist of sorts of articles that I am waiting on to come back to at some point in the future. For example, in an inactive article, I want to make a change, but I want first to give a week to see if anyone discusses my proposed change. It could be a simple list of articles with or without related dates. Drrll (talk) 12:01, 1 January 2011 (UTC)[reply]

List them at User:Drrll/To do. Or have another declared account (User:Drrll-todo?) and use the watchlist of that account to watch these articles. Fences&Windows 18:28, 2 January 2011 (UTC)[reply]

I would prefer that the list display alongside my regular watchlist, but I like the idea of using my userspace to host the list (I think I would keep the list at my main user page to simplify access to it by just clicking my user name). Drrll (talk) 22:35, 8 January 2011 (UTC)[reply]

Auto-refresh of watchlist

I have no idea if this has been discussed before, but would it be possible to implement an auto-refresh of the watchlist page (as it's really tedious to have to click "My watchlist" all the time)? I'm thinking that the default would be to have the current situation, but an option on "My preferences" would permit the auto-refresh to occur. Not sure about the refresh interval, but every ten or fifteen minutes would probably be okay. Cheers. GFHandel. 06:59, 6 January 2011 (UTC)[reply]

Is it really so tedious to perform one mouse click every ten or fiteen minutes? If so, and you're using Firefox, you could try the ReloadEvery extension, which gives you this functionality for any web page. Phil Bridger (talk) 16:28, 6 January 2011 (UTC)[reply]

I'm not sure the solution to the request should be to switch browsers. Auto-refresh is something that other products (e.g. GMail and Facebook) have found it useful to include. How difficult would it be for a preference setting to cause the following to be included in the HTML stream returned to the browser: <meta http-equiv="refresh" content="300">? That 300 is seconds and would mean a five minute refresh, however even nicer would be a UI element that allows the user to alter that value to suit. GFHandel. 19:15, 6 January 2011 (UTC)[reply]

I wasn't suggesting that you switch browsers, but simply that if you were already using Firefox then this would be a potential solution. There may well be similar features or extensions available in other browsers. If you want a Wikipedia-specific solution then I'm sure that someone with a little more technical knowledge than I have (maybe you?) could knock up a piece of Javascript to insert the HTML that you want, and that that could be implemented much more quickly than any change to the Mediawiki software (i.e. in minutes or hours rather than months or years). If there is significant demand this could then be packaged as a gadget available in the user preferences. You would probably be more likely to get some help with this by posting at the technical village pump. Phil Bridger (talk) 19:39, 6 January 2011 (UTC)[reply]

(edit conflict) Gmail and Facebook do not have auto-refresh/auto-reload, they have auto-update. Our API includes wlstart and wlend and realtime recent changes is possible using the API. However, if you're looking for a quick hack, add the following code to your /vector.js page:

addOnloadHook(function(){ if(wgPageName=="Special:Watchlist") setInterval("window.reload()", 5*60*1000); });

That'll reload your watchlist every 5 minutes. [Not tested] — Dispenser 19:43, 6 January 2011 (UTC)[reply]

Thanks. It works with one minor change (had to add "location."):

// Code to reload the Watchlist page automatically (every 5 minutes)
addOnloadHook
(
  function()
  {
    if (wgPageName == "Special:Watchlist")
    {
       setInterval("window.location.reload()", 5*60*1000);
    }
  }
);

GFHandel. 20:17, 6 January 2011 (UTC)[reply]

ArbCom reform

I've written an essay called WP:ArbCom reform. I originally posted on the Village Pump proposals page, however I think here is probably more appropriate. Anyway, comments or suggestions are most welcome. PhilKnight (talk) 13:47, 7 January 2011 (UTC)[reply]

What, specifically, are the problems that this would address? Herostratus (talk) 19:54, 7 January 2011 (UTC)[reply]
- Yes, it does rather jump straight into what PhilKnight wants done, without explaining why. Fences&Windows 03:52, 8 January 2011 (UTC)[reply]
  - Hopefully, it would make serving on arbcom less time consuming, which could encourage more candidates to step forward. PhilKnight (talk) 15:38, 8 January 2011 (UTC)[reply]

MOS: prose vs bulleted lists (notable residents)

A discussion is currently taking place about the MOS recommendation that bulleted lists should be rewritten as prose. It specifically concerns making a possible exception for sections on 'Notable residents' in articles about towns and cities. Your comments are welcome at: Wikipedia talk:Manual of Style (embedded lists). Thanks. --Kudpung (talk) 02:38, 8 January 2011 (UTC)[reply]

Unifying of discussion templates

Before scrolling down, please study the table below very thoroughly. I know these templates are currently well "established", but please see my comments at the end after studying the table.

Ref. Template Usage Renders as (notice line breaks, text formatting excluded, small text are my comments)

WP:FFD:

A1

First entry

Original template syntax
`{{subst:afd2 \| pg=PAGENAME \| cat=CATEGORY \| text=REASON}} ~~~~`

WP:FFD:

B1

First entry

Original template syntax
`{{subst:ffd2\|FILENAME\|Uploader=UPLOADER\|Reason=REASON}} ~~~~`

B2

Consequent nominations

Original template syntax
`{{subst:ffd2a\|FILENAME\|Uploader=UPLOADER}}`

WP:CFD:

C1

For deletions

Original template syntax
`{{subst:Cfd2\|CATEGORYNAME\|text=REASON. ~~~~}}`

C2

For mergers

== CATEGORY1NAME ==
Propose merging CATEGORY1NAME to CATEGORY2NAME
Nominator's rationale: REASON.

Original template syntax
`{{subst:Cfm2\|CATEGORY1NAME\|CATEGORY2NAME\|text=REASON. ~~~~}}`

C3

For renames

== CATEGORY1NAME ==
Propose renaming CATEGORY1NAME to CATEGORY2NAME
Nominator's rationale: REASON.

Original template syntax
`{{subst:Cfr2\|CATEGORY1NAME\|CATEGORY2NAME\|text=REASON. ~~~~}}`

C4

For conversion to article

== CATEGORYNAME ==
Convert to article CATEGORYNAME to ARTICLENAME
Nominator's rationale: REASON.

Original template syntax
`{{subst:Cfc2\|CATEGORYNAME\|ARTICLENAME\|text=REASON. ~~~~}}`

WP:RFD:

D1

First entry

== CURRENT-REDIRECT ==
* CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats)
REASON

Original template syntax
First template, if just one entry: `{{subst:rfd2\|redirect=CURRENT-REDIRECT\|target=CURRENT-TARGET\|text=REASON.}} ~~~~`

== CURRENT-REDIRECT ==
* CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats)

Original template syntax
First template, if used with 2 or more entries (If used with D2): `{{subst:rfd2\|redirect=CURRENT-REDIRECT\|target=CURRENT-TARGET}}`

D2

Consequent entries

* CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats)

Original template syntax
2nd (to one before last) template, if 3 or more entries: `{{subst:rfd2m\|redirect=CURRENT-REDIRECT\|target=CURRENT-TARGET}}`

* CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats) REASON

Original template syntax
Bottom template, if 2 or more entries: `{{subst:rfd2m\|redirect=CURRENT-REDIRECT\|target=CURRENT-TARGET\|text=REASON.}} ~~~~`

WP:TFD:

E1

Deletion discussions

Original template syntax
`{{subst:Tfd2\|TEMPLATE1NAME\|TEMPLATE2NAME\|text=REASON. ~~~~}}`

E2

Merger discussions

Original template syntax
`{{subst:Tfm2\|TEMPLATE1NAME\|TEMPLATE2NAME\|text=REASON. ~~~~}}`

WP:MFD:

F1

All MfD uses

== PAGENAME ==
REASONING

Original template syntax
`{{subst:mfd2\| pg=PAGENAME\| text=REASON}} ~~~~`

As some of you may have realized, the following changes may seem possible:

Proposal 1A: B2's functions could be merged into B1. It could be done by either:
1). Modifying B1 to function like E1 (supporting a few dozen entries in one template), or
2). B1 could be modified such that simply excluding |reason= would function as B2.

Proposal 1B: C2, C3, and C4, could all be merged into C1, by renaming default parameters such as |1= to titles such as:
|MergeCat1=
|MergeCat2=
|RenameCat1=
|RenameCat2=
This would easily enable the combining of these separate templates. An additional feature that could be added, which doesn't exist currently, would be to modify the merged-C1 to function like E1 (supporting a few dozen entries in one template), something like:
|MergeCatA1=
|MergeCatA2=
|MergeCatB1=
|MergeCatB2=

Proposal 1C: D2's functions could be merged into D1. It could be done by either:
1). Modifying D1 to function like E1 (supporting a few dozen entries in one template), or
2). D1 could be modified such that simply excluding |text= would function as D2.

Proposal 1D: E2 could be disposed. E1 could simply hold an additional parameter |type, with the content being either deletion or merger, thus making way to implement the functions of E2.

Proposal 2: All of these templates could be merged to one. This seems a bit "definitely oppose" or "impossible" on the first thought, but it does seem possible. For example, all the parameters could simply start with something like:
|AFD-PAGE1=
|AFD-PAGE2=
...
|AFD-PAGE20=
|AFD-PAGE1-CAT=
|AFD-REASON=
|FFD-FILE1=
...
|FFD-FILE20=
|FFD-UPLOADER1= (note)
|CFD-MergeCatA1=
|CFD-MergeCatA2=
|CFD-MergeCatB1=
|CFD-MergeCatB2=
|CFD-RenameCatA1=
|CFD-RenameCatA2=
The list goes on...

Note 1: Template functions (such as: (edit | watch | talk | history | links | logs) for all namespaces/files, and (notify | contribs | logs | talk) for creator/uploader), will be same for all variables.

Note 2: Either Proposal 1x or Proposal 2, would require substantial alterations to many pages (deletion request pages), tools (twinkle), editors (custom tools and bots), and many more areas.
But on the other hand, it unifies all key templates into one; greatly reducing confusion, pooling of editors' dedication, and makes it easier to keep an eye on for damages by accident or vandalism. Changes could also be made once and for all, instead of changing templates for each.

Note 3: The corresponding page templates (the ones placed on the pages, such {{Ffd}} as compared to {{Ffd2}}) could all be merged as well. But of course, thus would be much easier than the changes to the above templates.

I hope you understand what I am trying to say here, took me the whole day trying to put this proposal right :) Please avoid comments like "oppose - too complicated to carry out", and discuss the real technical issues on implementing this. I intend to move this to WP:VPR in about a week, if no serious issues are seen. Kind regards. Reh man 11:33, 8 January 2011 (UTC)[reply]

Discussions

I don't understand at all, because all you've done is paste in a table of code. Can you write out in prose what the aim of this is? What is the current problem, what is the solution, and how can it be implemented? Fences&Windows 00:14, 9 January 2011 (UTC)[reply]

OK, I guess I understand the proposal (more or less)... Essentially, in each case you want to take several templates that perform similar functions and create a new template that would perform all those functions depending on parameters, right? That doesn't seem to be very difficult to do (for example, the new template might be made into some sort of adapter, more or less like in the Adapter pattern). But I am not sure if that is advantageous... For example, you say "[...] it unifies all key templates into one; greatly reducing confusion, [...]". But is it really so? I am afraid that users will use the wrong parameters more often than they are using the wrong templates... Also, in many cases the "unified" template is going to be more complex and harder to edit than each of the previously existing templates. Thus I doubt if the change will result in "pooling of editors' dedication"... So, may I advise you to list the benefits of such change in a little more detail before moving to another "Village Pump"..? --Martynas Patasius (talk) 23:38, 11 January 2011 (UTC)[reply]

The likeliness of a user making a mistake is actually much more slim than the current format. Because, if this method is used, the template will only function if a parameter is given. And since all the available parameters will not be displayed on all discussions pages (for instance, at RFD, only the parameters relating to RFD will be shown), the probability of someone accidentally placing a param like |CFD-MergeCatB1= at FFD is near 0. If no parameters are shown (or a non-existent parameter is entered), we could make it to display a nice big red error message.

Also, this template will not be any harder to edit than trying to edit these current separate template. It'll only be longer. Like the benefits of other templates, a unified template greatly improves ease of maintenance and protection; one has to edit one template to make a wide change (vandalism blocked by protection), rather than many.

Another minor advantage, which is not related to this proposal: Currently, all other wikis are trying their best to get separate venues (FFD, RFD, ect) like en.wiki, but they either don't have the resources (templates), nor do they are able to translate the contents there to use. And oddly, these template could actually function on other wikis. To overcome this, 4547 went into construction. So, in the near-future, these types of "key templates" will be on Commons. And it is this "unified template" that has to be there. This is just another future step, nothing to do with this proposal.

If you are interested, we could start working together on this "unified template", and see where it takes us...

--Reh man 11:59, 12 January 2011 (UTC)[reply]

"minor edit" flag

There is an option to default all edits to minor within each user's profile.

Some considerable time ago, as I was doing a lot of minor edits, I set this on. I got out of the habit of checking, so even when making major edits (or creating new pages), I was flagging them as minor, until another editor pointed this out to me today.

What would help me is to amend the profile option to offer three posible selections:

Mark all as minor by defailt
Mark none as minor by default
Prompt me to before saving every edit

Is this feature something that could be developed, and would it be beneficial to other editors? Regards, Lynbarn (talk) 19:46, 9 January 2011 (UTC)[reply]

In theory, the preference to mark edits as minor will be going away any day now - see bug 24313. That would fix the problem if actually was done. Unfortunately, the bug has been stuck in limbo for a while. — Gavia immer (talk) 19:59, 9 January 2011 (UTC)[reply]

Time out message

I just came up with this idea about telling/reminding Wikipedians to take a break after a long time of non-stop editting. If a Wikipedian edits solidly for more then 45 minutes/one hour, a small message – just like those that appear asking for donations – will appear for a maximum of five minutes, asking them to take a break. The person doesn't have to respond to it – it is there to purely remind them. The idea is to prevent the eyes from prolonged exposure to the screens and allow these people to rest. The person will be given the choice of whether to allow this message to appear, on their My preferences page. Sp33dyphil ^(Talk) ^{(Contributions)}^{(Feed back needed @ Talk page)} 06:39, 14 January 2011 (UTC)[reply]

Shall we remind them to take a pee break too? How about when it's lunch time? ♫ Melodia Chaconne ♫ (talk) 07:02, 14 January 2011 (UTC)[reply]

Haha :D Sp33dyphil ^(Talk) ^{(Contributions)}^{(Feed back needed @ Talk page)} 07:41, 14 January 2011 (UTC)[reply]

Concur with Melodia ;) A good thing, but not worth to actually create banners and stuff. We could always mention such stuff at WP:INTRODUCTION, WP:FIRSTARTICLE, or wherever the place where we could inform new editors, as older people already know the consequences, by experience ;). Reh man 07:09, 14 January 2011 (UTC)[reply]

Some people may know it, but they won't actually take a break; it may take some nudging. Plus, it won't be a bigi banner or something like it, just a small popup reminding them to take a break. When a person is really involved in editting, they won't have any idea what the time is. Sp33dyphil ^(Talk) ^{(Contributions)}^{(Feed back needed @ Talk page)} 07:41, 14 January 2011 (UTC)[reply]

AFAIK, such a thing would most probably be a gadget, which I am sure, would definitely be opposed by almost everyone. To really be a Wikimedia "integrated health feature", which would (and should) be available on all wikis, IMO this should be proposed at Meta or Bugzilla... Reh man 07:49, 14 January 2011 (UTC)[reply]

Idea: Formatting an article into 2 or more columns

When textual information is displayed in a Wikipedia article, it is displayed as one column (except for tables). But this text is difficult to read because each line is too long. I read somewhere that the optimal length of a line should be about 66 characters, which is why many articles and books are formatted as two or even three columns. I recommend that Wikipedia developers add an option to increase the number of columns displayed for an article. This would make it easier for readers.