Misplaced Pages

Proposed addition to the toolbox

I'm proposing that we add a new link to the sidebar — "Subpages". This would appear in the toolbox menu on any editor's userpage, project namespace pages, or anywhere else that the subpage policy applies. Right now, the quickest way to access a page's subpages is to click "page information" in the toolbox and follow the link in the bottom of the first table. But unless people have actually read the subpage policy in its entirety, they may not even be aware of this function; until just recently, I looked for subpages by checking an editor's contribution log, scrolling to the bottom, and clicking the relevant link in the footer. I didn't even know there was such a matrix for project namespace subpages (nor any other namespace, for that matter). A "Subpages" link in the toolbox itself would be faster and more accessible, both for new users and experienced editors. It has already been in use over at Wikimedia Commons for roughly six years now, where it's proven itself convenient.

As far as I'm aware, this was proposed only once before, yet received absolutely no attention at the time. Thoughts? Kurtis 09:59, 6 May 2013 (UTC)

• Support. I would find that very useful. Ignatzmice•talk 11:48, 6 May 2013 (UTC)
• Fine by me. I've occasionally found it useful on Commons. Rd232 11:49, 6 May 2013 (UTC)
• Support. I am supportive of anything that encourages more use of subpages. Although I currently have code in my common.js to create a link to my subpages at the top of pages where Preferences, Watchlist etc are, I don't mind the redundancy (which would be only for me). (See also the proposal Misplaced Pages:Village pump (proposals)/Archive 92#My subpages I made). -- Toshio Yamaguchi 12:01, 6 May 2013 (UTC)
• Support, great idea. It's been forever since I noticed the box you mention at the bottom of Special:Contributions — the only way of checking subpages that I know is Special:Prefixindex, and I've been here since 2006. Nyttend (talk) 12:15, 6 May 2013 (UTC)
• Sure. I've had one in my personal js for ages, hugely useful. ~ Amory (u • t • c) 13:40, 6 May 2013 (UTC)
• Strong support. I would find this incredibly useful.  — TORTOISEWRATH 21:06, 8 May 2013 (UTC)
• Strong support seems like a very sensible suggestion. AutomaticStrikeout  ?  03:11, 15 May 2013 (UTC)
• Support: I like ideas like this that make the web sites that I frequent easier to use. — RandomDSdevel (talk) 21:43, 21 May 2013 (UTC)
• Support I'd use it more if i were reminded about it this way; it would also make it easier to spot problems hidden there. DGG ( talk ) 20:35, 24 May 2013 (UTC) .

"Updated since last visit" markers

It has been over a year since watchlist notification was turned on, only to be hidden immediately after. Now that the CSS has long been changed to allow better control over how to show changed watchlist items, I proposed to change the bullets back then, which met no opposition, but I never got around to implement it. So if there are no objection, I can put CSS in place the will replace the standard bullets ( and ) with green bullets ( and ), and re-enable the reset button. — Edokter (talk) — 11:12, 6 May 2013 (UTC)

• Questions What do you mean by reset button, what would that be doing? Regarding the bullets, I don't really see the benefit of having the green bullets over having the grey ones. -- Toshio Yamaguchi 12:08, 6 May 2013 (UTC)
  • The green bullets lets you see that pages have changed since you last visited them. The reset button appears above the list to reset the green bullets to their default state. — Edokter (talk) — 12:40, 6 May 2013 (UTC)
    • Are there different green bullets, something not 3D? ~ Amory (u • t • c) 13:44, 6 May 2013 (UTC)
      • No. — Edokter (talk) — 22:42, 7 May 2013 (UTC)
  • Toshio, do you have a watchlist at any other Wikimedia sister projects? This is just the "Pages that have been changed since you last visited them are shown in bold" feature, but improved, because bold is not the only option. (We can now: just color the background, or change the bullet, or keep it just bold, anything. Individually, with css.). –Quiddity (talk) 05:58, 8 May 2013 (UTC)
    • So the green bullets are just another watchlist customization like

.mw-changeslist-line-watched { ::: font-weight: normal; ::: font-style: italic; :::}

I am using in my common.css that shows you changed pages with a green bullet? Well, if that's the case, then I support turning it on by default, as long as it doesn't interfere with using another customization (like the italics I am using). -- Toshio Yamaguchi 22:14, 12 May 2013 (UTC)

I believe so. Please confirm, @Edokter:. –Quiddity (talk) 20:08, 15 May 2013 (UTC)

Confirmed. — Edokter (talk) — 21:40, 15 May 2013 (UTC)

• Support. I like the minimal plan. Just remember to update the docs at Misplaced Pages:Customizing watchlists#Styling of recently updated pages, and all should be fine. –Quiddity (talk) 05:58, 8 May 2013 (UTC)
• Strong oppose as before. This marker is completely redundant with my watchlist. I don't visit the vast majority of the pages on my watchlist anyways - many are on the list only to keep track of discussions without actually reading them.--Jasper Deng (talk) 06:11, 8 May 2013 (UTC)

  You don't want it, and that's fine. Why do you not want anyone else to have it? –Quiddity (talk) 21:43, 8 May 2013 (UTC)

• Support I like the idea a lot. Please go ahead. --Anthonyhcole (talk · contribs · email) 06:20, 8 May 2013 (UTC)
• Question What is the benefit of making this the default? Why can't we just list it as another customization at WP:CUSTOMWATCH? If there is a convincing reason to make this the default, I am willing to support it, but right now I don't see what that would be. Now of course everybody could argue I want customization XYZ as the default, but why bother? Anybody not satisfied with the default one can customize his own. I smell featuritis here. -- Toshio Yamaguchi 13:04, 16 May 2013 (UTC)
  • What we have now is a "customization" that is being forced on all users by default. If you wanted to have "plain", then we'd go to the Mediawiki default (which is bold-faced text), just like the CENT-listed RFC here supported back in December 2011, and tell the couple dozen power users who immediately freaked out over the change that they're the ones who have to go to the trouble of changing their settings to get the old, non-standard style. Using the Mediawiki default has the notable advantage of being consistent with what all users see at all the other WMF websites as well as at most non-WMF wikis that are running the same software. Using a non-standard default has no inherent advantages, although using a visible non-standard default is better than using a default that effectively disables the feature. WhatamIdoing (talk) 16:39, 16 May 2013 (UTC)
    • The default of bolded new things is hardly unique to mediawiki default, either - it's standard across a lot of software and applications, especially email clients, where new message subjects will be bolded until they're opened. So using the default also has the advantage of being consistent with the users' experiences on entirely other apps. -— Isarra ༆ 18:54, 19 May 2013 (UTC)
• Oppose - arbitrary colour changes aren't good for differentiating things unless their consistency can be widely guaranteed, and when these only support specific skins on a single project, these cannot. Please just restore the default and list this as a customisation option for those who prefer it. -— Isarra ༆ 18:54, 19 May 2013 (UTC)
• CommentSupport - Honestly, I think that much of this will be resolved with the new "flow" (or whatever they're calling it) system WMF will soon be implementing. Check out wikimedia-l if you have no idea what I'm talking about, or let me know if I totally misunderstood the proposal. With my current understanding, though, this would be a waste of valuable time right now if it's going to be replaced, regardless. ---Jackson Peebles (talk) 04:21, 23 May 2013 (UTC)

  Not really. Flow is just for user talk pages, and maybe other discussion pages in the future. This is still useful for articles and other types of pages. Anomie⚔ 21:01, 23 May 2013 (UTC)

  Thank you for the explanation, Anomie. I have amended to support. --Jackson Peebles (talk) 21:13, 24 May 2013 (UTC)

• Support Although I agree with those above that really we should just go back to the default bold. Anomie⚔ 21:01, 23 May 2013 (UTC)

Developer's Noticeboard

Recent events have highlighted the need for more effective communication between our software developers and the Misplaced Pages community. When software changes happen without enough input from the community, there are usually problems. When the community reacts against changes because of unforeseen problems, this in turn can alienate the developers from the community and creates a cycle that perpetuates the lack of communication. Right now, announcements and requests for input tend to happen in places other than this wiki. Even when they do not, they are posted to high traffic noticeboards such as the Village Pumps, which are hard for many people to keep up with.

I propose that we create a Developer’s Noticeboard on Misplaced Pages. Developers and Wikipedians who are subscribed to the software mailing lists could post advance notice of changes, and there would then be a centralized place for discussion to occur. Staying abreast of important software changes would no longer require watching multiple wikis, email lists, or noticeboards. ⇌ Jake Wartenberg 23:53, 7 May 2013 (UTC)

Suggestion: I think the first sentence should talk about more effective communication, not more communication. WMF staff already puts a lot of time and effort into communications. I think the issue is how those resources are spent, not how much are spent. -Pete (talk) 15:39, 8 May 2013 (UTC)

Done. Thanks ⇌ Jake Wartenberg 02:13, 9 May 2013 (UTC)

Question: How much of the opposition is because many of the participants (including me) only found out about the proposed specs and UI when it was deployed? I'm not sure there was an announcement that most users would have seen as a matter of course at the specs (or wireframing/UI mock-up) stage, but if there was, I missed it, and I would have liked the chance to comment/give feedback then. The Crab Who Played With The Sea (talk) 16:29, 10 May 2013 (UTC)

• Support a noticeboard if it is separate from WP:VPT clearly, as a place for Wikimedia developer announcements, not general tech discussion. We post on VPT all the time (it's the number one edited project namespace page for my work account), but people seem to think it's too noisy. I don't think that, as an experiment, a noticeboard devoted to Wikimedia technical announcements would hurt. Other ideas that have floated around are newsletters, eventually incorporating notifications for subscribed editors, and lots of other things. We also already publish mandatory Wikimedia engineering reports on MediaWiki.org and the blog, and lots of other things, but I would be happy to post announcements to a Wikimedia tech noticeboard specifically devoted to key feature updates. And we can still try other communication methods or close the noticeboard if it doesn't work. In the long run though, the volume and velocity of work by the Wikimedia Foundation engineers, designers, product managers, and data analysts is only going to increase. We're already discussing moving MediaWiki (for all 800 wikis) to a weekly release cycle instead of every two weeks. We already bust our butts trying to announce changes, and we still get shit thrown at us every time someone is surprised or annoyed. I think now is a good time for English Misplaced Pages to think of ideas for how it wants to hear announcements about upcoming changes. Steven Walling (WMF) • talk 00:06, 8 May 2013 (UTC)
• Or maybe we could have automatatic local duplication of the Wikitech-ambassadors list... --Yair rand (talk) 00:13, 8 May 2013 (UTC)
  • Note that's not something that needs Foundation support. Someone could just have a bot receive messages from that mailing list and post notifications of new threads on-wiki. Anomie⚔ 12:08, 10 May 2013 (UTC)
• Strong support. If I recall correctly, the WMF (or was it the devs?) have previously vetoed this idea because enwp isn't the only project around, and they feel it wouldn't be fair or a good use of their time to do "special" announcements here that aren't done elsewhere. So if anyone is about to deploy that argument: I can only say that from the perspective of an enwp editor...that's not a reason to continue to dig yourselves this hole. We, sitting here on enwp, would really like to know about upcoming deployments. You, sitting there in San Francisco and such, would really like us to stop being shocked at and, increasingly, reflexively opposing code changes. Many devs and staff, like Steven and Oliver, do bust their butts to let us know things, but they're limited by the fact that there's just no effective local place to tell us these things. A real noticeboard here, on enwp, is indisputably the best way for you guys to get us, the enwp community, to stop being shocked by these things. That you're also not telling, say, svwp, or enwikt, or any other project about upcoming deployments is probably a sign that you ought to work on your communication strategies, not a sign that it wouldn't save you spectacular amounts of grief if you were better able to notify the community(ies) of things you're working on. You know, from bitter experience, that the enwp community isn't going to follow you to mediawiki.org and ferret out what changes you're planning on making to code that affects enwp. That strategy, the making us come to you, isn't working, even if it's what's technically "fair", and as a result you guys are catching some serious nastiness and dug-in opposition to nearly anything you say from the community here. Please, pleeeeease consider a newer strategy: just telling us what changes you're planning on making, in a centralized location, on the project your changes will be affecting. You can tell svwp and enwikt too, if you want, or not - we won't judge and we probably won't notice either way anyway - but please don't not tell us and create more grief for yourselves just because you don't want to have to tell the Xhosa Wikiquote or something. A fluffernutter is a sandwich! (talk) 00:41, 8 May 2013 (UTC)
• Support Fluffernutter really hit the nail on the head with the word "reflexive." Sometimes it is indeed better to ask forgiveness than permission, but better communication could prevent a large amount of nastiness. ~ Amory (u • t • c) 02:10, 8 May 2013 (UTC)
• Support - worth a try. See also Misplaced Pages:Petition to the WMF on handling of interface changes. Rd232 04:18, 8 May 2013 (UTC)
• I think it's worth a try, but I don't expect it to work. It will just change the complaint from "I hate this surprising change" to "Even though they posted it to some page I don't read, nobody personally informed me about it, so I was still surprised and I still hate it".
  Think back to the discussion about turning on the Mediawiki default for watchlists, which places un-read pages in bold-faced type. It was discussed at Village Pump (proposals) for a month, it was advertised at CENT, and it had overwhelming support and almost no opposition from a couple of dozen editors. Then the change was made, and suddenly people are screaming at the devs (who were utterly blameless) pushing stuff off on the community without consulting them. I don't recall seeing any apologies for that bit of slander, either: people who were informed of the month-long open discussion generally just complained that near-unanimity from a couple dozen editors didn't count as a community consensus, rather than striking their mistaken comments about the devs. And the feature is still crippled by default, which means that most editors don't even know that it exists.
  So think about those people. Think about the people for whom a month-long open discussion, not at VPT and additionally well-publicized at CENT, was just a trivial sideshow that happened to disagree with the True Community Consensus™ (defined as "any statement that agrees with the speaker's personal opinion"). Do you honestly expect those editors to accept a posting at a noticeboard as a valid method of communicating with "the community" unless each and every one of those editors individually chooses to read the noticeboard? I'm thinking that the only thing that would actually work is that recent proposal for blocking people until they acknowledge receipt of the message. These people seem to behave like the people who start the stupid petitions every time Facebook makes a change to its interface—hating on it for a couple of months, and then not even quite being able to remember how the old version worked. I think that we might all be better off with an explicit policy of not listening to en.wp about general design issues (which 99% of editors are no more capable of providing advice to the devs than 99% of Facebook users) but, of course, dealing promptly with practical things, like templates or bots breaking. WhatamIdoing (talk) 04:33, 8 May 2013 (UTC)
  • Completely and 100% agree that the changes are just an immediate anger that will subside rather quickly once people get over the newness. (personally, I found that it took me all of five minutes to adjust to the section edit link moving) Having yet another noticeboard isn't going to 1) make people any less pissy about changes, and 2) won't force people to read when changes are coming. EVula // talk // ☯ // 05:04, 8 May 2013 (UTC)

  I think there's a distinction to be drawn between informing and asking permission. WhatamIdoing is right that asking permission from the enwp community for a code change is pretty much a non-starter; we specialize in failing to agree on anything, and anyway, one project shouldn't have veto power over MW-wide code. However, there's some ground to be gained in informing the community of these changes, even without asking our permission. If there were a reliable location people could check to find out "The code for X will be changing on date Y," it would save us tons of after-the-fact VPT threads ranging from "OH MY GOD WHAT HAPPENED TO X??" to "X suddenly changed and now there are salamanders crawling out of my vector.js, what do I do?" It probably wouldn't prevent all the "X-changers must die" threads, but those are never going to be entirely killable anyway. Why not pick the low-hanging anger-fruit and at least improve things incrementally? A fluffernutter is a sandwich! (talk) 14:28, 8 May 2013 (UTC)

  If each and every one of these people actually read (and remembered reading) the announcements on the noticeboard, then sure. But they won't, so I don't think it will matter in actual practice. It might be a nice gesture, but ultimately a fruitless one. WhatamIdoing (talk) 16:07, 8 May 2013 (UTC)

• Oppose: I don't think the answer to a sprawling system of mailing lists, IRC channels, local wikis (and their noticeboards), and global wikis (with their noticeboards and central notices) is to create yet another forum for announcements and discussion. This feels very similar to the proposed Misplaced Pages:WMF noticeboard.

  Given the existence of dedicated mailing lists such as wikitech-ambassadors and the entire Wikitech wiki, I can't see it being a great idea to create a noticeboard here that nobody will use. I agree that technical changes need better advertising, discussion, and feedback. m:Tech/Ambassadors has some thoughts on this (including its associated talk page) and there may be other ways to address the underlying issue here, but I don't think yet another noticeboard is what we want or need. --MZMcBride (talk) 05:02, 8 May 2013 (UTC)

• Oppose per all the reasons Max outlined. Plus, I have a sneaking suspicion we've discussed this before...development talk should be centralized somewhere (either on meta, mw.org, wikitech), not regulated to a noticeboard on a single project. ^demon 05:06, 8 May 2013 (UTC)
  • @^demon: No one is proposing that we centralize developer discussions on to English Misplaced Pages. What's being proposed is that we separate out announcements about WMF work from the stream at WP:VPT, which is pretty noisy. Folks like me, Oliver, and others already spend no small amount of time advertising and discussing changes relevant to this project locally, so all we'd be doing is moving those announcements and hopefully gaining some additional visibility. Steven Walling (WMF) • talk 07:23, 8 May 2013 (UTC)

    Yes, this. The devs, overworked souls that they are, probably wouldn't even be affected by the creation of such a noticeboard. It would be the domain of the community-facing staff, whose job it is to communicate these changes to us, to do the posting and the talking. And if they're willing to do that, why not let them have a noticeboard to do it at? A fluffernutter is a sandwich! (talk) 14:28, 8 May 2013 (UTC)

    I suspect that you're right, and I certainly hope this is true, because given a choice between "the engineer does actual work" and "the engineer talks about working", I pick actual work every single time. WhatamIdoing (talk) 16:07, 8 May 2013 (UTC)

Who's Max? --Closedmouth (talk) 07:42, 8 May 2013 (UTC)

Max is the first M in MZMcBride. 64.40.54.112 (talk) 03:09, 11 May 2013 (UTC)

• What McBride said. As a developer, frankly I'd like there to be less noticeboards. It'd be really nice if, when announcing a relevant upcoming or potential change, I could just put the announcement in one place such that everyone who cares could see it and discuss it. Instead there are already more places than I even know of, and indeed more than anyone could reasonably be expected to use and follow cross-project, and adding further project specific ones won't solve anything when folks can't even follow feedback on all of the existing ones already. Unfortunately, while these are real issues here, I just don't see this as a solution. -— Isarra ༆ 05:14, 8 May 2013 (UTC)
  • Cross-wiki watchlists, then? Rd232 05:22, 8 May 2013 (UTC)
• The problem isn't so much that people don't see announcements from the dev's (and chasing them to a noticeboard isn't likely to help visibility that mcuh, imho), but that by the time interface changes are "proposed" they are often presented as a fait accomplit. Just encourage the developers to say, for example, "we want to replace the OBOD with something, do you think this is a good idea?" Then wait for a consensus to occur on the change, suggesting different options if/as needed and remembering that changes that affect many people should require a very broad on-wiki consensus and may require advertising elsewhere is participation is lacking. Similarly, don't present huge packages that change everything or use extremely long presentations. Proposals/presentations that are short, simple, with the various changes split out as separate proposals even if they are meant to be part of a larger package, will result in higher participation than TLDR proposals. The location of the proposal is barely even relevant compared to the attitude and approach of making the proposal in the first place. – Philosopher  06:30, 8 May 2013 (UTC)
  • Yes, it's the development process that's the problem (cf WP:interface changes). There needs to be more exposure of what thinking has gone into different decisions, and what sort of evidence base is being used. Some of the problem is the community not having input into the process; some of it is the community simply not knowing why things are being done, which contributes to a feeling that a change is arbitrary. Rd232 11:04, 8 May 2013 (UTC)
  • It sounds like you're still expecting the devs to get our permission to make visible changes. They don't need it, and our interests are not best served by having any power over the devs' work. Design by an ad hoc committee of hundreds of mostly ignorant amateurs is always a disaster. We don't let the coders and designers control our decisions about achieving NPOV on a contentious article; they shouldn't all us to control their decisions about the website. WhatamIdoing (talk) 16:17, 8 May 2013 (UTC)
• Technical discussion is already so fragmented, another noticeboard isn't going to help (relevant xkcd). We should utilize the current methods and fix the current problems (why is m:GMD going to WP:VPM???). I'm on the wikitech-ambassadors mailing list, and nearly everything gets announced there, and in non-tech speak too. Legoktm (talk) 07:38, 8 May 2013 (UTC)
  • To appease those who refuse to involve themselves with mailing lists, we could have a bot or script that automatically reposts relevant messages from wikitech-ambassadors to a noticeboard page here on enwiki, which users could then watchlist. — This, that and the other (talk) 08:33, 8 May 2013 (UTC)
• Support a centralised, on-wiki noticeboard where the WMF communicates planned interface changes. Furthermore, I suggest that a structure similar to the Arbitration Committee noticeboard--i.e. announcements on the noticeboard itself, discussions on the talk page--may make it easier to follow and prevent it from duplicating the functionality of WP:VPT. wctaiwan (talk) 12:32, 8 May 2013 (UTC)
• Support - Brilliant idea!, →Davey2010→→Talk to me!→ 14:36, 8 May 2013 (UTC)
• Oppose -- I agree that communication is at the root of recent problems, but don't think that creating a new venue for communication will address that. I would rather see a solution that involves clear and inclusive development and articulation and goals, of transition plans, of backup/contingency plans, etc. I don't think there's any compelling reason that product development staff can't find more effective ways to communicate and develop and execute plans within the existing communication tools. -Pete (talk) 15:39, 8 May 2013 (UTC)
  • I want to note, my opposition isn't strong -- I don't see problems resulting from such a noticeboard. I just don't think we should allow ourselves to believe that the creation of a new venue will solve a problem involving complex communication dynamics. -Pete (talk) 15:42, 8 May 2013 (UTC)
• Oppose for all the reasons already said. Communication is needed throughout the development program with proper feedback and consultation. A noticeboard will only allow this not to happen with a response of "well we posted it on the noticeboard" when the complaints start to come in of an implementation that nobody was aware of or expecting. SpinningSpark 16:36, 8 May 2013 (UTC)
• Sigh. Communication is a two way process. Speaking and listening, writing and reading. Screaming into a well is not communicating with the community. Reading reports from your developers is not communicating with the community. You can make many changes that the community will never notice, but when you make a change that they might notice, you should really feel assured that they will notice, and some of those will object to the change. It is (at least in my opinion) your duty to seek out those objecting opinions and discover how the proposed change can be made with the least disruption. Surprise is a wonderful military tactic, but it's not a good way to win friends and build trust. It's true that FB complainers don't remember the way things used to be -- there are so very many of those ways, after all -- but the overwhelming memory is that the FB developers are screwing with them, and they don't like it. This is not a good way to encourage participation in an abstract undertaking like building an encyclopedia. I'm much more likely to want to see my grandkids, and will put up with a good deal more to do so. htom (talk) 18:18, 8 May 2013 (UTC)
• Oppose People will always be upset by change. This will just be another board they don't read and they will still be upset that they weren't personally told that the changes were coming. This doesn't help anything and if anything is more likely to wheel spinning. People get over change remarkably fast once the newness wears off. -DJSasso (talk) 18:34, 8 May 2013 (UTC)
• Indifferent I'm mostly indifferent on this because if this is deemed needed in addition to the messages I send out to wikitech-ambassadors, then I guess it needs to be done. I hoped those on -ambassadors could do much of the actual dissemination on the various 'pedias/projects because having someone local to the wiki, both in language and in expertise, is better at communicating what the real issues/changes will be for that community specifically, whereas I have to be fairly general for the exact opposite reasons (I'm English-only and not an expert in all the projects' methods/standards). I personally try to send out important/interesting-looking deployments to the -ambassadors list every Friday (when I send out the weekly Deployment and Roadmap update emails). There's way too much detail in those raw emails for most projects, even on a technical village pump (the intended audience is WMF Engineers and Volunteers). User:Greg (WMF) (talk) 18:55, 8 May 2013‎
• Support if it would help but I'm not sure it would. We already have Village pump (technical) and a few other venues where the techies normally hang out. I think it makes some sense though to have a specific place where the developers (both the WMF and non WMF ones) can talk and discuss issues and notify the comunity. Kumioko (talk) 20:00, 8 May 2013 (UTC)

• Comment: what about putting a Developer's Noticeboard on Meta, to counter the objection of giving too much prominence to English Misplaced Pages's concerns? Until cross-wiki watchlists arrive, that has an obvious downside, but that might be a good usecase for a sort of "cheap cross-wiki watchlist", where a bot mirrors pages from Meta to a protected copy of the page on English Misplaced Pages, so that edits on Meta can be seen here (notably, appearing in the watchlist). Rd232 20:37, 8 May 2013 (UTC)
  • @Rd232: MediaWiki developers (staff and volunteer) already have MediaWiki.org, and mostly use Wikitech-l, which is one of our most high-traffic mailing lists. Developers don't really need another discussion space, the proposal is a lot more about how to advertise user interface changes to people who aren't developers. With that in mind, and considering the fact that Meta has very little real community of its own, I don't think a wiki noticeboard there would be much help. Steven Walling (WMF) • talk 08:01, 9 May 2013 (UTC)
  • @Steven Walling (WMF): - yes I know developers don't need another internal discussion space, but they do need a space where they can engage with non-developers on issues where non-developers can usefully give input, and in ways where they can clarify their thinking etc. I suggested Meta because that emphasises that the purpose is engagement with the Wikimedia community; and suggested the cross-wiki watchlist bot thing because putting it on Meta without something like that would be pointless. Rd232 08:19, 9 May 2013 (UTC)
• Sigh. I understand what the developers are talking about with having so many places to communicate. If there was just one place to watch, I'd watch that. I've just signed up for the wikitech-ambassadors mailing list, but when it was first announced I was of the impression that it was a mailing list for people who were willing to *act* as ambassadors, and who understand at least 50% of what is on VPT and wikitech-l and so on. (Incidentally,I watch both of them, but understand well under 10% of wikitech-L and under 20% of VPT.) I looked at the messages about moving the section edit button on wikitech-ambassadors-L, and the thread title is "Breaking change notice", which suggests to me that it's something for other developers to be aware of, not that a significant UI change is about to take place, so I'm not sure I'd even have opened that thread if I had been subscribed at the time. It seems that most of the 150 or so subscribers are actually developers or WMF staff, so I've got the feeling it's a bit of an echo chamber. There does not appear to be any significant discussion there; few threads seemed to have responses. So, what I would like to see is a central location where I can find out about changes that will affect me as a user, particularly UI changes, that provides complete information on what will change (both what will be new and what will be eliminated), provided at least two weeks before the change will happen. That way, if there are serious concerns about the change (like the fact that Notifications has major accessibility and usability issues), they can be addressed before there's a raging torrent. Oh, and it needs to be written in plain language; the reason so few "regular" editors watch VPT is that they can't understand the vast majority of what is there. And whatever you do, don't send people to bugzilla. If this means a project-specific noticeboard, I'll be happy, and I'll put it on my watchlist. Risker (talk) 04:41, 9 May 2013 (UTC)
• Neutral, leaning oppose I frequently speak to both developers and Misplaced Pages editors, so I'm on the fence. In my opinion, while the community can't be prevented from making this noticeboard, I don't feel it would resolve the issues we tend to have. Developers must keep track of many things each day, and often don't have the time for another page to watch. I think the community can improve on the current system by working for more participation in discussions about rather-sweeping features changes. For example, I strongly feel that the consensus generated on this page (without a full RfC) for the changes to the watchlist was inadequate for such a change. I do not think we can keep faulting developers for what I view as at least partly the community's fault.--Jasper Deng (talk) 05:58, 9 May 2013 (UTC)
• I can't see what harm it could possibly do, and I think many users would appreciate it. — This, that and the other (talk) 11:32, 9 May 2013 (UTC)
• Meh. I have ambivalent feelings about this proposal. I'm not fundamentally opposed to it, and I don't think it'll cause problems, so it's probably worth a try, but I don't really expect it to solve the underlying issue.

  On the one hand, anything that can facilitate communication between the community of users and that of developers is a Good Thing™. Steven and Oliver seem to see this proposal as beneficial for the work they do, and both E2 and E3 already have a strong presence and local hub pages on enwiki, so an Editor engagement noticeboard on enwiki wouldn't seem out of place.

  On the other hand, I agree with Whatamidoing when they say "It will just change the complaint from 'I hate this surprising change' to 'Even though they posted it to some page I don't read, nobody personally informed me about it, so I was still surprised and I still hate it'."

  I'm also worried about the expectations. The proposal seems to be for a page where developers (or their community-facing colleagues like Steven, Oliver and I) post announcements; but the name "Developer's noticeboard" sounds to me like "A place where we put stuff for developers to notice", and that's not quite the same thing, so we'd need to make it clear what the page would be.

  Alternative 1: Notifications. It seems to me that this noticeboard would be yet another suboptimal workaround to a proper channel for topical notifications. Echo/Notifications was once presented as the solution to this problem, but "public announcements" are currently listed as "out of scope". I don't know what the timeline is (if any) for the support of topical public announcements in Echo.

  Alternative 2: Bot notifications. In the shorter term, as people have already mentioned above, there are already a myriad of venues for people to learn about upcoming changes; the wikitech-ambassadors is the one we're currently advertising. I'd prefer we consolidate venues and utilize the ambassadors list first, rather than create other venues.

  If the issue is that people don't (want to) use mailing lists, we have a list for people to sign up to get ambassador-related notifications on their talk page, but in practice it's not used much and not kept in sync with the mailing list. I imagine it wouldn't be too hard to subscribe a bot to the mailing list and have it post every first message of a thread to people's talk page. Would someone with technical skills be willing to help with this? The bot could also additionally post to a Developer's hub if people are really attached to the idea, and prefer to see messages in their watchlist rather than on their talk page.

  HTH. guillom 13:01, 9 May 2013 (UTC)

  • I think that there's something to be said for bot notifications. If every WMF project had a designated page for such announcements, the devs could automatically inform everyone of what was planned. Individuals at each project could manually flag announcements as being relevant or not, e.g., by adding something like Y Yes, affects us or N Not applicable—only affects Arabic wikis or whatever they wanted. That might reduce the amount of time that devs spend on communication (more talking == less coding). We could eventually develop an expectation that if you didn't choose to watch that announcement list, or didn't understand what it meant, then your surprise was purely your own fault.
    That would leave us only with the problem of people expecting every single tweak to the UI to be up for discussion, with "me" always outvoting everyone else (times every single "me" on a project). It might be helpful to explicitly manage expectations about responses. UI information pages might link to an informational page about the proven problems of crowdsourcing design, and the fact that people often appreciate changes once they've had a chance to get used to them. Feedback pages might benefit from a note that says something like "We normally review and prioritize feedback about once a week. Don't expect immediate, personal responses. Given a choice between spending an hour silently fixing the bug and spending an hour telling each person who reported it that we're going to fix the bug, we're going to choose fixing the bug." Part of the irritation seems to arise from people expecting ANI-speed responses, and that's not a desirable prioritization of our limited dev resources. A little more education might help, or, at least, it might give us a shortcut to responding to the inevitable complaints. WhatamIdoing (talk) 16:55, 9 May 2013 (UTC)
• Support to the extent that "more effective" includes "at an earlier stage" per my question above. The Crab Who Played With The Sea (talk) 16:29, 10 May 2013 (UTC)
• Support. This can be like the Arbcom noticeboard, which exists purely for the sake of giving the Committee a place to post annoucements. Arbcom and their clerks don't spend much time posting announcements at the noticeboard, so why would we expect the WMF people to spend lots of time at it? They're already spending time making announcements at other pages, like VPT; we're not trying to get them to do something that they're not already doing. Nyttend (talk) 19:44, 20 May 2013 (UTC)

Transclude it to VPT

I agree with WAID, but if somebody wants to try something, then create Misplaced Pages:Village pump (technical)/Announcements and transclude it to the top of WP:VPT the same way WP:ANRFC is transcluded to the top of WP:AN. That way people can watchlist VPT/A or just look at VPT. But I doubt it will make a difference. 64.40.54.112 (talk) 03:25, 11 May 2013 (UTC)

Tech news now available

Greetings. Partly due to this discussion, and partly due to previous plans, a weekly tech newsletter is now available. I've taken the liberty of subscribing VP/T to it (see Misplaced Pages:Village pump (technical)#Tech news — 2013, week 21, and feel free to subscribe a Developer's noticeboard in addition to or instead of VP/T.

If you think this is useful, please help us and contribute to it by adding newsworthy items to the next edition. This will help ensure good communication between users and developers. Also consider subscribing to tech news on your personal talk page, and joining the tech ambassadors list.

This is certainly not perfect and there's room for improvement, so I'll gladly take any feedback you have, here, or at m:Talk:Tech/News. guillom 19:24, 20 May 2013 (UTC)

Fixed Navigation Bar

This proposal seeks to establish the community consensus regarding the introduction of fixing the navigation bar to the top of the window. It will bring the look and feel more in line with other famous sites out there, as well as, in my opinion, make it more personal, which may lead to better editor retention.

I have made a crude mock up in case I haven't described it well. 1 2 The design is irrelevant; it is a demonstration of positioning.

This would have the side effect of making the new echo notification system a lot more visible.

Thoughts? 930913(Congratulate) 22:15, 8 May 2013 (UTC)

@Theopolisme:Just a note that I've started a quick mockup css, just add @import "//en.wikipedia.org/search/?title=User:A930913/fixnav.css&action=raw&ctype=text/css"; to Special:MyPage/vector.css 930913(Congratulate) 07:01, 9 May 2013 (UTC)

Doesn't work for me; all that happens is the "Updated since last visit" in a page's history is now highlighted in screaming green. Ignatzmice•talk 12:21, 9 May 2013 (UTC)

If this isn't working, simply go to the page and copy that text directly into your skin's CSS (or common CSS). Ignatzmice•talk 13:01, 9 May 2013 (UTC)

Related proposal: mw:A sticky navigation. --MZMcBride (talk) 02:39, 10 May 2013 (UTC)

Our friendly designer from Echo strikes again! Theopolisme (talk) 02:10, 11 May 2013 (UTC)

I've thrown together a really simple interactive mockup/demo for an idea that you can play with here. It's not perfect, and I built it inside of 2 hours, so buggy. --Jorm (WMF) (talk) 21:13, 20 May 2013 (UTC)

Discussion

• Support (or is this section for actual discussion, not voting? Feel free to rearrange). With the caveat of not everyone uses JavaScript, this is a great idea. (Maybe it doesn't have to use JS. Remember frames?) It would keep the "new messages" notification (and the Notifications notifications!) where you could see them. Not sure how much use it would be besides that, but it would look nice, definitely. Ignatzmice•talk 22:40, 8 May 2013 (UTC)
  • This could be done with CSS. There are even some script around that fix the entire top area (including the tabs) to stay visible during scrolling. — Edokter (talk) — 22:48, 8 May 2013 (UTC)
    • In that case, the only drawback would be "It's not very useful", which would be outweighed by "Yes it is, for this one thing". There could even be (yet another!) gadget to turn it off. Ignatzmice•talk 22:52, 8 May 2013 (UTC)
• Misplaced Pages...omg lulz so Web 2.0. But I like it. @Edokter: do you know what that script is called? If you smack a bit of sexy shadow CSS on the bottom I think you could hit it big. Theopolisme (talk) 01:00, 9 May 2013 (UTC)
• Maybe. This would certainly increase visibility. However, in general I don't like fixed tabs; they take up too much space. Right now I have 4 lines on top of each webpage: "Editing Misplaced Pages:Village...", "File Edit View History", the actual tabs, and the URL bar. A fifth would be very cluttersome. And some browsers have even more stuff on top. And this is assuming mobile is excluded. -- Ypnypn (talk) 02:25, 9 May 2013 (UTC)
• I hate losing screen real estate to links that I almost never click. Please don't do this, and if you're going to anyway, then please post a script that will get it off my screen. I also don't see the point: is it really critical for me to see those links every single second while I'm reading an article? I understand (and hate) Amazon's decision to do this (I might not care as much if I had a much larger screen), but really: why? Do you think I'll have a desperate need to click on my contributions or my sandbox in the middle of reading a page? WhatamIdoing (talk) 16:41, 9 May 2013 (UTC)
• This is a classic instance where a few people want it, and most people don't, hence a custom user script is indicated. See an old (monobook era) version at meta:Help:User style/floating quickbar#Fixing the user toolbar. Once it's working properly in vector, copy it into a new section underneath Help:User style#Fix the sidebar's position while you scroll. Hope that helps. –Quiddity (talk) 22:22, 9 May 2013 (UTC)
• Conditional support. I support this if and only if it is opt-in. Oppose making it the default, because it would take valuable space at the top of my browser window. -- Toshio Yamaguchi 12:01, 10 May 2013 (UTC)
• Conditional support. Also support this only if opt-in, and pressing Page Down or Space actually scrolls one visible page, instead of that plus height of the fixed area. Oppose making it the default. cmɢʟee୯ ͡° ̮د ͡° ੭ 18:52, 10 May 2013 (UTC)
• Oppose as a default change - this seems premature. Stated reasons either don't currently apply in practice, or just aren't good reasons in general in my book.

Link persistence for notifications and whatnot is completely unnecessary - the way mediawiki is set up, nearly every action takes one to the top of a new page where the personal toolbar is clearly visible. This may at some point change, at which point a new skin implementing a more persistent style of navigation not just for personal, but general site navigation, would be required, but we do not currently use a model where infinite scrolling and inline editing and commenting are standard or even supported.

Screen real estate is valuable and should place emphasis on the content, not the user. This is an encyclopedia, not a social network or what have you, and while some principles apply across the board, many do not, and even those that do carry different weights on each. I would argue that saying 'facebook/whatever did it' is not a valid reason for anything by itself. If there is a specific reason facebook/whatever did it that applies here, however, that's another matter, but the reason is what should be considered first and foremost and I don't think the reason applies here for this particular case.

So this might be useful for some folks, but in general it is just not apt to be a good change given present software behaviour as well as the specific skin layout otherwise. -— Isarra ༆ 21:43, 14 May 2013 (UTC)

Superfluous pop-ups

I, and I'm sure others too, don't need useless pop-ups to tell you what you just did, like "Your edit was saved" or "This page has been added to your watch-list" {There may be others}. I.E.: When I click on save I don't need a confirmation of success my action, only a notice in case it didn't worked, which we already have. Pop-ups like this just add to page loading time and have no practical use at all. Enhancing the interface is one thing, adding useless and annoying features seems to me just pleasing the programmers playing around with silly additions that nobody needs or wants. I sure understand that they in part live in a different world, not spending much time if any at all on what editors actually looking for. The last notification system is just the latest example of how the IT guys get ahead of the editors and implement changes that are not widely accepted but forced on them anyway. I'd like to hear some honest answers, straight forward and w/o any excuses. Thanks.TMCk (talk) 01:42, 11 May 2013 (UTC)

I agree. I don't really like either of those new features and wish I could turn them off. I don't really like the new notification feature either (except that it mentions things outside the talk page sometimes). Kumioko (talk) 02:38, 11 May 2013 (UTC)

Actually, the saved edit feature provided a statistically significant boost to the odds of newcomers staying around and contributing more. You may be confusing "Misplaced Pages" with "a website where every feature is built to be immediately relevant to you". Ironholds (talk) 03:07, 11 May 2013 (UTC)

@Ironhold: You resonce is nothing short of an excuse w/o back-up.TMCk (talk) 03:19, 11 May 2013 (UTC)

• "Edit saved": See Giving new Wikipedians feedback post-edit and meta:Research:PEF. It disappears after 3 seconds.
• "X has been added to your watchlist." Clicking the watchlist button used to send the user to an entirely different page. Confirmation is a good thing, especially for new users. It disappears after 3 seconds.
• These 2 items ^^ are in the sitewide javascript, and are good for new users (who we're trying to encourage), and "disabling" it for individuals would not decrease page load times. Not even by a millisecond.
• Notifications: We (Wikipedians) have been asking for better notification-systems (and better talkpage-threading systems) for years. Various groups of developers have pounded their heads against these incredibly complex problems for years and years. We're now getting the first taste of that software update, which will vastly change (and thereby horrify some people) the talkpage system. I, for one, will be happy to not have to explain how to "sign and indent your talkpage messages" and that "no, there's no way to be notified when a discussion you've contributed to (or are interested in) has been updated". I've been unimpressed with the ranting and insults that some editors have been throwing at the devs recently. Yes, there was a major problem for the first week of Echo, and now it's fixed (IPs now get hard-to-ignore colored banners again). Smaller problems will also be fixed as time goes on (links to diffs, etc). They'll be fixed a hell of a lot faster if bugreports weren't mixed together with insulting diatribes. Being Rude is Not Magnificent. –Quiddity (talk) 04:07, 11 May 2013 (UTC)

• You may be my new favourite person, good sir. Ironholds (talk) 08:08, 11 May 2013 (UTC)

+1 — Scott • talk 12:30, 11 May 2013 (UTC)

Edit saving confirmation: How to turn it off

The edit saving confirmation can be turned off by adding .postedit { display: none;} to your common.css. -- Toshio Yamaguchi 08:48, 11 May 2013 (UTC)

Ditto for watchlist confirmation, by adding .mw-notification-tag-watch-self {display: none;} - grumblejustneededapoliterequestgrumble. –Quiddity (talk) 20:02, 11 May 2013 (UTC)

• Thanks Toshio Yamaguchi. At least I can get rid of one annoying feature (even so I should be able to turn it on or off in my preferences but for such, there is too much ignorance from computer freaks that think they know what's best for all of us). Again, thanks for helping me disable one annoyance. If you you have other scripts on hand that works on the "added to your watchlist" popup or any other feature that adds to loading time and might not be wanted or needed by longterm contributors please let me know, here now or on my talkpage later. Much appreciated, TMCk (talk) 22:27, 11 May 2013 (UTC)

  There are hundreds, if not thousands, of these "features". It's not possible for create a page that will list every single possible feature that someone might want to change, and every possible alternative for that feature, and have that page actually be useable by a human. If you want total control, then you will have to get your own website and run only the version of Mediawiki that appeals to you. If you don't want to do that, then you'll have to find a way to live with consensual reality, which is that WP:You don't own Misplaced Pages, which means that the website can be changed at any time without your (or my, or our) consent or knowledge. This is the basic fact of wikilife: This website is not owned by the users. This website is owned by a non-profit corporation, whose legal purpose is not running the website in a way that gains your approval.
  As for the specific examples you list, I've been very grateful to see the watchlist message on the multiple occasions when it didn't add the page to my watchlist correctly, and the "Your edit was saved" has occasionally been reassuring (far more reassuring than silence if the previous action produced a blue screen of server unhappiness). I'm pretty good at ignoring positive confirmation messages (I have more skills to verify that it worked than a brand-new user, after all), but I am pleased that these exist and that someone isn't optimizing this website for power users like me. WhatamIdoing (talk) 22:39, 13 May 2013 (UTC)

  Sure it's possible. Firefox did it. Certainly not something you want on the main preferences page, but hey, it is possible. -— Isarra ༆ 15:19, 16 May 2013 (UTC)

  Are you thinking about Firefox's "about:config" system, which is the most frightening geeks-only prefs page I've seen for years? I honestly don't believe that page is useable by normal people. WhatamIdoing (talk) 00:46, 18 May 2013 (UTC)

  As a non technical but very heavy user , I too would like a secondary page giving clear and simple ways to alter aspects of the interface. there are all sorts of tweaks I would like to make,to focus on the parts i use, and I edit enough to make it worthwhile to go to the trouble. (like when I was spending 8 hours a day writing in MSWord, I had several dozen of customized commands and buttons, none of which required actually learning the macro language.) This is something which can be customizable without interfering with the function of the site for anyone else. BUT I ask whether having extensive local css would slow down page loading or saving? DGG ( talk ) 23:27, 17 May 2013 (UTC)

  but forthe feature mentioned, I find the confirmations being discussed here exceedingly useful, and they have saved me from many errors. DGG ( talk ) 23:27, 17 May 2013 (UTC)

SI Units of measurement

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

As an engineer I strongly recommend that all articles in Misplaced Pages should use only SI UNITS as far as measurements are concerned. The IMPERIAL UNITS should be discarded completely. There is no purpose in using different types of measurements in the 21st Century, 3rd. Millenium. If there is an international system to express measurements, let's use it only.200.148.82.67 (talk) 14:43, 13 May 2013 (UTC)

English Misplaced Pages is written for a general English-speaking readership, not only for engineers and scientists. WP:MOSUNIT already recommends SI units for articles about scientific topics, but in the US and among older readers in the UK and in some other English-speaking countries SI and other metric units are not widely understood, so we should use both systems in other articles. Phil Bridger (talk) 14:51, 13 May 2013 (UTC)

Right. The sum of all human knowledge must include imperial measurements for a minority group of English-speaking users because the English language, which insists on being the world's lingua franca, can't adopt international systems like the metric system or the International System of Units. ChristineBushMV (talk) 19:00, 13 May 2013 (UTC)

(after edit conflict with TortoiseWrath) Are imperial and US customary measurements not part of the sum of all human knowledge? Misplaced Pages's job is to present information in a way that its readers can understand, and, for many of our anglophone readers, this means including non-SI units alongside SI units. My personal preference, as someone who is old enough to have been brought up on imperial units and £sd, is to use SI and/or other metric units, but for much of our readership, especially in the US, these are gobbledygook. Phil Bridger (talk) 20:46, 13 May 2013 (UTC)

• Unimaginably strong oppose. As a scientist myself, I use SI units daily; though I would favor their exclusive use, it's simply not the case, and a majority of our readers (non-scientist Americans) would be completely alienated by values like "6 Mm," "190 kJ," "8.3 dm," and "124 kPa." These units are great, and I'm of the opinion that they ought to be used by all, but Misplaced Pages does not take sides on social issues, and this is certainly one of them. It's still best to display those measurements alongside "2.317 million sq. mi," "45 Cal," "8.8 quarts," and "36.6 in Hg," respectively.  — TORTOISEWRATH 20:37, 13 May 2013 (UTC)
• Recommendation duly noted. Praemonitus (talk) 23:46, 13 May 2013 (UTC)

New template

Hi I would like to propose that template which people can put on templates and projects and articles be created so that they can take the page they want to be created. Paladox2014 (talk) 13:56, 15 May 2013 (UTC)

I really don't understand tis proposal, are you meaning to say we should create a template that should notify editors a page needs editing? Cuz if so, I believe that exists. Tech Addict, Fan-Ficion Writer, and Aspiring Filmaker 14:37, May 15, 2013 (UTC)

As I understand it, Paladox means a template like this:

If not, then Paladox needs to clarify the proposal, as in that case I don't seem to understand as well. -- Toshio Yamaguchi 15:02, 15 May 2013 (UTC)

Wouldn't it be better to just start the article, maybe adding a template:under construction. Rmhermen (talk) 16:34, 15 May 2013 (UTC)

This sounds like a WP:OWN issue. Misplaced Pages editors don't get to "reserve" certain articles they intend to create, this isn't a race or contest, and if someone else does create an article you had intended to create, there are no rules preventing you from working on it. --Jayron32 03:31, 17 May 2013 (UTC)

Mandatory expiration of indefinite edit locks

Indefinitely protecting articles leads to the so-called "mission creep" where an increasing number of pages become locked indefinitely, creating a divide between users (who often have little interest in administrative matters and will not contribute to articles) and a priveleged administrator group. This is counter to Misplaced Pages's inclusive attitude and there is no basis for indefinitely protecting an article, as current attitudes towards a wide range of topics are not necessarily indicative of attitudes several years from now.

I have been viewing the list of protected pages here (Category:Wikipedia_protected_pages) and have found several examples to demonstrate this, the most notable being (Laura_Wilson, protected 2009), and an extensive number of articles which are semi-protected from random edits with no reason listed under the protection log.

Proposal: These articles should be de-protected in a graded manner with a set timeline. If articles are extremely controversial, then the articles should be protected for a maximum of five years.

Considerately, LT90001 (talk) 12:45, 16 May 2013 (UTC)

Duplicate section removed Often, these pages are protected for other factors. They are often unprotected upon request at WP:RFPP. Overall, I can't see any benefit to mass-unprotecting all of these pages - which may have been protected at the subjects request, or due to a sockpuppetry spree, or other factors. Also, the article you linked to (Laura Wilson) is protected with the reason "BLP issues - please email me before removing". Therefore, I can't see how this will gain consensus. Mdann52 (talk) 12:56, 16 May 2013 (UTC)

 : I'm sure many articles are protected for good reason. I'm arguing against the indefinite nature of these protection. indefinite is a very long time. LT90001 (talk) 23:37, 16 May 2013 (UTC)

Some things are meant to be protected indefinitely, like Main Page and Template:Infobox, because the risk of vandalism is just too high. -- King of ♥ ♦ ♣ ♠ 02:37, 17 May 2013 (UTC)

It is not an onerous step to request unprotection at WP:RFPP for any article which is protected which you believe should be unprotected. Indeed, it happens several times per day. --Jayron32 03:29, 17 May 2013 (UTC)

I understand that those 'root' pages need to be protected, but if you look on the list Category:Wikipedia_protected_pages_without_expiry, there are a huge amount (1,652) on the list (although several are probably misclassified). I think it's presumptuous for editors to indefinitely lock certain articles, and gaining the ability to moderate all changes.

I specifically refer here to articles placed under protection that has lasted over a year.

• It is switching from an inclusive model of editorial role to a gatekeeper model of articles.
• Moderated input is against Misplaced Pages's interests and ethos.
• Simply seeing a lock, I suspect, is enough to deter users from randomly editing (which is scarce enough as it is).
• The rollback mechanism already exists.
• Editorial misuse is possible, especially if reasons are not openly stated on the protection log.
• Similar cherry-picking of content in line with an editors' interest is plausible. Although unlikely, an opaque system can't be monitored effectively.
• Changes in world events, societal attitudes, and the short attention spans of trolls for many articles means that a perpetual edit lock or moderated edits is not warranted.
• Although an apparatus for manually de-protecting exists, but it is not fair for the majority of Misplaced Pages users to know about or have to use this obscure mechanism.
• There is no reason why vast majority of indefinitely protected articles should be protected indefinitely. This means forever! Why not just a year or two and then subsequently renewed?

Can anybody see my point of view here on this? I just think it has the potential for abuse, deters random edits, and is unwarranted for the vast majority of pages! Indefinite is a very long time! LT90001 (talk) 00:32, 18 May 2013 (UTC)

Comment LT90001 probably doesn't realize this, but Category:Misplaced Pages protected pages without expiry lists pages with any form of protection applied to them. This includes Misplaced Pages:Pending Changes, Semi-protected pages, and move-protected pages, as well as pages with full protection. So really, the 1,652 number isn't as bad as it seems. Howicus (talk) 00:50, 18 May 2013 (UTC)

Comment Administrators do not generally lock pages they are active editors of (vandalism-prevention is sometimes an exception) and they do not lock them and then moderate what changes are made to the article. Usually someone asks for page protection, an uninvolved admin decides if it is appropriate and for how long, and gives a reason in the protection log. Other admins might change this although they probably will ask the first admin about their reasons. The admin who locks an article is generally not involved in processing edit requests on the talk page of locked articles. That would be to much like WP:Own. Rmhermen (talk) 17:27, 18 May 2013 (UTC)

Teahouse for Spanish Misplaced Pages

I want to create or help to create like a Teahouse but in the Spanish Misplaced Pages. It sure will help.??? Thoughts?? User:Technical 13 thinks it is a great idea Can anyone help me??...Thanks Miss Bono (zootalk) 14:13, 16 May 2013 (UTC)

Contact user:SarahStierch who was very involved in the creation of the Teahouse. I don't think she knows all the technical details, but I bet she knows who does, and she should be able to give you excellent advice on how to proceed.--SPhilbrick(Talk) 01:33, 18 May 2013 (UTC)

I'm most certainly volunteering to help out and I am starting a plan in my sandbox. It may take some time so I may be beaten to it by Sarah! Chihin.chong (tea and biscuits) 20:05, 21 May 2013 (UTC)

Hatnote proposal

A few months ago I wrote an “Introduction to” article and an “Overview of” article to complement an existing article. I notice that neither or these two articles are getting many hits compared to the original article. A similar observation was made at Talk:Angular momentum#Suggest merge. Could this be because the hatnote associated with the original article is not particularly prominent. I designed an alternative hatnote which is shown below:

I would like to try this out for a week or so on the article Metric system to see whether there is an increase in the hit rate of the “Outline of” and “Introduction to” articles. If this does result in an increased hit rate, then it would not be difficult to create a template with a few standard messages. Any comments? Martinvl (talk) 19:44, 16 May 2013 (UTC)

I think it isn't an inherently bad idea, although the notice is a bit large--although that is kind of the point. :P In moderation, though, I personally don't have a problem with a trial, although maybe a slightly smaller size would be preferable. Theopolisme (talk) 20:46, 16 May 2013 (UTC)

Hatnotes and notices are part of the interface, so their very presence takes away space from the article. Presumably viewers came to read the article, so anything that detracts from that experience is not a positive. I think we need smaller hatnotes, not big distracting banners. Praemonitus (talk) 23:22, 17 May 2013 (UTC)

No to this specific proposal, we don't need a hatnote that looks like a maintenance template. I have no opinion on some other kind of hatnote. Anomie⚔ 21:09, 19 May 2013 (UTC)

@User:Praemonitus: Yes, I agree that readers came to read this article, (in this case Metric system). However many readers might find it too technical, so I want to tell them that they might find Introduction to the metric system more appropriate to their needs.

@Everybody: Taking on board what others said, here is an alternative layout.

Martinvl (talk) 21:01, 22 May 2013 (UTC)

Still looks too much like a maintenance template to me. Anything with an mbox style will. Anomie⚔ 21:02, 23 May 2013 (UTC)

Another proposal:

I have tried using small text to enable the crucial question to be highlighted. Also the use of blue rather than red or orange is less "hostile".

Martinvl (talk) 13:51, 24 May 2013 (UTC)

RfC: Pending changes Level 2

An RfC is open on whether to implement pending changes level 2 protection, closed in a previous RfC as "no consensus". Deadbeef 06:14, 18 May 2013 (UTC)

Chat box/ Automated Discussion Room

Convenience Over Discussion through Chat Box

Although I am new to Misplaced Pages editing,my suggestion is that, all us Wikipedians can actually discuss issues and improvements via a direct automated chat box similarly like the Facebook or Twitter where everyone could have direct messages conversed throughout every webpage(s) related to Misplaced Pages- similar that to a chat room.

Talk Page

Improvements on Talk pages are necessary. The concept of Facebook or Twitter chat boxes to channel message can actually be upgraded through the talk page(s) of Misplaced Pages, where talk page is sometimes more complex and somehow, misleading. Chat box is more often a trend for today's computer generation system as it provide a speedier conversation process to all Wikipedians in order to have a smooth analysis, discussion, and most importantly time saving factor- whereby all these features could be considered as cost free and a more convenient element for a chat box system.

Security and Legal (only to those who joined in as Misplaced Pages members)/(Account holders)

Privacy and personal security are always the priority for every online users as I basically think that Misplaced Pages could be a safer social network that could protect accounts and secure private and confidential data of user's account from other online spywares or cyber threats. Generally, chat box is often a suitable method to communicate with each other as we could assume that the only people who could edit another person's Misplaced Pages web page contents must be encouraged to create an account and add on any other article's owner(s) into a group list, in which this is a system being widely applicable by websites like Yahoo, MSN, and G-mail. This design can actually help to protect all users' Misplaced Pages articles from unwanted online vandalism such as: plagiarism, or any other copyrighting violations, as well as editing with false information and issues that might cause sensitivity mainly described as (racism, unnecessary criticism, profanity and so on.) Although based on Human Rights Act 1998, officially, each and every individuals are given a right to criticize and participate into opinion based discussions, but according to the law some countries have tight statutory legislation. Censorship is required to avoid any legal issues and misrepresentation. Anyway, back to the chat box proposal, I think it's a good idea to come up with something fresh and new that will contribute to the Misplaced Pages with even greater convenience.

This proposal accepts any kind of discussion(s), if there are better ideas, please feel free to contribute by dropping by and suggest useful ideas. No offensive words or argument(s) are allowed. Only opinion based and pure discussions are needed. AAZIO (talk) 08:14, 18 May 2013 (UTC)

• Why? In my opinion, what we currently have perfectly fits Wikipedias needs. What would that discussion system achieve that we cannot currently achieve with our talk pages? Granted, the current system might be confusing for many new users. But I see too many potential problems with such a system (stalking, harassing .... ) which in my opinion would outweigh the benefits. -- Toshio Yamaguchi 12:45, 18 May 2013 (UTC)

• A further comment You say:"the only people who could edit another person's Misplaced Pages web page contents must be encouraged to create an account and add on any other article's owner(s) into a group list"

That isn't going to happen per the 2nd point of the Wikimedia Founding principles. -- Toshio Yamaguchi 12:51, 18 May 2013 (UTC)

• The point of Misplaced Pages talk is to advance the encyclopedia (improving the articles, better organization, attractive presentation) and all of that discussion needs to be accessible to all who participate and records of it kept so we know when and why and by whom. Our current talk pages do that although not always easily. Chat does not seem to me to fill these needs. We don't have a need for real-time chat - questions might not be answered for days or months - there is no time limit. Also there is a new talk page system being developed called ... Rmhermen (talk) 17:07, 18 May 2013 (UTC)
  • I confirmed that protection can be added without a reason - which rather surprised me. Beside my test edit I only noticed one of the last 500 protection log changes without a reason. Still I would support a change requiring a reason to be present (We already have for a version of this for article edits). Rmhermen (talk) 17:45, 18 May 2013 (UTC)

• To:Toshio Yamaguchi"Well, I can see that there are some good feedback based on this proposal. As per your opinion,I kinda agree with you about the potential problems with the so called "chat system" that I've proposed (stalking, harassing....) in which it might eventually be cyber threats. That is why I have proposed some security measures based on the edits. As per Rmhermen, he pointed out that he supported security system to be developed or should I interpret: "improved" adequately with reason to be present. So in my opinion, it may not "outweigh the benefits" as you've mentioned, reason: because everything is worth to be given a try, especially for security and protection. I agree with the registration (as according toWikimedia Founding principles 2nd point) and chat box proposed by me sound kinda absurd though, but since you said although "the current system might be confusing for many new users", I hope to hear from you that, are there any other improvements that could be proposed to avoid such case? If Misplaced Pages could construct a rather easier method for new users, wouldn't it be great to have so many people to express their talents through editing articles based on Wiki system? Let's put the talents aside first, editing is kinda useful for most users to share what they know to the rest of the world, so I hope you can send in more feedback to improve such system so that in the future it will reduce the complexity of edits with Wiki. Anyway, thank you very much for your utmost kind advice, because I'm actually new to Misplaced Pages myself (just joined in since 13 May 2013). Hope to hear from you. Let's make Misplaced Pages a better place for learning. AAZIO (talk) 03:55, 19 May 2013 (UTC)
  • As WhatamIdoing points out below, Flow is already being worked on, which tries to address the issue with the current system being confusing for new editors. However that doesn't really seem to be like a live chat (at least not at this point). -- Toshio Yamaguchi 22:49, 21 May 2013 (UTC)
• Major changes to talk/discussion approach are already being planned. WP:Flow will first replace user talk pages, and later (possibly much later) spread to other discussion pages. This is a massive, major, complex change. The devs have done a lot of study on how different types of users interact with the existing talk pages (which are basically a kludge created because a proper system couldn't be created at the time), but they're just getting started. It's going to require a lot of time, energy, and patience while they get the new system sorted out. WhatamIdoing (talk) 18:52, 19 May 2013 (UTC)

RfC regarding a proposal to include a sentence about Carnap's paper in Quine's dispute of this paper

Discussion notification: Should Hindi Misplaced Pages be included among our mainpage interwiki links?

Please add your comments on whether or not we should have an interwiki link to Hindi Misplaced Pages on our mainpage in this discussion. Thanks, ThaddeusB (talk) 02:38, 19 May 2013 (UTC)

Derive a More Colourful Misplaced Pages in the Future?

I'm overwhelmed by curiosity over Misplaced Pages's style of edit, but at the same scope, I find that besides plain and simple webpage(s) being brought up and edited in Black and White, can we just think of transforming Misplaced Pages into a more colourful, lively, and attractive source for learning? My point here constitutes about, if something like a colour tool kit could be manifested into the Toolbox at the Wiki sidebar, then editors could actually use colour in their edits in order to make Misplaced Pages's webpage(s) to be attractive enough for learning and researching. Basically, majority of the human beings could learn effectively through colours based on quantitative habits. (revised)

Further Idea(s): Kids love colourful views, for example, if Misplaced Pages could come up with an idea by assembling/recruiting more experts to create colourful mind maps in which children may find these sources interesting and attractive + less complicated words used. (revised) This, in turn can also help younger viewers to understand better, effectively, and efficiently. Although still considering myself new to Misplaced Pages, This topic can still be improved and discussed through more opinions and suggestions. Feel free to join in for more brain storming session as I believe that ideas are light bulbs that updates the societal changes. Everyone, let's triumph for a better future through ideas and knowledge.AAZIO (talk) 06:31, 19 May 2013 (UTC)

• Opinion(s):
  • I'm not exactly sure what you're asking for. Are you wanting colourful backgrounds? Side bars? The text itself? I hardly think any of that furthers our encyclopedic mission. — Huntster (t @ c) 07:09, 19 May 2013 (UTC)
    • Huntster, Everything mentioned as above by you, and why is that so? things like mind maps can actually be done if further research are carried out. Can you explain why? Anyway, Thank you for the opinion.AAZIO (talk) 07:28, 19 May 2013 (UTC)
  • We already encourage the addition of images to articles, which can be of many kinds such as photographs, maps and diagrams and should make use of colour where appropriate. Your language above about memory capacity is not quite clear, but if you are saying that over 70% of memory capacity is used for colour then that claim is simply bizarre. Which experts' research came up with this figure? It sounds more like the kind of junk statistic that would be presented in a cheap course in design or marketing rather than anything based on psychological research. Phil Bridger (talk) 08:14, 19 May 2013 (UTC)
  • @ Phil Bridger Sorry, you can mark me wrong about the junk statistic, since it is an opinion based discussion, but I need some solutions. All we want is to discuss about improvements and changes, not just comments. True, I agree about my language may be unclear, perhaps I should change it to "brain power" instead. I agree with you that "photographs, maps and diagrams should make use of colour where appropriate", but those are all different from mind maps. If you have better ideas or solutions, then do you mind sharing them out? We are talking about improvements anyway.. AAZIO (talk) 08:43, 19 May 2013 (UTC)
    • Is there (already) consistent use of colour in tables? Or does this vary on a project-by-project basis? I find some colour-coding, in the absence of a key, confusing. e.g. is it obvious here United Kingdom in the Eurovision Song Contest#Contestants what the dark red signifies? Martinevans123 (talk) 11:35, 19 May 2013 (UTC)
  • We actually can use color in our edits with HTML, but I've never seen a reasonable use for it other than in tables where it corresponded to a value (e.g., political parties). This type of thing should not be done by individual editors because it will just turn Misplaced Pages into MySpace, a gaudy mess. If there's any scientific benefit to adding colors and decorations, it needs to be done by an outside group that can actually prove it's useful. Otherwise we shouldn't touch it with a ten-foot pole. I have no confidence in editors redesigning the whole site ad hoc and throwing pink and yellow boxes everywhere because "It could help readers differentiate between each thing". —Designate (talk) 12:01, 19 May 2013 (UTC)
    • You don't need to know HTML. You can use color right now if you want. I just don't see the point. This is supposed to be a reference work, not a fruit salad. WhatamIdoing (talk) 18:59, 19 May 2013 (UTC)

1. Brainstorming is best carried out over at WP:Village pump (idea lab). This page is more for well-defined proposals.
2. See Misplaced Pages:Writing better articles#Use color sparingly - for reasons of accessibility, and to avoid turning off the various demographics who would not appreciate widespread color-for-color's-sake.
3. See This recent thread regarding mindmaps, and also this blog post about Wikidata tools that are under development. (They're a long way off, from being a stable resource, but will be fantastic when they arrive).

HTH. –Quiddity (talk) 02:12, 22 May 2013 (UTC)

• I'm not at all clear how this would be beneficial, but I can think of one big way in which expanding our reliance on color could be substantially problematic. Nyttend (talk) 23:28, 22 May 2013 (UTC)

Linking subjects to books at your local library (Forward to Libraries)

This Request for Comment is seeking proposals from the community to decide how to use the newly created Forward to Libraries (FTL) service that is running on Wikimedia Labs.

Overview

We now have a new tool on Wikimedia Labs called Forward to Libraries (FTL).

The same way {{coord}} provides readers with a helpful resource (finding the location of things), FTL provides a helpful resource to readers by helping them find books, reference material and other reliable sources on a subject at their local library. The service not only helps readers find detailed information from reliable sources, it can also be used by editors to expand and cite our articles.

This RfC is to determine how to make the best use of this new tool. 23:58, 19 May 2013 (UTC)

How FTL is implemented

The library templates produce links to a server script on Wikimedia Labs that redirects to searches in a local library's online catalog or other discovery system, so that users can find appropriate reading materials there. (Users can register their preferred library target for "your library" links; otherwise they can choose from the overall list of libraries. There are currently over 200 local library catalogs known to the service, along with larger catalog aggregations like WorldCat, as well as a catalog of free online books. More libraries are added regularly, and users can also go to a form (linked further down this page) to request specific libraries be added. The data on library links is published at Github, and I'm preparing scripts and documentation so that other Wikimedia developers can import and update this data as needed if I'm not available.)

The server script tries various techniques to formulate appropriate library catalog searches. If VIAF or Library of Congress identifiers or terminology are available, the forwarder will normally issue a search based on the corresponding subject or author headings, since those are what are commonly used in library catalogs. The forwarder can also try to convert the Misplaced Pages article title to a standard library heading based on algorithms and data that I will be be publishing in the near future as well. If no officially "authorized" library heading can be found, the forwarder will generally try a keyword search based on the Misplaced Pages article title.

I'd be happy to give more information to folks who might be interested in improving the implementation or helping maintain the Wikimedia forwarder. JohnMarkOckerbloom (talk) 01:32, 21 May 2013 (UTC)

How should FTL links be presented

The Forward to Libraries (FTL) tool is currently used in various templates as both boxes and inline links. The box template is {{Library resources box}}, and the two main inlined link templates are {{Library resources about}} and {{Library resources by}}. There are some lower-leval templates for single links {{Library link about}} and {{Library link by}}, which are normally not used directly.

• Use in infoboxes The obvious place for links would be the External links section, but that's not how we use {{coord}}. We put that at the top where people will see it because it's a benefit. Similarly, I think the FTL link would be better used in a library resources sub-section of our infoboxes. That's where readers naturally look for information. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)

What articles should use FTL

• Use in most articles Perhaps not current events or popular culture subjects, but most everything else would probably benefit from having an FTL link. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)

FTL discussion

Misplaced Pages was not meant to be a final destination for readers. It was meant to provide an overview and to point readers to reliable sources with more detailed information about a subject. Linking a reader to books down the street at their local library seems like a benefit to both our readers and editors. 64.40.54.57 (talk) 23:58, 19 May 2013 (UTC)

I think the proposal is that an extra field be added to many infoboxes, although discussion is invited on any other suggestions. Is there an example of how it would appear? Johnuniq (talk) 01:18, 20 May 2013 (UTC)

• Frankly the list of libraries signed up is way too small, and this form of search will not produce good results for a vast number of articles. Premature. Johnbod (talk) 02:03, 20 May 2013 (UTC)

@Johnuniq, my particular proposal was for the link to be used in an infobox, something like this.

This is just a quick and dirty example that could be changed in as many ways as {{infobox}} will allow. Editors are already using the FTL tool in {{Library resources box}}, etc.. 64.40.54.57 (talk) 02:16, 20 May 2013 (UTC)

Johnbod, the libraries don't need to sign up, all that needs to happen is for the url of the library OPAC to be added to the database, which is being done by request at this point. I don't know if there's any limit to the number of institutions that can be added to the service. The libraries in BC are there because I added a request, which you could do for your locals. The Interior (Talk) 02:38, 20 May 2013 (UTC)

Here's the request page: The Interior (Talk) 03:43, 20 May 2013 (UTC)

• Comment. I don't think FTL is helpful. I tried using it moments ago and found out that Google books search was much more helpful. Mohamed CJ (talk) 11:23, 20 May 2013 (UTC)
• Comment I really don't think 'further reading' should be in the infobox. And can we restrict searches so that it finds relevant books? Edgepedia (talk) 18:46, 20 May 2013 (UTC)
• Comment, why in the infobox? Wouldn't this be more of an external link, or a see also item similar to how we treat wikicommons, or wikisources templates?--RightCowLeftCoast (talk) 06:52, 21 May 2013 (UTC)
• Sounds good This is a definitely a good idea. I have just seen Bird article and there it is working wonderfully. The point Mohamed CJ has mentioned is valid too— most of the readers of Misplaced Pages will not need/never check those "find in your library" links. But, I personally strongly endorse the idea to provide an option to learn more about a subject. For example, I don't think not too many readers check Special:BookSources, but, that's a superb option! FTL can be a good alternative of "External links" and "Further reading" (since I can see it is providing "online books" lists too). About Johnbod's comment, that is correct, I am specially worried about WikiProject India articles and libraries, but, it can not be grows, until it is started. In my opinion, infobox should be the best place to add these links only if there are really some good material in the database! --Tito Dutta (contact) 02:35, 22 May 2013 (UTC)
• Comment - Is there any way to automatically match&update the list of libraries that FTL needs, with the extensive list that we already have compiled at Misplaced Pages:Book sources? The auto ISBN linking that we have works wonderfully, (eg ISBN 9780441012039), most of the time, and it would be a shame to have to manually replicate that entire list of libraries. –Quiddity (talk) 02:51, 22 May 2013 (UTC)
  • Thanks for your comment. I'm starting to go through that list now, when I don't have other explicit requests, concentrating primarily on the English-language libraries (since subjects and author names, unlike ISBN's, are language-specific). So I'm hoping that before too long lots of libraries in one will be in the other. I do need more detailed catalog linking information than just ISBN searches, but it may be possible for my templates and the BookSources service to draw on the same unified datasets down the line. I'd be interested in hearing more from anyone who's involved with or knowledgeable about the BookSources implementation. JohnMarkOckerbloom (talk) 18:28, 22 May 2013 (UTC)
• Comment2 - Using a random article example, George Carteret, I'd disagree with placing a link in the infobox (because we generally prefer to avoid external links within the body of an article as much as possible), plus not all articles have, or will ever have, an infobox, but.... possibly "Search Libraries" in the lefthand sidebar's Toolbox section? –Quiddity (talk) 02:51, 22 May 2013 (UTC)

In case FTL data is really helpful, in my opinion, placing it in infobox will make it more prominent and increase chance of getting noticed. In Infobox, article body ISBN links are placed which finally take to external sites. But, the only factor is— the amount and value of the data we are presenting! --Tito Dutta (contact) 03:04, 22 May 2013 (UTC)

• Comment - should be like any-other external link. That is - in the external links section only.Moxy (talk) 17:29, 22 May 2013 (UTC)

• This looks very much like an attempt to reinvent the Worldcat wheel. There is no chance of this ever being as comprehensive as Worldcat. Phil Bridger (talk) 18:59, 22 May 2013 (UTC)
• Support. I can't understand Phil's objection; as I read it, this is completely different from Worldcat. Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location that deal with a specific subject. It seems to be good for saying "Since you want to learn more, go to your local public library and borrow Title1 or Title2 on this subject", and that's a wonderful thing for us to be able to provide — basically like a geo-located and automated ==Further reading section. Nyttend (talk) 23:20, 22 May 2013 (UTC)

"Rather than helping readers find all the locations of one work, it's meant to help readers find all the works in one location" that is an excellent description of the difference between WP:Forward to Libraries and WorldCat. Thanks very much for that, Nyttend. 64.40.54.104 (talk) 02:11, 23 May 2013 (UTC)

Worldcat has keyword search of book titles, just as FTL appears to, and for each book will order the list of libraries by distance from your indicated location, so will not only find what is in your local library but will also tell you the closest library that has a book. Phil Bridger (talk) 12:15, 23 May 2013 (UTC)

Personally I prefer WorldCat because I use several libraries, and would have to set this to one of them only. (WC goes by area code, if you're willing to supply it) But I think that for most people the proposed link would be quite sufficient, and having it right out there is good. BTW, I note that WorldCat is relatively useless outside the US and Canada, listing only the very largest national and university libraries. DGG ( talk ) 22:26, 24 May 2013 (UTC)

Making a Special page Recommended Watchlist.

What about making a Special page Recommended Watchlist in which Admins can add pages and its link can be near current watchlist. So pages which need more attention will be watched through recommended watchlist special page, for a certain period of time.

Also protected pages will be automatically included in the recommended watchlist after the protection time is ended, for a certain period of time. KhabarNegar (talk) 00:14, 20 May 2013 (UTC)

Normal pH of the human body

What's the normal ph level for the human body? — Preceding unsigned comment added by 24.4.159.220 (talk • contribs) 16:35, 20 May 2013 (UTC)

This isn't the right place for your question. Try asking at "Misplaced Pages:Reference desk/Science". — SMUconlaw (talk) 10:39, 20 May 2013 (UTC)