Wikipedia:Village pump (proposals)/Archive 82

Proposal to create a new namespace. Suggest TemplateS:

• Any template created in this namespace would automatically substitute when saved.
• If subst: or safesubst: is added it should be ignored (as wherever used it will always subst).
• The preview display should be as is presently the case with e.g. {{subst:Example}}
• If used in another template, the syntax should be e.g. {{{Example}}} instead of {{{{{|safesubst:}}}Example}}
  • Although if safesubsted, the safesubst: should be ignored.
• If a TemplateS is included within another template (either in the Template or TemplateS namespace) it should sit and wait to be transcluded before substing.

In simple terms, a template namespace allowing the creation of templates that should always be substituted, without the need for the use of subst:

This would cut down on accidentally not substituted templates where they should have been. It would cut down on unnecessary transclusion. It would save a lot of explanation and confusion. Any present templates that should always be substituted (e.g. {{subst:Uw-vandalism1}} etc.) could be moved to the new namespace and continue to function just the same way but with automatic clean-up of errors. Etc. etc.

However patronizing this is going to sound: Please keep the comments free from hyperbole (this would be the worst thing ever!), presumption (this would be too difficult to implement), and negativity (this is a shit idea). This may not be 42, and I'm quite sure there are lots of technical issues involved. If you think the idea is shit, explain how it can be improved. Most importantly, where there's a will there's a way. fredgandt 20:48, 9 December 2011 (UTC)

How about introducing a new magic word, e.g. __AUTOSUBST__ instead? When a template containing this magic word is used, it will be automatically substituted. Also, triple-braces are used for template parameters. Another syntax will have to be used. Perhaps a nosubst: prefix. - ctzmsc3|talk 21:17, 9 December 2011 (UTC)

I like the magic word idea. Simple way to get an auto substitution without the fuss of my proposal. fredgandt 21:54, 9 December 2011 (UTC)

Although I have had second thoughts (see below) fredgandt 00:55, 10 December 2011 (UTC)

I have to say this: This would require a major rewrite in core, so perhaps it is best to submit a feature request at Bugzilla first to see if there is any support in doing so. This is standard advice for proposals requiring a major rewrite. A note about why this will not work: template space is technically no different from any other namespace. The parser will transclude or substitute anything you can throw at it. I myself would love to see parser functions not being substituted at all, but that also requires a rewrite. — Edokter (talk) — 21:19, 9 December 2011 (UTC)

My thinking was that, for example, to transclude Wikipedia:Example we use {{Wikipedia:Example}} but to transclude Template:Example we just use {{Example}}. My thought is thus, that since certain page names in certain namespaces are assumed by the tranclusive process, to be the source of templates, a new namespace could (when assumed).........

I have just found an enormous hole in my plan.

How would the software know...?

Hole fixed. As long as there were no Template: and TemplateS: templates with the same name, all is well.

.......parse the result of the transclusion as if substituted.

Simply put: If {{Example}} works (it doesn't transclude User:Example or Example or Wikipedia:Example) then we use that part of the system to add the new namespace and providing there are no templates in both template namespaces with the same name, each would behave uniquely.

You (Edokter) and I will it seems forever disagree about substituting parser functions. I believe that once they have done their job, they should be substed. The only time I see a use for an unsubsted parser function or magic word is when the refreshed page should return a new value. Example (not parser but...) substing {{REVISIONUSER}} is always correct unless you specifically want the page to show the last editor every time it's loaded. Or a parser function {{#ifeq:A|A|Yes|No}} is written in stone. It will never tell you anything else. Not substituting it is a waste of resources with no justification. Obviously that is a long a complex converstion with many what if's.

I actually didn't know we could go direct to Bugzilla to make feature requests. For the immediate future, I'd like to see where this leads. I rather like the idea of a magic word to use in the template (suggested above). fredgandt 21:54, 9 December 2011 (UTC)

Although I have had second thoughts (see below) fredgandt 00:48, 10 December 2011 (UTC)

• Like the new magic word idea (I'm assuming that would take a lot less of a rewrite in the wikimedia code?)Crazynas ^t 23:35, 9 December 2011 (UTC)

Although the magic word idea does seem simple, I have my doubts.

The creation of a custom namespace is very simple. See mw:Manual:Using_custom_namespaces#Why_you_would_want_a_custom_namespace (zooms in on section highlighting exactly what this proposed namespace would be for).

The new namespace would be in almost all ways an exact copy (in function) of the Template: namespace (so easy to create the basics).

• Here's where the magic word idea gets complex when considered against the new namespace.

A new magic word would need to be recognised throughout Wikipedia, by all scripts that might encounter it. This could mean (not 100% sure) a great deal of interweaving and rewriting. Like trying to play Pick-up sticks in reverse; not only when correctly used but also when incorrectly used. Without each and every script knowing what to do with the magic word if it finds it, we could end up with a great many spanners in the works.

The proposed new namespace would be a stand-alone development area where the few tweaks required could be carried out, without disturbing anything else.

The tweaks would be where the technicalities are not fully known to me, but I can hazard an educated guess that not much more would be required than an instruction to add "subst:" to the raw text of any template transcluded from the TemplateS: namespace (unless already there etc. etc.).

These tweaks could amount to little more than a series of ifs and else ifs. fredgandt 00:48, 10 December 2011 (UTC)

The main problem with a magic word is irreversibility. A vandalised or accidentally __AUTOSUBST__'d {{Convert}} woudl be a nightmare.

The name-pace idea is cute, though. Rich Farmbrough, 19:11, 10 December 2011 (UTC).

If it's implemented correctly, then __AUTOSUBST__ vandalism shouldn't be a big problem. As I understand it, adding __AUTOSUBST__ to a template and clicking "Save" wouldn't automatically subst every existing transclusion of the template. It would only cause subsequent transclusions to be substed. In other words, only when someone adds the template to a page and clicks "Save" would the template get substed. Most high-use templates are protected anyway, so it's unlikely that even a clever vandal would be able to do too much damage.

I like this proposal, but it will require thinking like this to ensure that more problems aren't introduced. The current solution to this problem is to add {{substituted|auto=yes}} to the template so that it gets added to

yak

20:20, 12 December 2011 (UTC)

That's ({{substituted|auto=yes}}) good to know. Thanks I still think a new namespace is simplest all round. fredgandt 20:32, 12 December 2011 (UTC)

UNESCO's Open Access to Knowledge and Information could not ask for a better platform than Wikipedia.

What if government committed to these ideals incrementally shifted their tax-funded knowledge resources to Wikipedia? This would pose a considerable increase editing burden on Wikipedia, but would also dramatically increase the quality of the information resources, shifting to a true "real-time" encyclopedia.

I am trying to include this in a proposal for healthcare reform in Ontario, as it pertains to certain policies/procedures in our province's healthcare system that are often poorly understood/obscured. I would like to train/encourage my colleagues to participate in Wikipedia Medicine project and the other initiatives relevant to human health.

Ideas/Feedback? Always appreciated. Laith Bustani (talk) 14:25, 10 December 2011 (UTC)

• How would we cover events that are politically controversial? Wikipedia doesn't have ads to avoid any appearance of bias, this would be worse. -- Eraserhead1 <talk> 15:24, 10 December 2011 (UTC)
• Response: Hi Eraserhead1. Thanks for your feedback. I think the governments would have to subject themselves to the editorial policies of Wikipedia or risk deletion of their content, just like anyone else. That is the beauty of the concept, governments would be accountable to a universal, democratic/systematic means of validating their communications. Laith Bustani (talk) 16:01, 10 December 2011 (UTC)
• My current policy focus is healthcare, which is unique because everyone is affected by it, and my colleagues and I are actively looking at ways to improve engagement and transparency in the data analysis that leads to new recommendations for healthy living in its broadest sense.Laith Bustani (talk) 16:05, 10 December 2011 (UTC)
• Government programs are often politically charged, I don't see how we could have large scale contribution from government without a large dose of political bias coming with it, based on what ever party happens to be in charge at the time. Governments are not immune from having conflicts of interest either. Monty₈₄₅ 17:39, 10 December 2011 (UTC)
• Oppose - there's no way we could remain neutral if we did this.
  Wha?
  19:30, 10 December 2011 (UTC)
• Comment - confused here. All U.S. government produced material is PD and all country articles were expanded or started by importing the CIA Factbook. All U.S. city articles were created or expanded by importing U.S. census data. Thousands of articles are illustrated by images from the U.S. military, the U.S. National Archives, the German archive[2], Queensland Library and many other government libraries and archives. But I don't see how having governments directly involved would make us more an encyclopedia or more "real-time". You certainly don't expect that the U.S. government would edit the 2011 NATO attack in Pakistan until after their investigation is completed? Or that U.S. and Pakistan government would cooperate to build a neutral article on the death of bin Laden while Pakistani jets were still flying combat patrol. (Or choose your favorite 'friendly' pair -- Israel/Gaza, Georgia/Russia, whatever) Rmhermen (talk) 20:06, 10 December 2011 (UTC)
• Comment- Thanks Monty845, Sven Manguard, and Rmhermen for your points. The same "difficulties" "biases", etc. exist in the way that information is currently handled. The scary thing is that that we pretend these problems don't exist and at least with regards to health policy, we end up with a muddled web of recommendations that are often contradicting/confusing and biased. The strength of wikipedia is not the software, but the community. I can replicate a "wiki" for all sorts of things, but without the human editors to maintain integrity of the knowledge, it is a waste of time. I guess what I am saying is this: I am committed to trying to adopt the democratic editing principles behind Wikipedia to public health policy and even (this would require some tweaking on the privacy side of things) electronic medical records. What I need to know is the best way to "integrate" this effort with Wikipedia's existing treasure trove of knowledge. If there was a "win-win" way of doing this without replicating the wikipedia infrastructure/community, that would be amazing and go a long way of convincing the government that this is a good idea. Laith Bustani (talk) 22:50, 10 December 2011 (UTC)
  • Even restricted to the matter of health, individual governments give conflicting recommendations. The U.S. and EU differ whether several compounds are generally safe for human consumption, the U.S. withdrawal of RotaShield was not appreciated in Africa, the continued use of DDT in Africa is not appreciated by some Americans, etc. I am not seeing how this relates to Wikipedia the encyclopedia. Rmhermen (talk) 23:14, 11 December 2011 (UTC)
  • Comment: Rmhermen, the problems you (and others) point out here are actually opportunities. The problem with the world health organization and other governmental regulatory agencies is 1) lack of resources (mainly human) 2) lack of a prospectively agreed-upon, teachable system for resolving conflicting/contradictory recommendations. As a physician, I have to process conflicting recommendations all the time. When I recognize that recommendations are opinions, and trust the opinion of the person who I am trying to help above those of "experts", then amazing things happen. Yes, I have to be conscious of laws, regulations, my personal abilities/limits, etc. This is the "art" of medicine. What I see the wikipedia community/platform as making possible is a "transparent" debate/discussion of universal health issues/treatment recommendations that will take them from being improperly applied/generalized to highly customized/refined through broad-based, and ongoing editing. It pushes the concept of "real-time" historical record, but because of the diversity of its community, and it's Wikipedia:Five_pillars its it has perhaps more integrity than any governed body I know. I have no delusions that this is a "perfect fit", or that there are not real "problems", but I would not be surprised if Wikipedia's founders were challenged with the same logistical impossibilities when they originally came up with the idea.Laith Bustani (talk) 16:55, 12 December 2011 (UTC)

As a former public health worker myself, I fear your naivete has led you astray. We already have a massive problem gathering sufficient administrators and editors to edit the existing 3.8 million articles in the English-language Wikipedia alone. There is no way on Earth we could assemble the additional volunteers to maintain even the flawed level of accuracy and integrity which the existing Wikipedia articles display, for all the additional subject matter you are proposing to dump into our laps. --Orange Mike | Talk 17:02, 12 December 2011 (UTC)

• • Response: Orangemike, I freely admit to my Naïveté in this regard. Do we have statistics on the number of editors and the contributions they make to Wikipedia's integrity (last I heard, studies cited 96% accuracy, surpassing Encyclopedia Britannica). What is the processing cue like? OK, now, what if in exchange for governments agreeing upon wikipedia as a "good-enough to start" place to start embracing UNESCO's principles, how difficult do you think it would be to teach the skills required to 1) write higher quality articles 2) learn the editing tasks essential to maintaining Wikipedia's integrity? You see, if you are telling me that even on Wikipedia, there is way more work to do than people to do it, what hope in hell do I or any other government have in setting up a separate "walled garden" to replicate the process. I see this as a potential area to develop win-win relationships with small groups that are ready for this type of experimentation. I am holding up my hand and saying "pick-me, pick-me" as a test case for the application in healthcare policy. With respect to health care conditions/treamtent, though I have signed up for the Wikipedia medicine project, I do not routinely reference Wikipedia in the treatment of my patients and stick with more traditional information sources (journals, UpToDate, etc, colleagues). That being said, I have been amazed at the quality of some of the content and think that if I could get more of my (smarter, less naive) peers to participate, then we might go a long way to capturing/cleaning up the knowledge/experience that is wasted every time a treatment is initiated for an individual and the results of the treatment lost. Laith Bustani (talk) 22:41, 12 December 2011 (UTC)

That material could never be used in Wikipedia - unless you first get it published in a reliable peer-reviewed journal (preferably it get collated into a review article) and we decide it is a necessary addition to a encyclopedia-type article. No original research is a basic rule. Rmhermen (talk) 23:04, 12 December 2011 (UTC)

I'm not really certain what it is you're trying to achieve. To have accurate information about public health on the English Wikipedia? Great, you can get started by fixing these thousands of problems. To have health policy makers use the English Wikipedia to communicate with each other and to decide what their next policy will be? No, thanks: that's not an encyclopedia's job. We'll report what they've decided after they have WP:Published their decisions. Being involved in interpreting raw data and making these decisions would be a violation of the WP:No original research policy. WhatamIdoing (talk) 23:49, 12 December 2011 (UTC)

To get some highly needed outside input on this issue, please see Wikipedia_talk:Articles_for_deletion#Bold.2C_revert.2C_discuss where I argue that AfD should be Afd. Debresser (talk) 14:40, 11 December 2011 (UTC)

Oh, my. I thought it was another round of Wikipedia:Perennial proposals#Rename_AFD, but this is actually a discussion on the capitalization of the initialism, i.e., whether the page should refer to itself as "AfD" or "Afd". Don't we have anything better to do with our time these days? WhatamIdoing (talk) 00:07, 13 December 2011 (UTC)

Hey Ya'll - I am going to copy and paste this e-mail i've sent to three wikipedia admins/contacts. I got shot down by all three, the last one gave me this link.

See here, and if you do this -- more donations will come. Thanks.

Howdy,

I know you probably get a bunch of e-mails all day every day. But I think I have a good idea. Other public non profit organizations use this idea, and i suggest wikipedia use it too. I didn't know who to contact, so I ended up here, although i'm in South Carolina. My suggestion (ready?)... have an online gift thing that you can give to wikipedia in OTHER PEOPLES NAMES and wikipedia e-mails the person you're gifting, confirming the amount you gave IN THEIR NAME, FOR THEM, instead of getting them a stupid little gift...

Do you hear me? This is much better than getting someone a crappy dollar store gift, this is me donating to wikipedia and pawning it off as a gift ;)

They will like it, I would love it (showing off my support....) and less crap is given (they're just going to throw away my gift, or re-gift)

Please let me know how you feel about this idea. If you don't like it, I would still appreciate a response.

Thanks, Greg — Preceding unsigned comment added by 68.209.77.205 (talk)

Seems like a perfectly reasonable idea to me. Psychological trickery that would probably work. fredgandt 21:14, 11 December 2011 (UTC)

Who would want to receive a gift like this? Whilst Wikipedia is wonderful, I reckon most people would prefer a gift donation to be made to a charity that saves lives (or puppies or whatever they're into). Presents have to be meaningful, and unless the recipient is already a keen Wikipedian, then I think the gift would be a bit misplaced. Bazonka (talk) 21:19, 11 December 2011 (UTC)

Assuming by your indent that you are talking to me; It strikes me this would work in the same way you can buy people a square foot of moon or a Scottish Lordship. Not all gifts have to be meaningful or serious. Apart from anything, it is whether this would encourage giving that matters. I think it probably would, since people like to give things they might not have thought to buy for themselves. fredgandt 21:26, 11 December 2011 (UTC)

Actually it was a response to Greg. I have no problem with this proposal in principle, but I just reckon that there are other charitites that would be more appropriate for gift donations. Bazonka (talk) 21:40, 11 December 2011 (UTC)

You need to talk to

User:Meganhernandez, who is in charge of the 2011 fundraising campaign. I'll let her know about your question. WhatamIdoing (talk

) 00:10, 13 December 2011 (UTC)

I'd like to be auto scrolled to the section I didn't edit, in the same way we are scrolled to the section if we did edit. fredgandt 21:20, 11 December 2011 (UTC)

Is it not simpler to click your browser's Back button? — This, that, and the other (talk) 10:11, 12 December 2011 (UTC)

Simpler for whom? Certainly simpler for WMF but no so simple for however many millions of users per day. I see the current behaviour as being contrary to expected behaviour. fredgandt 11:34, 12 December 2011 (UTC)

Hmmm. I have never used the Cancel link. Looks like all it does is reload the page without linking to the section. I always used browser back or backspace. ---— Gadget850 (Ed) ^talk 11:56, 12 December 2011 (UTC)

I always use the back button for this reason. It should not be hard to add a section to the link. However, a bigger peeve of mine is that the Cancel link should be a button. — Edokter (talk) — 17:27, 12 December 2011 (UTC)

I see the individual MediaWiki messages, but where is the edit summary and related built? Directly through the software or in an interface page? -— Gadget850 (Ed) ^talk 18:00, 12 December 2011 (UTC)

Totally agreed Edokter. Not being a button is also contrary to expectation. The addition of the section title to the URL would be a doddle for WMF. The question is, whether anyone feels it should be requested. So far, it seems people don't even use it. fredgandt 18:11, 12 December 2011 (UTC)

From [[3]]

Dear readers of this Talk:Non compos mentis. I am having troubles with Compos Mentis, as it is not mentioned in the English Wikipedia. I would like to refer to Compos mentis from my article about a new word called: Mentification. So I would like to change the subject of the page to Compos mentis and explain about it, and after having done that, in the same page I will let it be followed by the original explaination about Non compos mentis. To mention Compos mentis first is for reason that Compos mentis is more essential compared to Non compos mentis. I will leave all explanations as well as all references intact concerning the original term Non compos mentis. For your information: the term Compos mentis in my language (Dutch) has the same basic meaning in legal terms as in English, although the approach is in Dutch more from the neutral side, as Non compos mentis holds implicitely a judgement about the status of the mind and therefore the term: Non compos mentis seems like a prejudgement. A comparable situation would be with the term: Billable hours (at work) as there are also Non billable hours that would not directly lead to a specification on the clients bill. So to explain Non billable hours, one would explain billable hours as well, and first. My question to you: Would the proposed change above be all right with you? I will just wait for a couple of days. If I hear nothing, then I will make the change with all related consequent changes. Else we can discuss the subject further. Bouwhuise (talk) 23:16, 11 December 2011 (UTC)

Bouwhuise (talk) 07:56, 12 December 2011 (UTC)

List_of_legal_Latin_terms#C has "Compos Mentis" listed. FYI. fredgandt

11:37, 12 December 2011 (UTC)

Proposal to create a new magic word we can insert into long threads to create an [edit] link without creating a new section.

• I envisage being able to add the magic word (e.g. {{EDITPOINT}}) anywhere within a section, and have an [edit] link created at that point in the thread (floated to the right of the page as with all normal edit links). This would not create an {{anchor}}, section or subsection heading, or be recognised by the toc.
• When followed, the editor would be presented with an edit page populated by all the text of the section the EDITPOINT is in, from that point onward (including text in sub-sections), as would be normally expected, but not any text from that section that is above the EDITPOINT.
  • An alternative to this would be that all text from that section is presented as normal, with the exception that the raw text is then automatically scrolled to the point at which the EDITPOINT is featured. This may be a more practical and appealing usage, but may have technical difficulties the primary proposal doesn't.
• The reasoning is that when wanting to edit half way through a long section, we are presented with the whole section and its subsections, with little to no obvious indicators throughout the unformatted raw text to follow in order to find the point at which we wished to make our edit.
  • With EDITPOINTs inserted at intervals, we could access the section far nearer to the point we wish to edit than at present. We could simply use the nearest EDITPOINT that is above the focus of our attention.
• I believe this would make editing easier, would be relatively simple to create and install, and would have few downsides.
  • There is one obvious possible downside: Overuse. A simple solution for this is to
    faux-pas
    , so would cause little extra work for guardians.
• Summary: A simple new mark-up that creates an [edit] link without creating a section. When followed, the editor gets an edit page populated by all text from the section the EDITPOINT is in, but automatically scrolled to the point in the raw text where the EDITPOINT used is situated. only from that EDITPOINT onward. This would make it easier to hone in on the point in that thread we wish to edit (reduced searching of the raw unformatted text).

Thanks for reading. fredgandt 08:43, 4 December 2011 (UTC)

Questions about EDITPOINT

Questions: I am concerned that the feature would just be used to make every paragraph an EDITPOINT and deter people from making logical section headers, as they would have in the past.

• Q1: Would points be overused, and flood a page with [edit][edit][edit][edit][edit][edit]?
• Q2: Since headers were no longer needed, would header titles suffer?
• Q3: How about create non-indexed headers "==Break2=={{nonindex}}" shows header "Break2" as [edit] but not in Table-of-Contents box?
• Q4: Should a page be "fractionalized" instead, by a menu option "Fract" which re-displays the page with dozens of "[edit]" links, for each paragraph of the page (with no need to embed editpoints)?
• Q5: How would a page redisplay to the edited thread unless editing by header? I do not think it could, and after an edit, the page would display to the top and no longer jump down to the section just edited.

Those are some other questions to consider before stating Support/Oppose. -Wikid77 14:27, revised 18:23, 6 December 2011 (UTC)

Compare to header [Edit] as a name: The concept is intended to not list any EDITPOINT headers in the Table-of-Contents box. However, that it might be ok to name a small section header as "====[Edit]====" to show a left-side "[Edit]" break (with a right-side "[edit]" button). For example, there is an header as "[Edit]" here:

  [Edit]

This section, with header "====&nbsp; [Edit]====" is a 4th-level header which clearly indicates that it can be edited, without needing to create an {EDITPOINT} marker here. However, the header "[Edit]" will also appear in the Table-of-Contents box, above. Logically, users might see such break points are obvious edit-buttons, without the need to conceal editpoints. As more users insert headers named "[Edit]" as text edit-points, then the concept would be understood more widely, without adding special features. Does that seem like a good idea? -Wikid77 18:18, 6 December 2011 (UTC)

Support/Oppose of EDITPOINT concept

• Strong support - eminently sensible. Pesky (talk …stalk!) 08:53, 4 December 2011 (UTC)
• Support. Seems like a good incremental short term solution, and I'm pretty confident it could be implemented easily (but would require minor Mediawiki code changes). Some concerns: if the page is very large, including all text all the way to the end might be too much text. Perhaps just to the end of the section? Also, should the {{EDITPOINT}} tag itself be included or not? How would edit conflicts be handled? Alternatives: I think the better long-term solution here is a real in-place WYSIWYG editor that lets you edit as you read without switching views or formats, but that's a long way off and very hard to get right. As an intermediate alternative, it might be nice if there was some kind of "edit here" feature that let you just right click any piece of text and choose "Edit here" and it would open up an editing view scrolled directly to that location. Dcoetzee 09:25, 4 December 2011 (UTC)

• As I see it, this is a small step in the right direction, not a giant leap. I proposed that the text presented in its raw format is all the text from the section the EDITPOINT is in, from that point onward. Edit conflicts would be dealt with in exactly the same way as they are now. This is basically just an invisible section heading that even the toc doesn't see. The actual tag would of course be visible in the edit window, otherwise nobody could ever remove or more them. fredgandt 09:54, 4 December 2011 (UTC)

• Support. The number of times I'd have used this recently just at
  WT:NOT would have saved me a good hour at least (not including fewer edit conflicts). Thryduulf (talk
  ) 12:45, 4 December 2011 (UTC)
• Weak support: to me it seems that those edit points are useful before inserting them, not after; another concern is that the articles would get littered with edit points. Still, that might be useful, so why not? Though I would prefer an option to add (visually) tiny edit point to every block element on the page. — Dmitrij D. Czarkoff (talk) 13:27, 4 December 2011 (UTC)
  • What do you mean by "block element"? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
    • It was about HTML elements with block properties, though I get that Mediawiki abuses HTML markup, so this could be limited to the topmost sub-elements of the article (each text block, blockquotes, etc...) — Dmitrij D. Czarkoff (talk) 16:09, 4 December 2011 (UTC)
• Comment: this isn't going to happen; the devs will say it's covered by LiquidThreads, and anyway editing is based fundamentally on sections, so the best you can do is scroll to a pre-specified point in the wikitext. That latter idea though can be done by a script. The timestamp with (UTC) at the end of each signature is fairly unique; a script could add a little mark at the end of each (UTC), and when clicked it goes into edit mode and searches for that timestamp in the wikitext. Rd232 ^talk 13:45, 4 December 2011 (UTC)
  • Is liquid threads ever coming though? It's being trialled on some user talk pages on Wiktionary, but it's not ready for general release yet and hasn't had any significant changes for a couple of years. It's good in theory, but I've yet to be convinced it will actually do what it's trying to do. So in the meantime, why not implement this interim proposal that is technically possible without requiring years of development? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
    • Well for one thing, the client-side script I suggested would be a better solution than the magic word. For another, I severely doubt that if a bug was filed today it would result in a change to Wikipedia's functionality in less than 2 years, even if the developers agreed in principle. Developer time is simply too limited. Rd232 ^talk 19:39, 4 December 2011 (UTC)

    The

    Helder

    22:20, 4 December 2011 (UTC)

  • LiquidThreads is for discussion pages, not articles... I don't see the relevance. Dcoetzee 04:49, 6 December 2011 (UTC)
• Rd232 is correct: whatever the merits, this proposal will not be implemented. For one thing, inserting "===Break 1===" is almost equivalent (yes, it's not the same and has defects, but it's very similar). Re LiquidThreads: That's the knockout; devs would not want to work on some tweak that would be obsoleted by LQT. My opinion: LQT would kill good editors, and I hope the community manages to repel it (in brief: too obtrusive; encourages "this is a forum"; POV pushing would never end; too hard to remove unhelpful comments). Johnuniq (talk) 02:25, 5 December 2011 (UTC)

What about automatically inserting edit points every x bytes in a section over a length of y bytes? That way it would be impossible for people to go nuts with it. Add an option to show/hide edit points in the preferences, or for each page individually, and anybody that doesn't like them wouldn't have to deal with them. Put me down for a Weak support. Falconus^{p t c} 11:58, 5 December 2011 (UTC)

Although I agree with those suggestions and think they would improve the overall proposal, I think asking for more than the simplest upgrade could lead more certainly to it not being added. I'm going to be updating the proposal to simplify it (technically) with just that in mind. Very basically, I think proposing the alternative (in the proposal lead) method is more likely to be considered for creation and installation, since it is nothing more than an adaptation of the code controlling nd displaying section headings. fredgandt 20:36, 5 December 2011 (UTC)

• Support. They don't have to be used in articles. If an article section is that long we would make section breaks.Jasper Deng (talk) 22:42, 5 December 2011 (UTC)

• I've struck out (crossed through) and inserted (shows underlined) some text in the proposal lead since having a think about it. The proposal seems to be getting bogged down in technical details. Can we first establish simply if there is a rough consensus for some sort of functionality that allows this kind of thing? Once we know if the basic idea is worth exploring, we can get techy-wid-it!
  • I've started work on a user script and a template that may or may not amount to something useful. I'll keep you posted. I would prefer the function/feature to be part of the Mediawiki software though. fredgandt 19:42, 6 December 2011 (UTC)
• Support - sensible idea for pages with longer sections. A can see issues arising with these edit points being overused, however, so there would need to be clear instructions on how to use them (perhaps a new WP namespace page on edit point guidelines).
  talk
  ) 00:54, 13 December 2011 (UTC)

• Week support: "==Break2=={{nonindex}}" could be used too.. as well as the normal breaks. Weighing it with the possible litter we can get yet the usefulness of such edit-point. --lTopGunl (talk) 23:47, 13 December 2011 (UTC)

End of EDITPOINT thread

To add a Support/Oppose note, edit this section and place text above the header "End of EDITPOINT" so that new text will be listed in the Support/Oppose section. -Wikid77 14:03, 6 December 2011 (UTC)

Jimbo is looking for input regarding the passage of SOPA and how it will effect Wikipedia.here. Crazynas ^t 22:55, 10 December 2011 (UTC)

Wikipedia:SOPA initiative in the unlikely event that we get to that point, some advance planning would be good. Crazynas ^t 10:31, 13 December 2011 (UTC)

• Please visit this discussion on Wikipedia talk:Merging to comment. Protonk (talk) 00:53, 14 December 2011 (UTC)

I feel that when multiple non-registered users are participating in a discussion on a talk page it is sometimes difficult to keep track of who is saying what (as strings of numbers are less memorable IMO than names). Therefore I propose that the current mechanic which governs how external links in square brackets are displayed (i.e. by labelling them as the n^th link on the page, where the number changes automatically – e.g. [4] [5] [6]) be grafted/exported/whatever onto IP signatures, so that in future they automatically look something like this:

Comment 1. 1.23.456.78⁽¹⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 2. 9.01.234.56⁽²⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 2a. 1.23.456.78⁽¹⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 3. 7.89.012.34⁽³⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 3a. 9.01.234.56⁽²⁾ (talk) 14:56, 12 December 2011 (UTC)

Comment 3b. 1.23.456.87⁽⁴⁾ (talk) 14:56, 12 December 2011 (UTC)

Except that this is evidently a mock-up, and the aesthetics can be played around with, but you get the idea. My thinking is that the "[7] [8]" technology already exists, so it would reduce the workload in creating this feature? It Is Me Here ^{t / c} 14:56, 12 December 2011 (UTC)

Just a note, and I say this as a someone not very familiar with the underlying software and mechanics of Wikipedia, but when you create three external links, of which the first and third are the same, they will not have the same number (see here). So I am not sure, whether applying the external links mechanics to the IPs (if that's possible at all, I don't know) would have the effect you want to achieve. Toshio Yamaguchi (talk) 15:09, 12 December 2011 (UTC)

I don't think there's much chance of this being incorporated into MediaWiki, but it would be easy enough for someone to write a userscript that adds your indicator after all IP sig links. Anomie⚔ 16:51, 12 December 2011 (UTC)

There is no way to do this with the current method of applying the link icons; see Help:External link icons. -— Gadget850 (Ed) ^talk 17:40, 12 December 2011 (UTC)

The proposer is presumably thinking of citation links, which can be made to repeat numbers, but which involves quite a bit of overhead. --erachima talk 18:30, 12 December 2011 (UTC)

Those are done by the Cite software extension. ---— Gadget850 (Ed) ^talk 12:53, 13 December 2011 (UTC)

There's an RfC on making the the {{Orphan}} tag invisible. It's at Template talk:Orphan#Proposal - Change this to a hidden category template. I'm spamming it here because it's a highly visible template and so this is an important issue. (Arguably a CENT RfC might be in order since this is template that many readers see often. It might be called for to bump it up to that level if anyone wants to.) --Herostratus (talk) 16:48, 13 December 2011 (UTC)

The Articles for deletion process currently operates as follows:

In some cases, this process is unsatisfactory. If no meaningful contributions are made to a discussion on its first day, it is likely not to be visited by contributors until the eighth (closing) day. Many people will only click on today or closing, and not seek out any of the intermediate days. So some AfD's disappear, undiscussed, into limbo for a week, during which time nothing happens - the AfD is effectively inactive.
So, I propose the creation of an AfD holding pen for new discussions. The following process will then take place:

• A discussion is opened in the AfD holding pen (or whatever we want to call it). This pen can be accessed through the Deletion discussions box - technically, it will be just the same as a daily deletion log, but won't be limited to one day's AfDs only.
• It stays in the pen (potentially for several days) until the discussion has properly begun, i.e. someone has contributed who is not the deletion proposer or the page's creator. It is then moved to that day's deletion log.
• The AfD then follows the current procedure until closing day. Perhaps the length of discussion time can be reduced to less than a week.

This will reduce the number of AfDs that are relisted by ensuring that all undiscussed AfDs are still easily accessible via the Deletion discussions box.
I don't think that the holding pen would get overloaded, because things should be moved out of it fairly quickly. We may want to consider a maximum holding time before an Admin can retire the AfD as unresolved, though I suspect that this would not be reached often. Bazonka (talk) 22:33, 5 December 2011 (UTC)

An interesting idea, but is there really a problem with the current system? It only takes a few seconds to relist a debate and most articles up for AfD aren't of the "urgent that this be deleted" variety. --Philosopher ^{Let us reason together.} 04:31, 6 December 2011 (UTC)

The problem is not with the few seconds to relist, but the fact that it can take a week to get there, during which time it is likely that nothing will happen because the discussion isn't readily accessible. I do take your point about urgency though; perhaps it's just me that gets frustrated by these unnecessary delays. Bazonka (talk) 07:51, 6 December 2011 (UTC)

I disagree that the debate isn't readily accessible.

CAT:AFD, for example, is a great way to view all the active debates in a particular topic area - or in all areas, if you have time to kill. To be honest, I doubt I've ever used the discussions template posted here. UltraExactZZ ^Said ~ Did

20:28, 6 December 2011 (UTC)

That is indeed useful, if you know it exists. I didn't, and I bet plenty of other people don't either, because there is no simple route to it from

WP:AFD. Perhaps this should be made more prominent. Bazonka (talk

) 20:49, 6 December 2011 (UTC)

You could also promote

TALK

10:14, 7 December 2011 (UTC)

As you can see, I have added some all options to the Deletion discussions template. This should help people to more easily find discussions that aren't on their first or last day. This does not necessarily mean that discussions won't remain undiscussed though, but it might reduce the number a bit. Bazonka (talk) 20:51, 8 December 2011 (UTC)

Someone has been reverting my edits to the "Deletion discussions" template claiming that it is "completely unusable", which I dispute. Some other opinions at Template talk:Deletion debates would be appreciated. Thanks. Bazonka (talk) 07:20, 14 December 2011 (UTC)

After spending some time recently RevDeling and

N.B. restricting Special:Protectedtitles to Sysops and above would still leave the problem of Admins having access to a sort of oblique Oversight log, but at least this move would be a start. It Is Me Here ^{t / c} 10:52, 13 December 2011 (UTC)

I think a better solution would be that if you RevDel (or RFO) a SALTing of a page, you unSALT it, RevDel (or RFO) the unSALTing log, and if necessary add an approrpiate entry in MediaWiki:Titleblacklist. This way, you don't have the problem of admins seeing RFO material; you don't restrict the community's ability to view Special:Protectedtitles, a restriction which should only be done if absolutely necessary; and frequently the user who was thwarted in recreating the SALTed page due to SALT will try to get around it by homoglyphs - and Titleblacklist is a better way to stop such users. עוד מישהו Od Mishehu 16:30, 13 December 2011 (UTC)

But surely that would not solve my main concern (publicly viewable/un-hideable gunk, whose existence means that we are not following through with

WP:DENY fully), since in your situation we would simply have gunk at MediaWiki:Titleblacklist rather than at Special:Protectedtitles

?

Having said which, another thought has just struck me: is it possible to have the software check whether a salted page cannot now be created by non-autoconfirmed/non-Sysops anyway (since a lot of the titles I was sending to RFO were quite old, possibly predating AbFil, Titleblacklist and the rest of it)? If so, perhaps a list of such "over-salted" pages could be drawn up, and an OS could go through them and remove them from Protectedtitles in the way you suggested? It Is Me Here ^{t / c} 17:25, 13 December 2011 (UTC)

I imagine it would be relatively simple for a bot to take all the pages listed at Special:Protectedtitles, and check if each one of them has a SALT log entry which it can find. If the bot in question is run from an admin account, it will find just the "over-salted" ones; if it runs from an account without admin access, it will also find the salted ones where the log was admin-hidden. עוד מישהו Od Mishehu 20:04, 13 December 2011 (UTC)

How about a modification to the software to make such pages hidden in Special:ProtectedTitles, while those that are no problem can still be publicly viewable?  Hazard-SJ  ±  03:55, 15 December 2011 (UTC)

Does it just have to be ClueBot who fixes vandalism? I am sure that many acts of vandalism on Wikipedia get corrected by users who are not bots. ACEOREVIVED (talk) 10:59, 7 December 2011 (UTC)

I actually noticed during some recent huggling that a number of IPs were reverting vandalism (manually). In fact, I'm pretty sure that one IP was following the huggle feed in the IRC, because I ran into him or her reverting stuff about 20 times in two hours.

Wha?

16:47, 8 December 2011 (UTC)

Past research has indicated that for every IP-based act of vandalism, there are three or four well-intentioned edits by unregistered users. It's not at all uncommon to see unregistered editors fixing vandalism. WhatamIdoing (talk) 23:37, 12 December 2011 (UTC)

This discussion appears that it should be totally closed now, as it appears that ClueBot is again active - look at the history of the article Higgs boson, and if you click on the article's history, you will see that an act of vandalism was corrected by ClueBot today (December 15 2011). ACEOREVIVED (talk) 16:09, 15 December 2011 (UTC)

I would like to see the data regarding IP users, where can I find the analyses?

WP:HUMAN has a graph from 2007 (4+ years ago — donkey's years for a website). Thanks --Squidonius (talk

) 19:21, 15 December 2011 (UTC)

• confused why this is here and not on the
  Bot request page.Crazynas ^t
  00:34, 11 December 2011 (UTC)

I am not a bot programmer. I want to reach a consensus here and then file a request at

WP:BOTREQ. I thought such a task should have a consensus before being requested. Toshio Yamaguchi (talk

) 00:56, 11 December 2011 (UTC)

You can still post your request at

WP:BOTREQ. I will do it as a courtesy. PaoloNapolitano

10:56, 11 December 2011 (UTC)

Botreq would likely ask for consensus. Funnily enough I have been thinking about this sort of thing. The development cost for a single section of a single page is fairly high, but a generic solution (also called AI) is attractive. Rich Farmbrough, 21:19, 11 December 2011 (UTC).

Agreed; not a great cost/benefit ratio just for Sony, but in principle a tool like this could really help keep business coverage up to date. (Hmm. How about a bot for annual results or market cap?) bobrayner (talk) 21:11, 15 December 2011 (UTC)

I propose to create a new userright. Users with this right would be able to circumvent the

What happened to administrators? We can ask them to make necessary modifications if necessary. This doesn't often happen, so I wouldn't support.  Hazard-SJ  ±  03:48, 15 December 2011 (UTC)

Last I checked, administrators can't get around the spam blacklist; other than adding something to the whitelist. This was last week I had this problem.--v/r - TP 03:58, 15 December 2011 (UTC)

Bypassing the spam blacklist would render the page uneditable to all other users. No. T. Canens (talk) 04:13, 15 December 2011 (UTC)

Not exactly, since approx. 2010 you can edit and save paged with blacklisted links: spamlist only prevents new blacklisted links. Still, I don't think a new userright is a proper solution to Toshio's problem. — AlexSm 04:29, 15 December 2011 (UTC)

I definitely remember seeing instances this year where a newly blacklisted link prevented others from editing a page until someone found out what the culprit is. T. Canens (talk) 06:08, 15 December 2011 (UTC)

If it's any help, I recently submitted a patch that would help by telling you all the instances of offending links in one go. This makes it even easier to write a script that automatically 'nowiki's the bad links. - Jarry1250 ^{[Weasel? Discuss.]} 00:22, 18 December 2011 (UTC)

This is something that had bugged me for a very long time: How come the way we edit on Wikipedia is needlessly complicated? Although I have come to terms with it (at least with most of it), I imagine that a turn off for many new editors is how confusing everything is. They would not know how to use templates/categories/infoboxes etc. or even know how to bold or use headings. On many online sites, where you can contribute to discussions etc, there are buttons at the top of the editing box, not unlike microsoft word, that allow you to easily edit colour/bold/size etc. and a lot of other stuff without having to worry about three lines for bold and a copy and pasted line of text for colour etc. In other words, what you see is what you get. Whilst editing, you would see stuff in bold or coloured etc. Also if there were buttons along the "Advanced", "Special Characters", "Help", "Cite" row that had all the infoboxes/templates etc.. or something like that... it would make all our lives soo much easier. Why isn't this done?--Coin945 (talk) 11:19, 16 December 2011 (UTC)

There is wikiEd – is that what you were looking for? It Is Me Here ^{t / c} 15:04, 16 December 2011 (UTC)

And see Wikipedia:Village pump (technical)#Visual editor. – ukexpat (talk) 15:18, 16 December 2011 (UTC)

Ahh... thankyou very much. Both seem rather promising :)--Coin945 (talk) 04:36, 17 December 2011 (UTC)

Currently editing the section loads the whole source and sections are sometimes very long and all that content is loaded in to the edit-box as well. How about placing a small reply link (or button) at the end of talk page sections, clicking which will load the same section as an almost empty edit box and by default will have only the indentation suitable for a reply to the last comment which could be changed if required by the editor. This will prevent loading the whole text if some one only needs to reply and will also prevent mistaken editing of other comments. Or maybe even better than the reload, clicking the reply link expands into an edit box of the same format as mentioned above and clicking a save button in that would simply post the reply at the end but not reload the page instead become "your reply has been saved - reload page to see it" or something similar. The normal editing can still take place by clicking the 'edit' link while this will be an additional help. The proposal is open to be further decided as an opt-in/opt-out option that would be adjustable by individual users for themselves so as to see or not to see the reply link. --lTopGunl (talk) 15:27, 16 December 2011 (UTC)

The Liquid Threads extension does this, but we don't use it. I would however oppose implementation of the extension as many talk pages would need reconstruction.  Hazard-SJ  ㋡  23:54, 17 December 2011 (UTC)

How about having a new one which just posts the text into the source without any other changes in page structure or display by by-passing the reload following the proposal above? --lTopGunl (talk) 00:47, 18 December 2011 (UTC)

Would it be possible to remove fundraising banners for IPs from which donations have already been received this year? — Preceding unsigned comment added by Heymisterbill (talk • contribs) 20:54, 16 December 2011 (UTC)

technically, probably, but that would involve tracking and finding out whether it's a public computer (removing it from a shared computer is not good). And it would only work with cookies or something. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 22:16, 16 December 2011 (UTC)

In theory, it already does that. --Yair rand (talk) 05:42, 19 December 2011 (UTC)

While I'm doing my part to reduce the huge backlog in Category:Non-free images with orphaned versions more than 7 days old, I've several times found images in which an old version, not the current version, is preferable; for example, if the latest version is of substantially higher resolution than an older version. Unfortunately, in such cases I must delete the entire image, rather than just deleting the version, and then I need to restore the older version. If it's possible, I'd like to see the (del/undel) text for the latest revision be just as useful as it is for all older versions. Is it possible? Nyttend (talk) 13:11, 18 December 2011 (UTC)

For an example of what I'm talking about, look at the logs for File:Beastie Boys - Ch-Check It Out CD cover.jpg. Nyttend (talk) 13:15, 18 December 2011 (UTC)

Normally, one would revert to the proper version, then delete the old revisions. — Edokter (talk) — 19:45, 18 December 2011 (UTC)

In which case I need to delete even more revisions. If I could just delete the current revision, it would entail less effort. Nyttend (talk) 20:38, 18 December 2011 (UTC)

I have a suggestion that might make some money for Wikipedia and serve its goals at the same time.

I would like to be able to BUY a copy of a certain year of the entire site. I cannot say if this would be a set of DVD's or a large stand alone hard drive, but I would LOVE to have my own copy of the whole site. There are times that one's internet is not working and to have your own copy of the closest thing to an Encyclopedia Galactica would be delightful.

A second reason I think this is a good idea is that it would allow a researcher to document changes over time. For example, the word "soandso" only has a placeholder in Wikipedia 2011, but by 2012 it is a huge document. The phrase "soandso" appears to have entered the popular lexicon between 2011 and 2012.

We can learn a great deal about the past by looking at a popular encyclopedia at that time. What were the prevailing attitudes on certain subjects and what subjects might have been taboo. It would be a shame for Wikipedia to be moving forward in time and to leave nothing historical in its wake. The evolution of Wiki's or Wikipedia itself is a subject worthy of study, but unless there exists a static snapshot of a moment in time, that historical context is lost.

In the final analysis there is the fact that when civilization collapses, I'd like to know a few backups are out there somewhere.

See Wikipedia:Database download. You can download the whole site to your hard drive, for free. However, if civilization collapses, I think that the internet would be among the bottom of social priorities. Cambalachero (talk) 02:25, 17 November 2011 (UTC)

Do you know about

page history? You can see all versions of every page, ever. For example, So and so began as a rather odd redirect in 2005 [9], and gradually expanded [10] [11]. (Not a great example; it's far more interesting to look at the historic versions of more substantial articles). Also, you might find nost:HomePage interesting, which is a frozen snapshot of Wikipedia from 2001 - e.g. nost:Earth

.

There's various plans in place to provide a 'snapshot' of Wikipedia in various formats. I just hope they remember to write

Don't Panic in large, friendly letters.  Chzz  ► 

09:09, 17 November 2011 (UTC)

Oh and by the way: you can also buy printed editions of Wikipedia! mabdul 11:55, 30 November 2011 (UTC)

• Oppose It's a good idea, but the encyclopedia is too large to try to document the entire thing. At this point, how would we easily make a distinction between actual articles and "Wiki" pages, such as the projects and special pages? What articles should be included/excluded from a printed addition. At this stage, with American culture moving away from print media and embracing the digital age, it would be like taking a step backward, rather than a step forward. Tarheel95 (Sprechen) 16:57, 5 December 2011 (UTC)
• There are various (free) versions that you can own, but they do suffer form some limitations. Cambalachero's idea is a good one in principle. Rich Farmbrough, 21:29, 5 December 2011 (UTC).
  

Provided you don't care about the images, this provides a dedicated offline copy of Wikipedia in a handheld package. Dragons flight (talk) 21:39, 5 December 2011 (UTC)

• Proposal is out of place. There is no policy or guideline of the English Wikipedia that has much to do with this. If you want to buy a physical copy from the Wikimedia Foundation, contact them directly and see if you can come to a mutually agreeable price. Alternatively, it doesn't have to be the Foundation; nothing stops anyone, really, from downloading the whole site and selling you a physical copy, but if you want to place an ad for such a person, this is probably not the right place to do it. --Trovatore (talk) 21:44, 5 December 2011 (UTC)

• My studies show that the English Wikipedia would fit on a large external hard drive, along with all media it uses (although they may have to be at reduced size). I think this could be sold for $100 USD, possibly less. I think it's an excellent idea for someone to do this. I might do it. WMF isn't going to do it, as they generally leave commercialization of content to others. Dcoetzee 10:25, 8 December 2011 (UTC)

Sure, go for it. Anyone can; it's (almost entirely

* Many people have copied various parts of Wikipedia to various formats; that's all great. No problem. And if they make $$$ from it, good luck to 'em.  Chzz  ► 

10:23, 14 December 2011 (UTC)

• If you want to buy and carry a copy of Wikipedia, consider the WikiReader which retails for less than 100USD. You can download updates yourself or subscribe to their service and receive new copies of Wikipedia via the post. I have one on my coffee table and I love it. LeeColleton (talk) 04:11, 20 December 2011 (UTC)

Alright, this may sound silly, and may possibly be more appropriate on meta, but I don't use meta, so I'm asking here. I generally use the URL to navigate between wikis, for example if I'm looking at someone's Special:Contributions, I just have to change en. to fr., and there I am. And then, if I need to go to commons., I don't need to change .wikipedia.org, the software automatically translates it to .wikimedia.org. My "problem" is that it doesn't do the opposite translation. So if I come from the French Wikipedia, e.g. Discussion utilisateur:, I'm not redirected to User talk: when I change fr. to en., nor is wikimedia.org redirected to wikipedia.org once one changes the prefix. I propose that domain and subdomain redirects be established for all languages, at least to and from (from is already done) .en for interlanguage, and from .wikimedia.org to .wikipedia.org when going from meta or commons to a wikipedia (the opposite is already done). This could also apply for other types of wiki though I'm not familiar with them. Thoughts? P.S. I'm technically incompetent, sorry if there is something preventing this in the software or some kind of technical conflict that I'm not aware of. Regards CharlieEchoTango (contact) 07:01, 19 December 2011 (UTC)

This sounds similar to something proposed on the wikitech-l mailing list recently. Anomie⚔ 12:24, 19 December 2011 (UTC)

Good to know, thanks! Was there any follow-up on the proposal? CharlieEchoTango (contact) 03:10, 20 December 2011 (UTC)

May I suggest we start a workshop like they have on the French Wikipedia? I don't exactly know how they work, but the idea seems to be that they are pages where novices and experts congregate and discuss things. I know that sounds similar to the Ref Desks, and they are working well, but I mean starting workshops focused on specific goals, not linked merely to existing projects, but encompassing something broader. I think the best starting point would be a writers' workshop, focusing solely on improving the writing standard/ encyclopedic style of articles. The workshop would consist initially of one page, where we would nominate an article to work on, thrash out suggested improvements to the writing, and then post the changes back in the articles. Editing of content would be kept to the barest minimum. If successful, the idea could be expanded. IBE (talk) 13:50, 19 December 2011 (UTC)

• Haven't finished reading the proposal and a firm Support from me. Volunteers and students in a relaxed, easily found (and suggested (linked)) project space somewhere. would be awesome. Perfect way to boost quality, productivity, and retention (by way of encouragement). fredgandt 13:57, 19 December 2011 (UTC)
• Check with WikiProject Guild of Copy Editors. ---— Gadget850 (Ed) ^talk 13:59, 19 December 2011 (UTC)

Thanks for the link. I've noted it and will pursue it with them. Any further comments on the suggestion are welcome, but I did feel there had to at least be something very similar already. IBE (talk) 16:13, 19 December 2011 (UTC)

I uploaded files to here and not Commons with good reason; I'm fine with them being on commons, but they are easier to manage from en.wiki (such as tracking where they are, for instance) and it is a rather a rude shock when you're tryimg to assemble an article months or years later and you find they are no longer in your contributions list or upload log (yes, they somehow...disappear). Could people please obtain the explicit consent of users before rudely moving their image to commons? John Riemann Soong (talk) 05:34, 14 December 2011 (UTC)

• Bear in mind that you consent to allow this with any of your contributions. Photos simply happen to be most likely to be moved off wikipedia entirely (rather than text which is edited, deleted, moved around, etc.). I have a number of files uploaded here rather than commons for a variety of reasons and I don't usually have an issue with someone else reuploading them to commons and deleting the copy here. IF that happens just download the commons copy and re-upload it. Protonk (talk) 06:11, 14 December 2011 (UTC)

  The problem is when people delete your files and you have no idea where they went (because they disappear from your upload log, and they don't show up as a redlink because they are on Commons). John Riemann Soong (talk) 07:35, 14 December 2011 (UTC)

• Use the {{keep local}} tag, designed for this purpose. Making requesting user consent mandatory would make the majority of cases, where the uploader is no longer active, rather difficult. However, I personally find that keeping them all on commons makes them easier to track, especially with the ListFiles function. sonia♫ 06:34, 14 December 2011 (UTC)
• You're free to use {{keep local}} if you really want, but keep in mind this means any improvements made to the images or their descriptions on Commons, possibly long after you've departed the project, will not be seen on enwiki. This should not be a long-term solution. I agree that tracking files moved to Commons by user is an important issue and hope that once it's solved it'll eliminate this concern. Obtaining permission beforehand is infeasible because many departed users are impossible to reach. Dcoetzee 07:36, 14 December 2011 (UTC)

• While I sympathize with your inconvenience here, having to get the permission of the author to move or change something flies in the face of so many principles, policies, and standards on Wikipedia that the answer is, flat-out, no. --erachima talk 08:01, 14 December 2011 (UTC)

  There's nothing wrong with having the file kept locally. Yes, it can be copied freely -- but deleting a perfectly good, encyclopedic, functional copy without the author knowing about it at all is an issue. John Riemann Soong (talk) 08:18, 14 December 2011 (UTC)

Deleting an encyclopedic, functional copy where it is redundant is common and sensible-- say, for example, if a user made the same article twice under different names. Unifying all possible images in one place means that changes made will apply across all projects, making things more efficient (not to mention it being easier to find free files in one place). I doubt that anyone has meant to be rude in moving your files; they're just doing their job. The simple solution is to use {{keep local}}; it's created as a courtesy to users like you who prefer it this way, as much as it's not ideal. But your proposal is impractical and its implementation would slow file work dramatically. sonia♫ 08:36, 14 December 2011 (UTC)

I seems that an automatic notification if/when a file is moved would be helpful. At least then people would know if the (not their) files were moved, and where to. fredgandt 08:43, 14 December 2011 (UTC)

Yeah, notification could be done, but "explicit consent", no. It'd just add bureaucracy. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 08:51, 14 December 2011 (UTC)

• Oppose: moving to Commons no way harms editor — the image can still be watched, tracked and whatever. Moving images to Commons is in line with word and spirit of Wikipedia rules, and explicit author's content would just make matters worse for Wikimedia with no one's benefit. — Dmitrij D. Czarkoff (talk) 09:07, 14 December 2011 (UTC)
• Oppose, but see the problem: As
  Dmcq (talk
  ) 10:26, 14 December 2011 (UTC)
• Oppose: Sleeping editors shouldn't block a move forever. A little background, before sending thousands of pix to Commons I sent hundreds (mostly more useful ones) to en and many of those have later been found by other edtitors and moved to Commons. Problem is, sometimes I don't see the notice in the original file, thus fail to follow the link and watchlist it in Commons, with the result that they are poorly categorized and not geotagged. So, if I fail to see the pre-announcement or otherwise do not object in a few days, the transfer ought to go ahead anyway. Silence implies consent. On the other hand, the thing I wish is, the moving bot should also watchlist it for me in Commons. Jim.henderson (talk) 19:39, 15 December 2011 (UTC)
• Oppose. I like the idea of an automatic notification if it's possible, but requiring consent would be problematic indeed. Commons exists for the sake of making media available to all WMF sites, so all images should be there unless there are copyright issues — please establish a Commons account and upload images there, rather than here. Nyttend (talk) 13:20, 18 December 2011 (UTC)
• Oppose per
  WP:OWN. I'm no fan of {{Keep local}} which is why I proposed a long time ago that it needs an optional reason parameter, but sadly that got shot down because, well, people who like OWNing their images and having to actually specify a reason for their desire to OWN might cause cognitive dissonance. And that would be bad. —Tom Morris (talk
  ) 09:31, 20 December 2011 (UTC)
  • when a person releases an image under a free license they still actually "own" the image its just that they have given permission for the image to be used providing that certain conditions are met. Gnangarra 09:51, 20 December 2011 (UTC)
• oppose seaking permission before hand. I think it would be a good thing when the bot transfers the image to commons to post on the users talk that the move has occured, as user talk pages dont get deleted, if in the event that user becomes inactive the notifications will just sit there so that when the user is active again they'll know what happened. Gnangarra 09:51, 20 December 2011 (UTC)

There's an RfC on eliminating the need to add the <!-- Metadata: see [[Wikipedia:Persondata]] --> comment from the persondata template and perhaps even eliminating it from the articles as more significant edits are made. It's at

The discussion of this at Wikipedia talk:Persondata#Can we stop adding the annoying, useless comment now? and Template talk:Persondata#Can we stop adding the annoying, useless comment now? show that there was consensus to remove the comment in the template, and that it has been removed, as you had wanted. Is your post here asking for something more? If not, let's close the discussion here. Senator2029║talk 15:40, 21 December 2011 (UTC)

Yes my questions are answered thank you. You can close the comment whenever you want. --

talk

) 20:21, 21 December 2011 (UTC)

Greetings. My name is Jonathan Obar, I'm a professor in the College of Communication Arts and Sciences at Michigan State University and a Teaching Fellow with the Wikimedia Foundation's Education Program. This coming semester I will be running a little experiment in one of my undergraduate classes. I thought that I would propose the idea to the community before things get rolling, and ask for your suggestions, feedback, criticism, and also your help!

Here's the idea... students these days (especially those studying communications) are fascinated by social media. The Education Program has done a fantastic job tapping into this fascination and the results are clear. A recent survey analysis that we completed suggests that more than 70% of the students (across the US) that have participated in the Education Program are enjoying the experience and prefer editing Wikipedia to writing "traditional" term papers. To students, social media is fun, but it's also relevant. Many communication students hope to get jobs with a new media focus and hope that their university experience prepares them for the position that they've been hoping for. This new class I'm developing, this small experiment, takes the Education Program to the next level. Instead of training students to be editors, why not train them to be administrators? The goal will be to provide students with a far more in-depth understanding of how Wikipedia operates, how the hierarchy of administration works, how policies are created (what the policies are), what admin tasks are completed daily, and so forth. What will also make this class different from most of the classes that are participating in the Education Program is that the entire class will be devoted to the "learn to be an administrator" concept, whereas most EP classes focus mainly on course content (depending upon the discipline) with the Wikipedia component being secondary.

In speaking with members of the Wikimedia Foundation and a variety of experienced administrators, it became clear right away that the students would not be able to actually perform advanced admin tasks. We had discussed potentially matching students up with admins as "buddies" so that the students could shadow them (it's an idea we're still considering), but I realized that this wouldn't allow students the freedom to participate in a truly active learning experience. Of course we wouldn't want students performing admin tasks without having gone through the formal RfA procedure, something that we won't be able to have the students do in such a short period of time (most of them probably don't have enough edits to get to the first level anyways). So, instead, the course will do the following:

Students will...

Step 1

• Study Wikipedia policies in general
• Study Wikipedia admin policies and procedures
• Learn how the community operates
• Introduce themselves to the community in a variety of ways
• Begin to integrate themselves into the community
• Begin to edit

Step 2 Conduct a variety of basic admin tasks like...

• New page patrol (will introduce themselves to the community first)
• Recent-change patrol (will introduce ...)
• Review images for copyright issues (will introduce...)
• Begin to organize a "bookshelf" for administrators
• Begin to build the bookshelf

Step 3

• Reach out to the admin community to chat
• Review different admin boards
• Reflect on their experiences and write about them
• (Hopefully) interview a few administrators about their experiences.

As you might imagine, I'm going to be figuring things out on the fly as I see how things go. For now, I thought that I would bring this idea to the community and ask for your feedback and suggestions. Personally, I think that this new idea will benefit all involved. From what I've heard there is a backlog of admin-related work on WP, our class could try to make a contribution in that area. I have also heard that the administrator community isn't growing at the rate it once was - our program is potentially training the Wikipedia admins of the future. The WMF likes the idea because it still gets students involved, connects a university class to WP and may lead to a new arm of the Education Program. The benefits to the students are obvious... learn the interworkings of one of the most popular social media/networking sites in the world.

Anyhow... What do you think? Anyone interested in helping out? I'd love to have some admins skype into our class, perhaps a few at a time for a discussion/debate? It'd be great if the students could interview a few admins too! Learn about what you do and why you love it!

Really looking forward to your comments.

Sincerely,

Jonathan Obar Jaobar (talk) 06:59, 20 December 2011 (UTC)

• I am supportive. We do need to train more admins. Having students learn about Wikipedia before they edit content I believe will be better then them trying to edit content before learning how Wikipedia works.
  talk · contribs · email
  ) 07:27, 20 December 2011 (UTC)
• From what I have seen in my experiences in
  admin coaching, people who edit for the purpose of becoming an administrator are like shooting stars: Bright at first, but they fade fast. I'm not convinced that what we need is to train administrators; what we need is to raise up editors who like what they're doing here. People who like it here and like what they're doing here tend to do a better job of things, from what I see. bibliomaniac15
  07:37, 20 December 2011 (UTC)
• This is a great idea... but so far, only in theory. I don't know if you're aware of this, but the various Education Programs are on thin ice due to the vast amount of substandard content they generated -- skim WT:United States Education Program, the threads I linked to at WT:Canada Education Program and the whole of WT:India Education Program to get a feel for the issues. The most successful student projects on Wikipedia have professors that are experienced Wikipedians. This need for this is more acute since you are teaching Wikipedia and how we ward out unwanted content. This means you need to get your hands dirty shoveling crap, especially in the areas in which you want to teach (this will help you answer student questions). It's great to have the backlogs reduced, but doing so in an incompetent manner is counterproductive.

Calling Wikipedia "most popular social media/networking sites" is

cause for concern

.

Also, I have removed your email address as publishing it on-wiki is a

Bad Idea(TM). MER-C

07:44, 20 December 2011 (UTC)

Disclaimer: I have worked with

this one of which created many good articles such as this article - all of which were made by 1st year undergrad students and in this case classified as a DYK on April 19, 2011). Hence I would not worry about the experience of the professor - instead would ask/hope that users would make any suggestions to the type of tasks these students could perform without requiring admin rights. Epistemophiliac (talk

) 16:20, 20 December 2011 (UTC)

I agree that User:Jaobar has more experience than the typical EP professor. My specific concern is that he has little personal experience in the areas he wishes to cover (e.g. image tagging and [13]). MER-C 12:52, 21 December 2011 (UTC)

• I'd downplay the "admin" side given that in spite of the community's frequent stated belief that adminship is "no big deal", it is a term of art in the Wikipedia community. They are really being taught how to administrative tasks, rather than tasks that require sysop powers. Given that people are likely to get a bit tetchy about this, and given that students might get the wrong idea and go around claiming they are now Wikipedia administrators because they do new page patrolling, I'd leave off the word "admin". Think about it like this: imagine if you taught a bunch of graduate students how to teach undergraduates. You might call said training course 'How to become a professor'. But that doesn't mean they are professors at the end of it, they are TAs who have skills that would be handy for them if they choose to stay in academia. The course could quite easily be called something like "How to be a Wikipedian" or "How to edit Wikipedia" or something like that. There does definitely need to be a better name for "that thing that non-admins do that is administrative". I've used the term "admin-like tasks" but that's kind of a mouthful. There's "WikiGnomes" which I use and like, but I have a funny feeling it might not play well outside of the Wikipedia community. (Of course, if we called admins "sysops" then saying that non-sysops are "administrators" doesn't imply that they have any kind of special powers. But, there are good reasons why we shouldn't call admins sysops!) —Tom Morris (talk) 09:06, 20 December 2011 (UTC)
• There should be more emphasis on building an encyclopedia. Everything on the syllabus is worthwhile for an administrator, but the students should actually know how to build an article as well. If they cannot do this there is not a chance that they would survive a
  WP:featured article should be covered. Graeme Bartlett (talk
  ) 10:46, 20 December 2011 (UTC)
• I'm broadly supportive of this: an introduction to Wikipedia's culture and policies would be a valuable course. In particular, there are a number of skills that are secondary to editing Wikipedia that nonetheless are highly applicable elsewhere that might be useful to include in a university course, such as the basics of copyright (and free licenses), or perhaps some rough ethical considerations on things like
  ⚡
  }} 15:12, 20 December 2011 (UTC)

"basic admin tasks like... New page patrol (will introduce themselves to the community first) Recent-change patrol (will introduce ...) Review images for copyright issues (will introduce...)" But these aren't admin tasks. These are tasks any editor can do. Are you trying to discuss the tools admins have (blocking, locking, deleted/restoring, editing certain pages) or just non-article writing tasks that everyone can do? Rmhermen (talk) 02:14, 21 December 2011 (UTC)

• These aren't specifically admin tasks, but they introduce the concepts that admins need to be familiar with and are often the types of work people are required to do before successful completion of an RFA. Before taking on speedy deletions, contributors need to verify an understanding of what constitutes an unacceptable article or image; before blocking vandals, contributors need to demonstrate an understanding of vandalism and the best approaches to unproductive changes. These are among the tasks that an admin trainee might be put to do. I'm not sure myself how anybody could otherwise learn how to be an admin on Wikipedia without actually being an admin, although interviewing existing admins seems a good idea. Otherwise, the only way I can think to give them a taste of adminship is to set them up on a mock wiki and let them have it. It would be good practice with the tools, but there's no way that they could replicate our culture, unless a bunch of us followed along and tried to replicate our controlled chaos. :) --Maggie Dennis (WMF) (talk) 13:32, 21 December 2011 (UTC)

• Per Rmhermen, you're suggesting a course in social-media oversight editing. There's nothing wrong with that, but it doesn't require an admin bit; especially where wikipedia offers
  WP:ANI and the entire variety of disciplinary systems that depend on quality reporting of issues. Bit holders are just our drudges. More could be got out of protecting a day's Featured Article than by bit hunting. The final dot point would break ethics laws and expectations of professional conduct from teaching academics where I live; your professional and legal obligations may vary. Also, your course content seems kind of sparse if this is a 36 hour face to face contact / 120 hour total learning obligation course. It omits some elements of social-media oversight, like content evaluation (quality & importance rating, peer review, GAN, A-class review, FAC). It also seems a bit overbalanced towards "whack-a-mole" moderating, as opposed to community culture building. Fifelfoo (talk
  ) 02:50, 21 December 2011 (UTC)

- All suggestions are welcome. This is one of the reasons that I posted this note. This will also be an experiment. I expect to make mistakes ... and will learn from them! Thanks so much for your comments and feedback. Please offer more if interested! Jaobar (talk) 06:28, 21 December 2011 (UTC)

About looking for spots for people to introduce themselves, may I suggest getting your students to leave notes on WikiProject talk pages? While there are no real spaces for editors to have a conversation that's not related to the encyclopaedia in some way, WikiProjects will in general be very happy to welcome new users, and only too happy to point them in the direction of work that needs doing. You could maybe get your students to look at the

Department of Fun ;) — Mr. Stradivarius ^♫

09:25, 21 December 2011 (UTC)

Students, the scholarly community and the Wikipedia community have different definitions of social network, and I suspect the student definition is similar to ours. We tend to delete facebook-like crap with little (if any) mercy and posting such nonsense has adverse consequences. I suggest you make it clear to anyone who is going to edit that Wikipedia, as far as they are concerned, is not a social networking site. MER-C 13:11, 21 December 2011 (UTC)

Yes, while from an academic standpoint Wikipedia may be a "social network", from a practical, how-we-do-things-here standpoint, it most certainly is not. One of the first items that the course curriculum should focus on is what Wikipedia is not. From the recent, shall we say, "difficulties" in the Canada program, it is clear that the differences between writing academic papers and encylcopedia articles must be hammered home right at the beginning. Let's not encourage students to run before they can walk. – ukexpat (talk) 15:59, 21 December 2011 (UTC)

I would avoid all notions that this course is intended to teach people how to become Admins or prepare them for adminship. I used to be very active in Admin Coaching and still find it amazing that the community doesn't respect coaching. But it doesn't. Wikipedia frown upon admin coaching and people who underwent it were actually criticized and opposed because they were 'taught how to pass an RfA not to be better wikipedians.' A notion I disagreed with, but alas that view killed wikipedia admin coaching. Also, one of the issues that hurt coaching was that some coaches had check the box issues that they wanted their coachees to do. "Go tag x articles for speedy deletion", "Go patrol x number of new articles", "Go welcome X number of users", "Go participate in x number of XfD's", etc. What ended up happening is that people with little knowledge/interest in specific tasks went in and made their contributions to fullfill the coaches expectations and disappeared. They didn't learn anything and often created more controversy/issue than it was worth.---Balloonman ^{Poppa Balloon} 22:36, 21 December 2011 (UTC)

Isn't the normal thing to do just to tag them with {{

WP:TFD? -- WOSlinker (talk

) 20:35, 21 December 2011 (UTC)

Your right and I thought about doing that but since its used on over 40, 000 articles I hesitated doing that. If you think that venue would be better suited for this discussion its completely fine with me. --

talk

) 20:54, 21 December 2011 (UTC)

There should be an option to not watchlist by default pages in a certain namespace. For example, I have enabled watchlisting by default as it is very convenient, but I try to keep my watchlist below 600-700 pages at any given time. It's fairly tedious to do, because everytime I edit a WT:AFC page, block a user, or leave a message to a user talk page, the page is watchlisted. I would like a feature that enables automatic watchlisting only for specific namespaces. This also addresses the above proposal on separating pages from their talk pages (e.g. WT from WP, etc). Any support for this? — Preceding unsigned comment added by CharlieEchoTango (talk • contribs) 06:22, 8 December 2011 (UTC)‎

• Oppose due to this being potentially a pain in the rear end. I can imagine too many occasions when I would have to override the exclusion of a particular namespace manually. This proposed feature would actually more than likely cause the very issues being cited as reasons to oppose the above proposal to be able to un-watch talk and other pages etc. etc. In particular the potential to forget to watch and to think that you are when you're not seems rather strong. With the other proposal, the normal behaviour (we have now) would have to be manually undone on a per page basis, meaning the likelihood of forgetting is significantly reduced (to basically zero). Simply speaking: I wouldn't want to automatically not watch all (for example) talk pages, since more often than not I want to watch both the talk and main (just occasionally not both). Blanket exclusion of a particular namespace from being auto watched is too harsh for my liking. fredgandt 09:16, 8 December 2011 (UTC)
• Support. Anything that helps customization of autowatch would be useful. I wouldn't expect most users to use it, but I don't think it would hurt. I think a prototype of this could potentially be implemented in pure Javascript, and then anyone who wants to try it out can just include it. Dcoetzee 09:54, 8 December 2011 (UTC)
• Support as an opt in with the suggestion that it be made a "gadgets" feature - I wouldn't use this, but I understand how it could be useful. If it isn't possible to do opt-in, the simple alliterative would be to have autowatchlisitng on for all namespaces or for none of them, creating results identical to the two options we have now.
  Wha?
  10:43, 8 December 2011 (UTC)
• Comment: I would certainly think that an admin who blocks a user should, for at least a reasonable time, have that user's talk page in his watch list. I would also expect this if you leave a message. Communication is two-way. If you initiate it, you have the obligation to be reasonably attentive to replies. --Stephan Schulz (talk) 11:59, 8 December 2011 (UTC)
  • Note that for some users like myself, I currently have autowatch disabled (because I make minor changes to many articles) but would be more likely to enable it for the User talk namespace, for precisely that reason. So your argument seems to actually favor the proposal. Dcoetzee 13:12, 8 December 2011 (UTC)
    • Yes, this is a two-headed snake, which is why I put it in as a comment, not a !vote. --Stephan Schulz (talk) 15:02, 8 December 2011 (UTC)
  • Well, my message wasn't very well worded, heck, wasn't even signed, of course I keep the page on my watchlist when I leave an open-ended message, what I'm referring to is mostly related to script sent messages on user talk pages; e.g. welcomes, "Your submission at AfC was created", user warnings, CSD notices, etc. No point in watching most of the time and it grows very quickly to an unmanageable (for me) watchlist. I get your point on communications, but I also see no point in keeping hundreds of declined AfCs or various WP pages (like this one). Removing them manually every other week is tedious. Regards, CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)
    • I suspect this will get lost, but it reminds me of a feature I would like, the ability to watchlist a page, with the watchlist expiring after a month or so. Perfect for this situation and many others--SPhilbrickT 15:58, 14 December 2011 (UTC)

Yes please! -- John of Reading (talk) 16:02, 14 December 2011 (UTC)

Yes, that's something I also would like to see. Toshio Yamaguchi (talk) 16:18, 14 December 2011 (UTC)

A biodegradable watch of a page? So after n time it auto un-watches? Yep, I'd go for that. As long as it was something that could be selected on a per page basis and was not default behaviour. Perhaps this should be separately proposed. fredgandt 18:07, 14 December 2011 (UTC)

• Opppose You could do this with a simple user script. And I echo Stephan Schulz's comment above. Anomie⚔ 12:05, 8 December 2011 (UTC)
  • Which script? CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)

if (wgAction == "edit" && [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 100, 101, 108, 109].indexOf(wgNamespaceNumber) != -1) { 
    document.getElementById('wpWatchthis').checked = true;
}

• Customize the numbers in the list as needed; namespace numbers in the list will be auto-watched if you add this to your
  ⚡
  }} 16:00, 8 December 2011 (UTC)

• Well this would certainly solve my problem, thanks! I added it to my User:CharlieEchoTango/common.js, but it doesn't seem to work. Purged the cache, logged out logged in, tested on two namespaces. :/ CharlieEchoTango (contact) 16:14, 8 December 2011 (UTC)

• Nevermind, I had to disable automatic watchlisting first. Silly me. Thanks a lot, Nihiltres. :-) CharlieEchoTango (contact) 16:20, 8 December 2011 (UTC)

• It seems to watchlist the associated talk namespace regardless of the script (e.g. if I choose to watch ns4, ns5 is included with it even if left out in the script). Not a big deal, though. CharlieEchoTango (contact) 16:33, 8 December 2011 (UTC)

• That's inherent to the watchlist feature. If you watch a page, you also necessarily watch the associated talk page or content page. My script merely chooses which namespaces will have auto-watch enabled: it might make sense to auto-watchlist page pairs when you edit a talk page, but not when you just edit content. {{
  ⚡
  }} 16:50, 8 December 2011 (UTC)

(Note that the above script will not work in IE7< due to lack of indexOf support.) --Yair rand (talk) 01:18, 23 December 2011 (UTC)

• Support as an option that should probably be available by default, but I'll otherwise make my above 30-second script into a more user-friendly Gadget as soon as Gadget preferences are available (
  ⚡
  }} 16:10, 8 December 2011 (UTC)
• Support with comment - I don't see that this would be a bad thing as long as its opt in and not required. I think that there is a lot of room for improvement in the way Wikipedia handles Watchlists and any functionality that allows users some flexibility in it is helpful. --
  talk
  ) 16:14, 8 December 2011 (UTC)
• Oppose I do not see the need for such a feature. When the 'Add pages I edit to my watchlist' feature is enabled, you can just uncheck the 'Watch this page' checkbox above the 'Save page', 'Show preview' and 'Show changes' buttons. Toshio Yamaguchi (talk) 17:43, 10 December 2011 (UTC)
• Support I also agree with an opt in comment, as not every user (including myself) are user script literate. Only a few are, and I agree that so many articles I tagged for deletions, users I warned and so forth gets automatically watchlisted and removing it can be a pain. Secret ^account 06:29, 13 December 2011 (UTC)
  • This proposal would offer you the opportunity to not watch any talk pages or all; any articles or all. Are you really sure that will be helpful? fredgandt 06:59, 13 December 2011 (UTC)
• Comment Some people here might find user:js/watchlist useful. It's fairly easy to install and to use in my opinion (see instructions on that page) . I have it installed, since I also have "Add pages I edit to my watchlist" enabled (hell I would miss a whole lot of stuff if I hadn't) and it makes killing unwanted pages popping up on your watchlist mostly painless. Toshio Yamaguchi (talk) 22:58, 14 December 2011 (UTC)
• Support Per Sven Manguard. Rcsprinter (state the obvious (or not)) 20:36, 16 December 2011 (UTC)