*'''Support''' Most projects don't need local uploads, and having allowed it here is redundant at this point. [[User:Ktr101|Kevin Rutherford]] ([[User talk:Ktr101|talk]]) 03:06, 17 May 2013 (UTC)
*'''Support''' Most projects don't need local uploads, and having allowed it here is redundant at this point. [[User:Ktr101|Kevin Rutherford]] ([[User talk:Ktr101|talk]]) 03:06, 17 May 2013 (UTC)
*'''Support''' restricting to uploader group only, and immediately, with clean-up to follow. I spend a fair amount of time reviewing images uploaded here and most are out of scope, copied from Commons, or not tagged properly for copyright. What remains are suitable for Commons. Tagging them for {{tlx|nld}} results in no, or very delayed, action from the Meta sysops. I've raised this before that I don't see the point in actually tagging files for delayed deletion because nobody seems very interested in dealing with it, so let's move it to Commons. [[User:QuiteUnusual|QuiteUnusual]] ([[User talk:QuiteUnusual|talk]]) 09:14, 17 May 2013 (UTC)
*'''Support''' restricting to uploader group only, and immediately, with clean-up to follow. I spend a fair amount of time reviewing images uploaded here and most are out of scope, copied from Commons, or not tagged properly for copyright. What remains are suitable for Commons. Tagging them for {{tlx|nld}} results in no, or very delayed, action from the Meta sysops. I've raised this before that I don't see the point in actually tagging files for delayed deletion because nobody seems very interested in dealing with it, so let's move it to Commons. [[User:QuiteUnusual|QuiteUnusual]] ([[User talk:QuiteUnusual|talk]]) 09:14, 17 May 2013 (UTC)
** Tagging files doesn't always work as expected, no. If the tag adds the file to [[:Category:Deleteme]] (e.g. {{tl|NowCommons}} or {{tl|Delete}}), then it is shortly deleted. {{tl|No source}} has no notification template and the {{tl|Possible copyright violation}} template tells that you should use a non-existing notification template. The good thing with {{tl|Possible copyright violation}} is that it moves the file to [[:Category:Deleteme]] if the file hasn't been edited for 7 days, so that the file eventually is deleted. Maybe that feature could be implemented for {{tl|No source}} and {{tl|No license}} too, so that we won't have a three-year backlog. --[[User:Stefan2|Stefan2]] ([[User talk:Stefan2|talk]]) 12:08, 17 May 2013 (UTC)
Navigation for those who want to understand subject in unknown world.
Latest comment: 11 years ago1 comment1 person in discussion
Wiki's application had been the well known application in the world which allow us to understand things effectively. But when we talk on topic like making people educated as in college or university, it would be a tough job for any site. I had always wanted to understand everything better, though I find it hard to navigate the favorable article on the topic, indeed it provide the link to another article if particular topic is unknown but the main problem is, how to get the destiny which is unknown to user them self. You would need an ideal navigation and user interface to unknowns.
As I have been through such problem, I always like to suggest for the development of thing so called timeline, perhaps Wikiline! It would be a map in understanding the topic matter, rather than searching some random stuff in the topic people could actually read the topic more effectively. Everything had developed Itself with reference to time, Science, technology, society, politics, economics and so-on. Now articles describing the topic is linked by a timeline interface. This interface would allow us to navigate through time, like first come Galileo experiment then Newton and so on. It allow the user to see the reason for the development and let them understand and develop their perspective on the topic more accurately and effectively.In the interface I visualize this application as the Microsoft encarta's timeline with timeline on different topic selectable by the simple roll out. Though it would be very vast in every topic. Books, Musics, Movies e.t.c are arranged in author, Band or singer, or director, actor/actress e.t.c's biography arranged in timeline of About Personalities, Filtered according to the contribution place. Wiki, should also embed the Audio, Video, flash etc files to the articles. On lecture, Movies, Books, Songs etc. Posting it as an expectation to such well navigator of article, It would be my honor, to contribute to wiki society for any interface and conceptual problems.
-Ronit Ramdam
Of course! But for now, 1)a thorough use of the search engine features, and 2)clicking through the (diff'ed) sequence of a page history (if you're on a fast network), is enlightening enough for your prototype.
A category page is like your "topic". It has a history too, but its pages section is riddled with new and deleted, miscategorized and recategorized, pages that don't make for the solid history that could educate the public, like an "encarta" could. The history page sequence of a category page would show its subcategory section is riddled with category pagename moves and renames. The categories frame is likewise confusing. But you know what, in the future, you know, where ideals happen, a computer could generate notable events for your "wikiline" in a kind of programmable "hindsight" report whose criterion are simply that if the title is stable in time, (else if etc.), there is probably something to it that is worth looking into. But the end result will require creative intelligence, such as now available in people like yourself, to create them by hand. Cpiral (talk) 19:17, 21 April 2013 (UTC)Reply
Give bureaucrats the ability to grant the flood flag to non-admins
Latest comment: 11 years ago25 comments15 people in discussion
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.
There is sufficient support to allow bureaucrats to grant/remove the flood flag, but not such a consensus to allow admins the same ability. PeterSymonds (talk) 14:40, 28 March 2013 (UTC)Reply
Hi guys, I know we've have this discussion before but I was just trying to give a non-admin, User:Vogone the flood flag (he was sending out translation notifications) and found that as a crat I couldn't. I know I can remove the flag, but can anyone think of a reason why crats shouldn't be able to temporarily add the flood flag for a non-admin, given that I could theoretically give someone a temporary bot flag? Thehelpfulone01:04, 20 February 2013 (UTC)Reply
Sideline but I agree that admins could also grant this right. There are very few admins who actually work here and it would be in their interests to be able to do this. Those who don't work here won't even notice the change. --Herbytalk thyme14:20, 20 February 2013 (UTC)Reply
Past discussion can be found here for reference. My opinion has not changed since, though. So Oppose giving this ability to admins as it will allow administrators to grant pseudobot flags. Neutral for bureaucrats as I don't really like flood flag to be assigned to other users since I believe flood flag is for exceptional and personal use for admins and we should not worry if RC gets flooded for a while; however 'crats can already assign bot flags so I think it fits better for us to be able to do this. If a user expects to flood we already can assign a bot flag temporary which have the same effect. Nonetheless if bureaucrats are allowed to grant and remove flood flag from others, this should only be done following a well founded request. Mass hidden edits other than very very simple stuff should be community approved as it happens with bots. A policy change must follow too. Thanks. -- MarcoAurelio (talk) 15:01, 20 February 2013 (UTC)Reply
I don't understand most of your comment. I thought the "markbotedits" user right already allowed admins to mark any edit as bot or not. I don't see why admins shouldn't be able to set this flag for themselves at-will. Your comment reads as an attempt to needlessly keep power and control with bureaucrats. How very bureaucratic. :-/ --MZMcBride (talk) 17:15, 20 February 2013 (UTC)Reply
Sorry, that was my bad. That's what I thought the situation was here, which only added to my confusion. So this is just about non-admins, I guess. I agree with you, then. I'll clarify below. --MZMcBride (talk) 18:02, 20 February 2013 (UTC)Reply
I support allowing admins to enable or disable the flood user group on their own account. Admins are trusted users. The edits are still reviewable both at Special:RecentChanges and Special:Contributions. I thought admins could already apply the bot flag to any edit of their own currently (and one day, any action). The arguments for keeping this ability confined to the bureaucrat group are completely unconvincing to me. --MZMcBride (talk) 17:15, 20 February 2013 (UTC)Reply
Admins are already able to do this, on their own account. This discussion is about adding the ability to admins to add this right to other (non-admin) users, which can currently can only be done by a bureaucrat, but only by adding the user to the bot group. Savhñ17:20, 20 February 2013 (UTC)Reply
The initial proposal might have been that, but MZMcBride's comment was (sort of a) reply on MarcoAurelio's opposition to give this right to admins, which is also being discussed here (You yourself mention that in your vote). And yes, admins are able to give themselves the flood right. Savhñ17:28, 20 February 2013 (UTC)Reply
Just to confirm: admins can give/remove the "flooder" user right from themselves, and crats can remove it from others but can't grant it. What I'm proposing is that crats can also add the "flooder" user right to other users (but it would be used to give the right to non-admins, as admins can give the flooder right to themselves). Thehelpfulone17:49, 20 February 2013 (UTC)Reply
Okay, I'm vaguely more awake now. Why isn't Vogone an admin here? I don't see what problem you're trying to solve. The use-cases seem limited/rare. If someone is doing mass-editing here, they should probably have admin rights, I think? --MZMcBride (talk) 18:02, 20 February 2013 (UTC)Reply
Support allowing bureaucrats or admins to add and remove the flood flag from non-admins who need it, and completely disagree with MarcoAurelio's comment. I don't see any reason for the flood flag to be some "personal" thing, or to add people who aren't bots to the bot group temporarily. Ajraddatz (Talk) 21:59, 20 February 2013 (UTC)Reply
Are there cases where a user would be making a lot of actions here, would know what the flood flag is and how to request it, and we wouldn't want them as a local admin? The one example presented here (Vogone) seems like a case where the user should just be an admin. Are there other cases? --MZMcBride (talk) 22:03, 20 February 2013 (UTC)Reply
Not really possible. More than destruction of portals, the proposal (now withdrawn) was to make the portals into an automatic redirect to the right language; coupled with a more powerful mw:ULS, enabled for unregistered users and enhancing also interwiki (interlanguage) switching. At least the latter is sort of planned, but will take a while. --Nemo11:43, 23 March 2013 (UTC)Reply
Category for press coverage?
Latest comment: 11 years ago4 comments3 people in discussion
Using Wikidata shouldn't be a problem, in my opinion. Wikidata has already translations of all country names in all languages which have a Wikipedia article in their language edition. Regards, Vogonetalk01:24, 26 March 2013 (UTC)Reply
Meh … sadly Wikidata is and will be only deployed to Wikipedias for now. I forgot about the fact that Meta-Wiki is not a Wikipedia edition. But I am sure you could use the data already manually (c&p). Regards, Vogonetalk19:50, 27 March 2013 (UTC)Reply
History of Wikimedia
Latest comment: 11 years ago2 comments2 people in discussion
IIRC CLDR is correct. I guess you use monobook and that it's monobook unconditionally making everything in mw:personal tools lower case, right? I guess you'd have to file a bug against monobook; mw:ULS maintainers won't fight with unsupported skins I'm afraid. --Nemo23:17, 29 March 2013 (UTC)Reply
It doesn't unconditionally make every personal tool lowercase. The username is exempt, of course. :-) And Monobook is still supported. Yes, please file a bug in Bugzilla (if there isn't one already). I'd noticed this as well, I just hadn't gotten around to filing a bug for it. --MZMcBride (talk) 01:43, 30 March 2013 (UTC)Reply
I can confirm that this is lowercase in Monobook, but not in Vector. I didn't even realize that before! πr2 (t • c) 02:08, 30 March 2013 (UTC)Reply
Latest comment: 11 years ago4 comments3 people in discussion
Hello. I don't know if this is the right place for this so if it isn't, please point me to it. However I found a dead special page on every wiki I've tried. It is Tools -> Special pages -> Statistics -> List active users. The wikis I've tried is commons, en.wikipedia, sv.wikipedia, sv.wikibooks and this one (meta). - Averater (talk) 09:28, 7 April 2013 (UTC)Reply
Zero configuration namespace coming to meta near you
Latest comment: 11 years ago12 comments6 people in discussion
Hi, I am a new employee (and a very long time volunteer developer), working on Wikipedia Zero. My current project is to make adding new telecoms very easy and painless process, and to do that I would like to create a new meta namespace specifically for that purpose. We plan to have hundreds of telecom companies participate in this program, and we need to be able to scale easily, as well as to provide very comprehensive editing, visualization, and error detection capabilities. For complete details and complexities, please read Zero Architecture RFC. The new zero namespace will replace thistwo pages.
Having a separate namespace will allow us to:
Store all configuration as a JSON text, easily parsable by other programs
Perform exhaustive settings validation when saving, preventing accidental mistakes, verifying that IP ranges do not conflict with each other.
Have explicit permissions for telcos to edit just these pages, with a possibility of even more granular per/user control.
Eventually attach a form editor to simplify the process even further.
Rely on meta's proximity to the rest of production environment for stability and high availability.
Update: Per Thehelpfulone suggestion, we will need a new security group as well (zeroadmin) that will have write access to this namespace. At first it should only be the engineers involved in the Zero project, and once all the validation code has been implemented, it can be extended to more people, including Telcos.
Have you considered merging this to the Schema namespace, possibly changing the name if necessary? Creating a new namespace for every new application/extension is not particularly neat. --Nemo06:32, 9 April 2013 (UTC)Reply
I have considered it, but it does not solve most of the goals - schema has a very different fundamental structure, requires very different validation, visualization, and editing tools. This makes sharing a namespace much bigger problem than what it would solve. And I don't think we add namespaces for each extension, only the very few that require highly flexible and rapidly changeable wiki-based configuration systems, especially the ones where many people may be involved in changing it. --Yurik (talk) 16:29, 9 April 2013 (UTC)Reply
Should WMF post our fundraising AB testing retrospective on Meta?
Latest comment: 11 years ago6 comments5 people in discussion
The Wikimedia Foundation fundraising team is working on a big report on past AB tests of fundraising banners. The report will look closely at up to 100 tests performed in past fundraisers, demonstrating how we think we got the statistics right or wrong in each one. We'll be asking for comment and assistance from anyone interested in AB testing -- not only from the Wikimedia community. Each test will have many graphs. The finished report could include as many as one thousand graphs and 100 different pages. We will also be posting data sets to go with each test. We have a new reporting server where those datasets can be stored.
Is Meta an appropriate place to post that kind of report and host discussion with people inside and outside of the Wikimedia community? Zackexley (talk) 18:20, 10 April 2013 (UTC)Reply
What about having lots of people come comment and discuss here who aren't from the WM community? For example, people who will chronically forget to sign their posts! Zackexley (talk) 18:37, 10 April 2013 (UTC)Reply
The value of the graphs (both currently and into the future, as they become historical or not) is important to consider. If they're mostly valueless graphs, they probably don't need to be uploaded here (or on Commons), you could probably just link to a folder of the images on a server. (It's even possible to display the images inline without uploading them to a Wikimedia wiki using an obscure MediaWiki feature. That is, you could put the images in a folder on sillyserver.wikimedia.org and then link to them or display them inline here. It's something to consider.) That said, if the images/graphs are going to be valuable longer term, Meta-Wiki is a fine place to put them.
The same is true of text as it is with images. Meta-Wiki doesn't need 1,000 useless subpages. But it could always expand to host/house 1,000 valuable and neat subpages.
Latest comment: 11 years ago1 comment1 person in discussion
The mobile team in conjunction with the fundraising team is going to test out the new integration between the MobileFrontEnd and CentralNotice extensions. We will be doing this the next week (Apr 22-28th). What we will be putting up is a banner recommending users try out the new commons app (Banner). Specifically this banner will be targeted at logged in alpha/beta mobile users of en.m.wikipedia.org browsing in english and having a handset that we identify as an android device. If you have any problems please report them to Help_talk:CentralNotice/Mobile. Mwalker (WMF) (talk) 22:22, 19 April 2013 (UTC)Reply
We need "Meta:For Wikipedians"
Latest comment: 11 years ago3 comments3 people in discussion
I think that it would be useful if Meta developed a page as some of the sister projects have done that expresses the point and value of this site for Wikipedians. Often we see Wikipedians come here expecting it to be like the wikipedias (inherently rule-based) and we don't do well to explain our point of difference, the purpose, the benefits that we bring. Some examples of pages that I see we could look to for ideas are
I think part of the process of being a Wikipedian who metamorphoses into a beautiful Wikimedian is discovering these things on his own! Back in my day... Killiondude (talk) 02:51, 26 April 2013 (UTC)Reply
Latest comment: 11 years ago9 comments5 people in discussion
Apparently, Meta is a mess. I believe Manuel (User:80686) has brought up concerns about how hard it is to locate anything on Meta. [1]. He's started a chapters portal here. I thought with the recent clean-up and Pir's efforts, the categorization system was.....better than before. Can we do something to improve these pages? a clean-up drive or something? There were suggestions for opening up a new chapters: namespace on Meta a while ago, maybe something like that can be reconsidered again? Theo10011 (talk) 16:04, 25 April 2013 (UTC)Reply
I agree, we also have done a lot of clean up - we deleted all the old Help: namespaces in various languages last year, and have done a lot of categorisation work. I've been liberal in deleting old pages too (such as when I cleaned up all the OTRS pages on Meta). I'm happy to delete pages, but chapter people should help out too with the tidy up as they're mostly knowledgeable about which pages should be kept, which should be deleted and what goes where. If we did have a new namespace it would probably need to be called something else to include Thematic organisations etc too. Thehelpfulone16:58, 25 April 2013 (UTC)Reply
I know I should have helped out more with the overhaul, we all should have. I'm also not affiliated with any chapter, so most of my free time goes to following up on the lists and adding comments on existing discussions on Meta. Anyway, I'd still be very interested in restarting the discussion about a chapters/affiliates namespace - it makes more sense than an Iberocoop namespace, considering how much chapter stuff is already here. THO you can always ask the chapter people to help directly(don't know if they will). I'd like to have more thoughts on the namespace suggestion. Meta isn't only about chapters either, though I think some people get lost in that impression. Anyway, Thanks for all the great work PiR and THO! Theo10011 (talk) 17:09, 25 April 2013 (UTC)Reply
And this is why you are awesome. But I'm not the one asking for help or even a cleanup. My thought was that even after a lot of work by a few people here, the impression doesn't seem to be shifting. Maybe a larger structural change is needed so it has a more measurable impact? Theo10011 (talk) 17:22, 25 April 2013 (UTC)Reply
Did we really categorise that many pages? Stats? :) I categorised a few thousands in 2010 I believe, but there's always more to do. Most cleanup nowadays should be related to translation work.
I doubt the specific case is about how Meta is messy, but rather a quite natural effect of morphing expectations. A normal organization deals with legal and procedural requirements and typically fills some well-defined forms; Wikimedia's bureaucracy is just impossible. A chapter has to deal with internal processes (legal and formal, but also defined ad hoc for internal purposes and social e.g. depending on the members); then the WMF invents a new thing every other month that "you're not forced, or maybe yes, but in any case if you don't you're SO evil", and may be anything in an infinite amount of manifestations; then there is the pressure of the chapters' peers; then the meta/global community and all the communities with their expectations (why didn't you tell us this, where is that information, are you seriously not reading this, oh you gotta be kidding you're not doing this and that while you're doing that and this) etc. etc. And the boundaries between what belongs to a group or another are not pre-defined, either, which is why we needed to introduce the concept (so much abused) of a "movement" in the first place.
Meta is just the main place, the container, where this chaotic system coagulates and shows itself, it has no faults in itself. On the other hand, the visionary goal of the Meta:MetaProject to Overhaul Meta has always been and still is to find a way to show to the external world what the Wikimedia movements really is and values in all its complexity, and at the same time to find a way to bring it all together. We're still very far from that, and I doubt we're going in that direction at all (see for instance how little discussion on WMF matters there is, or how WMF software projects are discussed on en.wiki rather than Meta), but that's the purpose of this wiki. Maybe we'll find a solution in a decade (or two) more! The goal was set only 5 years ago or so by Anthere. ;-) --Nemo18:19, 25 April 2013 (UTC)Reply
Something like a feedback page for when the elections are over. See the linked "post mortems" from 2009 and 2011 as examples. --MF-W20:37, 27 April 2013 (UTC)Reply
«19:19,27 April 2013 Gaggysingh type of disease is in a particular part of body,the type of dietary suplement should be given.»?!? --Ricordisamoa20:54, 27 April 2013 (UTC)Reply
Restrict or abolish local file uploading to Meta-Wiki
Latest comment: 11 years ago29 comments15 people in discussion
TL;DR: Whether Meta-Wiki should abolish or restrict local file uploading, jump to conclusions
I would like to propose that we either abolish file uploading entirely in favor of Wikimedia Commons, or that we restrict the right to upload files to Meta to an 'uploader' usergroup.
b) files perfectly suitable for Wikimedia Commons.
c) files missing essential information of source/licence/permission (but once linked anywhere Meta:Deletion policy prohibits deleting which is nonsense).
Meta-Wiki does not have a fair use policy. Meta:Fair use has been in draft status since 2008 and was never approved nor half discussed. All files tagged as such are in violation of the wmf:Resolution:Licensing policy. In a recent RFD in which several people participated we deleted several files irregulary hosted as "fair use" images based on the absence of a local EDP and the WMF resolutions.
As I see things, there's no reason why freely and appropiately licensed files should be uploaded here rather than to Wikimedia Commons, where they for sure will be best mantained. I can't see a reason of allowing local file uploading given the existence of Wikimedia Commons unless the project does explicity accept fair use, which is not our case.
It is also notable that there are not much people interested in doing image maintenance here. That has the potential result of off-topic files and copyright violations to be hosted here for a long time before anyone notices, as it's happening now.
Given that, I propose that we abolish file uploading to Meta. We have a central Wikimedia Commons project with a very active community specialized in image maintenance which can be used for this. They have the tools for that.
III.- Restrictions
If, on the other hand, Meta still wants to keep the ability to upload files locally, I'd beg to consider placing a restriction on who can upload files here. Most of what is (correctly) uploaded and licensed here could have been uploaded to Wikimedia Commons without any problems.
a) If local uploading is kept, I think that we should restrict such uploading to the strictly necessary. That is currently things which can not be uploaded to commons because of —primary— commons:COM:PS (since copyrighted files aren't suposed to be stored here either) and to users that know what Meta is about. I'd suggest to restrict uploading to autoconfirmed users and/or administrators as some projects already do. This will ensure a low level of uploads, and from people that is expected to know basics for licensing and copyright (hopefully).
b) And just in case Meta-Wiki decided that fair use should be allowed here; I'd suggest to restrict local uploading to a 'uploader' usergroup (and admins) so that only approved users could upload files here that are not suitable for Wikimedia Commons due to licensing problems. The uploader permission would be granted to users that has basic understanding of licensing issues (esp. fair use) so they could just upload fair use files locally, uploading the free files on Wikimedia Commons.
IV.- Conclusion
I think that the most simple action would be to abolish entirely local uploading and start transferring local freely licensed files to Wikimedia Commons.
But I also can see a possible need of having local uploads in case a copyrighted files need to be uploaded because there's no free substitute for it (ie.: on bids, grants, fundraising, etc.). For that we would need to develop a decent EDP. However if we're going to host images (specially non-free) we need people interested in oversighting such activities or DMCAs and lawsuits could start to fly.
Support Obviously a good idea. No reason to host files here generally. There may be some very valid reasons for one or two people uploading them but that can easily be dealt with (I'm thinking WMF report type ones). --Herbytalk thyme15:57, 28 April 2013 (UTC)Reply
support, reasonable idea. As a minimum, it should be restricted to autopatrolled users (this way the right can also be "managed" a bit). Creating yet another user group (uploaders) seems unnecessary to me. --MF-W17:35, 28 April 2013 (UTC)Reply
It seems awfully premature to discuss restricting uploading here when nobody has reviewed what's already been uploaded here. I'd start by moving files to Commons where appropriate and deleting anything that's no longer needed. Then we can see where we are and how we want to move forward with what's remaining. --MZMcBride (talk) 17:43, 28 April 2013 (UTC)Reply
I believe MZ is suggesting that we should go through the files that already exist on Meta (of which there are many!) to evaluate whether they should be moved to Commons. However, Meta does seem to get quite a steady stream of uploads so restricting existing uploads could help with the clean up as it would ensure no more files could be added to the clean up workload unnecessarily. Thehelpfulone00:31, 29 April 2013 (UTC)Reply
Yes, I'm suggesting going through Special:ListFiles and moving files to Commons as appropriate or deleting files as appropriate. Once we do that, we can see what remains here at Meta-Wiki and determine whether restricting local uploading makes sense. If local uploading needs to be restricted right now due to misuse or abuse, there's always the AbuseFilter. --MZMcBride (talk) 00:40, 29 April 2013 (UTC)Reply
Well, but when I look at Special:Listfiles and/or Special:Log/upload, I see that most uploads are either from/for chapters (unfortunately often without license info - to be changed of course), or get deleted as out of scope for Meta. Restricting uploads to e.g. autoconfirmed users would probably already take away most of the out of scope stuff, which gets randomly uploaded here (without license info, of course). --MF-W01:43, 29 April 2013 (UTC)Reply
"Restricting uploads to e.g. autoconfirmed users would probably ..." Except that it is already restricted to the autoconfirmed/confirmed users. Ruslik (talk) 03:20, 29 April 2013 (UTC)Reply
Hmm, autopatrolled wouldn't be helpful either. It is also a trivial right and we currently have 1,382 users flagged as such. If we choose to restrict file uploading (and not the option to abolish it entirely) I think we need a more restricted group for this IMHO, so we can ensure that uploads are being done by people who knows what they're doing :) -- MarcoAurelio (talk) 19:52, 1 May 2013 (UTC)Reply
Support abolishing local uploads, in accordance with the Licence policy of the WMF. Also meta:Fair use is not only a proposed policy from 2008, it also is not in accordance to copyright laws in the US and thus is inegible as an EDP.--Snaevar (talk) 19:22, 16 May 2013 (UTC)Reply
Support restricting to uploader group only, and immediately, with clean-up to follow. I spend a fair amount of time reviewing images uploaded here and most are out of scope, copied from Commons, or not tagged properly for copyright. What remains are suitable for Commons. Tagging them for {{nld}} results in no, or very delayed, action from the Meta sysops. I've raised this before that I don't see the point in actually tagging files for delayed deletion because nobody seems very interested in dealing with it, so let's move it to Commons. QuiteUnusual (talk) 09:14, 17 May 2013 (UTC)Reply
As a temporary measure while this is resolved I have just activated the proposed MZMcBride's edit filter, raising the limits to 30 edits before a user is able to upload anything. As we speak, Meta continues to be flooded by innapropiate files and I'm deleting a bunch of recent copyvios now. From those that have commented here I see there's consensus in favor to restrict local uploading. If so, which restriction do we want to set? Absolutely no local uploads or allow certain users to upload, and under which conditions? -- MarcoAurelio (talk) 15:06, 7 May 2013 (UTC)Reply
It will not made sense to me to allow local uploads if we do not allow unfree content. And if we are going to allow unfree content, do we have the capacity (community interested, tools, etc.) to oversight how that unfree content is being uploaded and kept? I do not think we have any of this right now sadly. -- MarcoAurelio (talk) 15:06, 7 May 2013 (UTC)Reply
I don't see any point in accepting local file uploads if Meta only allows files which are allowed on Commons anyway. If an EDP is created, it may be better to restrict uploads to a separate uploader usergroup which is granted to users who need to upload files. --Stefan2 (talk) 15:23, 7 May 2013 (UTC)Reply
I do see use for an EDP - and have run into it myself. Meta can be used for many things, including talking about what is happening on other projects. Since there is no way to transclude files from a non-Commons project, if you are writing an essay or using examples from projects that have an EDP, the related materials (or remixes of them) should be hostable here. Similarly, partner press releases that might include fair use media should also be hostable here.
My proposal: have an EDP which is, roughly, the union of all other Wikimedia EDPs. (Derivatives of files that are allowed on at least one of our wikis should be allowed here - under the same fair-use or other conditions.) Uploads should be restricted to a usergroup. MZM's hack should be ok for now; a proper usergroup makes sense. –SJtalk14:36, 16 May 2013 (UTC)Reply
How would that EDP work? For example, the EDP on English Wikipedia heavily depends on how you wish to use an image and on which page you wish to use it. A file which is OK on one page may be unacceptable on another page, and Meta will obviously not use the file on the same page. --Stefan2 (talk) 23:45, 16 May 2013 (UTC)Reply
I do see the use of an EDP, as per Sj. I like the idea of a "cross project" EDP. I would up the minimum number of edits though (100?) as understanding the cross EDP thing might be too complicated after only 30 edits ;) notafish}<';>18:12, 16 May 2013 (UTC)Reply
I am a native Hebrew speaker with some fair knowledge of Arabic.
I am curretnly engaged in a PERSONAL project of comparing VOCABULARY
between the 2 languages & am wondering if my work may be revelvant/
useflu to your (this Wikimedia) wesbite & if its input can be incorporated
in it. Ideally, it should be ALPHABETICALLY!
I am NOT Wiki-technically inclined-so, in case of relevance, I'd need someone's
help guiding me how to do things...
I'd appreciate an early response on it & look forward to it :)
Kind thanks,
Avi
Great job now, User: Meta Wiki Welcome
I'm so proud that you're here. In Wikipedia, I never saw that nice present from you! (Son Phan) (talk) (UTC) 2:05 5 May 2013
Wikimedia Foundation elections 2013
Latest comment: 11 years ago7 comments4 people in discussion
Should not they be linked from the main page? I tried to find the page, and I am a relatively experienced meta user, but it still took me five minutes to check that there is no link on the main page, there is no sitenotice (I think it was at some point but now I do not see it), and that Meta:Elections is a red link. Well, I would probably be able to find it anyway, but I see absolutely no reason why it should not be in the current events.--Ymblanter (talk) 07:33, 10 May 2013 (UTC)Reply
This is fine, but this is not my point. My point is that if someone heard about the Foundation elections and has come to Meta to look at the schedule/ look at the candidates / ask a question / vote there is no easy way they can find the relevant pages. Linking from the main page (we have there Goings-on) would be natural.--Ymblanter (talk) 08:43, 10 May 2013 (UTC)Reply
I would appreciate your help, since apparently the markup is too complicated for me. I would like to insert the following text (feel free to change): Candidate nomination at [[Wikimedia Foundation elections 2013|Wikimedia Foundation elections]] started. Questions to the candidates can be asked now. May 17 is deadline for nominations; voting starts June, 1. , probably as of April, 24. Thanks in advance.--Ymblanter (talk) 09:12, 12 May 2013 (UTC)Reply
Allow admins to grant and revoke the "confirmed users" user right
Latest comment: 11 years ago12 comments8 people in discussion
I just noticed when Steven gave the "confirmed user" right to DPeterson (WMF), a WMF volunteer for Communications, that neither admins nor crats are able to grant this right to users (and so this was done through an account with the global staff flag). I don't see any harm in giving admins the ability to grant and revoke this right here on Meta, as is the case for both Commons and the English Wikipedia. Thoughts? Thehelpfulone19:59, 14 May 2013 (UTC)Reply
Maybe it would be good to give bureaucrats the ability to remove, but not to grant the right (for cases like the one you mentioned). Regards, Vogonetalk20:22, 14 May 2013 (UTC)Reply
I don't see a pressing need for this, as I don't remember this was used much before (and also the example of DPeterson (WMF) apparently was only by accident, as the account was also autoconfirmed and Trijnstel removed the rights a few minutes later). In my opinion stewards & staffers (for other staff accounts) can handle this sufficiently well, if it's ever needed. But also don't care much (maybe it should be set as standard on all projects to make the group assignable locally?). --MF-W15:45, 15 May 2013 (UTC)Reply
Per MF-W. I don't see the need. Some stats on how many times this userright was needed here would be good. If we had the need to assign this right regulary I'd probably change my opinion, concurring with Trinjstel's appreciations on bureaucrats. -- MarcoAurelio (talk) 18:29, 15 May 2013 (UTC)Reply
I cannot imagine a single situation where this right could be of use. I guess, there are only quite few accounts who are less than 4 days old and the only permission which might be of use here is the autoconfirmed permission, which lets users editing half-protected pages. An urgent need for that is quite unlikely for a new account. Giving bureaucrats at least the ability to remove it from accounts might be useful, though as it gets redundant quickly. Regards, Vogonetalk19:26, 15 May 2013 (UTC)Reply
I mostly agree with you, Vogone. This is why I am asking to keep the current status of the system, because it is not worth the config change in light of the very sporadic cases where this right was ever needed. -- MarcoAurelio (talk) 20:13, 15 May 2013 (UTC)Reply
'Autoconfirmed'='confirmed'. So 'confirmed' usergroup permits users to edit semi-protected pages as well. It was actually created in order to make it possible to grant users (auto)confirmed status before they become autocomfirmed naturally. (As 'autoconfirmed' is an implicit usergroup.) Ruslik (talk) 10:44, 16 May 2013 (UTC)Reply
Move meta.wikimedia.org to www.wikimedia.org
Latest comment: 11 years ago15 comments9 people in discussion
Hi.
The multilingual portal for Wikipedia is at www.wikipedia.org. Same for Wiktionary, Wikinews, Wikiversity, etc. Even Wikidata and MediaWiki are multilingual projects located at www.
I propose moving meta.wikimedia.org to www.wikimedia.org. This is a variant of an older proposal, but is much more limited in scope. This proposal is only about changing the URL from "meta.wikimedia.org" to "www.wikimedia.org". Other redirects (such as http://meta.wikipedia.org) would continue to work.
Currently, this website is known as Meta-Wiki, or Meta. Would the website at its new location be called "Wikimedia.org" or something like that? harej (talk) 04:16, 16 May 2013 (UTC)Reply
That's a good question. I have no idea. I don't see any good reason to change the site name (or project namespace). This site will still be a meta-wiki. I'd say the site name is outside the scope of this proposal, but I'd be interested to hear what others think. --MZMcBride (talk) 04:19, 16 May 2013 (UTC)Reply
The site name is very much part of the proposal if you're proposing eliminating the current site name from the URL. Right now, we have a website called Meta that is logically at meta dot wikimedia dot org. Eliminating that and just making it wikimedia.org would create a disconnect between the URL of the website and what it's actually called, and I hate when people do that. harej (talk) 04:25, 16 May 2013 (UTC)Reply
It'd be more logically at meta.org or metawiki.org. :-) I agree that you raise a good point to consider. I just personally don't see the two as being as tied together as you do. That is, it doesn't bother me to use www.wikimedia.org and continue calling the site Meta-Wiki. Perhaps I'm alone in this. It would bother me to call the site "Wikimedia.org," I think. --MZMcBride (talk) 04:33, 16 May 2013 (UTC)Reply
This is "Wikimedia Meta-Wiki", so it's at meta.wikimedia.org. The www. subdomains should only used when there is no other project, like for mw.org and Wikidata. For "Wikimedia", we however have also Wikimedia Incubator, Wikimedia Outreach, Wikimedia Commons, etc. --MF-W14:29, 16 May 2013 (UTC)Reply
No. I'd preferr to keep things as they are. The current URL makes more sense than the proposed. Meta is not the whole Wikimedia, and as MF-W says, other projects use the same terminology. This is Meta, at meta.wikimedia.org; not very hard to remember. -- MarcoAurelio (talk) 15:35, 16 May 2013 (UTC)Reply
I don't see any benefits. Personally, I also don't see meta being a frontispiece for any of that WMF stuff, nor the need for it to be. Meta is inwardly customer focused, it supports the broader wikis, and is mechanistic, not leading with content, especially not for the casual visitor. If someone comes to wikimedia.org, I am pretty certain it is not meta for which they are looking. — billinghurstsDrewth15:51, 16 May 2013 (UTC)Reply
I think it's still fairly common for people to type in "noun" + ".com" when looking for something on the Internet. For example, if you want shoes, you'd go to shoes.com. If you want porn, you'd go to porn.com. For information about Wikimedia, you'd go to wikimedia.com (which kindly redirects to wikimedia.org). --MZMcBride (talk) 18:29, 16 May 2013 (UTC)Reply
And surely they don't find anything relevant at the current portal. :) I don't know what they're looking for, but certainly not what there is now. By the way, I think people are more likely to type noun+whatever in Google: yes, I saw them, they are lazy like that. And here's what they get. File:Google2013-wikimedia-com.pnggoogle:wikimedia.com --Nemo09:42, 17 May 2013 (UTC)Reply
The Foundation should reach out to the registrant of the unused (since 2009) domain metawiki.org and try and take it. I'm serious. — Scott • talk 08:01, 17 May 2013 (UTC) Actually, Minh Nguyễn's suggestion below is better. The Foundation is the top level and should get the central domain, which is wasted on the current content of wikimedia.org. — Scott • talk09:49, 17 May 2013 (UTC)Reply
I'd rather wikimediafoundation.org be moved to wikimedia.org. It would be consistent with the various WMF chapters (such as uk.wikimedia.org), and at this point, I think the WMF is what people generally look for when they visit wikimedia.org. – Minh Nguyễn (talk, contribs) 09:25, 17 May 2013 (UTC)Reply
Support local crats to be able to temporarily grant and retract the flood right. — billinghurst sDrewth 01:28, 20 February 2013 (UTC)
Oppose locking me and 
Neutral for bureaucrats as I don't really like flood flag to be assigned to other users since I believe flood flag is for exceptional and personal use for admins and we should not worry if RC gets flooded for a while; however 'crats can already assign bot flags so I think it fits better for us to be able to do this. If a user expects to flood we already can assign a bot flag temporary which have the same effect. Nonetheless if bureaucrats are allowed to grant and remove flood flag from others, this should only be done following a well founded request. Mass hidden edits other than very very simple stuff should be community approved as it happens with bots. A policy change must follow too. Thanks. -- MarcoAurelio (talk) 15:01, 20 February 2013 (UTC)
Strong support, per above. On Wikidata, we have completely disabled uploading (see). --Ricordisamoa 19:26, 16 May 2013 (UTC)