Wikipedia:Village pump (proposals)/Archive 54

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211

Main page feature suggestion

Hi i have suggestion, to have a "Today's featured article" section is great, but wouldnt it be good to have a "Article that needs your help" section to (or similar name). Where everyday 1 or up to 5 articles are posted which are in need of help, which could be any article basically. As long as it is not a Featured article. My suggestion would be to have a similar style like the "Todays featured article" with one listed article everyday that is todays help article, or to have a list of 5 articles that is todays articles that need help from the editors. Please come with more suggestions and we might get some consensus. would be nice. But my main suggestion is to have one article per day that is under the "Article that needs your help which perhaps could stand beside todays featured article or in a small column or similar. --Judo112 (talk) 21:24, 12 September 2009 (UTC)

• My main reason for the suggestion is that i think that there is thousands of articles that could be mutch improved if more people knew about them and paid them attention. I also believe that it is a project that could improve the overall standard of articles on Wikipedia.--Judo112 (talk) 21:33, 12 September 2009 (UTC)
• Support Gosh, I think this is a very good proposal. (Be warned Judo112, that you will certainly meet great resistance by a few very loud and conservative people. But don't discourage! I'm also happy to help you out if you feel discouraged.) GeometryGirl (talk) 21:35, 12 September 2009 (UTC)
• Dont worry im up for a fight;) No but seriously i hope that most of the Wikipedians see the greatness in this idea and that it will improve the overall standard of Wikipedias articles tat sometimes is low and sometimes is very high.--Judo112 (talk) 21:47, 12 September 2009 (UTC)
• Strong support. The idea of a temporary collaboration has sprung up in myriad incarnations since 2001 – COTW, ACID, all kinds of WikiProject collaborations – but I think this is the kind of idea that needs a full-force reboot. Putting one article on the main page every day to be improved would do so much: it would rekindle some of the community magic lost in the last few years; it would encourage new users and help train them; it would actually convince people to start editing again. This is far more important, in my view, than ITN or DYK.
  If you have too many articles, people will just ignore it. Highlighting a single article (which would be chosen much in the same way as the main page FA – underrepresented subjects, with clear and actionable paths for improvement) and giving it as much attention as possible would go much further than anything we've tried before. I absolutely support this idea. —Noisalt (talk) 21:44, 12 September 2009 (UTC)
  • Yes, and per Noisalts idea i change the first suggestion to One single article everyday as it will be the most effective. Hope to see a strong support for this so that we can start having this feauture on the main page up soon. Also agreeing that the "DYK" section could be moved or removed in favour of this new section which would be so mutch more productive.--Judo112 (talk) 22:03, 12 September 2009 (UTC)
• I guess I'm loud and conservative. Protonk (talk) 23:17, 12 September 2009 (UTC)
• Support I love this idea, and this would be a great way to improve articles. However, a few questions remain.

• 1. Which articles will be chosen?
  2. How do we nominate and choose articles? Will it be like FAC?
  3. Will new criteria have to be created?
  4. Won't it be a huge vandal attractor? Will it have to be semi-protected? Does that ruin the purpose?

warrior4321 23:38, 12 September 2009 (UTC)

Certainly any vandalism it attracts because of it would be dealth with swiftly for the same reasons. ♫ Melodia Chaconne ♫ (talk) 00:08, 13 September 2009 (UTC)

• A possible answer for questions 1, 2 and 3 would be: pick a stub at random. There would be no nomination, no criteria, etc. GeometryGirl (talk) 00:20, 13 September 2009 (UTC)
  • The fact that you said stub means that you want criteria. The proposal is for the improvement of articles, not expansion of articles. This would mean that even a GA article aiming for FA would be able to fit in this proposal. This is why criteria is required. What do you mean stub chosen at random? By whom? When? If we allow stub choosing at random, we would get around 500 putting their stub that they just created over there. For something that is going to go on the main page, this will require some organization. warrior4321 00:27, 13 September 2009 (UTC)
    • This was just an idea. Basically there are thousands of stubs. My idea was to pick out one stub of all the existing stubs at random (using a functionality similar to Special:Random) where all stubs are equally likely to be picked (so that there is no bias). GeometryGirl (talk) 00:40, 13 September 2009 (UTC)
      • The main page is intended for readers, not editors, so perhaps it wouldn't be best to put this on the main page? Of course there is also the issue of where you would put it, the main page is full already. Prodego ^talk 00:41, 13 September 2009 (UTC)
• Which articles will be chosen? How's C-class or lower sound? Will new criteria have to be created? I would suggest that articles be on approachable (non-technical, non-obscure) topics; those which a random, but interested researcher without specific expertise could reasonably make constructive contributions to. How do we nominate and choose articles? Will it be like FAC? I hope it would be lighter-weight than FAC. --Cybercobra (talk) 01:33, 13 September 2009 (UTC)
  • My one concern with this proposal is: we have a huge backlog of articles that are very long and moderately well-written but just don't have any sources cited, so they languish outside the GA/FA process. New editors aren't going to be interested in adding inline citations, so we'd just we adding to that backlog. —Noisalt (talk) 02:34, 13 September 2009 (UTC)
    • Any article should be able to be choosen as long as its not a featured article according to me. If B-class should be a highest level of artcile can be discussed(but sounds good to me). In my opinion we could remove the DYK section in favour of this one. What i also mean is that people can do whatever they can to help improving the article listed, i mean every article is helped when there is many edits .--Judo112 (talk) 06:17, 13 September 2009 (UTC)
      • I also think that FAC process of choosing article for the day is the best way. If there is vandalism we just have to protect it when it comes to that. On Wikipedia there will always be vandals but most people wants whats best for the wikipedia.--Judo112 (talk) 06:19, 13 September 2009 (UTC)

Historically, the general consensus has been that the Main page should be for our readers not our editors. That is why the selected articles (bolded items) on the Main Page are chosen based more on their quality, not based on how much their subjects are important or significant. That is why there are only a few links to encourage new editors, not an entire Main page section devoted to it. Thus, a dedicated section for existing editors to find something new to do or work would contradict this general guideline. What you propose might be better suited on Wikipedia:Community portal instead. Zzyzx11 (talk) 06:21, 13 September 2009 (UTC)

• Zzyzx11 your proposal often leads to that the new feature in the end isnt used at all and doesnt result in anything and in the end is blocked and becomes some sort of historic rememberance of a try to help articles. Also i think that the new section should one day include an article like Kaka Ferskur that is in need of expansion and references and then the next day an article like Anna Anderson or similar..So we get a wide range of articles. But i personally definitly think that the new section should be on the main page because else it will not attract many wikipedians and in the end it will not be used.--Judo112 (talk) 06:25, 13 September 2009 (UTC)
  • I just want to point out that i can only see this suggestion work if the section gets a place on the Main Page, or else it will just die out like that other project that one article was choosen for work during a week. I saw that it had been blocked and not touched since like 2007. I am afraid this suggestion will see the same faith if not it doesnt get priority over the Did you know section which seems ineffective anyway.--Judo112 (talk) 07:04, 13 September 2009 (UTC)

break 1

• Support We've got plenty of readers, we need editors. - Peregrine Fisher (talk) (contribs) 07:08, 13 September 2009 (UTC)
  • Nice to see that we are reaching some consensus this quick. I think Wikipedias Main Page need some drastic changes like this one in order to improving the overall standard of Wikipedias articles. And as Peregrine point out we already have readers we need editors and we need to improve the overall standard of our articles.--Judo112 (talk) 07:34, 13 September 2009 (UTC)
• Support One suggestion: the pool of articles should be those labelled "High Priority" by numerous projects. In this way, the improved article is likely to be a greater contribution to a whole; and if supported by a diversity of subjects, likely to appeal to more editors. Iciac (talk) 08:25, 13 September 2009 (UTC)
• Oppose – the process for choosing the daily 'featured needy article(s)' would necessarily have to entail either a means of selecting the worst articles on Wikipedia, or the best-but-still-need-a-teeny-bit-of-finishing-off-work articles. Either we showcase the trash, or we showcase good work and pretend that it's our trash. I don't think that this is a viable idea, I'm afraid. ╟─TreasuryTag►senator─╢ 08:39, 13 September 2009 (UTC)
• Oppose Per treasur tag, and because we should present a good finished face to the world. —Preceding unsigned comment added by Patton123 (talk • contribs) 10:27, 13 September 2009
• I like it! I suggest we choose articles that are 1) important subjects for an encyclopedia, 2) currently not good and 3) needs general attention more than Wikipedia experience. Take Parent: Everybody knows what a parent is. There is plenty of reasearch about parenting, the role of parents in history and different cultures, etc. Our article is absolute crap and doesn't seem to be getting anywhere. There would be an overlap in purpose with DYK, which is supposed to show new and far-from-finished article. However, DYK has been raising its standards and left room for something like this. That hard question is where to put this on the main page. --Apoc2400 (talk) 11:26, 13 September 2009 (UTC)
• Support apoc idea: We could do it as Apoc points out. All i am interested in is that it will be on the Main Page so that we see some results.--Judo112 (talk) 13:49, 13 September 2009 (UTC)
  • And for those opposing, what kind of image/face do wikipedia show when we have tousands of stubs and not well references articles that could be helped by this suggestion?. This idea would increase the overall standard of wikipedias article and thereby help Wikipedia get a better reputation in the long-run.--Judo112 (talk) 13:49, 13 September 2009 (UTC)
    • By the way who is the second to oppose.the person hasnt even bothered to sign hes/hers comment.--Judo112 (talk) 13:53, 13 September 2009 (UTC)
      • Parent would be a perfect article for the main page. Friendship, Cuisine, Love letter and World are other examples in the same vein. GeometryGirl (talk) 14:02, 13 September 2009 (UTC)
        • Many of our vital articles are like that – concepts that are so general no one thinks to work on them, like fear, woman, toy, trade, area. In fact, the vital articles list would be a great place to start. —Noisalt (talk) 16:00, 13 September 2009 (UTC)
          • I was thinking about vital articles as well. That would probably last us a few years, if we did vital articles below GA or below B. Random stubs will not work, because a lot of them may need merging or deleting, or the difficulty in researching them is too high. Even though we'll get some help from people who have never edited, the work (that lasts) will still be done mostly by normal editors, so highlighting the vital articles would get them on the way towards the next B,GA,FA, level, which is hard to argue against. - Peregrine Fisher (talk) (contribs) 16:44, 13 September 2009 (UTC)
• Support: I've both read about and seen for myself that the Wikipedia editors' community is becoming...insular. It isn't what it used to be, that for certain, and that is definitely not just the registered editors' faults. Unregistered vandals make casual editing hard for those who wish to do it. Nonetheless, I believe an 'Articles Needing Help' section could give a jump to the casual editing community, something which Wikipedia needs to maintain, lest it become Conservapedia. Okay, maybe not that far, but... BobAmnertiopsis∴_ChatMe! 16:47, 13 September 2009 (UTC)
  • I say for once let the village pump discussion lead to something. Lets make room for this new section on the Main page where it fits so it will be usefull. And let start with the article Toy. that will be a great start.--Judo112 (talk) 16:52, 13 September 2009 (UTC)
    • So feel free to fix it. Would be so happy for Wikipedia if we finally did something new and refreshing for the Main Page.--Judo112 (talk) 16:54, 13 September 2009 (UTC)

break 2

• Opposed The main page is for readers, not editors.
  — V = I * R (talk to Ω) 16:57, 13 September 2009 (UTC)
  • As already pointed out before, readers we have... and plenty of... editors is whats needed. And this kind of new feature is what could bring the Wikipedia to have an overall better quality of articles and also get many new editors. And i believe you are wrong to because if the main page was only for readers there wouldnt be any attempt to get editors to edit pages like todays featured article etc etc.. then it would only be a big Wikipedia news kind of main page or wikipedia information whxih its not.--Judo112 (talk) 17:33, 13 September 2009 (UTC)
  • I have now said everything i can say, and told all my point of views that can be find in this section of discussion. Now i leave it up to the Wikipedia users to decide. Hopefully i will see this feature up on the main page soon.--Judo112 (talk) 17:37, 13 September 2009 (UTC)
    • We don't need more editors, or different editors, we need better editors. This isn't a solution to that issue, as people will edit articles that their interested in and that they are capable of writing for. The main page itself is for readers because it shows articles which are primarily intended to be read, and it should remain that way. This proposal is specifically tailored to highlight articles which are intended to be edited, and while that's a fine and admirable goal it should not be something that is featured on the main page.

      Here's one suggested remedy: develop a page in the Wikipedia namespace which accomplishes the goals of this task, and after it's up and operating we can talk about adding a link to it to the sidebar. That should accomplish a similar level of attention while leaving the main page alone.
      — V = I * R (talk to Ω) 20:08, 13 September 2009 (UTC)

      • A better suggestion is for people to go and see what Wikipedia already has before proposing things here. This is the third section of this page as it currently stands where people are proposing things that already exist. Uncle G (talk) 11:06, 21 September 2009 (UTC)
• Support Fine idea. I've long maintained that higher priority should be placed on improvement of existing articles. However the fact that anything linked from the main page becomes a vandal-magnet is concerning... It would be interesting to compare how much vandalism the article gets versus the amount of productive edits. -- œ^™ 18:40, 13 September 2009 (UTC)
  • This problem can be solved easily by todays Wikipedia. Blocking all unregistered users from the singel article for a few days,hours or weeks is the easiest way and is quite often used on Todays featured article when the vandals are to many. There will always be vandals but you have to believe tht most users are on Wikipedia to help...thats my philosophy:)--Judo112 (talk) 20:30, 13 September 2009 (UTC)
• Support There are many bots out there that can help in creating the list and picking articles neutraly, based on tags on the page (User:B. Wolterding/Cleanup listings for example). And with the number of articled needing attention growing by then minute, I'm sure a constantly changing list could be done. Maybe something like:
  • Article 1 lacks sources.
  • Article 2 needw to be wikified.
  • Article 3 is lacking an image.
  • (Purge|create a new list)
  • etc, etc. - Trevor MacInnis ^contribs 19:16, 13 September 2009 (UTC)
• Support, but it should not be on the first page, maybe the village pump.— Preceding unsigned comment added by 207.161.190.232 (talk) 19:52, September 13, 2009 (UTC)
  • IP:207.161.190.232 please edit more than one article before getting involved in serious discussion like this one. And get an user page here on Wikipedia to.--Judo112 (talk) 20:23, 13 September 2009 (UTC)
    • Judo112, I'd appreciate it if you withdrew that comment. It seems unduly like biting a potential newcomer. The point raised by the IP editor is actually a fair one, and should be judged on its merits, not the lack of an account or apparent shortage of previous contributions (since many people have dynamic IP addresses, it is entirely plausible that this is somebody who has edited anonymously previously, or even that it's just a user who hasn't logged on). The awareness of the existence of the village pump suggests a certain level of familiarity with Wikipedia already. However, to the IP user: I too recommend that you you register for an account if you have not done so already. You will find it makes communication, keeping track of edits and watching articles you are interested in, much easier :) TheGrappler (talk) 00:20, 18 September 2009 (UTC)
• Support having it on the main page absolutely. This gets us back to the roots of what a wiki is all about, and I think it would do a lot of good. I think something selected truly at random (rather than by a nomination process) would be best. Cool3 (talk) 20:17, 13 September 2009 (UTC)
  • Good and i hope everyone agrees with me when i say that the new section has to be placed on the Main Page, because else it will only be visited less and less and in the end no one will use it and it will be blocked and only visited as a cemetary for some old project that died out like so many times before here on Wikipedia.--Judo112 (talk) 20:21, 13 September 2009 (UTC)
  • I would suggest having a script which chose an article C class and lower at 0:00 UTC. warrior4321 20:24, 13 September 2009 (UTC)
    • Very good idea Warrior. Maybe we could fix this up soon as it seem to be many people who is supporting this suggestion.--Judo112 (talk) 20:27, 13 September 2009 (UTC)
      • I agree that this is Main Page or bust. Anywhere else kind of defeats the purpose. On further reflection, though, I do have an idea about the article; it's sort of a waste if we end up with an utterly inconsequential stub. So, what if we take a random article C class or lower that has received a "Top" or "High" importance rating from the appropriate WikiProject? Cool3 (talk) 20:33, 13 September 2009 (UTC)
        • Even better Cool3:) good ideas!!--Judo112 (talk) 20:36, 13 September 2009 (UTC)
          • I would suggest further that the new section is either placed where DYK section is today or close to it. But i would prefer to have it where DYK is today and that DYK is moved a step down.--Judo112 (talk) 20:36, 13 September 2009 (UTC)
            • I like the idea that we first tackle page which have received high or top importance in WikiProjects. I just hope this doesn't lead to abusing the importance of pages, and we suddenly see pages which aren't essentially high importance, as high important just for the improvement. warrior4321 20:39, 13 September 2009 (UTC)
              • I really dont see any worries, we have to take the good with the bad, overall i dont see anything bad coming out of this. lets try it and if it doesnt go well we can always try something else. Would be best if someone fixed this new section up tonight for a first article so that we can see how it works.--Judo112 (talk) 20:42, 13 September 2009 (UTC)
                • The Main Page need some new style anyway. If someone is wiling to do the edits we could have it up by 0:00 UTC tonight i guess. It would be great if someone did it.--Judo112 (talk) 21:05, 13 September 2009 (UTC)
                  • I think that may be a bit premature. The real thing is for someone to create a prototype/mockup of what it would look like. Then, an RfC or similar would be needed. Main page redesigns are pretty major events. Cool3 (talk) 21:29, 13 September 2009 (UTC)
                    • We aren't going to revamp the main page after a mere 24 hours of discussion that occurred over the weekend at the village pump. We also still have no process in place for choosing possible articles. AniMate^draw 21:34, 13 September 2009 (UTC)

break 3

• Oppose per Treasury Tag. Do we really want our worst articles on the front page? AniMate^draw 21:34, 13 September 2009 (UTC)
  • Wikipedia is an ongoing process, asking people to help edit some of the poorly written articles just shows that Wikipedia is not complete, and is always looking for proper edits to our articles. warrior4321 21:44, 13 September 2009 (UTC)
    • I second Warrior's reply. GeometryGirl (talk) 21:51, 13 September 2009 (UTC)
      • Yes, but traditionally the front page has been for our best articles. I think the best way to get more and better editors is to highlight the best of our work, not the worst of it. There are other ways to get people to edit articles that fall under this criteria... criteria that doesn't exist, mind you. This seems like something that could be handled by a WikiProject or some other process. Perhaps contacting the folks in charge of the signpost might be a better idea, or creating a template like the {{pic of the day}} that someone could update would work. Regardless, I do not believe this is appropriate for the main page. AniMate^draw 21:53, 13 September 2009 (UTC)
        • "traditionally the front page has been for our best articles" -> This is false: DYK and ITN highlight what Wikipedia does worst; newly created unfinished stubs, and articles on rapidly changing topics prone to editwars. GeometryGirl (talk) 22:04, 13 September 2009 (UTC)
          • So you now want to promote more "unfinished stubs"? Nice. Honestly, DYK, ITN, and FA are great for our readers. One deals with interesting topics they likely haven't heard of, one deals with timely articles they likely have an opinion about, and the third shows off our best articles. These are positive ways to draw in new editors and readers. This new idea would be showing off our crap. This is a negative way to draw in new editors and readers. I'm still opposed, especially since there are other ways to do this internally, like I highlighted above. AniMate^draw 22:25, 13 September 2009 (UTC)
• Oppose Why would readers be interested in 'articles to improve'? This is clear a change to the long established consensus that the main page is for readers not for editors and while consensus can change, it is important editors understand that the consensus was there and why it was there but I see no mention of this in the proposal which doesn't bode well. In any case, DYK in particular, and to a lesser extent ITN already fulfill the purpose. If really necessary, we could emphasise that editors are needed for DYK articles. Nil Einne (talk) 22:31, 13 September 2009 (UTC)
  • Isn't the goal of a wiki to remove the editor-reader distinction? Cool3 (talk) 22:37, 13 September 2009 (UTC)
    • Who told you that? There are in fact a large number of closed wikis that only allowed selected editors and some people even use wikis for their personal website which only they can edit. Wikipedia does allow anyone to edit, that doesn't mean we think of readers and editors as the same thing. In many areas, even outside the main page, our primary focus is our readers, since we are creating an encylopaedia for readers and not for editors. We would hope many of our readers would be editors, but that doesn't mean we try to force them to be or think there's no distinction Nil Einne (talk) 22:49, 13 September 2009 (UTC)
  • Nil Einne: Why would readers be interested in On This Day? Or Did You Know? They're so boring. But the fact that I'm not interested in it doesn't mean someone else can't be interested in it.

    As for this "consensus that the main page is for readers, not editors", I'm curious as to where that came from. I've never heard of it before now. —Noisalt (talk) 22:57, 13 September 2009 (UTC)

    • Obviously your entitled to think they're boring. I suspect many people are interested in learning more about stuff that happened today in history, it's a common thing in newspapers and websites alike. I guess you can call an interest in history a common human quirk and one of the ways that interest is sparked is by thinking what happened today in history. Similarly while many people may not find most thing in DYK of interest, I suspect many readers will end up reading at least one, we do have a lot of them and change them about every 8 hours, so it's not that hard. As you've acknowledged many people do have an interest in reading more about things which seem boring to you (and it should also be obvious that most people come to wikipedia to read not to edit). It's also quite clear it's our intention with DYK to interest our readers hence why we call it 'did you know' not 'wanna improve these recent articles?' and why we aim for an interesting hook to interest readers.

      As for never having heard of the main page being for readers not editors, have you ever actually participated in any area of the main page? I'm not trying to put you down here but this comes up all the time in Talk:Main Page and also in WP:ITN (it's why we don't put up things which are likely to be of substanial interest but don't yet have sufficient relevant content in the article) and I would suspect every other area relating to discussing the main page. For example this early discussion Talk:Main Page/Archive 4 from 2002/2003 implies it. Notice how there are multiple mentions of what the readers wants and even We're trying to keep editor links to a minumum on the front page. The earliest explicit mention of the main page being for readers not editors that I found is from early 2004 Talk:Main Page/Archive 14#Unique nature of Wikipedia is submerged, I think the explaination there is still of some relevance. Since there was some objection there, I would note it was next expressed at Talk:Main Page/Archive 25#Bootiful! with no objection. I would also note that in many of the other discussion it was implied as in the earlier discussion I pointed out, e.g. you'd find many discussions about how to make things better for readers. You'd likely also find a number of relevant discussions here [1] and [2] since as I mentioned this is often comes up. Nil Einne (talk) 23:38, 13 September 2009 (UTC)

    • I'll second Nil Einne. Stats show that almost anything put on DYK gets a substantial boost in pageviews, which is a good indicator that readers are attracted (probably by the hooks). DYK and ITN articles are theoretically great ways to pull a reader someone into editing - the articles are being actively looked after, so talk page discussions don't take weeks to get a response (or months, or even years as I've seen happen before to new editors, who abandoned the project long before getting a reply!) That means there is more guidance available to help a new editor through the hoops. Since neither DYK nor ITN articles are at featured standard, they often have room for improvement (and ITNs frequently need updating), so new editors have opportunities. Nevertheless they are only linked to from the main page if the article already has passed a certain quality standard, which may help new editors get the gist of what is acceptable. On the other hand, I admit I haven't seen specific evidence that ITN and DYK do draw in new users. We really need a more comprehensive study of what the pathways are to becoming a Wikipedia editor - my bet would be on people who are start editing annoying typos, which doesn't seem strongly linked to main page use though certainly typos often appear in DYKs. (I wonder if we should develop an evil "trapdoor" feature to entice unwary readers into editing, by autodetecting common typos on unprotected pages ... give unregistered users a banner warning that a possible error has been detected, asking them to click if they want to see it ... the typo gets highlighted and an "Is this a typo? Y/N" dialog box appears ... if they click "Y" a tool tip gently points them to the edit button ... and then we've got them ;) Particularly if they get a nice thank you message after saving, suggesting they register for an account, and an automatically tipped-off newbie-greeter leaves them a message, thanking them if it's a genuinely constructive edit, on their IP talk page just in case they don't avail themselves of the opportunity to sign up straightaway. I'm sure this would be a nightmare to program, but I reckon it'd be frighteningly effective!) TheGrappler (talk) 01:26, 18 September 2009 (UTC)

break 4

• Oppose - Duplicated by DYK, and Random article. Cirt (talk) 23:18, 13 September 2009 (UTC)
  • I wouldn't say that a DYK hook encourages readers to help cleanup the article, but I can see how Special:Random can be helpful to entice readers to starting fixing up articles, as most of the time every second click will result in some stub needing cleanup. Also there's WP:CHALLENGES as displayed in the highly visible Special:RecentChanges page which lists 4 articles instead of one that could use some work. -- œ^™ 23:51, 13 September 2009 (UTC)
• Oppose The encyclopaedia must be kept separate from efforts to entice readers. It's all very well to attach "edit" tags, and exhortations to get involved at the fringes of our pages, but intolerable on the front page of the product. Our mission must come first.  Skomorokh  23:23, 13 September 2009 (UTC)
  • Reply - Funny, I thought our mission was to build a free encyclopedia that anyone can edit. How does encouraging more people to edit an article that needs help conflict with that mission? If anything, this helps the mission! Nutiketaiel (talk) 16:49, 17 September 2009 (UTC)
• Additional comment As for the vital article proposal, I can see that as having the potential to destroy vital articles completely and I'm not exaggerating here. As someone who is a resonably regular participant in WP:ITN, Talk:Main Page and has also seen many other trouble hotspots, I know that there is strong concern among many editors of WP:systemic bias and in particular us exposing it on the main page. Indeed when I first read of vital articles (and similar things) a while back, it was one of my first thoughts and while it doesn't look too bad, it's not perfect and I can easily see a number of areas of contention. I strongly suspect one of the reasons why it has survived as well as it has is because many people don't care that much since it doesn't have that much of an effect. Most wikipedians probably don't even know it exists. I can assure you however that once you try to use it to choose articles worthy of listing on the main page for improvement, there will be a lot more attention and very likely some rather never ending and rather nasty arguments about what does and doesn't belong. We already see this to some extent in other areas of the main page, but they're naturally limiting since you need to fulfill other criteria and also have some degree of an established system Nil Einne (talk) 23:38, 13 September 2009 (UTC)
• Oppose. There are only ~2,600 featured articles, but there are hundreds of thousands of articles needing cleanup. You'd have to either just pick ones at random, which would likely end up putting the occasional offensive or spam article on the Main Page and would routinely pick obscure subjects that few are interested in working on. Or, you'd do it manually and have an organizational nightmare trying to figure out which articles to list from a potential pool of hundreds of thousands. Additionally, things on the main page tend to be vandal magnets, so its questionable how much improvement would actually happen. Mr.Z-man 00:59, 14 September 2009 (UTC)
  • And yet Wikipedia:Article Collaboration and Improvement Drive seems to operate in practice, despite assertions that it is theoretically impossible. ☺ Uncle G (talk) 11:06, 21 September 2009 (UTC)
    • Not a good comparison. Its on an out-of-the way page, seen by a handful of editors per day. If its on the main page, where it will be seen by thousands of people per second, the decision of which article to put there will become a far bigger deal. Imagine if DYK had no restrictions on what articles could be nominated. Mr.Z-man 23:35, 3 October 2009 (UTC)
• Oppose I imagine the implementation of this proposal would involve a board where editors would decide through discussion exactly which of our articles are in need of help, but not have problems so severe as to be unadvertisable. This would be adding a level of unneeded beauracracy, while the efforts would be better spent actually fixing the articles. ThemFromSpace 02:19, 14 September 2009 (UTC)
  • As noted above: Wikipedia:Article Collaboration and Improvement Drive already exists. Uncle G (talk) 11:06, 21 September 2009 (UTC)
• Oppose, we use DYK for the same sort of thing. Ironholds (talk) 13:42, 14 September 2009 (UTC)
• My suggestion (also made elsewhere) is to have a "random article needing help" link in the navigation section. Would this be more feasible? Jackiespeel (talk) 13:01, 14 September 2009 (UTC)
  • Yes i like this suggestion. In my opinion those who have stated opposed seems to focus on only the negative possible aspects while not even considering the obviously good aspects of the suggestion. I still in in Support, they also seems to be oppose more because the last few has been oppose and just following the trend.--Judo112 (talk) 13:54, 14 September 2009 (UTC)
    • stated opposed seems to focus on only the negative possible aspects while not even considering the obviously good aspects of the suggestion - I could say the same about those who have supported, after all as I mentioned above you didn't even mention this would be going against the long standing practice of the main page being for readers and not editors and while it's possible to change consensus, it's usually wise to at least mention you are changing it. they also seems to be oppose more because the last few has been oppose and just following the trend - it doesn't sound like you are assuming good faith. I suspect the bigger reason why you got more opposes is as word spread (for example it was linked on Talk:Main Page) people who don't regularly check out VPP came to voice their views. Perhaps the 'conservative people' geometrygirl mentioned Nil Einne (talk) 07:41, 15 September 2009 (UTC)
  • How do you define "article needing help"? If every article that isn't a GA or FA "needs help," that's more than 99% of articles, there would be little difference between that and the normal Special:Random. Mr.Z-man 18:32, 14 September 2009 (UTC)
• I like the general thrust of this, but I'm not so sure that the Main Page is the right place; flash mobs of brand new editors are hard to handle, and that's what you're mostly going to get by advertising like so on the front page, in my experience. Perhaps something in the village pump header? A watchlist notice? A template, something like WP:CENT? – Luna Santin (talk) 16:50, 14 September 2009 (UTC)
  • Well how do we handle the vandals today on the todays featured article for example.. blocking all non registered users whic is very effective and only takes a minute. So i dont truly see any kind of vandalism problem here. because then the todays featured article would b emutch more in the risk zone. For me still only the pain page is where this suggested feature could be placed. as it else would die out just as fast as it was a new feature on wikipedia. it is as simple as that.--Judo112 (talk) 16:07, 15 September 2009 (UTC)
    • Beg pardon? Articles linked from the Main Page are typically not semi-protected, given the importance of free editing to Wikipedia's culture. I didn't say "vandalism problem" -- yes, there will be one, but I find the maintenance issue to be of greater concern. Flash mobs of brand new users do not, as a rule, lead to quality. Far from "dying out", watchlist notices and centralized discussion have been an amazing success since their inception (attracting numerous experienced users to, among other things, this very discussion). Certainly I can see why you'd disagree with the suggestion, but dismissing it out of hand seems unwise. – Luna Santin (talk) 19:09, 18 September 2009 (UTC)
  • {{COTWCurrentPicks}} already exists, too. ☺ Uncle G (talk) 11:06, 21 September 2009 (UTC)

break 5

• Support Much of the needed improvements come from readers too, and it is important to show new articles being made and fixed, to show that Wikipedia is changing and that anyone can help. It will bring more editors in. Also, it doesn't have to be a terrible article, just one that needs improvement, like Pleasure, or other articles from the Wikipedia:Challenges page. We could also feature pages that require translation, or just other generally easy tasks that can be done by new users. And the articles for improvement don't have to be terrible stubs, just important enough to be well known, and easy to fix by new users.

  'Random article needing help [going by Open Tasks tags)' - or a section at a time 'Random stub' (getting on for 55 000 of them), 'Random most wanted article' etc. Jackiespeel (talk) 16:39, 15 September 2009 (UTC)

• Oppose any article featured so would end up protected with in half an hour, defeating the purpose. Icewedge (talk) 05:36, 16 September 2009 (UTC)
  • Because we always need to protect Featured Articles too, right? Bsimmons666 (talk) 01:18, 17 September 2009 (UTC)
• Comment People suggesting "Random article needing help" in the sidebar are so completely missing the point I wonder if they even understand the original proposal. We're not looking for an easy way to find articles needing help (they all need help); we're looking for an easy way to encourage many editors to work on one article at the same time. —Noisalt (talk) 00:15, 17 September 2009 (UTC)
  • Then look. These things already exist. Uncle G (talk) 11:06, 21 September 2009 (UTC)
• Support - I think this is a great idea. I think it would do alot to help draw people who see the main page into helping edit instead of just viewing, and benefit the project as a whole. Nutiketaiel (talk) 16:44, 17 September 2009 (UTC)
• Support Good Idea! But maybe have it in a sepperate area of wikipedia, and have a link to that page. Or better yet, just like the random article link, we could have a random article to fix link.Accdude92 (talk) (sign) 16:53, 17 September 2009 (UTC)
  • (a) I'm fairly certain this will fail in practice; (b) We should trial it anyway, preferably having agreed a trial period and certain criteria for "success" beforehand. "Good signs" would be a rise in the number of editors joining (even if no statistically significant rise is found, I appreciate editor recruitment figures are likely to be "noisy" and suggest that we should heed anecdotal evidence of particular users joining as a consequence), or that the nominated articles tend to improve (even if this is done by semi-regular or regular editors, and we fail on recruitment, that's still a plus point). "Bad signs" would include the nominated articles getting shredded; to some extent an accepted negative of this scheme is that it in some way degrades our front page and makes us appear less reliable/professional but I can't think of a way of measuring the specific effect of this initiative on that. My suspicion lies heavily that things on the main page often attract negative editing so this initiative would be very likely to fail. But until it is trialled who can say for certain? Unlike many websites we can reverse changes easily if they don't work out; conservatism here doesn't seem to offer serious gains. TheGrappler (talk) 01:01, 18 September 2009 (UTC)
    • These proposals have already been trialled. Wikipedia:Collaboration of the week is currently marked historical. If you think that these ideas are workable, get CoTW up and running again. Anything less is simply requesting that somebody else work on the problem. Uncle G (talk) 11:06, 21 September 2009 (UTC)
• Comment Unrelated to my previous point (that we should run a trial), is the problem of what articles should be listed. This has been discussed above by several users, I'd like to give my $0.02 on a variety of options:
  • Stuff that definitely must not go anywhere near the front page: two things spring to mind for me, biographies of living people and any article likely to attract controversial nationalist/religious/political points of view.
  • Poor standard "vital articles": the pro is that almost anyone knows something about these even if they're not an expert, which might encourage editing. But actually in turn that's a problem, since most non-expert edits will end up being reverted. The reason so many vital articles are in a poor state is that it's incredibly difficult (and often requires a range of expert knowledge in multiple disciplines) to structure and balance an overview article on a very general topic. It's widely suggested that the best way to do it is to deal with all the sub-articles first, then weave these improvements into the main article. It may also require extensive planning on the talk page to get the structure right. My comparison would be to the "well-meaning" damage that many FAs suffer when listed on the main page; they get random additions of overly-specific general knowledge, usually by "drive-by" editing, that tend to distort the balance of the article. Complex vital articles on subjects such as "toy" seem likely to suffer the same fate. Vital articles seem extremely likely to backfire.
  • Esoteric articles requiring expert attention: most people who see this listed won't have any way to change it or feel drawn to it. I suppose for an expert, the "wow, actually I could do something about that" may be proportionately bigger though. Perhaps there's a risk of a non-expert adding googled tidbits of (possibly not 100% true) info, which could be a pain to verify since it would require a real expert to check! I am aware this is a recurrent problem on e.g. physics, philosophy and economics articles in general, but am unsure whether a main page campaign would make things worse.
  • Articles that require a copyedit/wikifying/other primarily formatting issues: I've heard plenty of anecdotes that this is what draws many new users into Wikipedia - the opportunity to correct a typo seems a particularly common pathway to addiction :) On the downside, if you're just starting, the wiki markup language can look scary to edit, and it's difficult to judge a good level of wikilinking. On the plus side, this is still going to be easier than adding substantive content (especially if they get nagged into dealing with WP:V and coping with all those hard-to-grasp referencing templates). And it wouldn't require extensive coordination with other Wikipedians on the talk page, which may also help new users to just get on with it without finding they are reverted five minutes later.
• We could of course try a variety of these different types, rotating every couple of hours if we found that we drew enough attention by putting an article up for 3 hours, say. But if a particular class of article (e.g. broader "vital" articles) seems to draw more trouble than it's worth, then I suggest we focus on those types that give a more positive response. TheGrappler (talk) 01:01, 18 September 2009 (UTC)
• I oppose for a few reasons: first, I agree that we should strive to keep readership separate from editorial work as often as possible. Second, we should be promoting our highest-quality work on the main page; while I'm all for encouraging participation amongst our readers, the main page should remain free of our "Featured crap". Lastly, I agree that this seems like a duplicate to DYK. A well-intentioned proposal and without doubt a reasonable suggestion, but I don't think this would work well. –Juliancolton | ^Talk 02:32, 18 September 2009 (UTC)
• Support We need more and better recruiting. People know that it's possible in some abstract sense to edit but I don't think they have a sense that they can help out on a specific thing right now. I'm kind of surprised this hasn't made it to perennial proposals yet because it's come up several times before and has always failed, but I'll throw my support behind it again... (at least on a trial basis for now) Calliopejen1 (talk) 13:50, 18 September 2009 (UTC)
• Oppose Having an article that needs editing right on the front page would cause hundreds of edits to happen to the article almost instantly. Doing this would make the article almost impossible to edit. This would cause constant edit conflicts and massive amounts of useless content. I could understand 20-30 "articles that need your help" being shown in a list on the front page but having one is ridiculous. --Yair rand (talk) 18:26, 18 September 2009 (UTC)
• Comment - I think the selection of one article would not be productive - the 'pedia is too big now, and much generalised info has been added. Also see WP:ACID which works (or doesn't) in the same vein. So I'd oppose a specific article but support a link tagged 'Articles needing help' or somesuch to a random article with a tag on it (selected from expand, refimprove stub and some other ones which do not require specific wiki-knowledge like wikify or uncategorised. Casliber (talk · contribs) 21:36, 18 September 2009 (UTC)
• Strong Support I like it. And I disagree with the "presenting our best articles" argument. We need to recruit more editors, and this is the best way to do it. Also, if I may extend the proposal, we could divide the section into sub-sections (Science, Arts, etc.) to attract more people with localized interests. ƒ(Δ)² 17:15, 19 September 2009 (UTC)
• Strong support maybe we can make some of our readers editors! Ikip (talk) 06:58, 20 September 2009 (UTC)
• Oppose enough said already, starting with "don't confuse casual reader". The message "anyone can edit" is still there and serves the purpose well. NVO (talk) 16:25, 20 September 2009 (UTC)
• Support as attracting new editors does seem like a good idea, especially when it results in article improvement. I am sure the fine points of such a proposal would have to be worked out, but a nice good faith idea that merits at least trying. As Wikipedia does not have a deadline, we do not have much to lose by at least giving it a whirl. Best, --A Nobody^{My talk} 02:19, 21 September 2009 (UTC)
• Support, inspiring people to contribute is an important part of our mission. It has been a long time since there was an 'edit' link on the Main Page; this would bring back a bit of that spirit. +sj+ 04:46, 26 September 2009 (UTC)

break 6

• If it is not practical to have a 'random article needing help' on the main sidebar, would it be possible to have something similar elsewhere: eg on the various 'Category:Wikipedia articles in need of ...' pages? If suitable tags are devised and there are 'lists of topics on xxxx (insert subject of choice)' a similar arrangement could be made in subject areas.

The long lists on category pages may discourage people from pursuing. 16:27, 21 September 2009 (UTC)

• Support. This is an absolutely great idea, give it a trial run! Someone go and be bold already. If it doesn't work out, so be it, but why waste a bunch of time trying to predict the outcome, when a simple experiment will show us right away. HiDrNick! 19:25, 21 September 2009 (UTC)

• Would add the various 'Collaborations by topic' lists and similar listings. Possibly having a 'Select random article needing help in this category' box link or subheading at the bottom of the page might be more appropriate - 'the point being' to encourage people to deal more actively with the pages needing most help. If suitably devised (on list pages etc) might be appropriate to retain even if there is only a trickle through response. Jackiespeel (talk) 10:37, 23 September 2009 (UTC)

• Oppose - there are already more than enough collaborations that everyone already ignores. Adding yet another one would be rather counter productive. Putting it on the main page, would just be silly. --T-rex 02:41, 25 September 2009 (UTC)

• Support - right now we need more casual readers to become editors, and I think this is an excellent, prominent and enticing way to do just that. JoeSmack ^Talk 05:40, 28 September 2009 (UTC)
• Support – if we make sure to put out articles that are important but currently poor, this could be a very positive thing indeed. As an aside, I think that the idea that we should shy away from confronting readers about Wikipedia's collaborative, all-in model is toxic. We shouldn't be standoffish; rather, we should be trying to recruit and engender the involvement of every reader. —Anonymous Dissident^Talk 14:49, 30 September 2009 (UTC)
• Support Good idea! Wikipedia keeps getting hammered in the press for being incomplete/inaccurate/libelous and people sometimes forget that editing the 'pedia is a community thing. Anything that embiggens the community is a good thing. One caveat: it should never be a BLP in the "article to improve," because that's a tough thing for new people to understand and is just asking for a lawsuit.--24.131.95.3 (talk) 17:26, 5 October 2009 (UTC)
• Strong Support - a combined collaboration effort is an awesome idea, and putting it on the main page will allow it to actually get off the ground faster than old whole-Wikipedia collaboration efforts have.--Unionhawk ^{Talk E-mail Review} 18:26, 5 October 2009 (UTC)
• 'Strong Support* - This is an awesome idea! i agree with others who have stated that there are loads of poor quality articles and this would help a great deal! Also, i think that more wiki users will be encouraged to write if all they had to do was log on and find something they are interested in to improve!  :) —Preceding unsigned comment added by Malone94 (talk • contribs) 08:40, 9 October 2009
• Strong Support More editors is good. mkehrt (talk) 09:09, 9 October 2009 (UTC)
• Support with Qualifications: I think this is a promising idea, and it might have the reverse positive effect of luring editors every now and then to look at the same main page that readers see, rather than Watchlist (where I start), New Articles, etc. I think that (despite the PR implications) the best way of choosing an article for improvement would be to pick one that's closely-related to that day's Featured Article. For hypothetical instance (and in complete ignorance of the actual articles), suppose that Florence Nightingale (the nursing pioneer from the Crimean War) were the Featured Article and Clara Barton (the American Red Cross founder who started in the American Civil War) were a worthy article that needed all kinds of help. (Or assume the reverse hypothesis.) Then readers who were fascinated by the Featured heroine (or who already knew something about nursing and public health) might be inspired to see what they could contribute to the other's article. The one big caveat I would want to add is that there should be fair warning on the improvable article's Talk Page, and if the identities of two or three principal previous editors were clear, they should also get personal notifications. Nothing would be more demoralizing after painstakingly doing such cleanup as one could to a stubby, poorly-written or biassed article than to have a host of strangers suddenly descend on it en masse with the very best of intentions but little knowledge of its past history. As for the PR implications (or Putting One's Best Foot Forward), I think this might be an honest and straightforward way of showing how the best features of Wikipedia are built from the ground up, indulging in neither boasting nor self-reproach. —— Shakescene (talk) 09:37, 9 October 2009 (UTC)
• Qualified support. I think this is a good idea in principle, but the objection that it could cause loads of people to fall over themselves editing it (editconflictitis) is a valid one. So it would need to be done in a well-thought-out way to avoid that. For instance, there might be a daily pool of Articles To Be Improved, which are rotated rapidly enough to spread out the edits across articles. (There may be technical issues with that, like breaking caching; depends on what we can come up with on implementation.) PS Objections that it would duplicate existing collaboration efforts seem off the mark - very different audience. Rd232 ^talk 09:42, 9 October 2009 (UTC)
• Support I love this ides —Preceding unsigned comment added by Tim1357 (talk • contribs) 19:53, 10 October 2009
• Comment - This sounds like a good idea, however there are some things to consider. Though Wikipedia's regular participants are aware of its goals and inner-working, the average shmo has no clue. As unbelievable as it might seem, most people are under the impression that Wikipedia is a finished product. Even many frequent readers are still unaware that they have the ability to edit the encyclopedia. This is part of the reason we get a lot of flak in the media about our article quality. Wikipedia is a widely misunderstood animal, and no matter what we do, it seems it always will be (we even tried making the slogan "The encyclopedia anyone can edit", and even that didn't really work). The decision to make the main page an accommodation purely to readers as opposed to editors is a way of dealing with this public perception. We try to put on our best face to the public, so that they won't criticize us as much for being unreliable and amateurish; and consequently, this is the reason there will be resistance to changing the main page according to the proposal. "We" (those concerned with Wikipedia's public image) don't necessarily want everyone to see immediately "behind the curtain", because most will undoubtedly not understand, as has proved to be the case in the past. The prerequisite for this proposal is a much larger change. It would be putting on a different face to the public. The pros and cons of that would have to be weighed carefully before this should be implemented. Equazcion (talk) 20:25, 10 October 2009 (UTC)

break 7

• Oppose - For several reasons: 1) the main page should highlight our best work; 2) The article would either have to be chosen at random or go through some sort of selection process. If the former, we could end up promoting non-notable and/or obscure topics. If the later, the article could just be improved rather than wasting effort deciding which article should be improved; 3) If successful, it would lots of people trying to "improve" the same article over and over again when the effort would be best spread out among several lacking articles. It could also potentially lead to edit conflicts, edit wars, and other unpleasantness that could turn off newbies; 4) The page would most likely have to be semi-protected which would rather defeat the point of trying to convert readers into editors: "Please help us edit this article... except you can't because we had to semi-protect it because of persistent vandalism." --ThaddeusB (talk) 20:38, 10 October 2009 (UTC)

• Very well-said, and I agree entirely. –Juliancolton | ^Talk 00:54, 12 October 2009 (UTC)

• I think most of the potential problems you have just brought up will not be real issues if a different article is attributed to each page request (or that the page requests be split up for different articles). Alternatively, we could have a robot that would work as follows: Put article X1 on the main page until some number of different editors have made an edit (say, for the sake of argument 10) at which point a new article X2 is put on the main page until X2 has received edits from 10 different editors, etc. GeometryGirl (talk) 14:38, 12 October 2009 (UTC)

• I like that bot idea, good thinking. As for Thaddeus's other points, whether or not we should purely be showcasing our best work is one of the questions under discussion. Just saying we should continue to do that doesn't really address the issue. People have provided some decent reasons to perhaps shift from that tradition. The process doesn't need to be much of a process, if the articles will only be staying on the main page temporarily. The bot could choose articles based on maintenance categories, like copyediting required or stub, or there could be a list that autoconfirmed users could just edit at will. Equazcion (talk) 05:22, 14 October 2009 (UTC)

• “the main page should highlight our best work;” — fundamentally disagree with this, the main page should highlight what we do. We improve articles. Alex Muller 09:45, 15 October 2009 (UTC)

• Question Would this be a featured article that remains on the Main Page all day, or a random one that is different for each page request. If it were on the Main Page all day, then it should not be Random, rather it should be selected much in the way a Featured article is selected.Tim1357 (talk) 20:48, 10 October 2009 (UTC)

• Oppose The main page is a "reader-facing" page. It's primary purpose is to put a smiling face on the Encyclopedia for outsiders. Adding a feature for solely editors and not readers breaks this metaphor for no strong purpose. It is important to remember that while the distinction between "Reader" and "Editor" is not crystal clear, there is undeniably a distinction. The vast majority of the people who read encyclopedia do not edit it and are not interested in editing it, and that's a good thing. That's who the encyclopedia is for. APL (talk) 22:23, 14 October 2009 (UTC)
  • But the whole point of Wikipedia is that it's the encyclopedia anyone can [and does] edit. Readers are just editors who haven't got their feet wet yet - and we always need more! And does adding a small Article For Improvement to the front page really take away the Smiling Face? Most substantively of all, we should be reminding readers of the editable nature of Wikipedia, and this would help. Rd232 ^talk 09:58, 15 October 2009 (UTC)

• Support The main page should reflect the whole project, and should freely admit that it is an incomplete resource. It would give new editors a place to start. --Pretzels^Talk! 14:11, 22 October 2009 (UTC)
• Oppose per ThaddeusB. Also, my experience with DYK indicates that even getting 10,000 views in one day does almost nothing to attract contributions or new editors, and i doubt this would either.YobMod 12:37, 29 October 2009 (UTC)

Subproposals

• Taking on board the discussion above, I suggest the following as an alternative. For a trial of just one hour, have a random article from a suitable class of articles displayed for 1 minute each on the front page, as an Article Needing Improvement. Evaluate the impact, and go from there. The difficulty is identifying a suitable class of articles, but old unwikified ones might be OK. What's the worst that can happen? If that turns out OK, develop a longer trial, for maybe a day. Suck it and see, I say. Rd232 ^talk 09:51, 14 October 2009 (UTC)

• Agree GeometryGirl (talk) 13:06, 14 October 2009 (UTC)
• Agree - Good idea. Equazcion (talk) 23:00, 14 October 2009 (UTC)

• Question How do trials work on WP? What if it goes up for its trial, but then there is no consensus to remove it? Suddenly a feature for which there was no strong consensus has been added and can't easily be removed. APL (talk) 22:23, 14 October 2009 (UTC)
  • Being a trial, it would presumably be removed at the predetermined end of the trial. The fact that it's a trial implicitly includes consensus to remove it at the trial's conclusion, I would think. --Cybercobra (talk) 23:13, 14 October 2009 (UTC)
    • Precisely. It's a defined-length trial, with reversion to the status quo ante afterwards, while the trial is assessed. Rd232 ^talk 10:00, 15 October 2009 (UTC)
• Oppose I oppose this for the same reason I oppose the above. I don't doubt that it might have some sort of interesting impact, I simply believe that it will reduce the overall impact of the mainpage to outsiders. A trial won't help that one way or the other. APL (talk) 22:23, 14 October 2009 (UTC)
  • It's just a trial though. Why not give it a shot and see what people think from there? Equazcion (talk) 23:05, 14 October 2009 (UTC)

• Support The objective of trying to encourage participation in editing is an excellent one and the main page is a good place to do this. But there needs to be a good structure for this to prevent the highlighted article from being swamped by too many well-meaning newcomers. The idea of just exposing each candidate article for a brief time is a good one. Another possibility is a Master class - a demonstration in which one or more expert editors work upon a selected article as a living example of our methods. As well as demonstrating important editing techniques like citations, images, categories and so forth, a team of masters could also demonstrate our methods of collaboration such as the use of edit summaries, the talk page, good article review and so on. There might be a sidebar in which a commentator explains what is being done, as it happens. Such demonstrations might be organised as special occasions or, if there are enough volunteers, they might run continuously. Colonel Warden (talk) 23:32, 19 October 2009 (UTC)

• The whole thing sounds like adding a new line to Wikipedia:Community portal/Opentask with suggestions taken from a mix of Wikipedia:Article Collaboration and Improvement Drive and Wikipedia:WikiProject Vital Articles (B-class?). Make the code and test it there, perhaps. -- Quiddity (talk) 07:55, twentythird October 2009 (UTC)
• Support'. I oppose the general idea, but would be convinced by proof. The only way to find out is to try. However, i would suggest making it 24 hours, with hour long stingt on the front page. 1 minute is very short!YobMod 12:38, 29 October 2009 (UTC)

Problems

I may have missed it in this long thread, but I see a few problems with some of the later proposals. To be shown on the main page, people would have to write a blurb (like for DYK or FA), other people have to agree with the blurb, and then it gets on the main page (no matter if this is done randomly from a pool of approved blurbs, or with a fixed format like DYK). The time needed to do all this could better be used in actually improving the article (above, the example of unwikified articles was given: just wikifying them doesn't take longer than the process described). Remember also that when you have a pool of articles to choose from, you need a de-pool process as well, to remove sufficiently improved articles.

Any other system, like somehow transcluding the first paragraph of the article on the main page, does not protect the main page from vandalism. And if you portect the page, it can no longer be edited, invalidating the purpose of the exercise. Fram (talk) 09:56, 15 October 2009 (UTC)

Fair points, but there may be solutions. The Article may be listed without a blurb - just the pagename, under an appropriate generic heading + "what is this/what do/how to do it" intro. And if we base selection on standard maintenance categories, then removing tags after improvement will depool candidates. Rd232 ^talk 12:30, 15 October 2009 (UTC)

Main page Article Editing - reboot

A lengthy discussion above produced diverging views on the idea of having an "Article to be Edited" on the Main Page. Without wishing to rehash the entire lengthy thing, the discussion produced some points permitting some further development of this idea which may produce something worth trialling.

Advantages of figuring out a way to make this work: a) get more people on board as editors, via a route not determined by their conflict-of-interest desire to create an article about themselves or their company; b) more clearly communicate to readers exactly how Wikipedia works. Yes, some people are still a bit vague on what "the free encyclopedia anyone can edit" really means. ("Surely not just anyone?" Well, yes.)

Drawing on the above, then, I propose a short, definitely temporary trial of the idea, of the following form:

1. A trial of just 1 (one) hour, with no further action unless the results indicate further, longer trials are a good idea
2. Add a new section "Some articles in need of editing" (or similar)
3. In that section, provide a short intro on what the section is for, and links to appropriate help pages (depending on what help we expect the articles to need)
4. List perhaps 5 articles, just the pagename, no blurb.
5. List each set of 5 articles for just 1 minute, to keep exposure manageable
6. Choose articles at random (possibly favouring older tags) from standard maintenance categories, eg Category:Wikipedia articles needing copy edit
7. Articles will automatically be removed from rotation when the appropriate maintenance tags are removed by editors seeing sufficient improvement.
8. Articles listed on main page in this way be logged on a list (or possibly in a dated maintenance category) to allow established editors to review results after 24-48 hours of being listed.

Crucially, in this version the main additional workload is in setting up, rather than continuous: it's choosing which maintenance categories to work, and what standard (per maintenance task, not per page) intros to create for them, and creating appropriate bots to choose/rotate articles, etc. Well, I'm ignoring the additional workload involved in cleaning up after vandalism, and checking edits, because it's mostly not a new process - it's covered by Recent Changes, with an additional mechanism (list/category) to ensure Recent Changes Patrol doesn't miss things on these (briefly) high-traffic pages. Comments? Rd232 ^talk 16:50, 22 October 2009 (UTC)

For it to get on the main page at all, it would require a substantial amount of work to fit it in somewhere and make sure that the main page design still looks good on common browser/screen resolution configurations. For a short trial, you would have to do all of the setup work except some of the setup for a formal process to add the pages (so probably about 75+% of the work). I don't think the amount of benefit from a 1 hour trial really justifies the amount of work required to set it up. Additionally, the section appearing and disappearing from the main page while we do multiple trials and, if successful, create a formal process, could be confusing and annoying to readers. Mr.Z-man 17:51, 22 October 2009 (UTC)

I take your point about the work, but it may be worth the risk - and if we get people with some know-how, it may not be that much work (enough to justify doing it, anyway, because of the potential benefit if the trial works well and ultimately leads to implementation). As for the design, that needn't be any work at all - just nick the "Today's featured picture" format and duplicate that. Good enough for a trial, at least. And is changing a web page a little bit really going to start annoying end users? That's a stretch. And for the trial it won't affect that many. Rd232 ^talk 20:50, 22 October 2009 (UTC)

How many articles do you plan to put at once if you want to have a full-width section? The featured picture takes up more space than the featured article. It may not annoy them, but a new section appearing and disappearing, possibly multiple times, could certainly be confusing. The main page typically gets 5-7 million views per day, so a 1 hour trial would be seen by ~200000-290000 people. Mr.Z-man 02:18, 23 October 2009 (UTC)

Well I find it hard to put much weight on that, because websites change all the time, and we're only talking about a single trial, and maybe 1 or 2 more, longer trials after there before it might become permanent. Websites change all the time, and this is not a dramatic change. As for the "full width" point - I said 5 articles above, and I expected to take up the rest of the width with explanation of the section and help /summary links for editing. If it's really too much space, maybe split into two columns, one for each of two types of maintenance category. Rd232 ^talk 02:26, 23 October 2009 (UTC)

Facebook has just changed its homepage layout for the 5th time, affecting all of its 250 million users. Top ten websites change their appearance on a monthly basis. Our main page has not chnaged significantly since March 2006, getting on for four years. Wikipedia needs to be much more willing to experiment with new layouts. Like RfA, many people agree that the main page is in need of an overhaul, but no one can agree on a complete new system. The natural way to break that deadlock is to try small changes and see what works and what doesn't. If Rd232 is prepared to put in the work to prepare such a feature, it is entirely disingenuous to use the effort involved as an argument against it. Happy‑melon 11:21, 25 October 2009 (UTC)

Facebook probably isn't the best example, as several of their interface changes have made the news for being heavily disliked. I'm more concerned that Rd232 does not know what the design work involved is and is currently proposing to just sort of "half ass" it - "just nick the "Today's featured picture" format and duplicate that. Good enough for a trial" - I'm concerned that most of the proposal here is focusing on the easy things, particularly the new list just added below. The 2 most important things - the design of the section as seen by readers and the examination of the results - are being given almost no consideration. Mr.Z-man 17:55, 25 October 2009 (UTC)

The picture section is a set of three nested HTML tables. Duplicating that set should not have knock-on effects on the rest of the page. Nor should splitting one of those tables into two columns (or adding another nested table into the currently innermost) cause issues. No big deal, I'd say. As for the post-mortem: I've specified the creation of a list of affected articles to enable it, but beyond that, I don't see why I should do all the legwork working that out when dozens of people commented in the earlier discussion. Personally, I don't think this needs to be specified in advance; eyeballing would be sufficient for a general impression on effects. Detailed analysis (requiring automation) I'd think would be required for a later, longer trial, as there the volume of data would be too great. Rd232 ^talk 18:11, 25 October 2009 (UTC)

Wikipedians tend to have a rather short attention span. For every 10 people who comment on a proposal discussion, maybe 1 will actually follow through past the initial proposal. Another issue is that trials on Wikipedia have a tendency to become permanent, so people may be wary of a proposed trial without a detailed plan. Mr.Z-man 18:19, 25 October 2009 (UTC)

Yes, well... on the latter part, I can't see how what's proposed here has any risk of becoming (unintentionally) permanent. The "trial becoming permanent" issue is more for software things being turned on, and it not being clear enough under what circumstances/time frame it would be turned off again. Rd232 ^talk 10:19, 26 October 2009 (UTC)

Well it isn't really that much work.

• Blurb for the section (describing Articles for Improvement)
• Choice of maintenance categories
• Blurb for each of two maintenance categories (what/how/help links)
• A bot to do 60-second updates to that section, taking 5 articles at random per section (excluding previous selections), and to note on a subpage the articles it lists.
• Somebody to take responsibility to create the section, run the bot for an hour, and then delete the section.
• Post-mortem.

It should be easy to do such a bot (for an experienced bot writer - which I'm not!), and I'm sure we can manage the others too. The issue which actually bothers me, which hasn't be discussed AFAIK so maybe it isn't an issue, is how such frequent updates would interact with caching. Rd232 ^talk 12:41, 25 October 2009 (UTC)

I agree with Happy Melon about the need to have a easier process for making changes to the main page. And rd232's idea of doing a 1 hour trial seems like it might be worth a try. I would like to know however what would happen after the experiment is over. Should the criteria for success be decided on beforehand? Should there be a control group of pages that weren't listed to allow for comparison? There isn't much point in running the test if it's only going to result in more indecision when in comes time to figure out what to do about it when it's over.--RDBury (talk) 16:32, 29 October 2009 (UTC)

I haven't been involved, but some people have a lot of experience with having Featured Articles on the main page unprotected. There must have been some efforts to evaluate the effects of that. Perhaps we should cross-post on the Main Page talkpage. Rd232 ^talk 17:21, 29 October 2009 (UTC)

Arbitration committee structure for 2010

I have initiated an RFC on the Arbitration Committee size and terms for 2010. If we are to have a clear number of seats determined before the the upcoming election begins, vote now! ;-) But also add views at the bottom and come back after a week or two and review your decision after considering what others have to say. --John Vandenberg ^(chat) 09:20, 29 October 2009 (UTC)

attracting of translators

As my own experience shows I often go to read an english version of an article if it doesn't exist in my native language. I could translate and create an article in my native language but I can't be bothered doing it right now which means it won't be done ever. The more so because "this article is unnecessary for anyone since nobody create it so far" as I think then. I think I'm not only a person in such a situation. So I would suppose to make some technical enchancement to the wiki engine to help attracting translators. It could be done as follows.

If the engine has determined from the HTTP headers that a current visitor can speak another language besides a language of current article AND an article in that another language doesn't exist AND such an article is higly demanded (what you could also determine I think) then the engine would display some kind of earnest request to create a version of the article in his/her native language by saying that "NNN hundred million people would greatly appreciate your effort if you would..." ;-) --AlexPavlenko (talk) 13:45, 30 October 2009 (UTC)

That´s a very good idea which I support. - ☩Damërung ☩. -- 13:42, 1 November 2009 (UTC)

It could easily be annoying though. But using the header information is clever, it could maybe be used to trigger a one-time user-talk post encouraging translation. Rd232 ^talk 16:14, 1 November 2009 (UTC)

Provide interface link to talk page for IP editors

• Spawned from this discussion.

As constantly logged-in users fighting vandals and such, it could be easy to forget that IP editors don't have easy access to their talk pages. I myself just found this out recently. Anonymous editors see the new message notification when receiving a new message or warning, but that's the only time they are actually linked to the page (as is my understanding). Otherwise, they would need to find out their IP address and manually type it along with our user talk syntax, which new editors probably won't have a clue about.

If we expect IP editors to heed our warnings, keep aware of what they've been warned about in the past, and even form dialogs with us, shouldn't they have easy access to their talk pages? I propose a talk page link for anonymous editors somewhere in the top-right corner, just like registered users have in their interface. Equazcion (talk) 20:13, 30 Oct 2009 (UTC)

I have just written a fairly long comment on this in the discussion linked above. Obviously you are welcome to read my full post there, but the points from it most relevant here are as follows.

1. Yes, Equazcion certainly has a good point: there is a problem.
2. We should remember that the non-logged-in user interface exists primarily for the majority of Wikipedia editors, who read it and do not edit it, and it might well confuse them to be given a tag labelled "discussion", only to find that it led to a page full of messages they did not understand, quite possibly threatening them with being "blocked" if they continued to do things they had no knowledge of. I am therefore not sure that the change would not do more harm than good. My personal opinion is that the best way to deal with this problem would be to ban all editing by non-registered users, but I know that consensus is against this; granted that this will therefore not happen, I am not sure that the suggestion would on balance be better than the present (admittedly very imperfect) situation. JamesBWatson (talk) 20:39, 30 October 2009 (UTC)

This is a mistaken assumption. IPs have at least three quick and obvious ways to access their talk pages. It's not a problem. If I make a contribution in mainspace I can click on the (talk) beside my IP in the contribution history. If I post in non-name space and sign my post I can click on my IP and beside it, in the upper left, is a link to my talk page. If I post in non-name space and use four tildas to sign my name a link to my talk will be beside the listing of my IP as in this message.

IPs have easy access to their talk pages. It's functionality built into the user interface for IP users. It used to be harder, years ago, but it's been changed to deal with this early on. It's already there. It might be easier with the talk page link in the upper right, but just making sure people know it's not hard. --69.226.106.109 (talk) 00:55, 31 October 2009 (UTC)

Thanks for the info. I guess it's not all that hard, at least if you know where to look, or are used to making talk comments. Even in that case though I think a static interface link is valuable. But especially in terms of newbie editors, who might not know to look at page histories, and who might not have ever even made a talk comment that would've gotten signed, the interface link would help them significantly, I think. Equazcion (talk) 03:05, 31 Oct 2009 (UTC)

Here are the main ways IPs can currently get to their talk:

1. The link in the "You are not currently logged in" message, seen on every edit page
2. Typing Special:MyTalk in search box or address bar
3. Their signature (need not save the page)
4. History pages if they just edited
5. Someone else edits their talk

There's a problem, I think, with giving anons a more direct link to their talk page, which is that they would have no idea what to do with it. I think it would be misused. I've seen newbie registered editors post help queries to their own talk pages as if it's a 24-hour portal for communication with unseen watchers. If you know nothing about Wikipedia the purpose of "My talk" isn't intuitively obvious. Most vandalism there would not get patrolled either. Also remember that the vastly overwhelming majority of anons on Wikipedia are not editors! They merely browse the encyclopedia, and for them, talk pages are useless. • Anakin ^(talk) 13:49, 31 October 2009 (UTC)

• Support - this is done on many, many other wikis, and I don't know why this isn't done for Wikipedia.--Unionhawk ^{Talk E-mail Review} 13:51, 31 October 2009 (UTC)

  In a word: caching. Wikipedia pages are heavily cached, so the exact same page can be served to numerous annonymous readers. Except that it can't, if it has user-specific data like IP addresses on. This is why anons only see their page links on things like the edit screen and special pages: these have to be dynamically generated for each view anyway, so they can be added there without extra performance load. Happy‑melon 14:08, 31 October 2009 (UTC)

  Oh, so basically you're saying that if Wikipedia did this, servers would probably go boom? Or at least fail more often then normally?--Unionhawk ^{Talk E-mail Review} 14:15, 31 October 2009 (UTC)

  Special:MyTalk works for everybody without serving them different pages before they click the link. PrimeHunter (talk) 14:26, 31 October 2009 (UTC)

  Yeah, I thought of that shortly after posting that. What about just a link to Special:MyTalk added next to the Login link?--Unionhawk ^{Talk E-mail Review} 15:43, 31 October 2009 (UTC)

  Yes, I'm not saying that it's by any means impossible, just explaining why the method that is already built into MediaWiki is not used here at WMF. Happy‑melon 18:48, 31 October 2009 (UTC)

First, I don't think ease of access is the issue. Anon users do have easy access but that does no good if a) they don't know that have access and b) they don't know what they would be accessing and why. But though the mechanism of leaving a warning on the talk page is imperfect, I don't think it can practically be be improved upon. All we can do is encourage the anons to create accounts (which we already do at every turn) and hope they take the hint when they start seeing confusing messages pop up.--RDBury (talk) 18:47, 31 October 2009 (UTC)

I think providing an interface link would be an improvement. Perhaps also an interface message shown while viewing their talk page, that says "to return to this page in the future, click the blah blah link in the upper-right", etc. Equazcion (talk) 18:57, 31 Oct 2009 (UTC)

Would it be practical to use JavaScript to add the links on the client end? That would get around the problem of caching, and I don't think there's a significant issue with compatibility (and if there was, we could engineer in graceful failure). {{Nihiltres|talk|edits}} 19:37, 31 October 2009 (UTC)

Even if it were practical (which I doubt), how would that be better than Special:MyTalk? Rd232 ^talk 20:45, 31 October 2009 (UTC)

I'm trying to keep an open mind here. The key difference is visibility. Most people don't know that Special:MyTalk et al. exist, and that's the main impetus for this feature proposal! I recently used it to find the Internet-facing IP of my girlfriend's wireless network, and neither she nor her roommate were aware that it was there. There's a demonstrable use for the feature: make people aware of the shortcut. It's as simple as including two addPortletLink() calls in some of the skin. We can simply link to the MyPage, MyTalk pages and anything else we want, and as far as I'm aware that should work in just about any browser. Are there any problems with that that aren't immediately obvious (e.g. that. JavaScript must be available)? {{Nihiltres|talk|edits}} 23:25, 31 October 2009 (UTC)

I don't think IPs have user pages, just talk pages. I'm not really clear on your point, Nihiltres. My understanding is that Special:Mytalk is simplest, and the visible link text would be the same either way -- "My Talk" or "My Discussion Page". How would visibility differ by using javascript? Equazcion (talk) 00:10, 1 Nov 2009 (UTC)

Oh, I see. You mean that we would use MyTalk and perhaps MyContribs etc. at the MediaWiki level. That sounds reasonable too, though I was under the impression that that path was considered undesirable for various reasons—meaning that using JavaScript to generate the links would be better than not having them at all. IPs don't have user pages by custom, but they can, technically have userpages—for example, see Special:Prefixindex/User:24. Sometimes it's used for sockpuppet notices, et cetera. {{Nihiltres|talk|edits}} 05:20, 1 November 2009 (UTC)

• Support as the one who brought up the issue. I have no opinion about the technical issues but my main point is that new users do not even know that there is such a thing as a talk page. If no link is provided at some prominent place one cannot expect them to browse through page histories or to use functions like Special:MyTalk. --Pgallert (talk) 08:53, 2 November 2009 (UTC)
• oppose. Per above comments (Anakin and JamesBWatson) about confusing the hell out of the average reader and drive-by editor. It might be useful to long-term IP editors, but they're a much smaller constituency and even for them I'm not sure how great the benefit would be. Rd232 ^talk 09:18, 2 November 2009 (UTC)
• Have to agree with both arguments - if an IP has a talk page then s/he has to have a link there (truer for IPs even than named editors, since the latter are more likely to know about talk pages and how to get there), BUT we don't want to start displaying a meaningless red link to everyone around the world who reads Wikipedia. There ought to be a link displayed IFF the talk page exists. I'm sure that's not difficult to program, but I don't know how it would affect caching and performance. (Well if an IP gets the "You have new messages" banner, the software must already check every user's IP address against something, so I guess it shouldn't make much difference if it were checked against a list of IP addresses that have talk pages.)--Kotniski (talk) 09:29, 2 November 2009 (UTC)

'Delayed' speedy deletions

This is a proposal to make optionally speedy deletion templates for certain criteria more user-friendly, for those articles that don't obviously meet the criteria or could be improved to no longer meet them. Please see and comment on the proposal here. Cenarium (talk) 18:03, 2 November 2009 (UTC)

Backlog formatting

Hi! There is a discussion at Category talk:Wikipedia backlog#I find the tracking information useful on how Category:Wikipedia backlog should be formatted. The original version was [3], and proposals are [4] and [5]. All additional input at that talk page would be much appreciated. Thanks! –Drilnoth (T • C • L) 22:35, 2 November 2009 (UTC)

Talk page Comments subpage

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

This discussion has now tailed off, so I have moved it to Wikipedia talk:Discontinuation of comments subpages where the phasing out of these pages will be discussed further. Please continue over there ... — Martin (MSGJ · talk) 17:34, 7 November 2009 (UTC)

---

Many talk page Wikiproject templates have, when an article is unassessed, a pointer to a /comments subpage. E.g; WPBiography, WP Disney, ... The trouble is that this subpage is hardly used, so comments there will usually be completely ignored (it is not created by the tagger, so it will be on no one's watchlist). Once the page is assessed, the link to the /Comments subpage is no longer available, making this an abandoned orphan. For the vast majority of pages, this subpage is unneeded, since the actual talkpage of the article is very rarely used. Therefor, I propose that all Wikiproject templates no longer point to the /comments subpage but direct discussion of the assessment to the article talk page proper, where the comments will actually be seen (e.g. by the person that tagged the article for the wikiproject). I only noticed their existence by going through all recently created talk pages and finding Talk:Roc Raida/Comments, linked through the banner at Talk:Roc Raida. The chances of anyone noticing such comments are very small, and once the article is assessed, there are no more links to it.

As this is a change that will affect some of our most used templates, like WPBiography, some discussion is needed before implementation of this. A list of all templates that produce such /comments links would be useful as well of course... Fram (talk) 09:58, 13 October 2009 (UTC)

And if people wonder "what is the problem with those pages", apart from the things explained above: take a look at talk pages like Talk:Parboiled rice. Nothing strange, but when you use the "show" button in the Wikiproject banner, you get a text that doesn't really belong anywhere, but gives the appearance of coming from the project team. On Talk:Judy Feder or Talk:Randhir Kapoor, you can access the subpage through two different links in two banners, but it is a comment that should have been placed directly on the talk page, not on a subpage. Fram (talk) 11:45, 13 October 2009 (UTC)

Support deprecation, I'd suggest subst'ing the comments subpage to the talk page and then deleting it. –xeno^talk 12:26, 14 October 2009 (UTC)

I've never come across these, and from what you say, it's not really an idea that's working, or obviously necessary. An alternative to deleting these subpages would be turning them into a more permanent record (i.e. always linked, for re-assessments) but I'm not convinced that's really necessary either. Rd232 ^talk 13:16, 14 October 2009 (UTC)

Stop encouraging the creation of new ones, and then start working through the existing ones. Many may have valid comments, but some are utter nonsense - for example, back in April, I stumbled across one that was close to 500KB (that's not a typo, the exact size was 489,208 bytes) and appeared to be nothing but a copy-pasted government report or legal document or something. It had been created in January 2008 and hadn't been touched until I tagged it to be speedied. I have a feeling there are actually a lot more of these comment subpages that aren't much better. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:26, 14 October 2009 (UTC)

Support as well. Burying these comments on a subpage reduces their effectiveness. An important step in avoiding more of these being created might be to have the function removed from Template:WPBannerMeta which many wikiprojects use. Once that is done, I am sure a bot could detect the presense of the subpages, and subst them as User:Xeno suggested above. Jim Miller ^{See me | Touch me} 21:32, 14 October 2009 (UTC)

• Support. Long overdue. I've had to try and get attention on those comments subpages before, and it's mostly futile. The regular article talk page should be used instead. There's no reason not to. Equazcion (talk) 21:38, 14 October 2009 (UTC)
• Support this proposal as well. These things are half baked and poorly implemented, and it's time to get rid. Talk pages are for comments, so a /Comments subpage is highly redundant. No doubt many of them do have valid comments, but in my experience a lot of them are 2-3 years old and bear little or no relation to the article in it's current state. No reason for them to be transcluded in project banners either, because the comments are seldom specific to any one project. If any projects are interested in keeping comments in their banners, then a better way of doing things needs to be found. PC78 (talk) 11:24, 15 October 2009 (UTC)

Allright, I'll start and remove the link (encouraging to create them) from all talk page (Wikiproject) headers, I'll obviously not delete any subpages themselves. A bot to subst them on the main talkpages would be great though, as among the clutter there are bound to be noteworthy comments (e.g. one I found that pointed out a hoax article). Fram (talk) 12:41, 16 October 2009 (UTC)

Do I read correctly that you are taking substantial action on an issue after only 3 days of discussion on the Village Pump page? Has this been discussed elsewhere? What notifications have been made?

The initial examples are all WP:Biography - why not fix the problem locally? Other projects may (and do) value the /Comments page as a mechanism to provide long term comments on article assessments. Geometry guy 22:32, 16 October 2009 (UTC)

Wrong. The above examples are not all WP:BIOGRAPHY, and this isn't a local problem. If you actually look at Talk:Judy Feder you'll see that the comments subpage is being transcluded by two banners, and the comments aren't relevant to either project. PC78 (talk) 15:00, 17 October 2009 (UTC)

I agree it needs further discussion, but Wikiprojects should comply with community decisions. Cenarium (talk) 16:09, 17 October 2009 (UTC)

• Comment. I agree with the need to rethink the /Comments pages, because all to often they do present a false appearance of some kind of "official" assessment and editors often do not know what they are about. However, they obviously do serve at least some useful purpose: at the minimum, they often endorse a particular WikiProject banner (such as with WP:M banners) in a transparent fashion. However, /Comments pages must be better patrolled, and there should be a clear set of guidelines on their purpose. As I write this, there is an edit notice above consisting of a big orange exclamation point above next to some explanation about suggesting new proposals. Perhaps something similar could be done on /Comments pages? Also, the general banner text of "Please add to or update the comments to suggest improvements to the article" clearly does not elucidate the purpose of the field. "Please add WikiProject X comments" might be better. Le Docteur (talk) 01:36, 17 October 2009 (UTC)

The biggest problem with putting any information on these pages is that the subpage doesn't show up on anyone's watchlist except the person leaving the comments. Article creators won't know that the page has been assessed, or that any comment has been left at all. At least by keeping the information on the talk page, editors have a chance of it being brought to their attention. And do we really need to encourage the creation of more unwatched pages? I believe that the potential damage to the project exceeds any benefit that keeping these pages may have. Jim Miller ^{See me | Touch me} 15:20, 17 October 2009 (UTC)

• Support. I've thought about raising this myself and tried to find places /Comments was actually used. The ones I found just had a single short comment that could have been moved to the talk page. Perhaps these have value for certain articles but for the vast majority they just confuse people and add unnecessary pages. If they really are needed for some pages, then alternate templates can easily be created (or keep the existing ones as alternates and make the new ones the default). The descriptions given to the /Comments page all sound exactly the same as the description of the Talk page and I don't see why there are two pages for the same thing. If Geometry Guy has an example of where they are used differently then he should provide a link to show us. I have no problem with the project banners themselves, they serve important categorization functions, but the comment link should go away.--RDBury (talk) 14:50, 17 October 2009 (UTC)

• Comment Depreciation seems like a useful first step. Also, some banners currently support comments but don't actually use them. (See User:WOSlinker/comments for a list of the comments categories and their page counts.) -- WOSlinker (talk) 15:23, 17 October 2009 (UTC)

• Support depreciation and merging of relevant content in talk page then redirection of existing ones, or deletion if possible. Additionally to the above, this is extraordinarily confusing to new users, a usability disaster. New users see this and go commenting, on about anything, regardless of whether it's for such strange things as 'wikiproject assessment'. And so many genuine talk page comments get lost there... Detailed assessments are actually useful, and this is a further reason to put them on the article talk page, plainly visible, so that anyone can see them and try to help. There is a little more than 25200 such pages, see them here. Cenarium (talk) 16:10, 17 October 2009 (UTC)
• I definitely support the deprecation of this godawful feature. I propose the following first steps:
  • Removal of the 'forced comments' functionality (the |COMMENT_FORCE= parameter in WPBannerMeta). This means that, when no comments are present, the banner will not display a redlinked message asking for them
  • Deletion of the 470 empty comments subpages.
  • Deletion of the 2544 comment subpages which are not transcluded onto any pages
  • Deletion of the 2859 comment subpages which have not been edited since January 2007. I chose that slightly arbitrary age of 2 years 10 months precisely to get that sample number of around 3,000. There are 13,360 pages which have not been edited in the past two years. The number of subpages older than a given age follows an exponential curve up until around June 2007, then becomes a linear fit. Empirically, I'd say that the system ceased to be actively implemented wiki-wide around that time. Happy‑melon 19:20, 17 October 2009 (UTC)
• Oppose. This is a matter for individual WikiProjects. Comment subpages provide a way to sign and date WikiProject ratings, and have a permanence and easy accessibility that threaded and/or archived talk page comments do not. Some WikiProjects find them useful. Centralized moves to get rid of them are inappropriate. It is much more in the spirit of Wikipedia to allow WikiProjects to turn the features on or off according to their needs. Geometry guy 19:38, 17 October 2009 (UTC)

Please give a specific example of when a /comments page was used like this and why the talk page could not be used. I assume you mean WP:Mathematics as one of the projects that uses them, but the Mathematics banner says "Please also add comments to suggest improvements to the article," which is what the talk page is for. If the comments page has a different use then it should say what it is on the banner instead of confusing people. I'm willing to keep an open mind about whether these pages are useful but I have yet to see any evidence of it.--RDBury (talk) 05:50, 18 October 2009 (UTC)

It could be clarified: improvements are within the context of an article assessment - here editors have found even a signature and date to be helpful. Geometry guy 23:14, 20 October 2009 (UTC)

No, this is not a matter for individual WikiProjects. Comments subpages are in the Talk namespace and as such are not specific to any particular projects. Are you speaking on behalf of any particular project here? If any projects are interested in keeping these pages, they should be made to host them in their own project space. PC78 (talk) 06:54, 18 October 2009 (UTC)

• comment I've already stated my support above, but wanted to propose that perhaps GA comment subpages should also be included in this proposal. Since GA comments regard problems with the article while coordinating ways to improve it, which seem like the job of article talk pages in general, why not have those discussions occur there as well? Equazcion (talk) 19:48, 17 October 2009 (UTC)

  I assume you are referring to GA review pages (/GA1 etc.). They are not for comments, but for GAN reviews and individual reassessments. Separate pages are needed for transparency and permanent linking to reviews from ArticleHistory. Geometry guy 19:55, 17 October 2009 (UTC)

  Reviews and assessments sound like the same thing as comments for improvement of the article, just in different words. But my GA experience is a bit limited so I'll wait for others to weigh in. Equazcion (talk) 19:58, 17 October 2009 (UTC)

  I agree with Geometry guy that it would be difficult, and impractical to put GA reviews on the talk page, it's similar to FAs, except generally only one person reviews, and it's probably why they aren't centralized. There's a list here, also GA2 and so on. But there's also to dos which create problems similar to comments subpages, I think those should be embedded directly into the talk pages. Cenarium (talk) 20:06, 18 October 2009 (UTC)

• For those saying that this is for individual wikiprojects to decide. I don't think we can (or want to) stop individual projects from using these. However, the vast, vast majority currently use a central template which include this /comments on over 2 million talk pages, many of those for projects that don't use or monitor the /comments at all. There are thousands of /comments pages created without anyone reading them, having them on their watchlist, ..., wasting the efforts of the people that posted there in the first place, and often on articles where the actual talk page has no content at all except for the banners. This proposal is to deprecate the suggestion of creating /comments pages on all talk pages as the default, leaving it to specific wikiprojects to install the functionality in their own template if they prefer this. Fram (talk) 07:04, 19 October 2009 (UTC)

• Since I've had some time to think about this, I think the following is a decent plan of action:
  1. Stop WPBM from encouraging creation of new /Comments subpages - this would probably only be a temporary measure until cleanup on existing subpages is finished; individual projects which still want the functionality would have to weigh in somewhere
  2. Delete those subpages outlined by Happy-melon on VPP (bot work?)
  3. Review remaining subpages, substituting or simply deleting where appropriate (maybe this should happen after the next step, so that unwanted subpages don't require a second run to find and delete)
  4. Send requests to all projects which have been using the subpages, giving a brief overview of the situation and asking if they still want the functionality (provide a link to where they should comment; no reply equals silent consensus to stop using the functionality for their own banner) - it should also link to the category for existing subpages with a count of how many currently exist
  5. Functionality in the banner gets updated as follows:
     • All /Comments subpages get created as subpages of projects, instead of article talk pages - allows each project to maintain its own comments standards or whatever
     • An editnotice gets displayed every time a /Comments page is created, advising that it may be better to add the comments directly to the article's talk page
     • A preload template is offered for new subpages (not so sure on this one)
• All of this, of course, is pursuant to a consensus to actually take large-scale action on /Comments subpages, and is open to adjustment or refinement before being deployed. Thoughts? (cross-posted from Template talk:WPBannerMeta#TOC and comments transclusion issue) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 17:43, 19 October 2009 (UTC)

One of the points of having 'comments' pages for articles, rather than projects, was to have a single comments page per article used by all projects active on that article. Some articles have 5-10 projects listed on their talk page. Should there be 5-10 comments pages saying slightly different things? It's the same argument that was had before over whether the rating should be same or different between WikiProjects. Anyway, I suggest that someone tries to find out where the initial discussion was that led to these comments pages being created. I suspect it was somewhere in WP:WP 1.0. And those that participated in those discussions should be notified about this one. Carcharoth (talk) 18:42, 20 October 2009 (UTC)

If changes are made, they should be done to non-WPBM banners as well -- WOSlinker (talk) 18:04, 19 October 2009 (UTC)

• Comment - Before anything is done, what is needed is to find out exactly how many of these pages there are, and to get the opinions of people who write on these pages and use them. i.e. Ask someone to actually dig out some data on this: how many such subpages there are and the sizes of them, and which projects actually use them, before blanket subst'ing and deletion takes place. Also suggest finding the best ones and getting the people that use them to participate in the discussion. Also, comments made on a talk page often get archived without being actioned. The idea of having a separate workflow for general talk page comments and one devoted to assessments and planning how to improve the article, is a valid one, even if not widely adopted. Suggest WP 1.0 project contacted, as they use these subpages in some of their reports. Also, talk page archives organised by topics allow better integration of such comments, and allows similar ones from over the years to be grouped together. Finally, copying and deleting will affect the edit and contributions history of those that edited those pages (and lose attribution). Suggest leaving redirects in place, and when pasting to talk pages, use an edit summary that points to the redirects for the edit history and attribution, and make sure the redirects are tagged as containing useful edit history, so they are not deleted by various bots that like hoovering up such things. Carcharoth (talk) 14:13, 20 October 2009 (UTC)

To get things started I did a random (more or less) sample of 50 pages that use the "maths tag" template; there are about 7000 such pages total. Here are the results:

26%-Page did not exist.

28%-Page consisted of a single signature with no comments.

34%-Page consisted of a short single comment (at most one line). A typical comment was "Needs references"

8%-Page consisted of a single long comment.

4%-Page consisted of multiple threaded comments. The pages were talk:Standard deviation/Comments and talk:Differential equation/Comments.

I didn't keep a tally of the number of different contributors but my impression is there were 2 or 3 users that accounted for most of content.

These results apply only to the Mathematics project and the results may be a lot different for other projects, and admittedly the sample size is small. But I thought the Mathematics project was appropriate because some of the opposition to the proposal is associated with it.--RDBury (talk) 17:47, 20 October 2009 (UTC)

Sampling is not really good enough here (though thanks for doing that survey). What is needed is some indication of who is using these pages, and to do that, all of the major contributors to such pages need to be listed and notified. Imagine someone spent hours doing hundreds of these pages a few months ago, and then looks for them in their contributions log (if they were an admin, they would find them in their "deleted contributions" log) and is mightily puzzled until they find out the pages were deleted, and a copy-paste copy of their comments is now lingering unread in some talk page archive somewhere. Carcharoth (talk) 18:36, 20 October 2009 (UTC)

I think the sampling is useful to tell what kind of editing is being and done and how much notification will be needed. If people actually did put a lot of work into some of these pages then I say by all means keep it and keep the link on the talk page, which is why I suggested having an alternate template for just such cases. But I think the statistics show, though not conclusively given caveats I mentioned, this really doesn't happen very often. It's silly to worry about preserving and making sure comments are accessible when it's just somebody leaving a signature with no actual comment, or adding "Needs references" or "Important topic" with no details. Being concerned about preserving useful information is one thing, and there are ways around that, but if you're worried about hurting the feelings of people who made a lot of meaningless edits without contributing to the quality of the articles then you've got to do more to convince me.--RDBury (talk) 22:26, 20 October 2009 (UTC)

See above, here is a list of all of them (at the latest search index update). Cenarium (talk) 16:20, 21 October 2009 (UTC)

• Old discussions - I found the old discussions here: 1, 2, 3 (May to July 2006). I will notify the people who took part in those discussions who are still here, as they may be able to shed light on what has changed since then, and whether the current use of these comments subpages has fulfilled initial expectations or not. 18:55, 20 October 2009 (UTC) UPDATE: Have notified the five main participants in those discussions, as listed here. Also left a note for the Version 1.0 Editorial Team here. Carcharoth (talk) 19:15, 20 October 2009 (UTC)
• Comment: For the record, I've deleted and oversighted at least a few of these comment pages because the only comment made there met the criteria for oversight, including people posting extremely personal details (true or not, some of it accusing people of criminal acts) on the page. I don't know whether or not they would show up on the web, but they certainly weren't on the radar of most people including the usual editors of the main article, sometimes for weeks or months. Risker (talk) 20:33, 20 October 2009 (UTC)
  • This may mean that bot-actions can't be done here and all comments pages that have been created will need to be manually inspected for such problems. The empty subpages are likely to be cases such as: (a) creation in a vandalised state followed by blanking; (b) valid creation followed by vandal blanking; or (c) valid creation followed by vandalism followed by blanking of the vandalism. There is no way of knowing until they are manually inspected. The main problem seems to have been that these pages didn't end up on anyone's watchlist, unlike the normal page and talk page. And stuff slipped by recent changes patrol. So this is both a strong argument for deprecating the pages (they are mostly unwatched) and also for not undertaking blanket bot actions. Carcharoth (talk) 21:57, 20 October 2009 (UTC)
• These pages were created with the intention of adding a small "assessor's note" to pages within WP:1.0/I. Originally, the comment subpages were directly transcluded on pages such as Wikipedia:Version 1.0 Editorial Team/Tropical cyclone articles by quality/1 in the listings. Due to technical reasons, they are now being linked instead of being transcluded, but the transclusion capability is slated to be re-enabled with wp10v2. Titoxd^{(?!? - cool stuff)} 21:02, 20 October 2009 (UTC)
  • What these pages were originally intended for and what they are actually being used for are not necessarily the same thing, but I'm afraid the usefulness of Talk:Eye (cyclone)/Comments (to pick one) is utterly lost on me; as far as I'm concerned, comments such as these belong on the talk page. But if these pages are primarily being used by WP:1.0, then I would suggest moving the lot of them to [[Wikipedia:Version 1.0 Editorial Team/Comments/foo]], and transcluding them from {{WP1.0}} only. PC78 (talk) 22:43, 20 October 2009 (UTC)

    Even a signature and a date indicates that the rating has been revisited at least that recently, and by whom. Geometry guy 23:58, 20 October 2009 (UTC)

• Comment. Editors interested in WikiProject Mathematics' use of comments subpages need not go to the trouble of finding random samples of 50 pages to check. Instead you can visit Wikipedia:WikiProject_Mathematics/Wikipedia_1.0 and its subpages such as Wikipedia:WikiProject_Mathematics/Wikipedia_1.0/Algebra/Top, Wikipedia:WikiProject_Mathematics/Wikipedia_1.0/Analysis, Wikipedia:WikiProject_Mathematics/Wikipedia_1.0/A-Class_mathematics_articles and Wikipedia:WikiProject_Mathematics/Wikipedia_1.0/Frequently_viewed. Geometry guy 23:14, 20 October 2009 (UTC)
  • Hmmm, an example of a project using comments correctly (or at least usefully), perhaps, but there are alternatives. A mere date for the assessment could be placed directly in the banner; so too could an actual comment, or comments could be transcluded from a subpage of the project. Take Talk:Pierre de Fermat, for example: the comments subpage contains just a date, which might makes sense to you chaps at the Mathematics project, but when transcluded in the Biography and France banners also on that page, the same comment becomes confusing, obscure, and probably not even accurate as a date for the assessment. PC78 (talk) 23:40, 20 October 2009 (UTC)

    I agree that one drawback of the current set-up has always been that WikiProjects have to share the comments subpage of an article and all comments get transcluded by all banners. If this can be fixed while allowing WikiProjects which value dated, signed and commented ratings, to continue to use them, that would be helpful. Geometry guy 23:58, 20 October 2009 (UTC)

    I agree. And furthermore, one of the biggest drawbacks to the assessment scheme as set up was not having a way for people to sign and date their assessments (and even add a comment). This would have forced people to take responsibility for the assessment they were making. The absence of this led to rapid-fire "rough" assessments, with little structure present to lead people forward on a path of article improvement, but rather a "we've rated it, our job is done" attitude. If that could be turned around, it would be be far more useful than tearing down the current system. Carcharoth (talk) 00:57, 21 October 2009 (UTC)

Assessments are meant to be rough though, particuarly at the bottom end of the scale. IMO it's not until you get to B-Class where constructive criticism becomes useful, and we have the B-Class checklists for that purpose. Most Stub-Class assessments are pretty obvious, and many of those are done by bots. I don't personally see any need for assessments to be signed and dated, or for an assessor to leave comment. Assessments can always be queried or changed if belived to be wrong, and there are numerous venues where people can seek feedback on an article. Let's be realistic: providing "rapid-fire" assessments to the 371,267 (at the last count) currently unassessed articles on Wikipedia would be a mammoth task in itself without pausing to comment on each and every one. PC78 (talk) 15:08, 21 October 2009 (UTC)

I was involved in the setting up of the bot-assisted assessment scheme back in 2006, and so I was asked for feedback. Sorry I was slow in responding! In our early assessment work at WP:Chem we often found it useful in our tables to list what the main problems were for two reasons

• The assessment may not be obvious. For example, if it's listed as Start for quite a long article, you might wonder why if you just glanced at the article. A brief comment like "needs better refs" can be very helpful when looking over a table of article assessments.
• We used to use such comments as a pointer to the main work to be done, to raise the article to the "next level". For example, someone might see "needs better refs" in the comments column of the table, and work to fix that problem in that article.

That was a very different situation to where we are now. The reality today is that most projects do not use the tables as much as we expected - the stats table is much more popular! Also, many projects are dealing with thousands of articles. As a result, the comments are much less visible than we had anticipated, and therefore much less useful.

I like the compromises being discussed above. If there are projects that find the Comments feature useful, they should be allowed to continue, IMHO. However, we need to find a way to remove the feature in cases where the WikiProject is not actively using the feature, because for most projects it is the "god-awful" thing Happy-Melon refers to. I think Le Docteur makes an excellent point; also, Carcharoth's comment is spot-on about the need for assessors to provide more information on the article than a simple B or C - I think that was a big reason why I supported the /Comments proposal initially. I like DinoGuy1000's list of suggested action points, and I think we should make the default setting in banners be "Comments=off". I'd also add a handful of my own:

• Solicit comments over at WT:1.0 (though I don't want to create a forked discussion!)
• CBM will be upgrading the WP1.0 bot in 2-3 months' time; we could see if it's possible to limit comments to only those projects that use comments actively. We could also have /Comments edits listed in the WP1.0 Bot logs that WikiProjects review.
• Maybe we should have an expiry date on comments, perhaps after one year?

Longer term, it would be nice to have a full review of how we carry out assessments, and how to streamline the process. In some cases, that may mean finding ways (technical or social) to get features like /Comments to function the way they were intended. But personally, I want to make sure I have three clear months of copious free time before I propose such a thing.....! Thanks for a great discussion, Walkerma (talk) 21:39, 23 October 2009 (UTC)

Aah, you raise a few points I hadn't considered, Walkerma!

One possible solution to the visibility problem is to have the bot generate another report specifically of articles with comments, and remove the comments column from the current assessment log pages. It would still be quite a bit of stuff for larger projects using comments, but it would at least be focused specifically on comments, allowing much closer review and response.

LiquidThreads is not long from being enabled on Wikipedia; when that happens, it will be possible to forgo the /Comments subpage system for a dedicated assessment thread which could then be linked directly from the banner. This would allow each project to maintain its own assessment comments locally, would get rid of the unwatched subpages, and would allow for direct discussion, all in one fell swoop (it's actually such a Good Idea™, I'm amazed no one else mentioned it earlier). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 22:01, 23 October 2009 (UTC)

Section break

Ok, I think we're coming to an agreement here. For a first step, I have removed the "forced comments" functionality from WPBM, so nonexistent comments pages are not redlinked and their creation is not actively encouraged. At some point I will also delete the three groups of pages I listed above (empty, unlinked and ancient). Is there a more general plan to proceed from there? Happy‑melon 11:52, 25 October 2009 (UTC)

The deletion of pages requires specific community discussion. In particular, deleting Comments pages older than January 2007 is flawed because in slow moving areas, the comments are often still relevant. Further, comments pages may be unlinked because of page moves (prior to the "move all subpages" option); these may also contain useful information. Drawing attention to relevant WikiProjects of broken links would be a much more helpful approach than deleting the pages. Geometry guy 23:44, 27 October 2009 (UTC)

True, an Miscellany for deletion would need to be opened at some stage. However we are still quite a long way away from that as we first have to work out what to do with the content of all these pages and then get a bot to deal with it. Gguy, I appeciate that you value these comments pages, but the consensus here is that they are not the best way of doing things. I recommend helping to work out the best way forward rather than the stick-in-the-mud approach. — Martin (MSGJ · talk) 14:10, 28 October 2009 (UTC)

I encourage you to ensure that your thinking is shared by Happy melon, who seemed poised to act and move on to the next stage. Nothing in my above post is stick-in-the-mud: I provided helpful and positive suggestions, and wish to ensure that good faith and often useful contributions to the encyclopedia are not deleted "at some point" without discussion or consideration of better options. Geometry guy 22:02, 28 October 2009 (UTC)

My suggestion would be that a system of "inline" comments be developed so that, for WikiProjects who wish to use comments, the contents of each /Comments page may be substituted into a comments parameter in their banner (example below). This makes the comments project-specific and eliminates the need to have a separate page. This would only be suitable when the comments are reasonably short, but from what I read here it seems that they were only ever intended to be for short comments (or even just a signature). — Martin (MSGJ · talk) 12:00, 25 October 2009 (UTC)

Of course, we could keep the current appearance (but without the navigation links), e.g.

Since I came to the realization of its potential applicability to this, I'm still pulling for exploiting LiquidThreads in some capacity. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:35, 26 October 2009 (UTC)

True, there may well be features of that extension which can be expolited here. However, we don't know when it may be enabled, and even when it is enabled, it will likely take some time adjusting to it before we can decide the best approach. Are there any disadvantages with my proposed method of dealing with this? — Martin (MSGJ · talk) 18:48, 26 October 2009 (UTC)

I don't think so, it looks good to me. And it's true that there's no deployment schedule for the extension yet, but it is being beta-tested on one of the testing wikis, so it's probably a good bet we'll see it enabled here within six months. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 19:16, 27 October 2009 (UTC)

It's not going to be ideal for any comments of substantial length, though. PC78 (talk) 10:54, 28 October 2009 (UTC)

Yes, I suppose you are right. I was thinking that, (for the second approach above, at least) the display would not be any longer and so would not cause any problems. However, if it was any more than a short paragraph of text, it would make the template syntax rather difficult to follow. So, on reflection, perhaps our approach should depend on the size of the /Comments page:

• if the size is 1kB or more then the contents are substituted on the talk page under a suitable heading
• if the size is under 1kB then the contents are placed inside a comments parameter on every WikiProject banner template on the talk page. (If a particular project decides not to use comments, then the contents of this parameter can be ignored.)

I don't think that the former method would be appropriate in all cases, because there are quite of lot of these pages which contain nothing but a signature and date - hardly worth pasting into a new thread on the talk page. — Martin (MSGJ · talk) 14:20, 28 October 2009 (UTC)

I don't see any consensus here for even the deletion that Happy-melon describes. What we have is a large number of Comments pages, ranging from 'empty' to 'appears empty but useful stuff in the page history', to 'in use', to 'currently in a vandalised state'. And little way of distinguishing between them. The option that appears to have most consensus is substituting the comments to the current talk page and then deleting. I object to that because it destroys the contributions histories. There are also problems because it may indiscriminately copy vandalism onto active talk pages. There is also the question of useful comments hidden in talk page histories. What I suggest is the following:

• (1) Inform all WikiProjects this feature has been disabled for future use, and ask which WikiProjects are using these pages. Wait a month for replies, and then filter out the pages that are in use and tag them as such. This stage may prove impractical, so skipping to stage two may be needed.
• (2) Set up a bot to turn all or a subset of Comments pages into redirects to the talk page of the article, giving in the edit summary a diff to an explanation of what is being done here. Simultaneously, the bot should leave a message on the article talk page that a Comments page exists, that it may or may not contain useful review information, and that those wanting to view that information should view the history of the Comments page (with a link both to the page history, and to the page immediately before it was turned into a redirect).

And that's it. Possibly protecting the redirects to prevent future resurrection of this system without wide-ranging consensus. Carcharoth (talk) 08:23, 31 October 2009 (UTC)

That's a useful reply and might be a good route forwards. Here is a possible refinement of your proposal with more detail:

1. Find a bot that can deliver a message to all the projects which maintain a category for articles with comments. (This list has been compiled by WOSlinker.)
2. In the message, the project is informed that the comments functionality is changing and is given an option:
   • Remove all functionality. (This will be the default if there is no reply.)
   • Continue using comments as an inline parameter. Support for this can then be added to the project banner.
   • If a project really wants to continue using separate pages, then it is possible to use subpages of their WikiProject (but I don't think this approach should be encouraged).
3. Wait a month.
4. For the projects that choose to use a comments parameter, on each page (if the size of the /Comments page is less than 1kB) substitute the contents of the page into the template code. Compile a list of pages which were "oversized" for each project to review.
5. Redirect all /Comments pages to the talk page. Leave a note on each talk page, as Carcharoth describes above.
6. Remove default support for /Comments subpages from WikiProject banner templates.
7. Perhaps after a year, it may be assumed that any useful information has served its purpose and deletion of the pages can start.

— Martin (MSGJ · talk) 23:17, 1 November 2009 (UTC)

I have drafted a message to post on WikiProject talk pages. Any help in copy-editing or making it clearer would be appreciated. — Martin (MSGJ · talk) 19:25, 4 November 2009 (UTC)

Drafted message looks good. Agree with your more detailed proposal, except point 7. It makes little sense to delete the pages (even after a year), especially if you are leaving a talk page message pointing people to the history of the redirect. Deletion destroys contribution histories. Would you suggest deleting some of the oldest talk pages because "it may be assumed that any useful information has served its purpose"? If not, then these pages shouldn't be deleted either. Of course, if there are pages where the page history is only vandalism, then by all means delete, but don't assume currently empty pages only have vandalism in the page history (or have no page history). Carcharoth (talk) 00:34, 6 November 2009 (UTC)

Okay, well point 7 can be left to a future time if a MfD is ever opened on these pages. It's certainly not important at this stage. Personally I would still prefer to substitute the contents on the talk page, as it is easier to read than having to check the history, but I don't think it's that important. — Martin (MSGJ · talk) 16:20, 6 November 2009 (UTC)

Ratings are meant to be WikiProject-specific

In general, WikiProject ratings are up to individual WikiProjects to decide upon. If some project wants to use comments subpages, that is their prerogative.If some other project wants to invent a D rating, that is their prerogative as well. Other projects are not required to use these things. The WP 1.0 system is not intended to be a top-down ratings system, it is intended to be a bottom-up system in which each WikiProject does what it feels is best. — Carl (CBM · talk) 00:17, 21 October 2009 (UTC)

Ratings generally are WikiProject specific; that isn't the issue here. I wouldn't have so much of a problem with comments pages if they were project specific, but they aren't, we're talking about common pages that are shared by any project which places it's banner on a talk page. We just need a better way of doing things. If coments were moved into project space, they could be specific to each WikiProject, and I'll bet they would be better mainatined as well. PC78 (talk) 14:45, 21 October 2009 (UTC)

If a particular project wants to not share the comments page, but wants to have their own page, all they have to do is change their template to use their own page. — Carl (CBM · talk) 14:18, 28 October 2009 (UTC)

Well, yes, but the issue here is whether or not we should have shared comments pages to begin with, and concensus so far seems to be leaning towards "no". PC78 (talk) 23:38, 29 October 2009 (UTC)

You could always adjust the banner to display a subpage in project space, e.g. Wikipedia talk:WikiProject Mathematics/Comments/Parseval's theorem instead of Talk:Parseval's theorem/Comments, although I think the additional page is probably unnecessarily bureaucratic. An inline comment would work just as well, and I'm sure a bot wouldn't have a problem to read the contents of the parameter if lists of these are required. — Martin (MSGJ · talk) 22:45, 1 November 2009 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal: Allow Editors to be Administers in their own Namespace.

Hello,

My proposal is to allow users to administer the pages that are in their userspace domain. For example, I would be able to protect, delete, and do all other administer funtions as long as the pages had the prefix : User:Tim1357/ and User talk:Tim1357/. Tell me what you think. Tim1357 (talk) 14:39, 22 October 2009 (UTC)

Definitely not in the User_talk: space. User request is a valid reason for deletion and protection, so, this is really not necessary (nor technically possible)--Unionhawk ^{Talk E-mail Review} 14:43, 22 October 2009 (UTC)

Ingenious idea. If an admin warns you for vandalism, you just delete your talk page and create a new one, to hide the fact. If you don't like an article you just move it into your user space, delete it there, and poof! its history is gone? What a great way to create a lot of additional work for admins. Hans Adler 14:58, 22 October 2009 (UTC)

(edit conflict) ^This. Convenient, but a veritable buffet for vandals. --King Öomie 15:07, 22 October 2009 (UTC)

Firstly in response to Unionhawk, yes it is technically possible, just might require a tweak to the software. Secondly in response to Hans, thanks for the sarcasm, it's always a pleasure to hear; but there are ways to get around such a problem. Articles created in userspace could be flagged as such, and deletion by the user could be allowed only for those with the flag. And that's just one example.

I think this is a nice idea, but not across the board for all users, just those who have been established for a while. And admins would need to have the ability to override anything the user did.

That said, I unfortunately doubt this feature would be enough of a priority to actually be implemented any time soon. Equazcion (talk) 15:06, 22 October 2009 (UTC)

Too complicated for too little gain. –xeno^talk 15:08, 22 October 2009 (UTC)

The additional license given to users in their own userspace is a privilege, not a right. Allowing them special powers would run contrary to that. Chris Cunningham (not at work) - talk 15:12, 22 October 2009 (UTC)

To argue for the sake of arguing, saying something is a privilege and not a right is a way to show that an ability can be taken away as easily as it's given. It's not evidence against offering more privileges. Give the users the added privilege of administering their own userspace, and it's still a privilege that can be taken away, not a right. Equazcion (talk) 15:21, 22 October 2009 (UTC)

Maybe "privilege" wasn't the right word. "Licence"? The current situation is basically that you can do things in your own userspace which you probably shouldn't be doing, but which you'll be let away with. That's quite different from giving allowing one to do things which are physically impossible for others to do. Chris Cunningham (not at work) - talk 15:32, 22 October 2009 (UTC)

Proposals usually explain the benefit expected. This one doesn't. (Costs have been indicated above.) Rd232 ^talk 15:31, 22 October 2009 (UTC)

The illusion of power? Everyone would feel kinda like a little admin. Might boost morale :) Equazcion (talk) 15:47, 22 October 2009 (UTC)

Hans pretty much sums up the problem. (I can think of a few other really messy things that I won't describe further.) Easily abused, with negligible tangible benefit. Has the added risk of tempting users with no other admin-tool experience to wheel war in an area where they are least likely to be impartial: their own userspace. Editors 'experimenting' in their own space may need professional help to clean up after errors.

Looking at CAT:CSD right now I only see one userspace page, and that's the result of a misplaced {hangon} template rather than a U1 request. The cost-benefit tradeoff does not seem worthwhile. TenOfAllTrades(talk) 16:18, 22 October 2009 (UTC)

Just like to point out that userspace CSDs are usually the first to go since they're generally uncontroversial, and don't require any real investigation. There are a lot of them, I think; they just get handled quickly. But I guess that still proves the same point, that the proposal isn't so worthwhile. Equazcion (talk) 16:33, 22 October 2009 (UTC)

Very much thanks for the sarcasm... the whole purpose of this page is to shoot off ideas and look for meaningful feedback. Tim1357

It was a nice idea, but Hans Adler explained why it won't work. Fences&Windows 15:46, 26 October 2009 (UTC)

An alternative for this would be a "wiki-sandbox", a "project" where all users are given admin rights and can "play" with creating pages or accounts and then delete, restore, block, unblock, protect, unprotect... Of course, it would be a project created merely for this purpose, without any other tangible purpose or valuable content. It could allow users to see how do those tools works or "feel powerful", and yet keep all the potencial harm contained at a place where no effects can be done (even indirect or subtle ones) over the real projects. However, I don't know how much it would cost to run another project, even if just at a "testing" scale 200.68.71.147 (talk) 14:31, 28 October 2009 (UTC)

There are many such test wikis that allow people to play admin, and above. I think even the Wikipedia test wiki allows it. –xeno^talk 14:34, 28 October 2009 (UTC)

There may be some benefit from allowing users to delete their own subpages, so for example they can delete "User:John Doe/Why did I create this" without having to go through an admin. But if admins aren't bothered by these requests then I don't see any reason for a change.--RDBury (talk) 16:13, 29 October 2009 (UTC)

Thanks for the feedback, I suggested this because i feel bad asking admins to delete my user pages, but if they aren't bothered by it then I agree; there is no need for this. Tim1357 (talk) 01:03, 4 November 2009 (UTC)

In its defense, this idea is actually kind of nifty; perhaps not on wikipedia itself, but I can see all kinds of uses for it on wikia-like sites. :-) --Kim Bruning (talk) 01:42, 4 November 2009 (UTC) For all those who last saw me wearing a wikia t-shirt, that was because it was a perennial freebie swag handout! I even left room for it in my luggage! I swear I'm not in any way biased, honest.

Ok, if the pro-Hans group is worried about talk pages being deleted to "hide" warnings (which warnings are meaningless anyways and if you've been here for over a year you figure that out and then they dont scare you); then as someone mentioned- allow it users to be admins over subpages and not over their talk page. Are admins that insecure about their "power", which they have because we ALL, admins and regular editors and IPs, give that group called "administrators" power and can take it away just as easily, both strip from the group called admins and we can strip individuals. You worry about an article being moved from article space to user space and then getting its history deleted...then block that from happening. Instead of having a war of admins vs the common guy, how about you figure out how to let the common user control his own pages in a way that cant be used for evil? If we didnt give people powers just because a minority might abuse them then we would have no admins at all (because, yes, I see admin abuse at least once a month). It seems those that dont want users to have this ability seem to think of all of us as in the worst light. Really? That many bad seeds in Wikipedia? Good think we have soo many admins to keep us in line, without them we'd have all this vandalism and Wikipedia would crash, we'd be children with no parental oversight. The world would end because you cant trust non-admins with responsibility, because if they were responsible editors theyd want to be admins and have been promoted already!Camelbinky (talk) 02:24, 4 November 2009 (UTC)

I strongly support the option of giving editors with some history behind them the ability to delete pages that were created by them, in their own userspace, and are still there. Why should an editor have to run to an admin to delete every user-space page they put together as an experiment, and have finished with? bd2412 T 02:51, 4 November 2009 (UTC)

Bug vote

Question: do the developers pay any attention to the voting on bugs at Bugzilla? If so, would it be worth making an effort to identify (perhaps via RFC) some bugs the community thinks particularly important, and then get people to vote for those? A general discussion on management of bugs might be helpful, as there isn't (AFAIK) any single place on Wikipedia that discusses these. Rd232 ^talk 10:16, 29 October 2009 (UTC)

I guess they pay some attention, but generally they don't much care about (or are quite unaware of) what users feel they need. There really ought to be a forum for proper on-wiki dialogue involving both editors and developers, so that solutions can be arrived at constructively and action taken to implement them. Bugzilla doesn't really work in this regard. --Kotniski (talk) 11:28, 29 October 2009 (UTC)

Yes developers do pay some attention to votes, but it is usually not a very compelling factor in determining developer behavior. Most of the bugs with a lot of votes are "supported" in the sense that yes we'd like to do that, but often the changes required are complicated for one reason or another and so no one has picked up the project. I agree with Kotniski that the community (on both sides) could probably benefit from an on-wiki discussion forum (at Mediawiki.org?) for feature requests, as bugzilla is not a good medium for the community to express it's preferences. Dragons flight (talk) 17:01, 29 October 2009 (UTC)

Nope, they're pretty much ignored by us. We keep voting enabled, as it makes for a good bookmarking system if you don't want to necessarily be on the CC list for a bug. As far as using it to establish priority/importance, I've never once looked at the number of votes. As far as discussions with devs...I'm hesitant to suggest using mw.org as a discussion forum as we pretty much use that for documentation; very little discussion takes place there at all. ^demon^{[omg plz]} 17:58, 29 October 2009 (UTC)

I think the structural problem is more that very little discussion between devs and editors takes place anywhere. A few devs visit forums like this, but its very ad hoc, and many devs never visit. Right now there isn't anywhere that is really set aside for community discussion of new features, so we end up with VPT threads that quickly disappear, hard to find Wikipedia: pages, threads on Meta, and chatty bugzilla entries that aren't very helpful. If you've got a better suggestion about where to have the community discuss the development of Mediawiki rather than mw.org, I'd love to hear it, but it seems the most logical of the wiki spaces to me. Dragons flight (talk) 21:33, 29 October 2009 (UTC)

Well, the developers are most active on IRC in #mediawiki, it's easy to ping most of us there. The wikitech-l and mediawiki-l lists are good, and Bugzilla is the ultimate place to discuss bugs/feature requests. Of course "me too" comments are unhelpful and clutter discussion, but on-topic posts to Bugzilla are certainly welcome. I can tell you that most developers aren't interested in wading into massive enwiki discussion, they're long-winded and prone to losing focus. Typically, we like shorter discussions that cover the essential points :) Perhaps we do need a place on mw.org where we can list stuff of specific importance to various WMF communities, linking to bugs/threads/whatever so we can get a quick and condensed version of what the community needs. ^demon^{[omg plz]} 23:16, 29 October 2009 (UTC)

Yes, there are ways for individual Wikipedians to "ping" a dev. This is fine for pointing out bugs. It's not great for asking for new features. If JohnQWikipedian comes up and says: "enwiki needs more flying monkeys", it is hard to know if that is merely his opinion, or really an opinion of the enwiki community, and if it is a community opinion how the demand for "flying monkeys" compares to the need for "sexy starfish", etc. So, in general, only the very loudest and most insistent requests (often made through multiple channels) actually sink into the developer consciousness and get attention, while many other good ideas get filed into bugzilla only to disappear into obscurity. I agree that most developers don't want to be sorting through piles on discussion. They want to have a result / summary to work from. That's fine. But right now though, we don't have a good process for identifying/discussing which features it is that the community wants so there isn't a good way of producing a credible summary. Dragons flight (talk) 00:30, 30 October 2009 (UTC)

That's a good summary of the problem. So, what can we do about it? How can we produce results on What The Community Wants? RFC? WikiProject? New Village Pump subpage? I found Wikipedia:Feature request (archive) linked from Wikipedia talk:Bug reports and feature requests, so some effort to do this has been made in the past. Rd232 ^talk 08:59, 30 October 2009 (UTC)

I think it's a bit more complex than has been suggested (and this is why bugzilla doesn't work). It's not that users get together and decide what they want, then they tell a developer, and the developer does it (or in practice, doesn't do it). There needs to be developer involvement in the discussion from an early stage, so that the dev can explain what's easy, difficult or totally unfeasible, what side effects might come up and so on, and so that users can modify their expectations on this basis, and so that a consensus is reached involving users and dev(s) that can actually be acted on in a fairly short time-frame. Anything that splits users and devs into two separate communities is a bad thing and leads to warped priorities - we're all on the same side here, working for the same goal, and there needs to be full and effective cooperation.--Kotniski (talk) 10:49, 30 October 2009 (UTC)

It's a valid point on needing that sort of input, but it's surely unrealistic to expect devs to spend substantial time involved in such discussions. There are WP editors who know a lot about the software and its use - getting them involved in such a centralised discussion would help a lot. And if necessary specific questions can be asked of devs, via some established and preferably public/recorded (not IRC) channel, and hopefully answered. Is there such a channel? Is there such a centralised discussion? Not to my knowledge. Rd232 ^talk 11:01, 30 October 2009 (UTC)

That's a need, but I don't agree that's it's unrealistic to expect devs to join in discussions. We're working together - we should all be talking to each other. Devs must and doubtless do discuss things so that they know what's expected and what's going to work - at the moment I suspect that the time they spend on discussion is spent discussing with each other, which serves only half the purpose. The sickness is well illustrated by the comments above where it's admitted that devs pay little attention to votes on bugzilla. They live in their own world; they think they know what's wanted and needed, and are contemptuous of anyone telling them that the priorities should be different. This isn't a criticism of anyone personally; it's presumably the system that brings about such attitudes, and we can try to change that system. (Though I'm not too optimistic about it happening unless some very senior dev recognizes the problem.)--Kotniski (talk) 11:14, 30 October 2009 (UTC)

Yeah it is an interesting clash of cultures. However, what the wider community (and this goes for most popular open source projects) often forgets, is that the developers are there to code and most of them do this for free. It is their love for a project that makes them want to work on it. Now from experience I can tell you that there is nothing more unmotivating for a developer than wading trough discussion after discussion of complaints and rants. Most of it is crap you can't use, and most of all, it cuts into the limited amount of time you have available as a developer to donate to the project (every hour you read, you cannot write code). This is HUGELY underestimated by most people, because most people are used to companies where people get paid to deal with your problem.

Fragmentation of the communication methods also comes into play. Think about this: the developers publish news via blog, communicate via IRC, discuss on the mailinglist, keep score via bugzilla, document via wiki. That are already 5 systems you need to keep up with that really have nothing to do with actually writing the code (another 3 systems (svn/codereview/commitlogs) to keep up with). Entering into discussion with non-peers however would be the most time consuming of all that and is yet another platform you need to keep up with. It's not that it's not possible, but it's chaotic and hard to implement in a way that isn't too obstructive.

The most common solution is to have people in between. A type of "ambassadors" who understand enough about the technology and the community to clearly and appropriately communicate ideas and bugs to developers and communicate back the issues that developers run into delaying a feature for over 6 years. This is quite common in businesses, but in volunteering work, it's work that only few people volunteer for. I used to spent hours a day on a forum of an open source project trying to be a bridge. So much that I almost didn't write any code myself at some point, but at least OTHERS were getting some work done. In essence that is also what you see on VP/T. People on IRC and the mailing-list who are not developers, try to create a bridge between en.wp and the developers, but it's a big project and a lot of communication.

The usability team tries to communicate more directly with the community by having feedback pages on their wiki pages, but because they never answer anything there, it seems more like a dumpground for opinions. It would be good if they indicated there that they had at least read the feedback. This is something for the new CTO to deal with and put some energy into. —TheDJ (talk • contribs) 13:19, 30 October 2009 (UTC)

I agree with all that. Hence my vague idea to try and create a better filter within the community on what we want to communicate to devs. If we could periodically agree on some key points via that filter (maybe a monthly summary?), and have a clear channel for communicating those key points (maybe via "ambassadors"), giving small amounts of useful information to devs, we'd be getting somewhere communication-wise. Rd232 ^talk 13:39, 30 October 2009 (UTC)

We could try. Do we know who the new CTO is, by the way, so we can ask him/her what he/she thinks about all this? (Or following on from what the DJ says, could the "usability team" - again I'm a bit vague on who they are - in fact taken on the role of "ambassadors"? Though I'm really unconvinced by people who say that developers' time is wasted by talking directly to their fellow wikians - the rest of us have to do it - though I'm not suggesting they should trawl through other people's discussions.)--Kotniski (talk) 13:56, 30 October 2009 (UTC)

There is no new CTO yet :( The usability team is really not suited to take on the role. They have a dedicated task, and they should not defer from that too much. Also, we as wikians kinda do the same. The AbuseFilter and the anti vandalism bots for instance are a part of our "filters" for dealing with stuff we don't really want to deal with. We need to come up with a system that will filter for the developers. —TheDJ (talk • contribs) 14:39, 30 October 2009 (UTC)

One of the problems is the popular use of "bug" tracking software to report both "bugs" (malfunctions) and "not bugs" (feature requests, complaints about "antifeatures", etc.). The latter being situations where the software is working as designed but it's producing behavior that some find undesirable or annoying. This makes the less tech savvy users view anything they don't like about the software as a "bug" even though it may be working properly. Also, I never liked the term "WONTFIX" which seems to be saying "yes we know it's broke but we're going to leave it broke". IMHO no report on a "real bug" should ever be "WONTFIXed". If the developers of mediawiki, or any software for that matter, decide not to change a "not a bug" or not to implement a feature request for whatever reason, a better term for closing such reports might be "AINTBROKE". If it is a bona fide malfunction that simply can't be corrected in the current version of the software then it should be called "CANTFIX". --Ron Ritzman (talk) 12:36, 30 October 2009 (UTC)

Hmm, that would just be a name change. It would be better to have a meaningful assessment for each bug or request - how much work it would require, what its priority is, and consequently how long we can reasonably expect to have to wait for it to be addressed. At the moment we just don't know - and we're left to make workaround decisions which often depend on how long the bug/featurelessness is going to remain in place.--Kotniski (talk) 13:56, 30 October 2009 (UTC)

Unless the change is deemed to be so important that its assigned to a paid developer who actually does have an obligation to meet deadlines or the person making the estimate is about to start working on it immediately, any such estimate would typically be a wild guess. For example, it took about 7 months before someone got to T20019, but the fix itself only took about an hour to do. Mr.Z-man 17:08, 30 October 2009 (UTC)

I guess that situation's pretty common. It's really frustrating making these requests, knowing that they won't take much time to solve, but getting no response as to when anyone's going to get round to them. Anyway, who does the deeming? Surely users' votes should be the main criterion when deciding what's important and what isn't? --Kotniski (talk) 17:43, 30 October 2009 (UTC)

I share your frustration and have found that in most cases Bugzilla is a graveyard for feature and improvement requests, with or without voting. It seems that the only way something gets implemented is by getting a developer interested by other means. Of course this is frustrating and unprofessional, but reminiscent of other community-driven project such as Firefox. Cacycle (talk) 19:07, 30 October 2009 (UTC)

Well we seem to agree on the problem... How about this, as a starting point discussion on doing something about it: (a) Wikipedia:MediaWiki/Discussion (b) Wikipedia:MediaWiki/Discussion/For Developers. B would be updated infrequently, perhaps on the first of every month, as a summary of the current views and questions emerging from A. After each update, devs would be notified, maybe via IRC, and asked to comment/reply. Rd232 ^talk 20:05, 30 October 2009 (UTC)

The problem is more the work ethics of the developers which is mostly driven by personal interests and choices, higher priority fixes, and sexy new features. It is also not really possible to enforce any additional work on volunteers from outside. The only solution would be a self-imposed agreement between developers to clean up the Bugzilla backlogs in a systematic and serious fashion, perhaps guided by the number of votes and the date of the request. Cacycle (talk) 17:16, 31 October 2009 (UTC)

I don't see how the second sentence follows from the first. Well-structured communication of the community's priorities, as a sort of peer pressure, seems more likely to be achievable, and to have some effect. Rd232 ^talk 17:40, 31 October 2009 (UTC)

Yes, you can't force volunteers to do anything, but peer pressure works wonders (except that something someone said above implies that developers don't consider editors to be their peers, hmmm...) Though I think it's important to bug the new CTO (or perhaps the people making the choice of CTO, if the process is ongoing) on this issue; someone who's getting paid - by us, in a way - ought to be even more responsive to the needs of the project. --Kotniski (talk) 17:45, 31 October 2009 (UTC)

Well if we're not peers, then surely we're customers or something? Either way, a clear, brief, occasional exposition of what we want ought to have some significance for them. Rd232 ^talk 20:47, 31 October 2009 (UTC)

No, we are different groups. That has always been the problem. Sets of volunteers, dedicated to an encyclopedia, but all with different amount of time and skills. The developers don't work for us, they donate TO us, to help us write (or maintain). To structurize those donations in a useful way is almost a form of art. Only the element that structurizes might be steered by us. This used to be brion, but he was less of CTO, than he was an engineer. Lets hope that with a new CTO we can influence that focus and improve the communication. And sure, we can invite and discuss, but it's not like the developers are unreachable, unreasonable or without focus. Perhaps it would suit the community to once in a while venture out of their comfort zone of wiki just as much as it would benefit developers to be active on wiki. We forget that as "hostile" or strange as some consider the core developer community, our own community is bound by similar rules and conventions, that can be difficult to understand for outside developers. And we need to remember that we are just one wiki in over 1000s that are benefitting of the work of the developers of course. We may be important but we are certainly not the only wiki with opinions. We cannot expect developers to participate in all 200 language variants of wikipedia + all the other installations. I don't think a Wikipedia:MediaWiki/Discussion would work, but I do think that we should make a plea to the future CTO when he comes aboard to make this communication one of his focal points. —TheDJ (talk • contribs) 13:17, 1 November 2009 (UTC)

"I don't think a Wikipedia:MediaWiki/Discussion would work" - why not? You say we can't expect developers to "participate", but that's not what I proposed. I proposed developing a sort of Monthly Memo, which they would hopefully read and ideally respond to. The memo, after being produced each month, could be pushed anywhere more helpful than en.wp, if it makes any difference. And you say the developers are not unreachable - maybe not, but precious few people have any idea how to reach them (and that's probably a good thing - we don't want to flood them). Rd232 ^talk 16:22, 1 November 2009 (UTC)

As I mentioned above, if I were organizing I would lean towards having something like mw:Feature requests as a organizing front, which would be a wiki environment accessible to the community, but also a single point of reference rather than having every wiki community develop their own feedback mechanism. One advantage is that Mediawiki.org is one of the places the developers "live". A drawback is that Mediawiki.org has not historically been used for much discussion and it is unclear if people would really embrace it for that purpose. Regardless of location, I think the solution needs at least two functional pieces. 1) A discussion forum to consider various proposals and strive for consensus about what is wanted and technically reasonable, and 2) a review process to summarize what is approved and propose implementation steps that need to be taken in a way that provides clear and direct guidance to developers. Ideally members of the technical staff would be involved in both pieces, but especially the latter. Dragons flight (talk) 09:55, 2 November 2009 (UTC)

As a foot note to the above discussions, I would be rather surprised if the CTO hire had "helps coordinate between editor and developer communities" as a much of a requirement. Wikimedia is top ten web destination with hundreds of servers in multiple data centers. I would assume the CTO's first priority is meeting the hardware needs of the organization and coordinating foundation software initiatives to make the best use of available hardware. Yes, there is a strong managerial and communication component to the CTO job, but working with editors would probably be low on the list of communication priorities compared to working with developers and foundation staff. More realistically, one might hope a staff developer (but someone less highly ranked than CTO) would be put in charge of facilitating community-led initiatives. Dragons flight (talk) 11:11, 2 November 2009 (UTC)

What we could do is maintaining a list of enhancement requests, by topic, relevant to the English Wikipedia; it could help to coordinate the efforts at the community-level and developers may find interest in one request or another; it may be a step towards a better communication between the community and the technical staff. Cenarium (talk) 17:21, 4 November 2009 (UTC)

Proposal

I have an idea. What if the Foundation asks the developers, the sysadmins, the staff, the en.wp community, the commons community and 5 other smaller language communities to write a "Plea" to the next CTO? Describing the main issues and problems they would like the next CTO to take into account. That way the new CTO can get an overview of the challenges, opinions and emotions of the different groups he will need to work with. —TheDJ (talk • contribs) 13:26, 1 November 2009 (UTC)

That's probably worth trying, but I see no reason why it should compete with my en.wp Monthly Memo, to give my proposal above a crappy handle. Rd232 ^talk 16:22, 1 November 2009 (UTC)

WP:DevMemo

I've created WP:DevMemo as an attempt at implementing my idea of a structured discussion on communicating with the developers, and generally organising our thoughts on what we actually want. Comments please, and pitching in, and watching the page. Rd232 ^talk 15:22, 5 November 2009 (UTC)

Floating an idea (knowing it'll be shot down, because nothing changes here)

It's rather easy to gauge how up-to-date a published encyclopedia article is by its publication date. but not so easy with a wikipedia article. So what about a "last updated" field on the mainpage? Sure, it wouldn't be foolproof, but at least it would be a better guide than the one that doesn't exist now. --Malleus Fatuorum 05:16, 1 November 2009 (UTC)

I think we already have this, in the footer of every page: "This page was last modified on...", to the right of the Wikimedia logo. Equazcion (talk) 05:24, 1 Nov 2009 (UTC)

I see that stamp actually isn't on the main page though, if that's what you were referring to. I wonder why... Equazcion (talk) 05:27, 1 Nov 2009 (UTC)

It is on every (non-Special) page, including the Main Page—but the Main Page has some CSS to make it disappear, at least for both Monobook and Vector, each in their respective MediaWiki:Foo.css page. To put that on the Main Page would be as simple as deleting a line or so of code in each page and waiting a month or so for the caches of unregistered users to expire. Now, I don't see what the usefulness of this would be, since that would only reflect the last time that the Main Page was edited, not the whole of Wikipedia—and the whole of Wikipedia is edited so often that such a piece of data would likely be largely useless anyway. I'm not opposed to the idea, but I don't understand why anyone would care were it implemented. Can you explain, Malleus? {{Nihiltres|talk|edits}} 05:36, 1 November 2009 (UTC)

It's hidden away in small text at the bottom of the page, I agree, where probably nobody ever looks. But I was proposing something of equal prominence to the FA bronze star. --Malleus Fatuorum

Seems to be some confusion here, probably my fault. I'm talking about a prominent display of when each article was last updated. --Malleus Fatuorum 05:41, 1 November 2009 (UTC)

So you want the 'last updated' stamp to be more prominent. I could agree there. I never really notice it. I think the present display is just for technical attribution and reference purposes, rather than something practical that people are supposed to notice. Could be something to consider. Equazcion (talk) 05:48, 1 Nov 2009 (UTC)

Yes, exactly. --Malleus Fatuorum 06:00, 1 November 2009 (UTC)

That I can see getting shot down (forgive me :P ). While I agree that the information is interesting, I think that neither the average reader nor the power-user will benefit from this proposed change—the information is already there, just it's not in the reader's face. Putting it in the user's face rather than leaving it in the footer is either a) annoying for the reader, who has more chrome-text to ignore, b) a usability failure for the newbie editor, who would therefore have more chrome-text to read, or c) annoying for the power-user, who will likely hide it as irrelevant, since for any decent page analysis they'd use the history page anyway. I don't see the use nature or use frequency of the feature as justifying a more prominent placement. Are there particular benefits to making it so prominent? {{Nihiltres|talk|edits}} 06:11, 1 November 2009 (UTC)

(edit conflict)When you consult an encyclopedia, do you care if it's the 1911 edition or the 2009 edition? If you don't, then of course my suggestion falls on deaf ears, as I knew that it would. --Malleus Fatuorum 06:26, 1 November 2009 (UTC)

That's a straw man argument. It's natural that I would care about the difference between a 1911 edition and a 2009 edition, but it's silly to expect there to be such a sizable distinction if the difference in time is a second or two at most (as I mentioned) as opposed to the 98 years you give as a straw man. It is a reasonable assumption that the encyclopedia as a whole was last edited less than five seconds ago. For individual articles the difference is more interesting, but still of trivial use for most readers, and therefore not useful in a prominent position. I would broadly advocate making the interface as simple as possible, and this proposal seems to run counter to that principle. {{Nihiltres|talk|edits}} 16:24, 1 November 2009 (UTC)

The "silly" argument is the one that you've just put forward. If I'm looking at an article on, say, the 2005 Hertfordshire Oil Storage Terminal fire, and I see that it hasn't been updated since 2005 then I know immediately that it's out of date. --Malleus Fatuorum 16:42, 1 November 2009 (UTC)

No, it's not silly, because I specifically said "For individual articles the difference is more interesting, but still of trivial use for most readers". I like the availability of the information, but I don't think that it needs to be made more prominent. {{Nihiltres|talk|edits}} 22:10, 1 November 2009 (UTC)

(edit conflict) A lot of times when I'm reading a article, usually after having looked up an obscure topic, I'll not notice how old the revision is. I've found myself wandering in the history of a page and being surprised by how long it's been since the page was updated. That can really cast an entirely different light on an article. I think the time that information was last updated is crucial, and is usually obvious in other mediums. The stamp doesn't need to be so prominent as to be bothersome. Just a time and date, perhaps as Malleus suggests, in the upper-right corner, small, where FA icons go. Equazcion (talk) 06:21, 1 Nov 2009 (UTC)

Attempted and failed. --Cybercobra (talk) 06:19, 1 November 2009 (UTC)

The majority seemed to be in support.What made that discussion a failure? Did you ever try filing a bug? Equazcion (talk) 06:24, 1 Nov 2009 (UTC)

The majority was in support of adding an "elapsed time" field next to the existing "last modified field", but not for making either field more prominent. A bug for adding said field was filed: [6] --Cybercobra (talk) 06:28, 1 November 2009 (UTC)

That's too bad. I really think the mockup has promise Equazcion (talk) 06:31, 1 Nov 2009 (UTC) →

This should really be revisited. It seems very intuitive to me, even expected on web sites now, on pages where information get updated. Equazcion (talk) 06:33, 1 Nov 2009 (UTC)

That mockup is exactly the sort of thing I want to see. --Malleus Fatuorum 06:36, 1 November 2009 (UTC)

Not me. I'm unsure of the merits altogether, but I'd definitely oppose "2 hours since last edit" style, a last-modified-style "This version dated xx/xx/xxxx yy:yy" would be better formatwise. I'm unsure not least because many articles don't really need much updating, and others need it a lot, and so the reader may not know how to interpret the last-modified; and it will definitely encourage dummy edits to bump the last-modified. Rd232 ^talk 07:53, 1 November 2009 (UTC)

(retab) To be honest, having anything more than what we currently have right now seems kinda pointless. Pages are getting edited all the time. And, as any college student will tell you, no one is using Wikipedia as a source for a paper or project (using Wikipedia's sources however is an entirely different matter). I'm not opposed to changing it around, I just don't really get why it's an issue. Articles of significance, from what I've seen, getting updated regularly, and articles of some random obscure thing may not get updated that often simply because there may not be any real info that can be added. Anakinjmt (talk) 08:22, 1 November 2009 (UTC)

If, as appears to be the case, this isn’t going to be changed, perhaps there could be a user script for those of us who do want to see this displayed prominently at the top of the page? MTC (talk) 08:57, 1 November 2009 (UTC)

This will never be implemented due the need to cache pages and time based variables negating that affect. Just like {{{currentuser}}} variables that people want this will never happen server side. This would make every page un-cacheable due to the variance in time. If this is implemented it would have to be done with client side JavaScript. β^_command 11:31, 1 November 2009 (UTC)

I've seen sites use the calculated "time since" on pages that have changed within 24 hours, switch to a "yesterday @ [time]" for pages changed 24-48 hours ago, then just show the date and time for everything after that. If the "time since" only needs to be calculated and cached for pages that changed in the last 24 hours, I think that'd be relatively little strain on the servers. Equazcion (talk) 13:33, 1 Nov 2009 (UTC)

I think there's a difference between a minor edit fixing a typo or reverting vandalism and an update where someone has reviewed the article. So if this goes ahead I would suggest ignoring minor and rolled back edits. ϢereSpielChequers 13:43, 1 November 2009 (UTC)

I threw together a script at User:Anomie/lastmod.js to put the last modified date in the corner. But do note that it doesn't even try to determine whether it's really "last modified 2 years ago, except for a vandalism+revert/interwiki bot edit/minor punctuation adjustment 3 minutes ago", as that would require far too much effort downloading past revisions. Anomie⚔ 14:54, 1 November 2009 (UTC)

That's awesome Anomie, thanks! Looks nice. This would be nice to include in gadgets. I still think it should be considered as an across-the-board implementation though, in MediaWiki. Equazcion (talk) 15:51, 1 Nov 2009 (UTC)

Isn't that the spot where coordinates are usually located btw ? —TheDJ (talk • contribs) 16:24, 1 November 2009 (UTC)

Yes, it is. I just went with the positioning suggested above, if someone has a better suggestion I'll see about changing the script. Personally, I wouldn't want that to be enabled for everyone, but it should be easy for someone to gadgetify if there is sufficient demand. Anomie⚔ 18:18, 1 November 2009 (UTC)

Shouldn't we instead be encouraging readers to check the history of a page to ensure that A) It is up to date, and B) hasn't been vandalized seconds before they load it? This is the reason wikipedia is looked at as semi-untrustworthy: because you never know when you are viewing a vandalized page - Unless you check the history. - ʄɭoʏɗiaɲ ^τ _¢ 18:51, 1 November 2009 (UTC)

As a frequent disambig fixer, I am quite certain that the date or time of the last edit often bears no relation to the degree to which the article is up-to-date. I'm sure I've made edits where the only thing I was doing was fixing a disambig link to an article that otherwise had not been touched in years - but it now indicates that it was edited very recently. bd2412 T 02:57, 4 November 2009 (UTC)

Improve the external links section

Hello,

I recently had the pleasure to talk with the former chair of the board of Wikimedia Foundation Anthere. I explained the interest of having the Webzzle Explore permalinks (or button) in Wikipedia pages and now we would like to get your opinion regarding this value proposal.

To show you a demo of what it could be with your agreement, we added the links to 2 pages in French and in English. Please keep them for the next 15 days in order to discuss the topic together.

English http://en.wikipedia.org/wiki/Champagne_%28wine%29 http://en.wikipedia.org/wiki/Champagne,_France

French http://fr.wikipedia.org/wiki/Vin_de_Champagne http://fr.wikipedia.org/wiki/Champagne_%28province%29

Either you find it interesting and we can work together to improve Webzzle, either you do not like and we won't go further with Wikipedia.

We developed Webzzle for 4 reasons:

- 1 - Extend the use of Wikipedia. With the Webzzle Explore feature in a Wikipedia page, the Wikipedia editors can add more value to their content and offer the end-users the possibility to find more related relevant knowledge regarding the topic of the Wikipedia page.

- 2 - Improve the relevance of external links. Webzzle ranks external links using a new "mutual-rank" technology. Webzzle uses concepts, Objects and Objects Structures instead of keywords and list of keywords to describe a content. Each action of a contributor is used to score a content. By analogy, It's similar to the Google PageRank but in 2 dimensions (URLs and Users). The score of a URL is calculated using the scores of the users who qualified it and the score of a user is calculated using the scores of the URLs he qualified. It's a virtuous system solving the problem on how to score URLs and Users in a social network. We work on that since 1999. The technology has been developed by a start-up and used at the CNRS (National Center of Scientific Research, as famous as NASA in France) to qualify and find expertise, document and Web resources regarding a specific topic. Like a mutual insurance business, our ranking technology works very well if they are more community users than spammers per topic as it should be the case if you like Webzzle. The quality increases as the number of users and URLs increase.

- 3 - Reduce the work of editors. A link qualified with several concepts can be relevant to other Wikipedia pages automatically. Editors can benefit from the work of other editors without doing anything. The more editors will qualify links in Webzzle, the less the workload to maintain external links will be and the best the quality will be.

- 4 - Remove spammers from Wikipedia. Today, commercial sites want to appear in Wikipedia to benefit from the traffic. Instead of removing these sites from Wikipedia all the time, we propose to put them in Webzzle. If these links are good, they will naturally get a good Mutual-Rank score. If they are bad, they will not be presented in the first results (after some run of the mutual-rank algorithms). FYI, most of the links in Webzzle today come from a virtual Webzzle user. We use this user to fight spammers too. This user has the ability to be over-weighted in order to increase the quality. We also have a “Trust-Rank” mechanism used to put to 0 the score of a user acting as a spammer.

The Webzzle technology is patended. The technology is free to use for non-competitive projects.

We look forward to having a positive talk with you. Xavier Vaucois. xavier (dot) vaucois (at) webzzle (dot) com

I'll just say this seems like a solution in search of a problem. Effectively wanting editors to outsource these things to a third-party does not help the ideas of generating a free (as in speech) encyclopedia. Q ^{T C} 08:01, 2 November 2009 (UTC)

Agree with OverlordQ on this one. Also, if the software isn't open source, you'll have a hard time convincing the community to jump on board. We're rather leery of non-free (Speech & Beer) solutions to problems. 76.123.56.217 (talk)

I'm also really unclear what this is solving. Aren't we just introducing a link guide this way ? —TheDJ (talk • contribs) 12:04, 2 November 2009 (UTC)

Since the Webzzle link in Champagne (wine) has been reverted twice:

• Webzzle Explore Feature to discuss in the Village Pump (http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Improve_the_external_links_section)

This results in a bunch of links, similar to most search engines. I poked around, but I don't see how these links are generated or ranked, so I don't see anything that differs from Google or Bing. We do often link to pages in the Open Directory Project, which is clear in how links are added and allows folks to suggest or change links. I just don't see the use or advantages. ---— Gadget850 (Ed) ^talk 12:48, 2 November 2009 (UTC)

It seems like the point of this is to add spam for this "Webzzle" rather than remove it. This thread on wikitech-l may also be relevant. Anomie⚔ 13:32, 2 November 2009 (UTC)

I am here to discuss with you. I posted this long message just to explain and invite discussion following a constructive talk I had with Anthere. DMOZ has links in the same manner as Webzzle. In our case, the links are set by editors (with the Save feature you can find on our site). I think DMOZ is a directory that was good, that ages now and that does not benefit from the effort of qualification of editors. We propose to build a collaborative system benefiting from new mutual-rank technology, a kind of DMOZ using collaborative technologies and Google ranking technologies if you want. Regarding patents, I gave them away (public domain). Anyone can use the technology. I put that sentence because I wouldn't like to see a dishonest person doing a Web Explorer based on the same technlogy. It's also very important to understand "why use Webzzle?". Me too, I use Google. But what do you do to go on the Web from Wikipedia in general ? On our side, we go back to Google and launch several combinations of different keywords and open many useless pages. With Webzzle we could enjoy the benefits of the work of editors through a "Social Search" if you want. There would be an engine not to get on Wikipedia, but leave with more quality. It's a new use of Wikipedia. Regarding spam, I repeat that if the editors qualify the links in Webzzle, the real spammers will not be presented thanks to the mutual-rank technology. Finally, since the time of the link on Wikitech, I had the chance to explain at least to Anthere and this is why I propose to talk about the interest of Webzzle for editors and end-users today. Don't you really think the value proposal is not worth for editors and end-users ? Webzzle

We are having the beginning of a good talk on the french bistro. On the English version, is anybody interesting in having a new section in Wikipedia to put DMOZ and Webzzle links ? Does anybody want to experiment a demo with me ? 12:53, 5 November 2009 User:88.166.5.153

Webzzle

Disambiguation pages are not articles

Per Wikipedia:What is an article?, disambiguation pages are not articles. But why do we continue to count them as ones?? This has been brought up before and garnered support and concensus, but never implemented. I believe they can easily be counted separately from actual articles by adding a tag such as #DISAMBIG, just like #REDIRECT. These can simply by transluded through the templates on ever dab page identifying it as such. Can we please implement this to prevent us from continuing to believe that dab pages are articles? Thanks, Reywas92^Talk 00:30, 2 November 2009 (UTC)

What's the practical issue at stake here? Are you concerned about the total article count that Wikipedia claims? Or what? Equazcion (talk) 00:35, 2 Nov 2009 (UTC)

Who says we are counting them as articles? AFAIK they already aren't, so I'm not sure what you mean. PC78 (talk) 00:37, 2 November 2009 (UTC)

Disambig pages are not counted as articles currently. MediaWiki:Disambiguationspage details the templates which place disambiguation pages into Special:Disambiguations, which again, aren't counted toward current article count. --Izno (talk) 00:42, 2 November 2009 (UTC)

Well I thought they still counted at Special:Statistics and other counts. Can you point me to a discussion or other page that says that? They show up at Special:Newpages. And Special:Disambiguations lists articles that incorrectly link to a dab page, not dab pages themselves. Reywas92^Talk 01:07, 2 November 2009 (UTC)

You are mistaken. As reported at Special:Statistics and in {{NUMBEROFARTICLES}}, "content pages" are every page in a content namespace (for enwiki this is just article space) with length greater than 0 and which is not marked as a redirect. There is no exception in code [7] for disambiguation pages. Dragons flight (talk) 02:39, 2 November 2009 (UTC)

An issue here is that while redirects have a clear technical meaning in all wikis, the concept of "non-content" article space pages (such as disambiguation page, index pages, list pages, or other things) currently has no clear definition in the database. Instead it is a purely content based distinction created by local contributors. This means that as one moves from one wiki to another, one may encounter different expectations about what should count as a "content" page. A label like #DISAMBIG might make sense here, but it wouldn't make sense on site not using disambigs. A more general label like __NOTCONTENT__ might makes sense. Developers generally would like solutions to be broad enough to work for all Mediawiki wikis. For the sake of argument, suppose we were to create a NOTCONTENT flag, are there uses for this other than the article count? Dragons flight (talk) 10:10, 2 November 2009 (UTC)

In defense of disambig pages, they're almost articles: they contain visible, encyclopedic content, including wikilinks, see-also sections, sometimes contain footnotes, infoboxes, and sister project links, and except for the additional MOS rules, we write them the same. None of that applies to redirects. • Anakin ^(talk) 16:12, 3 November 2009 (UTC)

Disambig pages should not contain infoboxes or footnotes. The full guide is at WP:MOSDAB. They're meant to be as simple-as-possible, purely a signpost at the crossroads.

I've replied further to Dragons flight at his talkpage. -- Quiddity (talk) 19:17, 3 November 2009 (UTC)

Well some do have infoboxes. Personally think I they're better for it. See Connor for example. The alternative is to split it into two (three?) articles, which seems less navigable. • Anakin ^(talk) 21:02, 3 November 2009 (UTC)

That's a disambig page mixed with a {{surname}}/{{given name}} page (hence containing Name infoboxes). WikiProject Anthroponymy advises us to list them at Wikipedia:WikiProject_Anthroponymy#Splits_from_disambiguation_pages after splitting, or add them to Category:Disambiguation pages in need of being split.

The WikiProject Disambiguation says "These are also not disambiguation pages, although short lists may be embedded on disambiguation pages until they are long enough to split off." Opinions vary, on how long is "long enough" ;) -- Quiddity (talk) 22:22, 3 November 2009 (UTC)

I understand now. Thanks for the links. • Anakin ^(talk) 15:11, 4 November 2009 (UTC)

Random article suggestion

It would be cool if we could edit the random article link to only give us random article in categories we like, or areas we like to help out. like if we are on the welcoming committee, random unwelcomed user.Accdude92 (talk to me!) (sign) 14:43, 3 November 2009 (UTC)

If people seem unwilling to respond to this proposal, be assured that it is most likely not because they disagree with it per se, but that it has been looked at in the past and, as of now, there exists no sufficiently "clean" way of implementing this in the current software structure. Or, I believe not, anyhow. - Jarry1250 ^{[Humorous? Discuss.]} 17:34, 3 November 2009 (UTC)

It sounds like an interesting job for an outside website to do, rather like the suggesting some music based on your past selections. Probably not something the man and a dog running wikipedia would want to get involved in though. They always have the search box for straightforward things they are interested in and then click on see alsos. Dmcq (talk) 17:42, 4 November 2009 (UTC)

Butchering of whole sentences (with sources) just because someone didn't think they "looked" right

I refer to the butchering of whole sourced sentences from introductory passages - or otherwise - that someone - often very frequent visitor of a page - comes in, deletes completely and puts as a reason "it was too long for the introductory paragraph" or "it doesn't look right there".

example: http://en.wikipedia.org/w/index.php?title=DNA&action=historysubmit&diff=323590547&oldid=323556736

If you think you are so right about it, then at least incorporate it to the rest of the article (since it wasn't redundant). Butchering whole sentences just because someone didn't think they "looked" right or even when they don't perfectly follow etiquette of positioning in the article but when they are sourced and not redundant should be an "offense".

This is not about a single occurrence, this is a trend, I don't refer to the above example or the above individual, but to the trend having people watching pages and deleting indiscriminately sourced information just because it doesn't "look" right. I suggest a rule denying that.

The excuse "it didn't look right there 'cause that etiquette rule says so I blatantly delete sourced information that isn't redundant should stop. Sure, wikipedia has plenty of editors and someone may eventually come and make a perfect submission obeying every single etiquette but having such a large group of elitists deleting sourced information just because it didn't "look" right, it drives people away from wikipedia, it brings its work back and in the end it destroys its productivity.

As in evolution in nature, there is not "perfection form the drawing board", evolution is a process of amendment. --fs 17:03, 3 November 2009 (UTC)

It looks like the sentence that was "butchered" was added by you in the previous edit [8]. I have never been involved with that article at all, so I can give an outside opinion: it does look like the sentence you added is out of place in the lede. Especially with well-established, long articles (DNA is 97kb), new additions need to be carefully integrated into the article, not simply added to the lede. Otherwise, articles get "overgrown lede syndrome", like a tumor on the side of a tree.

Now that the text you added has been removed once, I would suggest discussing your proposed addition on the talk page. But do try to find a way to integrate your addition into structure that has already been developed for the article, rather than simply ignoring that structure. — Carl (CBM · talk) 17:13, 3 November 2009 (UTC)

Also as an outside opinion, such a lengthy remark to make the basic point that the analogy is not perfect seems excessive. Analogies are never perfect and rational readers will understand this. I think that editors are obliged to treat such contributions respectfully, but not required to work them into the structure of an article where its not clear that they would be useful at all. I think Tim Vickers did a good job in this instance. Christopher Parham (talk) 21:05, 4 November 2009 (UTC)

Proposed original songs based on daily Today's Featured Article

I'm interested in starting a podcast of original songs written for kids and families, and in which I would write and publish a new song each day. I though it would be interesting for each song to be inspired by whatever happens to be Today's Featured Article at Wikipedia.

Naturally, I could simply do this and leave it at that. Recalling "In Popular Culture" sections from many Wikipedia articles, it occurred to me that this might be a possibility here, adding mention of the song in the featured article itself. I'd imagine doing so in a way that was consistent across the articles but also, of course, in conformance with Wikipedia protocols.

Yesterday, I contacted Wikimedia Foundation about this, and they told me that the Village Pump was the appropriate place to discuss this, as such proposals are resolved not via email by anyone in particular but, rather, within the community of editors.

They also expressed this concern about a possible conflict of interest, noting that referencing the podcasts in front page content might be seen as promotional. They encouraged me to discuss this here at the Village Pump prior to implementation to avoid my intentions being misconstrued and/or my account being blocked from contributing and/or my website being blacklisted from inclusion on Wikipedia.

I certainly don't want to -- and will not -- do anything that would be contrary to accepted policies, nor anything that would endanger either my account or my website(s). Hence this post, in good faith, to discuss the idea. Any feedback would be welcome. Thanks.

The podcast, fine, but in popular culture sections are sometimes frowned upon (like this...). I think no, since (no offence) the podcast is probably not notable enough to mention without making Wikipedia an indiscriminate source of endless information.--Unionhawk ^{Talk E-mail Review} 19:18, 3 November 2009 (UTC)

I don't think there's anything to prevent you from doing a song on the featured article, or anything else for that matter. However it would probably be better to post it to your own website or something like YouTube, not Wikipedia.--RDBury (talk) 19:49, 4 November 2009 (UTC)

Reliability

I propose a system to address the reliabilty issue in Wikipedia. I got the idea from the OTRS system in Wikipedia. It is something like this:

1. Say that the editors in a talk page agreed that 2+2=4 .
2. An uninvolved admin will close the discussion and create a special template or link for the consensus: {consensus|2+2=4}. The template can only be created or changed by admins (or a new user group).
3. An article can cite the consensus: 2+2=4 <ref>{consensus|2+2=4}</ref>.

Of course anyone can change the article to say 2+2=5 , but the citation will not support their claim.

This in no way should affect the decision to include the statement "2+2=4" in the article. But if it is included ,with the citation, the reader can have more confidance in the inforamation. Sole Soul (talk) 18:23, 4 November 2009 (UTC)

Consensus can change, references should be to reliable sources, not to talk page discussions between editors. Mr.Z-man 19:34, 4 November 2009 (UTC)

It sounds like an interesting idea but I don't think it would be practical for a couple of reasons. First, it would open up the possibility for people to use WP:Sock puppetry to create the appearance of consensus on their opinion and then be able to be able to cite it as a fact according to Wikipedia. Second, talk pages for an article are not necessarily monitored by people who would be qualified and/or unbiased enough to make a reliable determination. For example the statement "Wesley Crusher is a dork," might get a consensus agreement on the List of Star Trek: The Next Generation episodes talk page, but that doesn't imply that it should be cited as a reliable source.--RDBury (talk) 19:38, 4 November 2009 (UTC)

The current ad-hoc system of hidden HTML comments is sufficient for this role and is mostly and should ideally only be used for editorial/non-factual issues, such as sensitive/precise phrasing, choices that are at some level arbitrary (e.g. choice of examples), etc. --Cybercobra (talk) 19:44, 4 November 2009 (UTC)

I oppose this idea as Z-man notes that consensus can change, and the very mention in this proposal that "only admins" could then change the consensus scares the crap out of me. Please remember that administrator=school janitor and nothing more. They clean up our messes but they dont have any real "authority". They arent our superiors and arent here to supervise us, they do what we tell them to do with poweres we give them.Camelbinky (talk) 00:04, 5 November 2009 (UTC)

Agree with others above. In addition, we're supposed to cite reliable sources (i.e., not ourselves (mostly)). Simple clarifications (a paragraph or so) can be given in the usual footnotes, which is more presentable than linking to talk pages. • Anakin ^(talk) 02:18, 5 November 2009 (UTC)

Community lounge

I know Wikipedia is not a social networking site and there is irc and bla bla bla. But some people cant use irc. I think there should be a community lounge where people can just relax, and chat about the things going on Wikipedia. Now to make this different from a social network, subject would have to be Wikipedia related. But here, we could all meet each other and see if anyone has any common interests on Wikipedia. As of now, no one really knows anyone.Accdude92 (talk to me!) (sign) 21:10, 4 November 2009 (UTC)

That's what IRC is for. If you don't have a client, java.freenode.net/ \ Backslash Forwardslash / (talk) 21:37, 4 November 2009 (UTC)

Yeah, but some schools block it. And I just want a place where I can chat with other contributers, without getting into trouble with my school.Accdude92 (talk to me!) (sign) 14:39, 5 November 2009 (UTC)

WP:WebCite

I have completed a how-to essay, Wikipedia:Using WebCite, that describes how to use WebCite within Wikipedia. It is an analogue of Wikipedia:Using the Wayback Machine. Perhaps people can review it and proofread.--Blargh29 (talk) 01:51, 5 November 2009 (UTC)

3D logo of Wikipedia

May be you have also already wondered what is on the other side of Wikipedia logo globe. It's a bit like a far side of the Moon. Let's discover it. Let's create a fully 3D logo of Wikipedia. Miraceti (talk) 09:44, 5 November 2009 (UTC)

In all likelihood, there's some IP vandalism scrawled across the back. --King Öomie 17:30, 5 November 2009 (UTC)

See Wikipedia:Wikipedia logos#3D Versions, and this recent blogpost a-3d-sign-globe-for-wikimedia, and meta:Wikipedia/Logo and more! -- Quiddity (talk) 18:22, 5 November 2009 (UTC)

A project you might be interested in

Hi. I've recently initiated an informal WikiProject which will, in theory, help to support and rejuvenate the Wikipedia community. I'm looking for a few people to help me get it off the ground, so feel free to join up. Regards, –Juliancolton | ^Talk 17:47, 4 November 2009 (UTC)

The project now has a more defined idea of what we plan to do. Basically, we're calling for individual proposals on how to improve Wikipedia. Please help by posting your new ideas! –Juliancolton | ^Talk 21:15, 7 November 2009 (UTC)

Image Wizard

I propose an Image wizard, to guide a new user through the license options for uploading an image. It would work like the article wizard works, but give options for image copyright tags . For example the first question would be "Did you take the picture?" and then it would go from there (I.E. Was it uploaded by nasa?). This would be an easier way to choose the right option for tagging an image. I feel like our current system (Special:Upload) is to complicated for new users. Tell me what you think! --Tim1357 (talk) 00:35, 6 November 2009 (UTC)

I tried to write a wizard for image copyright licenses once. After twenty pages, I still hadn't adequately distinguished between "free" and "non-free" content; distingushing between "fair use" and "copyvio" would have been a nightmare. --Carnildo (talk) 02:00, 6 November 2009 (UTC)

You should take a look at how Wikimedia Commons deals with their uploads: http://commons.wikimedia.org/wiki/Commons:Upload. Fences&Windows 04:39, 6 November 2009 (UTC)

Isn't that just their version of Wikipedia:Upload? Rd232 ^talk 10:54, 6 November 2009 (UTC)

Oh yes, it is. Well, if editors are ignoring the clear existing guidelines, a wizard won't make a blind bit of difference. Perhaps we should be less tolerant of serial copyright abusers. Fences&Windows 19:51, 6 November 2009 (UTC)

There's an RFC on that very topic: Wikipedia_talk:Contributor_copyright_investigations#Process_board_proposal. But to be fair, both Wikipedia:Upload and Special:upload could be improved substantially in clarity: the former by organising the options more logically, the latter by reducing the "wall of text" effect with better layout and maybe less detail, and by being able have the "Step 1/2/3" descriptions within the form itself (this requires a software change). Rd232 ^talk 10:36, 7 November 2009 (UTC)

Please see Wikipedia:Images for upload. — Martin (MSGJ · talk) 13:01, 6 November 2009 (UTC)

SiteWideMessages

Extension:SiteWideMessages looks like a really cool way to publicize important polls, discussions, and elections. Dismissible notices can be sent out that appear on user talkpages. Multiple ones can be deployed at once, and they can be set to expire after a certain time. Individual messages can be set to only show themselves to admins; that could be used to alert admins when AIV is hugely backlogged, DYK is overdue, etc. Wanna turn it on? — Jake Wartenberg 23:20, 16 October 2009 (UTC)

• Support. Should also help in cases like Flagged Revisions, where the criticism was levelled that people "weren't told". Ironholds (talk) 23:34, 16 October 2009 (UTC)
• That was mentioned in T22458 for a talknotice, but it's once again only aimed for logged-in users, we need something everyone can see (by going to any talk page for example). If we were to use it for specialized things, we'd need a subscription system - not all admins want to get a new message for AIV backlogs for example. Cenarium (talk) 23:36, 16 October 2009 (UTC)

• I don't agree that a subscription system would be needed. A bot posts to AN when DYK becomes overdue despite the fact that most of the people who see it are probably not interested. This is less intrusive and dismissible. And one could opt out of the whole thing with CSS. — Jake Wartenberg 00:06, 17 October 2009 (UTC)

• You'd be surprised to how people react to messages, even the comparatively unobtrusive watchlist notices. A post to AN is nothing compared to a 'you have new messages' prompt then a UTP message, a post to AN is just another edit on the watchlist, nothing particular, or nothing if you don't watch it, not all admins are attentive to what happens on AN/ANI, most are not actually. I'm sure people would seriously be grieved by this, and no CSS magic could help this. Cenarium (talk) 00:18, 17 October 2009 (UTC)

• Besides which it's not really necessary to put messages on 2,000 admins' talk pages for issues that only require the attention of maybe 3. An opt-in list might be good, or perhaps some sort of "shift rotation" (30 admins notified each time)? Equazcion (talk) 00:24, 17 October 2009 (UTC)

• I didn't realize that it triggered the new message bar. Might be best not to use this for backlogs then. — Jake Wartenberg 00:28, 17 October 2009 (UTC)

• This problem could be solved with preferences options though:

1. do not show site messages (default unchecked)
2. trigger the new message bar for site messages (default unchecked, not when above pref checked)

This way we wouldn't need so much a subscription system for specialized messages. But it also means we shouldn't use this for general messages, because then those who do not want to see specialized messages won't see general messages too. So we could use the talknotice for general messages/community announcements (visible on all talk page, not just UTPs), which is visible anyone, and site messages only for specialized messages. I think it's the best approach, in terms of desired effects and technical feasibility. Cenarium (talk) 16:23, 17 October 2009 (UTC)

• Oppose – we have watchlist-notices, and some dismissible site-notices (for charity appeals etc.) – there should not be any more ways to spam users with material. ╟─TreasuryTag►sheriff─╢ 16:30, 17 October 2009 (UTC)
• To resume, support as long as there are the following Special:Preferences (misc) options:

1. do not show site messages (default unchecked)
2. trigger the new message bar for site messages (default unchecked, not when above pref checked)

used as mentioned above. Cenarium (talk) 20:13, 18 October 2009 (UTC)

• Like any power tool, this is likely to be very useful in the right hands and potentially disruptive and dangerous in the wrong hands. Thatcher 17:43, 22 October 2009 (UTC)
• Support I trust sysops to use this only when it is important. It seems to be useful, and a modification to the extension along the line that Cenarium suggested would make it intrusive to only those who want it to intrude on them. NW (Talk) 19:38, 22 October 2009 (UTC)
• We'd need probably a little more support for a site request, I'll go add it to WP:CENT. Cenarium (talk) 16:01, 24 October 2009 (UTC)
• Problem I missed this somehow...but anyway, I'm not going to say 'oppose' officially, but the way it looks, is that the ONLY way you see it is that you actually goto the talk page, right? (otherwise, if it showed a 'new messages' banner it'd render its point pointless). Well yes some people may get a lot, but I for one don't look at my talk page too often, and am sure others are like that too, and could easily miss messages because of this. ♫ Melodia Chaconne ♫ (talk) 18:14, 24 October 2009 (UTC)
  • From the extension page: "Users will be notified they have a new message." Rd232 ^talk 10:43, 28 October 2009 (UTC)
• Support. Seems like a nice tool. Try it, and if it gets abused or there are too many complaints or glitches, turn it off. Fences&Windows 01:19, 26 October 2009 (UTC)
• Support. I think as an extension it should be made to "opt-in", being off by default and set in preferences. I think this is a great idea. I use an admin dashboard, but I think this can be a great enhancement. What sort of protection will be on this? Valley2city^‽ 06:00, 26 October 2009 (UTC)
• Sounds good –Juliancolton | ^Talk 16:19, 26 October 2009 (UTC)
• Support, but opt-in makes it seem a bit pointless. How many people are going to bother? Trust the community to use it sensibly, and allow people to opt out. Rd232 ^talk 10:43, 28 October 2009 (UTC)

• Feature requested, T23377. We can tweak the global preferences in the future. Note that the default is: displayed on user talk pages, but no new messages prompt. Important notices should probably also be added to the watchlist notice. Cenarium (talk) 19:17, 1 November 2009 (UTC)
• Oppose Please god no, as mentioned we already get enough cruft, why force more. And hopefully, they'd ask for more then 12 people to comment before enabling this. Q ^{T C} 03:35, 5 November 2009 (UTC)
• Support so long as there is an opt-out, which should probably address most of the concerns raised by the opposes. --Tryptofish (talk) 23:30, 8 November 2009 (UTC)

Proposal - Bold watchlisting

I've been thinking about this for a while, and I think this will be a great new feature. I think it would a good idea to add an option to the watchlist where you can make certain pages appear bold (like watchlisted pags appear bold in the recent changes). Here's a sample of what the watchlist may look like with such a feature (feel free to edit):

4 November 2009

• (diff) (hist) (bold) . . Example; 00:00 . . (+111) . . Example (Talk | contribs) [rollback]
• (diff) (hist) (unbold) . . Example bold page; 00:00 . . (+70) . . Example (Talk | contribs) [rollback]
• (diff) (hist) (bold) . . Article; 00:00 . . (+86) . . Example (Talk | contribs) [rollback]

Such a feature would be used when an editor is keeping a closer eye out on one or more particular pages, possibly due to an event, or a large amount of vandalism and/or disruption on a particular page. This feature would also be useful to those with large watchlists.

In the recent changes, bold watchlisted pages may appear bold and italicized.

Any comments or concerns would be appreciated. Cheers, --Meaghan ^{guess who :)} 23:33, 4 November 2009 (UTC)

The idea has merit, but it may need to use something other than boldface for the highlight. There is an existing feature (I can't recall if it's part of the system or if it is one of the many scripts I'm running) that uses boldface for watchlist changes that occur after your last check. Perhaps a colour, or italics? --Ckatz^chat_spy 23:40, 4 November 2009 (UTC)

Yeah, maybe it could use more of an emphasis. Some examples:

Bold and italicized
4 November 2009 (2) (diff) (hist) (bold) . . Example; 00:00 . . (+111) . . Example (Talk | contribs) [rollback] (diff) (hist) (unbold) . . Example bold page; 00:00 . . (+70) . . Example (Talk | contribs) [rollback] (diff) (hist) (bold) . . Article; 00:00 . . (+86) . . Example (Talk | contribs) [rollback]

Bold and coloured in red
4 November 2009 (3) (diff) (hist) (bold) . . Example; 00:00 . . (+111) . . Example (Talk | contribs) [rollback] (diff) (hist) (unbold) . . Example bold page; 00:00 . . (+70) . . Example (Talk | contribs) [rollback] (diff) (hist) (bold) . . Article; 00:00 . . (+86) . . Example (Talk | contribs) [rollback]

Bold and highlighted in yellow
4 November 2009 (4) (diff) (hist) (bold) . . Example; 00:00 . . (+111) . . Example (Talk | contribs) [rollback] (diff) (hist) (unbold) . . Example bold page; 00:00 . . (+70) . . Example (Talk | contribs) [rollback] (diff) (hist) (bold) . . Article; 00:00 . . (+86) . . Example (Talk | contribs) [rollback]

--Meaghan ^{guess who :)} 23:55, 4 November 2009 (UTC)

I like the idea, and of the three examples I like the bold and highlighted in yellow the most. But, um, can you please change the colour of the toxic glow in the dark green headers on those collapsibles right above? I think my eyes are melting in my head right now from looking at it. A neutral earthy tone perhaps? Just anything that isnt so...bright and hurtful! Thanks!Camelbinky (talk) 00:00, 5 November 2009 (UTC)

Sorry, those were just the default colours for the {{collapse top}} template. I've changed them to a light grey. Cheers, --Meaghan ^{guess who :)} 00:26, 5 November 2009 (UTC)

I think they're currently trying to get bold watchlist items to differentiate between which pages you've viewed since the last change and whisch you haven't. They tried implementing it once a few months ago but it was buggy. It may have been put on hold. Something similar to this comes up often -- multiple watchlists, or flags for watchlists, some way for editors to differentiate groups of watched pages. The discussions have so far fizzled out, but I continue to agree that something like that would be hugely beneficial, as some of us have enormous watchlists that could use some form of organization. Equazcion (talk) 00:31, 5 Nov 2009 (UTC)

I am for the highlighting too!  REINCARNUT  (I'm over here) - You gotta do what you gotta do. 08:33, 8 November 2009 (UTC)

Disregard edit conflicts on talk pages

The way in which Wikipedia handles edit conflicts for articles becomes highly dysfunctional for talk pages. We shouldn't be changing each others' talk page entries anyway, so what's necessary when two editors try to change the same paragraph in an article doesn't apply to talk (project, etc.) pages. Why not just show contributions in the order they were submitted (like most blogs, which is not what talk pages are, but how they operate functionally)?

Otherwise, a premium is placed on not considering and composing careful comments, on not previewing or revising one's comments once composed, and in firing off snarky one-line ripostes rather than reasoned rebuttals. In theory one should amend and revise one's comment in light of someone else's near-simultaneous comment, but in practice one soon learns that taking the time to do so during an active debate would just result in every "save" producing yet another edit conflict. I ran into three edit conflicts in the space of 30 or 40 minutes tonight; when editing articles (which, unlike active talk or vandalism-reversion, isn't a real-time process) I may run into an edit conflict once every week or two. —— Shakescene (talk) 07:03, 8 November 2009 (UTC)

• Join in pushing for the quick implementation of LiquidThreads on en.wikipedia, as this is one of the primary issues which it addresses.
  — V = I * R (talk to Ω) 07:14, 8 November 2009 (UTC)
• Also see Bugzilla:4745 Equazcion (talk) 08:02, 8 Nov 2009 (UTC)

  Added to the current WP:DevMemo (Wikipedia:MediaWiki/DeveloperMemo/November2009). Rd232 ^talk 11:57, 8 November 2009 (UTC)

Feedback pages

Thought: we have the {{documentation}} template which creates /doc subpages for templates. We could have a similar template which creates /feedback subpages for Help: pages and perhaps policies and guidelines, using a preload template to provide users with a couple of questions to answer about how helpful it was, etc. This would encourage feedback from newbie users and collect it in one useful place. (Some might say "they can use the talk page", which is true. But the talk page may be full of all sorts of off-puttingly complex discussion, and on high-traffic pages you don't want such feedback disrupting such discussion either. Plus the subpages can have their own category, enabling Related Changes specifically on such feedback, for those interested in following it up.) Comments? Rd232 ^talk 16:01, 5 November 2009 (UTC)

That's a good idea; it's clear we need to get feedback from new users on specific pages or points. But they may still be puzzled by the new environment and hesitant to give feedback. For best results, we'd need an extension for that purpose; the WMF has already organized campaigns for feedback, it can be done. Cenarium (talk) 17:38, 6 November 2009 (UTC)

I had a crack at this - {{Feedback page}}, but I can't seem to make the preload work as expected - it just overwrites the page. I've used just an editintro for now, but that's less useful. Anyone? Rd232 ^talk 14:43, 8 November 2009 (UTC)

Got it. Now in experimental use at Help:Userspace draft. Any, er, feedback on it? Rd232 ^talk 01:36, 9 November 2009 (UTC)

Looks like this:

Rd232 ^talk 10:56, 9 November 2009 (UTC)

Any thoughts on the above template ({{feedback page}})? Rd232 ^talk 16:26, 10 November 2009 (UTC)

It feels like a good idea in principle, but a bad idea in practise. My fear is that it goes the same way as those comments pages we used to use when assessing articles, which just all got deprecated. That said, I don't see why it isn't tried, it could fly. Hiding T 18:36, 10 November 2009 (UTC)

Unlike those comments pages, the feedback pages are clearly aimed at a different audience. I'm not certain it'll work out either, but I think it's worth a try. Rd232 ^talk 09:20, 11 November 2009 (UTC)

I've made significant changes to the template, hope you concur. I moved it to {{leave feedback}} and now, {{feedback page}} can be used at the top of feedback pages (needs some work I think). {{leave feedback}} uses options, link for a simple link: , coord for the link within span "coordinates", and section for the section as above. It can use specific editintros and preloads. Cenarium (talk) 02:13, 11 November 2009 (UTC)

Yes, that's fine, though I don't get the "coords" bit. And the "feedback page" header needs work, I've tweaked it a bit but I can't make the layout as appealing as I'd like. How widely/quickly should we deploy this? Should we use on policy/guideline pages too? Rd232 ^talk 09:20, 11 November 2009 (UTC)

I've planned to modify it so we can use it not only on individual pages, but also for example to get feedback on speedy deletion from templates or messages. We shouldn't deploy it before it's stable enough. What about centralizing all feedback pages as subpages of Wikipedia:Feedback (ex Wikipedia:Feedback/<help pagename>, but also Wikipedia:Feedback/speedy deletion, Wikipedia:Feedback/page protection, etc . Cenarium (talk) 19:43, 11 November 2009 (UTC)

The coord is an alternative form. On certain pages, we won't be able to use a section, though something closer to a pagenotice would be better, but we don't have the functionality. Other forms could be added. As for policy pages, we could consider requesting feedback there too. Cenarium (talk) 19:48, 11 November 2009 (UTC)

There's discussion and coordination at Template talk:Leave feedback. Cenarium (talk) 03:55, 12 November 2009 (UTC)

[simple] button along the top, next to [article], [discussion], [edit this page], and [history] buttons

Add a button to the top of each article that takes the reader to the [simple.wikipedia.org simple.wikipedia.org] version of the article. There are many times when I need to do this, when I am reading about a topic with which I am not entirely familiar. The only way to do this for me is quite clumsy:

C-l C-[left arrow] C-[left] C-[left] C-[left] C-[backspace] s i m p l e .

Compare this to the dialect/script variant conversion buttons across the top of article pages on the Chinese wikipedia.

I think that this would give the simple wikipedia more exposure, which is good because it is a great resource and IMHO it isn't taken advantage of nearly enough.

If consensus is reached against my proposal, then please simply consider this a request for a user script to put in Monobook.js to make this happen. :)

Any suggestions or proposals of variations on this idea are more than welcome. :)

76.190.210.196 (talk) 06:22, 8 November 2009 (UTC)

If there is a simple article for a EN article, it should have an interwiki link, which appears in the list of links on the left side of the page. I don't see any reason to add a more prominent link at the top. This would give Simple inappropriate and undue weight over all other Wiki variations, for no reason I can see. -- AnmaFinotera (talk · contribs) 06:32, 8 November 2009 (UTC)

Well, it is a little different, seeing as they are merely different writing styles of the same, mutually intelligible language. I find that in practice, usually the interwiki simple link doesn't happen. It is very likely that the same people who is on en.wikipedia.org will also find simple.wikipedia.org useful is a lot higher than that of somebody on en.wikipedia.org finding, say, la.wikipedia.org useful. Okay, so that was a bad, straw man example, seeing as latin is a dead language, but you get my idea. —Preceding unsigned comment added by 76.190.210.196 (talk • contribs) 00:43, November 8, 2009

Not really (getting your idea). If the interwiki link is missing, it should be added. There are bots which do it automatically, presuming the article on Simple is named correctly. -- AnmaFinotera (talk · contribs) 06:47, 8 November 2009 (UTC)

(edit conflict) ¶ If the Simple English version of an article exists, then it should already be listed along the left-hand side of the page, together with versions in other languages. See, for example, Manhattan. I'm missing something here, because I don't see the need for an extra tab along the top, especially when I can think of several things where I or others would prefer to see tabs (e.g. view code without editing), but which haven't been tabbed by default because of concerns about crowding. —— Shakescene (talk) 06:39, 8 November 2009 (UTC)

The purpose of the Simple English Wikipedia (supposedly) is to help those with poor English skills, by using a limited vocabulary and simpler grammar. While a simplified covering of the topic is possibly a side effect of that, its not the intention, and its more likely a result of the article just being shorter and less-developed. Mr.Z-man 07:54, 8 November 2009 (UTC)

I think that there is a difference between the relationship between English and Simple English and with the other languages. I'd not mind maybe seeing Simple English italicised or bumped to the top or bottom of the interwiki links (and who'd be looking for it under S, anyway)? I don't think another tab would be helpful, there's enough clutter as it is. Pseudomonas_(talk) 16:26, 11 November 2009 (UTC)

Proposal discussion at Wikipedia:Village pump (technical)

A proposal is being discussed regarding an external project's possible access to Wikipedia's data. Please see Wikipedia:Village pump (technical)#DBpedia Template Annotations. Equazcion (talk) 10:59, 9 Nov 2009 (UTC)

ConnectomeBot , semantic wiki and external links

An editor has proposed a bot at WP:RFBA that will put external links in en.wikipedia articles to a semantic wiki on brain connectivity, ConnectomeWiki, related to the ideas and goals described in this (PDF) PLoS article.

This raises some questions that need addressed first by a wider community.

1. The basic appropriateness of the links for wikipedia. It appears, due to the specialized nature of the topic matter, that the substantive value of the links would have to be discussed with neurology or physician editors. Should the quality of the underlying links be discussed at WT:WikiProject Neuroscience, WT:WikiProject Anatomy, or WT:WikiProject Medicine/Neurology task force or some other place?
2. One editor suggested the proposal appears not to "run afoul of WP:ELNO," while another user calls the links essentially SPAM to the from en.wiki to the outside wiki.
3. The editor proposing the links is doing it for a project, and describes himself/herself as a student at the Institute for Neuroinformatics in Zurich. He/she is the sole person with a stated interest in the project, so far, and has made some links already (not with a bot) from wikipedia to the ConnectomeWiki in brain articles on Wikipedia. See the links and the user's edit history.
4. Are there additional issues that need to be discussed?

Does anyone have comments about this. I am posting this in two places (here and VPR), thus far, but it should be discussed only in one place, here. (Of course, if this is the wrong place, feel free to move as necessary.)

This entire conversation will be referenced when WP:BAG decides whether or not to authorize the bot, but, if you have comments purely concerned with technical issues on the bot that are best addressed at BRFA, please feel free to comment there, of course. Thanks. --IP69.226.103.13 (talk) 03:14, 10 November 2009 (UTC)

Connectome Discussion

Please discuss the issue, including your support or opposition and reasoning.

• Comment The changes so far have added a "ConnectomeWiki" parameter to occurrences of {{Infobox Brain}}, and that template was edited so the parameter would link to a suitable page at www.connectome.ch. However, the edit to the template was reverted ("revert EL link without discussion"). I am not ready to express an opinion, other than that suitable projects need to discuss the issue before the template includes an external link. Johnuniq (talk) 04:05, 10 November 2009 (UTC)
• Oppose.WP:ELNO, WP:NOTLINK and WP:RS for starters. Un-impressive site statistics. Only been around since 9 September 2009[9]. There are 5 registered Users (only 2 look like actual humans). Content is scrapped by Automated import of articles(via. ConnectomeBot). Unidesigner (talk · contribs) is not active in any of the purported projects, other than canvassing/promoting this topic, and has made no edits other than related to connectome.ch. I expect this site will soon be riddle with adsense and advertising, monitized by leeching wikipedia for traffic. Just another spambot intended to use Wikipedia as a "vehicle for advertising".--Hu12 (talk) 07:02, 10 November 2009 (UTC)
• Support. I'm the operator of ConnectomeWiki, registred at Wikipedia as Unidesigner. Let me comment on the points raised by Hu12.--Unidesigner (talk) 11:01, 10 November 2009 (UTC)
  • It is still early days for the ConnectomeWiki. I usually create the pages in text, write a python scripts and use ConnectomeBot to insert the pages. Starting date September 9th is a bit delusive since I already worked on the content starting early 2009 and we had to resetup the wiki because of an attack onto our servers.
  • There are not yet many users, mainly because the project is not yet advertized officially, no papers published. As a matter of fact, the ConnectomeWiki serves as a extensible knowledge-base for the ConnectomeViewer application for structural neuroimaging research.
  • I had to fight adsense and advertising in the beginning and so we decided to require an account to make changes. Also to allow for better recognition of the contributing authors.
  • So far content is concerned, on one hand, we are trying to be a hub for other diversely spread projects in brain connectivity research. Thus the many links to other databases. In this sense, we are web scraping, also inserting from other pages data if possible and only after proper discussion with them. E.g. Neurolex for the brain region hierarchy, Songbird brain connectivity, Temporal lobe connectivity in rats. Currently we are in a discussion with Elsevier to insert macaque brain regions and their references from the Logothetis&Saalem atlas. On the other hand, annotating semantic properties may turn out very useful in this field.
  • One of the main assets is the extraction of brain connectivity information from published papers. So an author has a highly selected list of related publications to a specific connectivity which will be managed by experts in the field.
  • Being secondly affiliated with the University Hospital Lausanne, Switzerland: parcellations of the brain according to the PLos paper were also inserted, and this are linked with the ConnectomeViewer, and be used in the future.
  • I'd welcome very much a wider discussion in among neurology & physician editors if possible.
• Comment: Concerning the ConnectomeBot, I would like to insert links in the Brain Infobox template pointing to the appropriate page in the expert semantic wiki ConnectomeWiki. Approximately 250 pages would be tagged, for Homo sapiens brains.--Unidesigner (talk) 11:05, 10 November 2009 (UTC)
• Premature: We have no reason to treat the Connectome data as a WP:MEDRS. The PLOSMed paper speaks to the need for something of the sort, not to the present, incompletely implemented system. The linking and discussion of any possible bot should be shelved until there are published reviews showing the Connectome content to be trustworthy.LeadSongDog come howl 16:49, 10 November 2009 (UTC)
• Premature: We are already making use of another neuroinformatics system, the NIF / NeuroLex framework being developed under auspices of the US National Institutes of Health. I don't think we should add links to another system unless there is clear evidence that it will reach a comparable level of sophistication. The best thing would be for ConnectomeWiki to be integrated into the NIF system, which as I understand it is highly flexible. Looie496 (talk) 18:38, 10 November 2009 (UTC)
• Strongly oppose I am generally opposed to any bot which links externally unless it can be shown that every possible link that it would employ would be both acceptable and relevant. Anything less would create a cleanup hassle. If any external links are relevant to an article they should be placed by hand. If the Wiki is a reliable source then it can be referenced by hand. Most of the links that the bot places won't be needed if these articles were to attain featured status, so they counteract ELNO #1. I also sympathize with Hu12's assessment of this situation as attempted spamming. ThemFromSpace 03:56, 11 November 2009 (UTC)
• Comment Okay, I accept your opposition. Thanks for the discussion and best of luck for the continuation of the great Wikipedia. --Unidesigner (talk) 09:25, 11 November 2009 (UTC)
  • Please feel free to revisit the issue in the future if the Connectome wiki becomes a stable and well-used resource with independent references to it. Thank you for being straight-forward and transparent in your approach to this task. --IP69.226.103.13 (talk) 09:38, 11 November 2009 (UTC)

Previewing references

So, it happened again. I add a bit of info to an article, complete with reference, preview to check that the info is fine, save -and find I've stuffed up the reference. Is there any way of making it so that the preview edit window also previews any references shown? So that, say, if you're editing one section of an article, you'll get a preview of that section and also of the reference list showing the references within that section? Grutness...wha? 23:53, 4 November 2009 (UTC)

You could add a dummy References subsection or tag while previewing, then remove it before submitting. --Cybercobra (talk) 00:14, 5 November 2009 (UTC)

Mmmm, yeah - that'd do the trick. It's a bit of a kludge, perhaps, but it would work. Thanks. Grutness...wha? 00:39, 5 November 2009 (UTC)

I agree it would be quite nice if there was a more integrated way to do it. --Cybercobra (talk) 02:07, 5 November 2009 (UTC)

Great tip though! I'd not thought of that. Fences&Windows 02:23, 5 November 2009 (UTC)

Actually, neither had I until just now. Funny how the mind works. --Cybercobra (talk) 02:30, 5 November 2009 (UTC)

There is at least one user script that does something like this. Anomie⚔ 02:41, 5 November 2009 (UTC)

This is a feature I would like to see added as well. You should submit a request. Rmhermen (talk) 02:33, 5 November 2009 (UTC)

I use Anomie's script, although it does not work with list-defined references. ---— Gadget850 (Ed) ^talk 10:46, 5 November 2009 (UTC)

How so? Anomie⚔ 17:30, 10 November 2009 (UTC)

• You can always not add the ref tags either, until after the preview. Hiding T 13:54, 10 November 2009 (UTC)

Try using substitute tags like sup^{Author Name. Book Title (printing/release date). Publisher. ISBN or similar. Page or pages.} converting them to refs before you save. -- allen四names 19:53, 11 November 2009 (UTC)

There's a script written by John Vandenberg based on an original script by a German editor ParaDox, at User:FT2/scripts/previewrefs.js. It's not perfect, but largely does the job. If someone wants to improve it and add it to the built-in gadgets.....? FT2 ^{(Talk | email)} 10:17, 12 November 2009 (UTC)

Set interests to sort information faster

Just a thought; I study biology and very often when i am on a disambuguation page, especially regarding an abbreviation, my interest is in biology. It sometimes takes a little while before i find what i look for. So i thought that it would ease my wikipedia surfing if i could set biology as my like main interrest, and maybe history as my secondary interrest and so on, and disambiguation-pages would sort the alternatives on disambiguation-pages and "search results"-pages depending on my interrests when i am logged on. Since most articles are tagged it seems alot of the work is already done, and when wikipedia becomes more and more complete the main problem would be to sort information to find the stuff that is relevant for you and sort away the irrelevant information.— Preceding unsigned comment added by 85.225.229.227 (talk) 21:25, November 10, 2009 (UTC)

Disambig pages aren't generated dynamically. The text on those pages are entered in by people, just as all other pages are.

It is possible to change them to dynamic pages and for a system such as what you are describing to exist, but... well, it would need to be developed first (and we'll completely ignore the performance issue that such a system could cause on a site this large).
— V = I * R (talk to Ω) 07:02, 12 November 2009 (UTC)

Create a How-To namespace

I just recently read something by a fellow editor who I respect, and it reinforced a view that I had myself. Therefore, I wanted to re-post the quote and create a proposal which related to it:

So I'd say that really, we need to split things better. For instance, make the Help: pages aimed very clearly at newbies - just simple and not too scary or detailed; focus on links. Where there's technical complexity, find a way of putting it somewhere else, eg a help page with a related name focussing on the technical, or on a subpage, linked from a section at the bottom. Keep guideline stuff separate. In the example kicking off this thread, Wikipedia:Images, the actual guideline stuff could boiled down to a paragraph, and the rest moved to a help page.

— Rd232, from [10]

Along that veign of thought, I'd like to propose a "how-to" namespace (or "howto"?). I think that this would make organization and maintenance easier to accomplish, despite the fact that it will invariably create more project pages. What do you think?
— V = I * R (talk to Ω) 11:52, 13 November 2009 (UTC)

You mean literally a new namespace (so howto pages would begin "Howto:...")? I'm not sure how it would differ from the Help: namespace - you mean that Howto: pages would be more advanced than Help: pages? (I'm not sure the difference is fundamental enough to require a new namespace, but some sort of clear division of pages by target audience might certainly be useful.)--Kotniski (talk) 12:00, 13 November 2009 (UTC)

What exactly is the Help: namespace for? My limited impression was it was aimed at helping readers use the encyclopedia (e.g. "here's how to make your browser display this foreign language properly"). --Cybercobra (talk) 12:21, 13 November 2009 (UTC)

To be clear, I am proposing a "literally new namespace", so that yes we could create "howto:" pages. I wouldn't characterize the resulting pages as "more advanced" then help pages are, but they would occupy a slightly different functional place. When I think of the "howto" type of namespace, I think of a quickstart style of documentation. There is a difference and a desire for both a more comprehensive "help" documentation, and a "just tell me what I need to know now" style of "howto" documentation. That's what I'm proposing, is a namespace to hold the "just tell me what I need to know now" style of docs.
— V = I * R (talk to Ω) 12:29, 13 November 2009 (UTC)

The problem with a "How-to" namespace is that it would serve as an open invitation to create video game cheat guides, recipe collections, and a host of other items prohibited by Wikipedia:What Wikipedia is not#Wikipedia is not a manual, guidebook, textbook, or scientific journal (WP:NOTHOWTO). "Help" is a common term for access to a software system's on-line manual/documentation, so there is no reason not to use the existing namespace. --Allen3 ^talk 12:38, 13 November 2009 (UTC)

Well, it could be Help vs Help-For-Beginners, or Help vs Advanced-Help, or Help vs Documentation/Handbook; there are plenty of variants in what we call it, but whether we need it or not needs to be decided first. Pseudomonas_(talk) 12:44, 13 November 2009 (UTC)

I'm not sure that a new namespace is justified, but if so, it should be Help: (for newbies) vs Manual: (for tech details), with clear links between their pages as appropriate. Rd232 ^talk 12:41, 13 November 2009 (UTC)

eh... no offense is intended here, and I'm not intentionally being flippant about this, but personally I tend to reject this line of (what I'm willing to admit is a reasonable concern) reasoning against. I don't say this out of hand, but I think (assume may be usable here) that the normal level of vigilance which we collectively assign to the Wikipedia and Help namespaces now will "natually" alleviate these concerns. (is that enough passivity for everyone?)
— V = I * R (talk to Ω) 15:23, 13 November 2009 (UTC)

I agree on the desirability for having demarcated simple (preferably requiring no previous knowledge of other Wikipedia material - far too many of the pages require you to read five other pages before they make sense) guidelines/instructions for new users performing common tasks, and a separate namespace could be a way to do it. Though if I can hobby-horse briefly, we probably want to have a small amount of material, not a namespace's worth. There's far far too much at the moment for a newbie to take in. I made an attempt at drafting something for newbies, although even that is probably too long. Pseudomonas_(talk) 12:27, 13 November 2009 (UTC)

We already have the system needed: Help pages for newbies go into "Help:" space. And more in-depth technical how-to guides go into "Wikipedia:" space and are marked at the top of the page with the {{how-to}} box. See for instance the two technical how-to guides Wikipedia:Category suppression and Wikipedia:Line break handling. No need for a new namespace.

Although I see that the people over at Wikipedia:Help Project want to move all the how-to guides into "Help:" space. That could work too, as long as the technical how-to guides still are marked as such.

--David Göthberg (talk) 12:46, 13 November 2009 (UTC)

David is correct. Most How-Tos are in Wikipedia: space currently anyway and that's one of the reason why we have that namespace. There is no need for a HowTo: namespace, just as there is no reason for a Essay: namespace or a Policy: namespace. Let's try to keep things simple okay? Too many namespaces would confusing. Regards SoWhy 12:53, 13 November 2009 (UTC)

I perhaps agree with that last part, but I don't agree that David is entirely correct - there are many in-depth pages in Help: space too (in fact I believe that namespace was originally created as a dump for software documentation pages, which are certainly not addressed to newbies, and it's kind of evolved randomly since then, with various kinds of pages being added to it, and other very similar ones being added to WP: space). I think the Help project's current plans are the first explicit strategy for tidying this mess, and ought to be generally supported.--Kotniski (talk) 13:18, 13 November 2009 (UTC)

The History of the Help Namespace

The original concept was to have main help pages on MediaWiki. Using templates, the MediaWiki content would be transcluded onto the various Wikipedia pages, then content specific to that Wikipedia would be added to the end of the page. Unfortunately, the MediaWiki pages were never updated and the differnt language versions of Wikipedia began to diverge in many ways. In 2008, this concept was abandoned, and the templates removed and deleted. Help pages have then been updated without regard for the other Wikipedias, but now includes help that is more relevant to en.Wikipedia.

The issues with the Help namespace and how to deal with certain issues is being actively discussed at the Help Project. ---— Gadget850 (Ed) ^talk 14:51, 13 November 2009 (UTC)

I posted a notice about this discussion on the Help Project talk page. I'm somewhat embarrased to admit that I knew nothing about that wikiproject before this.
— V = I * R (talk to Ω) 16:32, 13 November 2009 (UTC)

No embarrasment necessary, we have only been adding the projects banner to pages recently, and it was well hidden amongst the rest of help! There aren't really that many pages in help namespace ([11]), a few new ones to create but considering some can be merged or deleted , so it wouldn't be a problem to accomodate the how-tos. As JoeSmack says - its good to know others are thinking about these issues! Lee∴V (talk • contribs) 20:16, 13 November 2009 (UTC)

From the Wikipedia Help Project

So this discussion here seems particularly relevant to this thread. This table is an example of the challenged faced getting help/how-to/intro/tutorial material from WP to Help space:

Help articles that need attention (edit)

Page in Help: namespace	Page in Wikipedia: namespace	Comments
Pages in Category:Wikipedia multilingual support		Should be cleaned up and some possibly merged together.
Help:Diff		As of May 2012, needs updating for the new diff formatting (assuming that doesn't get reverted!)
n/a	Wikipedia:How to edit a page	not very easy to read - ouch!
Help:Account	Wikipedia:Account	No help page exists, WP space one is very TLDR/unfriendly.
Help:Files	Wikipedia:Images Wikipedia:Picture tutorial	unable to locate succint and helpful info on the parameters for using images easily - have found it at Wikipedia:Extended image syntax maybe this isn't linked very well
Help:Files	Wikipedia:Images Wikipedia:Image use policy Wikipedia:Extended image syntax Wikipedia:Preparing images for upload Wikipedia:Graphics tutorials Wikipedia:Captions Wikipedia:Gallery tag Wikipedia:Creation and usage of media files Wikipedia:Finding images tutorial Wikipedia:Uploading images Wikipedia:Ten things you may not know about images on Wikipedia Wikipedia:Picture tutorial	A lot of image pages with various amounts of duplication.
Help:Footnotes	Wikipedia:Manual of Style (footnotes)
Help:Wiki markup		could do with making both simpler and more comprehensive!
	Wikipedia:Starting an article Wikipedia:Article creation Wikipedia:Your first article	3 pages on starting an article

This table outlines some of the redundancy (and quite frankly, the shitty help support we have for new editors). We've been working on the dividing line between WP space and Help and what it should look like, how we should judge importance for the help pages, etc, here. Basically, there is a looooot of potential to help, and feels like me and a couple of other editors we're alone to discuss/do this, so I'm glad there's more interest right now! JoeSmack ^Talk 18:16, 13 November 2009 (UTC)

Minority-majority interplay on Talk pages

An essay has been drafted that concerns the treatment of a minority group proposing an addition to a Main page that is not favored by the majority of editors contributing to the article. Please comment. Brews ohare (talk) 17:23, 10 November 2009 (UTC)

I've been here a short time yet I've been involved in a few of these already. Not sure the reference to WP:BATTLE adds anything. WP:BFD, WP:JUSTA, WP:AGF, might be more useful. Maybe one should question even assuming or thinking along the lines of there being a majority or minority is counterproductive. Default should be that everyone is there to improve the article. Maybe also a discussion on the limitations of WP:IAR. Also a discussion on the preferred method of dispute resolution. I'm right now in the middle of trying to figure out if RfC is of any use whatsoever or just a long slow boat to nowhere and would like to know the answer if you have it. 2 edits. Lambanog (talk) 18:22, 14 November 2009 (UTC)

Button for grammatical info in lead section

(The graphic appearance of the "grammar-button" in the examples for this proposal is only a makeshift solution; if the proposal is accepted then a better graphic solution must be devised before implemented. Also for the technical implementation a much easier solution must be found, probably with js.)

Although Wikipedia is not a dictionary, grammatical information (etymology, plural etc.) is still desirable, but in the lead section when very long it compromises readability. I'd like to suggest an optional button, perhaps reading "grammar", which would work similarly to a "collapsible collapsed" table, only inline, i.e., within the paragraph: the extensive grammatical information would then be shown when the button is clicked. See examples below and HERE (or here for IE). As said, a better graphic solution must still be devised, especially only one word would suffice (without the "[show]"), and implementing must be made simple (some js and template programming will be necessary). Also the IE-bug concerning the "inline-table" css property would have to be solved.

Example using lead section for cathetus:

Cathetus (existing appearance)

In a right triangle, the cathetus (originally from the Greek word Κάθετος, plural Κάθετοι; its plural in English is catheti because it comes more directly from the Latin transliteration cathetus, whose plural is such), most commonly known simply as a "leg" is either one of the two sides which are adjacent to the right angle in a right triangle.

Cathetus (modified appearance – Mozilla, Chrome etc.)

In a right triangle, the cathetus

grammar
originally from the Greek word Κάθετος, plural Κάθετοι; its plural in English is catheti because it comes more directly from the Latin transliteration cathetus, whose plural is such

, most commonly known simply as a "leg", is either one of the two sides which are adjacent to the right angle in a right triangle.

Cathetus (modified appearance – IE)

In a right triangle, the cathetus

grammar
originally from the Greek word Κάθετος, plural Κάθετοι; its plural in English is catheti because it comes more directly from the Latin transliteration cathetus, whose plural is such

, most commonly known simply as a "leg", is either one of the two sides which are adjacent to the right angle in a right triangle.

View other examples here or for IE users here. Dan ☺ 18:28, 14 November 2009 (UTC)

And when you print the page? View it with a screen reader? See MOS:COLLAPSE. If the material is long enough to affect the readability of the lead, it should be moved into its own section. Happy‑melon 21:23, 14 November 2009 (UTC)

For printing etc. the default should simply be set to visible (and the button itself should be invisible). A more elaborate solution could create a footnote maybe. And I agree, with no collapsibility, the grammatical information in many leads should be repositioned outside of the lead. Dan ☺ 23:24, 14 November 2009 (UTC)

In that case, why not just use a footnote in the first place? Anomie⚔ 01:41, 15 November 2009 (UTC)

Well (grunt) I read about the collapse policy, a policy of which I wasn't aware and with which I don't agree, since it takes as a given that Wikipedia should be static – how many times out of a hundred is Wikipedia used in printed or other static forms? This is primarily an internet encyclopaedia. Actually, does anyone know any statistics? But that discussion doesn't belong here. I don't intend to challenge this notion any time soon, and (sigh) for a static Wikipedia this kind of dynamic element is indeed inappropriate. Dan ☺ 21:09, 15 November 2009 (UTC)

Diff rendering

When a space next to a punctuation character is added or removed, it doesn't clearly show up in the diff. In some cases, one has to closely study the diff, escepcially in long paragraphs. (example diff) Maybe the diffs in such cases should be rendered like when a space between two words (without punctuation) is added or removed (example diff)? What do you think? Iceblock (talk) 19:04, 14 November 2009 (UTC)

I would appreciate being able to see what it was, perhaps a different colour could be used to highlight the different spacing. Graeme Bartlett (talk) 21:32, 14 November 2009 (UTC)

I side with that, color up the changed spaces! Dan ☺ 23:16, 14 November 2009 (UTC)

I would like the algorithm to color changes in spaces, and "small" changes (like the addition of a comma). Haven't thought too much about it, but perhaps "highlight if length(change) < 2 or change matches whitespace". Johnuniq (talk) 23:42, 14 November 2009 (UTC)

Personally, I just use the following in my monobook.css:

span.diffchange, ins.diffchange, del.diffchange {
    background:#f88;
    color:#000;
}

This changes it from red text to black text on a red background. Unfortunately, that doesn't work here to highlight space-only changes; on a private test installation of MediaWiki the necessary elements around those spaces are generated fine, but here on Wikipedia they are not present in the output (I think tidy strips them). Anomie⚔ 01:51, 15 November 2009 (UTC)

I use this, which puts a red dotted border around all changes. It makes spotting punctuation changes easier, and I think it also picks up spaces:

.diffchange {padding: 0px 2px 0px 2px; border: 1px dashed red; margin: 0px 1px 0px 0px}

Equazcion (talk) 14:18, 15 Nov 2009 (UTC)

Here's a diff for testing: [12] I don't see the necessary element to indicate the change in the HTML at all. Anomie⚔ 15:58, 15 November 2009 (UTC)

New RC patrolling concept

I'd prefer this system to flagged revisions, simply because we can see a ! directly into the RC list. Moreover, it's already used in fr.w. JackPotte (talk) 19:30, 15 November 2009 (UTC)

Oppose This requires two database hits for each edit, as the reviewer has to report back to the server when the edit is checked. Tim1357 (talk) 01:35, 16 November 2009 (UTC)

WikiContest (or WikiTournament)

Very simple:
The WikiCup is held every year, which may be a very long period (in my opinion). How about an event within a month? (could be also in periods of two or three months). Like the WikiCup, each participant with his flagicon (but in this case, can be repeated). Two categories: minor league —in which only mainspace edits, page creation and minor edits are counted (individually) and major league —in which previous is considered, but also more points for upgrading to featured status, GA, DYK, etc.
Also, contributions to other wikimedia projects could be considered for users with global accounts (to verify the right). These could be uploading images, translations (from or to another language, news, etc...) which may form part of an actual series of contributions to an article here. - ☩Damërung ☩. -- 14:09, 1 November 2009 (UTC)

Anything that encourages article creation is a good idea. I'm all for it. - ʄɭoʏɗiaɲ ^τ _¢ 19:03, 1 November 2009 (UTC)

Yes, I agree, but making a contest/tournament out of it may encourage mass-creation of articles just because a user wants to increase their contest/tournament standings. Besides, Wikipedia is an encyclopedia, not a game site. Guoguo12 (talk) 21:03, 6 November 2009 (UTC)

There is certainly nothing that prohibits someone from setting something like this up. However, it is a lot of work so don't be surprised if no one volunteers to run it. --ThaddeusB (talk) 21:21, 1 November 2009 (UTC)

I can't say I like this idea. I see too many editors getting huge edit counts by adding indiscriminate trivia to articles. This is something to be discouraged rather than encouraged. I agree there is a need for more recognition efforts of editors, especially for some of the more thankless tasks such as fact checking. But I would rather see an award for making a single very good addition rather than 100 bad ones.--RDBury (talk) 20:02, 4 November 2009 (UTC)

These kinds of games should not be encouraged. That one of the goals is to encourage development of articles is a good thing; the notion of awarding people with prizes, even if they are nothing more than a silly graphic to post on their userpage, is not something the project should condone. But I'm just a grumpy fun-hater, so feel free to ignore me :p Shereth 20:07, 4 November 2009 (UTC)

Wowow, now, I never thought or talked about awards... Actually, when I posted this proposal here, I totally forgot about prizes or recognitions. I see you two talked about awards, and now that I think of it, maybe using just the existing awards (if desired) is just fine, I mean, we don´t have to create new ones or neither even give them forcibly. About that thing of the non-totally-enciclopedic edits, well I think it should be encouraged the making of more constructive edits instead of discouraging games which aims to that. But that´s just my opinion of something that I wanted to come up with. More opinions would be also apreciated again. - ☩Damërung ☩. -- 03:51, 5 November 2009 (UTC)

Well, in any kind of contest/game/competition there is an inherent award. To use a broader example, even if the Yankees had not been awarded a trophy for winning the World Series, they would still be awarded the title of "World Series Champion" for the year. A winner of a monthly WikiTournament, even if no one bothers with creating a trophy graphic to paste on their talk page, is still awarded with the title of "Winner of WikiTournament November". That's what I was getting at, really - it is my philosophy that we should not be in the habit of doling out titles/awards/recognitions, particularly when they might be sought out as a reward for winning something. I have no issues with the Barnstars that are granted individually for services already rendered. Again, it's all just my opinion. Shereth 14:37, 5 November 2009 (UTC)

Here's another thought. Some editors have taken it upon themselves to recognize editors that they view as "outstanding" with a Wikipedian of the Day/Month type award. To me this sort of arrangement is acceptable because no one is competing for the title; it is not granted based on reaching a certain set of goals/criteria first (or best), but rather is granted by identifying someone's existing contributions and rewards them for making good contributions without any anticipation of a reward. Therein lies the difference. I'd have no qualms about a group of intersted editors forming a kind of task force to identify good Wikipedians and "reward" them with being recognized as such, but formal competitions are not the sort of thing that I believe should be encouraged. Shereth 14:45, 5 November 2009 (UTC)

A prize, even if it is a fancy barnstar, gives a goal to reach for. Why do we have an edit count? Why do we have barnstars that you "qualify" for by edit count/longevity? Prizes make people feel good, and they drive their ambitions. A prize just gives people, in all their vanity, something to attain. - ʄɭoʏɗiaɲ ^τ _¢ 14:56, 5 November 2009 (UTC)

Perhaps I just prefer encouraging those editors whose goal they wish to attain is a valuable and reputable encyclopedia over those editors whose goal is a userpage full of barnstars and DYK question marks and shiny FA stars ... but again, that's just me :) In my perfect little world there would be no edit counts, no FA stars on userpages ... but I understand Wikipedia is not my perfect little world and that I am probably just being too serious for my own good. Shereth 15:04, 5 November 2009 (UTC)

If Wikipedia only had editors who were working purely out of selflessness, we would not be nearly as successful as we are now; we may not have been successful at all. Mr.Z-man 23:21, 6 November 2009 (UTC)

I think a 'game' like this one is a very good way to encourage editors to make a valuable and reputable encyclopedia. Even if their goal is only to have a barnstar, I don´t care as long as it helps to improve wikipedia. And yes, there are some edits which are not much valuable like the trivia sections, but we could find a way to avoid that and use this game to the benefit of wikipedia. - ☩Damërung ☩. -- 15:04, 10 November 2009 (UTC)

I don't see how a competition of this type can function on a less than a month time frame. In my experience a GA review, from the time requested until completed, can takes over a month. FAC likewise can last weeks. In those circumstances your ability to gain "points" would not be determined by as much by your skill or editting prowess, but by the speed in which reviewers can get to your article, which varies significantly by topic area, especially at GA. —Charles Edward ^{(Talk | Contribs)} 21:22, 16 November 2009 (UTC)

How about this: minor league lasts a month or two. Major league lasts three monts or four. - ☩Damërung ☩. -- 08:05, 17 November 2009 (UTC)

Force preview before saving for new users

I know this is enabled by default on some Wikipedias, but this might work good here, we should force new users to "think" before they hit submit by requiring them to preview their edits before they save their changes. This, along with maybe additional messages that could be shown to new users, could help some of the issues we have with new users, and may slow down the flow of junk in new pages. However I predict downsides, backlash, etc, but if done right, this could be perfect.

Of course by "new" I mean, not autoconfirmed, or specific amount of edits, etc. ViperSnake151  Talk  17:25, 7 November 2009 (UTC)

So let's send a mixed message. I'd rather have to clean up after someone who inserted bold than not have them edit again. :( --Izno (talk) 21:27, 7 November 2009 (UTC)

Please see previous related discussion here and here.--Fuhghettaboutit (talk) 00:59, 8 November 2009 (UTC)

Argh, another "bite the newbie" proposal. Five now in the past two months? I'm going to propose that anyone who wants to limit IPs or newbies have their editing limited or constrained for a month and that way they can see how it feels to have their own proposals put on them. Its easy to propose to limit the abilities of people who arent you.Camelbinky (talk) 01:49, 8 November 2009 (UTC)

I'm confused; how exactly is this bitey? Treating them different = bitey? Does that mean not allowing them to move articles is bitey? --Golbez (talk) 07:59, 8 November 2009 (UTC)

Some limits come out of necessity (can't let everyone edit every page and page moves can easily be disruptive). Normal editing should be as easy as possible, though. Adding extra hurdles will simply discourage more people from editing. --MZMcBride (talk) 08:04, 8 November 2009 (UTC)

The problem is that WP's rules are getting more stringent all the time - mostly for good reason, as some nuisances find new ways to spam / POV-push / generally be WP:DE; and some rules are unavoidable, e.g. WP:BLP or WP:COPYVIO. I think we need a newbies' guide that: is simple and practical (not the usual bureaucratese in which policies and guidelines are written); will hand the main problems at least 95% of the time; has links to the full versions of the rules. --Philcha (talk) 17:49, 15 November 2009 (UTC)

Your wish is in the making as we speak - Wikipedia_talk:Help_Project#Simplified_ruleset_refactoring! This is part of a little drive we are having at making a few introductions to wikipedi a- the talk page one is nearing completion .. feel free to add any comments / suggestions over our way :) Lee∴V (talk • contribs) 20:11, 15 November 2009 (UTC)

Someone just down there had an idea of forcing previews for new pages by new users....plus showing them our law of unintended consequences write-up as well. I do agree with that idea. I would like to amend my decision and say it would be good for new users and new pages, just not every edit. ViperSnake151  Talk  20:42, 15 November 2009 (UTC)

How about: Make the "show preview" button bold instead of the "save page" button for non-logged-in editors and make it the default for new accounts. If a newbie changes his "preferred action" settings before making a single edit, that's his right. Of course, this means having one more setting. davidwr/(talk)/(contribs)/(e-mail) 02:09, 18 November 2009 (UTC)

Municipal authorities/special district governments

Pennsylvania is home to over 1,700 "municipal authorities," similar to Special-purpose district in other states. These municipal authorities are alternate forms of local government, but are constituted for a special purpose--often for the governance of water, sewage, parking, housing, or economic development purposes. These entities are often described as "special purpose governments," as opposed to "general purpose governments", like cities or townships. They are not simply sub-levels of municipal government, they are governments themselves, with the taxing and bond-issuing power, condemnation power, and are subject the same ethics and open government laws as municipalities. I think this is a project that could be eventually extended to special purpose governments in all 50 states.

• The Proposal - The U.S. Census Bureau's Census of Governments documents and categorizes all of these entities twice per decade. I have organized this data into a spreadsheet, with the name, jurisdiction, type, location, and function of these municipal authorities, and I would like to utilize an approved bot to create stub-style articles on each of these entities. I understand that there are several natural questions that arise from this proposal.
  • Notability Question - There should be no shortage of significant, independent, and WP:reliable sources describing the each entity and its activities, as nearly every regional newspaper carries meeting summaries, financial data, and happenings in the local municipal authorities. In addition, these authorities leave significant paper trails, whether through official documents, like annual reports and meeting minutes. Finally, there is the Census of Governments data. As a separate thought on notability, the community has generally agreed that all governments, species, and villages are notable, a presumption that I think should be extended to municipal authorities/special-purpose districts.
  • Why a bot? - Because of the sheer volume of municipal governments identified in the Census of Governments, coding them by hand is not feasible. I have written and compiled all of the text already, but the task is too tedious to do manually.
  • Why just stubs? - The data is currently in spreadsheet format, allowing a bot to easily parse out the data into an article template that looks like a pretty good stub.
  • How about some examples? - Here is an example of what the template would look like. Here is a sample of what the stubs would look like. For this example, I picked a water authority.
  • I never heard of these things! - That's understandable. But, we still have articles on obscure mathematical models that I never heard of. Here are big examples:Sports & Exhibition Authority of Pittsburgh and Allegheny County, SEPTA, Philadelphia Housing Authority.
  • Possibilities for expansion - I really think that once we create stubs for these entities, people will expand them. There are lots of sources, and lots of people who follow their local government closely. I know that there are concerns about the decline in new article creation, so here's a big group of articles that are just waiting to be created. There's also a good government and open access benefit by bringing these important entities to the forefront of the internet.--Blargh29 (talk) 22:49, 10 November 2009 (UTC)

Here is a list of Special Services Districts and Municipal Authorities in Philadelphia, PA, taken from the U.S. Census Bureau's Census of Governments documents, with an official URL when available. Do all these examples meet the criteria for notability? If some do not, why not? --DThomsen8 (talk) 02:10, 11 November 2009 (UTC)

• • • • List:
    • Center City District (http://www.centercityphila.org)
    • Frankford Special Services District Of Philadelphia (http://www.frankfordssd.org)
    • Germantown Special Services District Of Philadelphia
    • Manayunk Special Services District Of Philadelphia
    • Old City Special Services District (http://www.oldcitydistrict.org)
    • Pennsylvania Convention Center Authority (http://www.paconvention.com)
    • Philadelphia Hospitals And Higher Education Facilities Authority (http://www.hospitalhighered.com)
    • Philadelphia Authority for Industrial Development aka PAID (http://www.paid-pa.org/)
    • Philadelphia Industrial Development Authority aka "PIDA" (http://www.pidc-pa.org/)
    • Philadelphia Industrial Development Corporation aka "PIDC" (http://www.pidc-pa.org/)
    • Philadelphia Regional Port Authority (http://www.philaport.com/)
    • South Street Headhouse District (http://www.southstreet.com)
      --DThomsen8 (talk) 02:16, 11 November 2009 (UTC)

• Comment. As with any article, these need to have secondary sources for notability. Many of these are of local interest only, and even then only appear as a line item in people's property tax bills. Abductive (reasoning) 02:20, 11 November 2009 (UTC)
• If only the census of governments data will be used, these should be limited to list articles (either broken down by county or by municipality). There is just not enough information in the COG database to create a full-fledged article. There should be no mass creation of stubs. Start with list articles and split off individual articles only when secondary sources are found. --Polaron | Talk 02:34, 11 November 2009 (UTC)
• As I said before, there needs to be 3-rd party sources before any article creation, not just a dump from a primary database. OrangeDog (τ • ε) 12:12, 11 November 2009 (UTC)

Different states have different policies and procedures for creating, pruning and merging these sundry authorities. Some of them are indeed important, and some of the most significant ones are those you've never heard of and which never get covered in the press (remember those levee districts in New Orleans?) However many are moribund, and haven't been heard from because they are supremely unimportant and non-notable. Their position in local government should still be noted somewhere in Wikipedia, but very far from all of them deserve their own stubs. A list or a table created by a bot for each state, or even for each county is fine, and probably necessary (how else would you know which districts guard your own riverbanks or water supplies?) but creating a contentless stub for every authority just creates clutter and hides the forest with trees. Leave the work to human editors. —— Shakescene (talk) 12:28, 11 November 2009 (UTC)

Can we agree that lists rather than stubs are the way to go? If so, would a list like the one I have provided above be a satisfactory starting pattern? An alternative would be to have a table rather than a plain list with the official website URL, as shown above. A table could have more information, but it should be limited to what is available on the U.S. Census Bureau's Census of Governments. However, some of the data there is misleading. The Pennsylvania Convention Center Authority has nothing to do with parks, but the Census of Governments says otherwise.

If there is a consensus here, I will make an appropriate sample from the list above, enhanced with some additional agencies not shown. Can the title be List of Philadelphia County municipal authorities? By this, I am implying individual lists by county. Perhaps this is not the best example, as Philadelphia County and the City of Philadelphia have a combined government with exactly the same geographical area, a unique situation in the Commonwealth of Pennsylvania. --DThomsen8 (talk) 13:58, 11 November 2009 (UTC)

Lackawanna County would be a better example, where the title would be List of Lackawanna County, Pennsylvania municipal authorities, and there would be a See also from Scranton, Pennsylvania, the largest city in that county. The list for Lackawanna County would include both municipal authorities for the whole county, and municipal authorities for just the City of Scranton.--DThomsen8 (talk) 14:10, 11 November 2009 (UTC)

An example (preferably in userspace for the time being) would be helpful to this discussion, yes. Shereth 15:47, 11 November 2009 (UTC)

User:Shereth, do you agree that lists by Pennsylvania counties would be an appropriate way to go? What about lists with name and URL, or else a table with more information? I prefer the lists with name and URL, as easier to create, at least with my present methods and skills. I can go ahead with two examples, Lackawanna county and Philadelphia county, as sandbox entries for now. If there is consensus, then I would want to move the examples to live articles, complete with categories and talk page templates. --DThomsen8 (talk) 15:57, 11 November 2009 (UTC)

Lists by counties seems to make sense. Go ahead and do a name/url type list as you've mentioned, if someone can think of a tabular format that makes sense that kind of change can be made at a later date but there's no reason to overcomplicate the initial example. This idea is perfectly reasonable. Shereth 16:05, 11 November 2009 (UTC)

That sounds agreeable to me.--Blargh29 (talk) 16:55, 12 November 2009 (UTC)

I would prefer to see some sort of list. I view these lesser governmental agencies much the same way I do elementary schools or local water districts: Sure, you can find all manner of references to them in reliable sources, but most of it is either directory-type information or information which is required to be published by law. Go for a list or merge the content into a "parent" article such as a county or an article about that type of entity, such as Municipal authority (Pennsylvania). Some of these may be "notable in their own right" and should have articles, but those should be hand-created. davidwr/(talk)/(contribs)/(e-mail) 02:16, 18 November 2009 (UTC)