Commons:Village pump/Proposals/Archive/2014/07

Automatic redirects

On Wikipedia, you are automatically redirected to the right article if you hit on a redirect. Here, you are taken to the redirect page and have to hit the link which leads you to the intended page. Why not follow the example of WP? It's a much better system. --Jonund (talk) 09:41, 4 July 2014 (UTC)

In Commons the #REDIRECT[[foo]] magic word works exactly in the same way as in “Wikipedia” — while I guess that you mean the English Wikipedia for the latter, all wikis powered by Mediawiki, I believe, work the same way in this regard. -- Tuválkin ✉ 10:35, 4 July 2014 (UTC)

Perhaps Jonund followed ?redirect=no link and then wondered. Jonund, please provide us with an example. -- Rillke^(q?) 14:03, 4 July 2014 (UTC)

More likely, Jonund visited a category tagged with {{Category redirect}}. There's a en:Template:Category redirect at the English Wikipedia as well (and corresponding templates on most other language editions as a workaround for bugzilla:3311), but I guess people are more likely to encounter categories here on Commons than on other projects. —LX (talk, contribs) 16:25, 4 July 2014 (UTC)

Yes, the pages are tagged with {{Category redirect}}, for instance Category:Polar bears and Category:Pine. It's the case with almost all categories about animals and plants, because they are generally identified by their Latin names. --Jonund (talk) 18:32, 4 July 2014 (UTC)

So there is nothing we can do about the inconvenience with having to click on category redirects? --Jonund (talk) 17:05, 7 July 2014 (UTC)

Now that bots automatically move files tagged with category redirect, why should they not just be turned into #REDIRECTs (with {{Category redirect}} as a hidden template) instead of the current notice? Thanks. Mike Peel (talk) 19:02, 7 July 2014 (UTC)

Support for OpenDocument file format upload

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

---

There very clearly is community interest in enabling OpenDocument formats, however at this time there is no consensus to do so. Looking at the feedback provided, three issues need to be addressed before a similar proposal would stand a chance of success:

1. A number of users have expressed that the inability to view documents without downloading them is a deal breaker. Participants have stated that the lack of such functionality places an undue burden on the users that patrol files for copyright and scope violations. There have also been security concerns expressed, with users unable to see if a file contains harmful macros before downloading that file.
2. A number of users have expressed reservations that this would enable new types of files to be uploaded before any discussion has taken place on how these new types of file would fit in with the project scope, and how the scope might need to be changed to accommodate them.
3. There is some confusion about which of the file formats this proposal covers (only the four listed at the beginning of the proposal, or all sixteen types listed in the middle). Discussions below about some formats would not apply to other formats, and the conversation wound up being disjointed because of it.

These concerns are substantial, and while a majority of people participating are in support, many of those in support are doing so with reservations, or on the condition that documents are previewable from the start. As such, "no consensus" best expresses the community's stance at this time. Sven Manguard Wha? 05:16, 19 July 2014 (UTC)

---

My personal recommendation, based on working through the comments below, is that future proposals focus on only one format, or one pair of sister formats (such as odp and otp), per RfC. There is nothing to say that four or five RfCs on different formats can't be held concurrently, but when some people in a single RfC are talking about spreadsheets and others about text documents, for example, it becomes very easy for the RfC to get muddled. Obviously this isn't officially part of the close, but this is as good a place to make the suggestion as any. Sven Manguard Wha? 05:16, 19 July 2014 (UTC)

---

Upload of OpenDocument files has historically been disabled because of security concerns. Per the discussions in bugzilla:2089, it has been established that these have all been cleared.

as Nemo notes on Bugzilla, support for OpenDocument upload has been repeatedly discussed as over the years, eg in Commons_talk:File_types/Archive_1, and Commons:Project scope/Allowable file types already defines them as “theoretically permissible” (under the same provisions as PDFs and DjVus).

I therefore open this section to make clear the community consensus of allowing upload of OpenDocument (ODT, ODS, ODP, ODG) files.

Further steps would be:

• Ask the devs to whitelist ODF formats
• Amend Commons:Project scope/Allowable file types and Commons:File types.

Thanks, Jean-Fred (talk) 14:02, 6 July 2014 (UTC)

• My opinion: big  Support, especially for ODP in order to have the source files for the many presentation slide decks we currently host as PDFs. Category:Created with LibreOffice & Category:Created with OpenOffice.org are the tip of the iceberg but already show the need. Jean-Fred (talk) 14:06, 6 July 2014 (UTC)

•  Question Having quickly read through the long bugzilla ticket, before getting swept away in a tide of support, could we have an explanation added here as to how the WMF will implement an ODF validator for all ODF uploads before they are released into production (or preferably provide a link to a working test version) so that we can test if, say, exports from current versions of Microsoft Office are in a valid standard of ODF rather than some weird local variation of it? --Fæ (talk) 14:14, 6 July 2014 (UTC)

The standard implementation of ODF is OpenOffice.org/LibreOffice still. We should encourage the use of free standards. MS has chosen to take a different path, as usual, so it cannot be a showstopper for us neither.--Aschmidt (talk) 16:49, 6 July 2014 (UTC)

I'm not quite sure what this means and the bugzilla discussion was inconclusive. Do you believe that our contributors will find uploads of their Microsoft ODF getting rejected or will the Commons wiki not be aware of the difference between open standard compliant files and non-compliant files? --Fæ (talk) 18:34, 6 July 2014 (UTC)

@Bawolff: Do you know or should I test? -- Rillke^(q?) 20:54, 6 July 2014 (UTC)

Dear Fæ, please do not confound ODF with Microsoft's w:en:Office Open XML. We speak about the former here. ODF is an exchange format, which Office Open XML is not.--Aschmidt (talk) 22:16, 6 July 2014 (UTC)

Sure, however these sorts of clarifications should be part of this proposal in plain English so that everyone knows what they are supporting. Presumably you are writing with knowledge of the specification that is to be applied to this new Commons ODF feature. Where is this detail defined so that I can read through it (for example a functional definition of how ODT, ODS, ODP and ODG formats will be displayed so that they are usable and meaningfully viewable on Commons)? --Fæ (talk) 22:28, 6 July 2014 (UTC)

I do not know what exactly is in the pipeline from the technical point of view for Commons. I have only drawn the line between ODF and OOXML so as to make it clear that if the proposal is accepted this has nothing to do with Microsoft formats whatsoever. It is about an open standard that is quite acceptable.--Aschmidt (talk) 22:37, 6 July 2014 (UTC)

MS Word also supports writing odt but I doubt it is fully standard-compliant or they interpret standards in a way rendering tools won't. -- Rillke^(q?) 11:33, 7 July 2014 (UTC)

 Oppose I see too many open questions here to support the current proposal as worded. Some ODF documents would be great and are effectively an extension of other formats we support, while others would need constraints defining or be rejected altogether. The bugzilla ticket referenced specifies none of this functionality.

For example although I can imagine what ODP files would look like on Commons (like presentations uploaded in PDF), I have no idea how ODS files (spreadsheets) would be displayed, especially when including multiple work sheets. In fact I would rather we reject ODS as a format as they would be outside of the current definition of Commons scope. It would be better to supply an easy tool to convert ODS or Google Spreadsheets to uploadable wikitables rather than burying the data in haphazard formats and with possibly browser-crashing embedded functions and macros. --Fæ (talk) 07:28, 7 July 2014 (UTC)

Ok. So first off, to be clear - enabling upload is not the same as enabling inline display. Currently we don't have support for enabling inline display, although should this pass, I would like to look into using webodf maybe. But, that would be more in the longer term, for now this just allows uploads. What's being proposed here would look like foundation:File:Key_Facts_wikimedia_generic_2011.odt. No display. Allows download, but nothing pretty. I assume the primary use for such a format would be for source files (much like how XCF is used here). As for what types we reject: We reject any odt file that is a valid Java applet. The only way to get one of those files is if you're doing something malicious. We will also reject dual format files (e.g. You can make files that are both an odt file and a pdf file. We will reject those). We also ensure that the file begins (starting at byte 30) with the magic numbers mimetypeapplication/vnd.oasis.opendocument.<valid odt subtype here>. (per [1]). We do not filter any macros. Whether or not a file is appropriate for the commons community (content wise) is a social issue, not a technical one, and up to you guys to enforce. As for which specific subtypes of open document to enable - that's configurable, and should probably be discussed here. For reference the different type of open document formats available are:

• 'chart-template' (otc)
• 'chart' (odc)
• 'formula-template' (otf)
• 'formula' (odf)
• 'graphics-template' (otg)
• 'graphics' (odg)
• 'image-template' (oti)
• 'image' (odi)
• 'presentation-template' (otp)
• 'presentation' (odp)
• 'spreadsheet-template' (ots)
• 'spreadsheet' (ods)
• 'text-template' (ott)
• 'text-master' (otm)
• 'text-web' (oth)
• 'text' (odt)

The proposal as worded above includes the non-template version of the graphics, text, presentation and spreadsheet format. Bawolff (talk) 17:17, 7 July 2014 (UTC)

Thanks Bawolff, that's very informative.

The clarifications above, that the files will not be view-able on Commons (and may never be), is a major headache for verification. These formats are going to be a nightmare to do any serious copyright validation. Expecting reviewers to locally download the files (which might have unknown macros that could cause your computer to crash or endlessly loop when displaying a file, as there is no restriction or checks on macros) to see what the file is about, leads us into all sorts of undesirable material, not just copyvios, but images and text "hidden" within files and material which is illegal for reasons beyond copyright and well beyond relatively harmless Rickrolling. Personally, I would be seriously worried about downloading files of this type with unknown macros, especially from anonymous accounts that I have no experience of working with. It's exactly the same as if some random Russian/Nigerian "businessman"/"prince"/"bank officer" sent you one attached to an unsolicited email, which I would send straight to the bin. --Fæ (talk) 06:42, 8 July 2014 (UTC)

Having no preview images does indeed sound horrible from a reviewer's point of view. Webodf with its online editing capabilities looks like a bit of an overkill to me atm. There are some tools to create preview images from odf for Linux file managers: KDE ODF Thumbbailer, ooo-thumbnailer, Gloobus preview. Maybe one of that could be used as a starting point? --El Grafo (talk) 08:47, 8 July 2014 (UTC)

•  JFDI, we've been waiting too long. :-) --Nemo 14:20, 6 July 2014 (UTC)
•  Support Indeed.--Aschmidt (talk) 14:45, 6 July 2014 (UTC)
•  Support Very useful. Raymond 15:33, 6 July 2014 (UTC)
•  Support +sqlite Boshomi (talk) 18:26, 6 July 2014 (UTC)
•  Support --Wvk (talk) 20:03, 6 July 2014 (UTC)
•  Support if, and only if we get thumbnails of the full document. Otherwise upload patrollers cannot verify the upload easily and there is a warning to re-users that these files may contain unwanted code or software. -- Rillke^(q?) 20:53, 6 July 2014 (UTC)

  To be clear, thumbnailing is not happening now. Eventually maybe, but we don't have support for that as of yet. Bawolff (talk) 17:23, 7 July 2014 (UTC)

  Then, uploading these types must be at least restricted to trusted users. Whether enforced by a filter, a bot deleting stuff or more appropriately through a configuration in MediaWiki. Or we have some reliable tool that thumbnails on a Labs server and integration through a gadget or both. If not enabled at all, I guess thumbnailing these types will never appear on Multimedia-Team's roadmap. -- Rillke^(q?) 09:39, 8 July 2014 (UTC)

•  Support People ask me from time to time to send a document, to modify or translate it, and I want them to go right ahead instead of waiting for my reply. Ziko (talk) 21:16, 6 July 2014 (UTC)
•  Support and Rillke's suggestions sound good. :-) --Anselmikus (talk) 22:31, 6 July 2014 (UTC)
•  Support -- Marcus Cyron (talk) 07:06, 7 July 2014 (UTC)
•  Support --Badener (talk) 10:01, 7 July 2014 (UTC)
•  Support -- Michael F. Schönitzer 11:22, 7 July 2014 (UTC)
•  Support -- sk (talk) 12:27, 7 July 2014 (UTC)
•  Comment -- not necessarily opposed, but traditionally only files with a fixed visual, audio, or audiovisual realization have been allowed on Commons. Spreadsheet files are more like abstract data than they are like a conventional type of media file... AnonMoos (talk) 12:45, 7 July 2014 (UTC)
•  Support in general, but  Oppose at the moment. Now that we've been waiting so long for the security issuse to be resolved, we shouldn't be hasty. We should take some time to think about what we want to allow and what not and develop new guidelines (think about Commons:SCOPE).
  • Spreadsheets/ods? There might be applications for that, but see comment by AnonMoos above.
  • Text/odt? We generally don't allow text-only files (with some exceptions, see Commons:SCOPE).
  • Presentations/odp? I fear we would mostly get stuff like File:Presentation-Halorespiration.pdf – essentially useless without the creator holding a talk.
  • Drawings/odg? Probably yes as an alterative to SVG, but does it actuelly work in practice (do we have a renderer)?
  • Databases/odb? Probably not … → not covered by this proposal anyway
  • Formulae/odf? They're created in an editor that basically just converts mouse clicks to a weired TeX-dialect. I guess an odf-to-real-TeX-converter might be more useful. → not covered by this proposal anyway

See also the comments by Fæ and Rillke above. I'd like to see a test implementation first. --El Grafo (talk) 13:31, 7 July 2014 (UTC)

•  Support --Jörgens.Mi ^Talk 14:11, 7 July 2014 (UTC)
•  Weak support Supporting in principle, but I do have concerns about scope, similar to those of AnonMoos. Michael Barera (talk) 16:24, 7 July 2014 (UTC)
•  Support If the security issues are a thing of the past, then why not enable their upload here? The display aspect can be sorted out at a future point in time (as an easy option: just auto-create PDF versions and display those instead). Thanks. Mike Peel (talk) 18:57, 7 July 2014 (UTC)
•  Weak support Thorough testing is needed and if we can't/don't have the functionality like pdf (seeing all of the document by turning pages, etc) it is pretty useless and not easily checked for scope and (c) status. I don't want to have to download all those files and open them locally. --Hedwig in Washington ^(mail?) 03:03, 8 July 2014 (UTC)
•  Oppose, per El Grafo, Hedwig, and Fæ. No need to turn open any flood gates if all what is flowing in is murky water we cannot even properly fathom. Some of these file types may be a good addition to Commons once reliable tools for parsing and vieweing them are developed and tested. Before that no, thank you. With MobileUploads vomiting trash in well established formats we’re already too well ranked to become the greatest garbage heap in the web (better than Imgur and other such buckets cuz no ads!), no need for more. -- Tuválkin ✉ 07:58, 8 July 2014 (UTC)
•  Support --Horndasch (talk) 08:00, 8 July 2014 (UTC)
•  Oppose for now per El Grafo and Tuvalkin (will change to support for some when there are tools for checking them). Green Giant (talk) 10:26, 8 July 2014 (UTC)
•  Oppose, sounds far too dangerous at the moment (per comments above). Shouldn't this be a RFC … ?    FDMS  4    13:26, 8 July 2014 (UTC)
  • It is. -- Rillke^(q?) 13:45, 8 July 2014 (UTC)

  Now. | FDMS 4 | 14:43, 8 July 2014 (UTC)

•  Comment I think this will add another flood of out of scope files. We have enough of them in PDF or image formats. For example, why do we need formulas when we have TeX? --EugeneZelenko (talk) 14:19, 8 July 2014 (UTC)
•  Support for presentation files (.odp), since I hate uploading presentation slides in PDF form - they are so hard to modify. Many times I wished I could upload a spreadsheet (.ods) or database (.odb) file here with some metadata of batch upload, so it can be preserved for future reference, so I would  Support those. Text files (.odt) might be out of scope, as currently defined, so I would  Oppose those, unless someone can give me an example where they can be useful. Graphic files (.odg) I assume are similar to SVG files. If we can make this format to be treated exacly as SVG than I would  Support it. Formulas (.odf) I would oppose per EugeneZelenko. --Jarekt (talk) 15:01, 8 July 2014 (UTC)
•  Oppose if no fast and easy on-site patroling/checking of the content of such files is available. --Túrelio (talk) 18:25, 8 July 2014 (UTC)
•  Oppose per Túrelio --Steinsplitter (talk) 19:04, 8 July 2014 (UTC)
• I agree exactly with the clearly thought-out position of @Jarekt: . I do think that ODT uploads should be enabled, and here is my example of where one would be useful: wikisource:Assessing the accuracy and quality of Wikipedia entries compared to popular online encyclopaedias -- I was given a Microsoft Word document, but the only thing I could upload was a PDF. I think converting to ODT and uploading would be helpful to some end users, much like the ODP use case Jarek points out. -Pete F (talk) 22:04, 8 July 2014 (UTC)
•  Oppose unless we have a possibility to check the content online. Macros seem also a problem. As per Fae above. Yann (talk) 01:37, 9 July 2014 (UTC)
  •  Comment I'd would start with one and see what happens. Probably charts or presentations. Why should we host templates and formulas when we have those covered with MOL and Tex? Images don't make much sense either, since OO handles the currently hosted file formats without any problem. Allowing macros here seems pretty dangerous since we can't try them all out and we need to make at least some effort to protect our users. Maybe(!) for WMF purposes only if it makes sense, with special rights attached. Well, rather not at all. --Hedwig in Washington ^(mail?) 03:32, 9 July 2014 (UTC)
•  Question Does anyone have reliable information on what macros can do? If they aren't filtered out and might present a security risk, that is a big concern. I do think we should support these formats at some point (all of those that are proposed here have legitimate use cases within COM:SCOPE), but it may be that we need more development before we can do that without becoming a potential virus hosting site. I don't think we need to have a thumbnailer (although it would be good to have one), as there are right now also other accepted formats that are similarly or even more "difficult" to check for compliance with Commons policies, such as everything with audio in it. darkweasel94 11:08, 9 July 2014 (UTC)
•  Support --ChristianSW (talk) 20:34, 9 July 2014 (UTC)
•  Oppose This is not a technical issue but rather a change in Commons` scope. I´d like to see a more detailed discussion about the intended or unwelcome new content and about consequences for reviewing or curating the uploads before supporting this. If you want to give it a try, you might consider restricting it to a new collaboration namespace that allows "joint work in progress" instead of being a repository for educational media. (Sorry for being so conservative, but I see a tendency to open the gates further and further without a corresponding increase in resources and tools for managing the content inflow. Someday this will result in being a dumpster and not a repository) --Rudolph Buch (talk) 13:06, 10 July 2014 (UTC)
  • This isn't a change in Commons scope. We are already hosting files that were originally ODG in SVG format, files that were originally ODP in PDF format, documents that, while I can't check on this machine, might have been originally ODT, in PDF format, and I'm sure spreadsheets also have their uses, if only to show (and make editable) the data sources for a diagram created with OpenDocument spreadsheet software. Hosting PDFs without their source forms isn't very much in the spirit of free culture, which is supposed to encourage modification, and similar considerations apply to SVGs (which are harder to edit than ODGs if the original was ODG). Our scope isn't changed at all by this, this is only a technical issue. darkweasel94 13:27, 10 July 2014 (UTC)

    Note—SVG is strictly validated. They are "passive", in that they cannot contain "macros" such as responses to mouseover instructions or have embedded URLs. From the proposal here, macros will not be validated or restricted for these formats and none can therefore be considered equivalent to SVG.

Note—Commons was never intended as a repository for tables of data, nor spreadsheet functions or macros. The official policy of Project scope would have to change, it makes a specific statement that it excludes:

--Fæ (talk) 14:07, 10 July 2014 (UTC)

(edit conflict) COM:SCOPE, first sentence says "Wikimedia Commons is a media file repository making available public domain and freely-licensed educational media content (images, sound and video clips)". And while a PDF can be seen as a sequence of images, an interactive presentation or a spreadsheet with functions allowing user interaction leaves the restraints of static content. In my eyes, this is a widening of scope. --Rudolph Buch (talk) 14:14, 10 July 2014 (UTC)

Yes, Fæ (talk · contribs), I do agree with the security/privacy considerations you're raising. Your second point appears to apply only to ODS files, not to anything else. But even ODS files aren't computer programs, in general. In the current situation, if someone creates a chart with LibreOffice Calc, and uploads it as SVG, that person is the only person who can practically make changes to it. This is not in our spirit. darkweasel94 06:31, 11 July 2014 (UTC)

I would call user created macros that execute as part of a file "computer programs". In fact I have solved some quite tricky computing issues using macros as a quick and dirty one-off solution. My understanding is that ODF supports macros of several types and on all its file format variations, not just the spreadsheet one.

The SVG point is slightly tangential, so going small... SVG files are just text files, so anyone can use a text editor to see how they work, and edit them. The "vanilla" SVG that Commons is limited to, means our files are pretty straightforward, if at times a bit boring to examine. I have editing SVG files from Commons using a text editor and for small and quick fixes, especially where you do not know what the originating tools were that created it, directly editing the text can make sense and this is most likely to keep the file size down to a minimum, as most SVG editing tools tend to add a lot of library standard stuff or make format changes that do not necessarily help the layout for the human eye. --Fæ (talk) 05:05, 13 July 2014 (UTC)

Yes, OpenDocument files can contain computer programs, as can SVGs; if they present a security issue, files with such computer programs should be rejected. But computer programs aren't the main use for OpenDocument files (just as they aren't for SVGs). Any file format can be potentially used for files that don't fall within COM:SCOPE, but OpenDocument (all the formats we're discussing here) has significant legitimate uses within COM:SCOPE.

I'm perfectly aware how SVG works. And now please imagine that for one of the files in Category:SVG pie charts you have more recent or otherwise better data and want to edit that diagram to reflect that data. You'd need to edit the SVG nodes themselves, and would probably get an imprecise and/or bad-looking result. If you had a source ODS file for one of them, you'd open that, change the data, save the new chart, upload it, and you're done. That's certainly far more in the wiki spirit. darkweasel94 07:53, 13 July 2014 (UTC)

Yes, SVGs can contain programs, however on Commons they cannot as these files are automatically rejected. If something similar were being offered for ODF support, this issue would vanish, however that is specifically excluded from this proposal. --Fæ (talk) 08:00, 13 July 2014 (UTC)

So it appears that we're agreeing. :) darkweasel94 09:23, 13 July 2014 (UTC)

as a point of note: pdfs support macros [2] and are allowed here (i dont know the relative power though. Googling suggests pdf macros are sandboxed unless the doc is signed. I dont know what the security model of odf formats are). SVGs also support macros, however we filter those for various reasons. Im not sure svg files can be called human readable without stretching that term. Odf formats are also xml formats like svg, just a little more complex, and zipped. (Actually an odg file is svg + some extra bits.) Bawolff (talk) 07:28, 13 July 2014 (UTC)

Bawolff -- PDF and SVG allow scripting to add limited interactivity to basically static file formats, but this is not the same thing as "macros" in the usual sense of the word. PDF scripting is fairly useless except in the context of PDF "forms" (totally irrelevant on Commons). Commons does not allow Javascript scripting of SVG files (something easily detected and rejected), but does allow SMIL animation... AnonMoos (talk) 20:05, 13 July 2014 (UTC)

•  Oppose Why would we want to upload text files, exactly? --Jakob (talk) 22:47, 10 July 2014 (UTC)
  • For Wikisource, for one. (Wikisource often documents e.g. laws. In Austria, acts of parliament (which are {{PD-AustrianGov}}) are available, inter alia, as Microsoft Word files which would be trivial to convert to ODT.) It would be easier to transcribe them to wiki format from there than from PDF files. Another use case would be documents like those in Category:Wikimedia Foundation documents. Additionally, ODT files are only one of four formats proposed here. ODG files would be very useful because they will often be the source format for SVGs. darkweasel94 06:31, 11 July 2014 (UTC)
•  Oppose +1--Kopiersperre (talk) 23:03, 10 July 2014 (UTC)
•  Oppose as long as we get no previews/thumbnails of the full document without downloading.  Support with previews and appropriate safety (e.g. automatic remove of embedded scripts/macros, ...)--Wdwd (talk) 06:49, 11 July 2014 (UTC)
•  Support --Impériale (talk) 21:26, 11 July 2014 (UTC)
•  Question If this is done, what technical measures (if any) will be taken to ensure that OpenDocument files do not contain embedded non-free typefaces? —LX (talk, contribs) 08:39, 15 July 2014 (UTC)
  •  Counterquestion What technical measures are now taken in that regard with PDFs? AFAIK embedded typefaces aren't the rule with OpenDocument files: if you open an OpenDocument file on a computer without that font installed, it will generally not be displayed in the original font. PDFs on the other hand contain all vector and raster data needed to display the file everywhere, so it seems to me that they are the much bigger "danger". darkweasel94 09:38, 15 July 2014 (UTC)

    I'm guessing nothing, but it's something we should think carefully about before we make the problem worse. As I understand it, PDFs typically only contain the glyphs actually used in the document, so reverse engineering a complete, usable font file from a PDF ranges from difficult to impossible. For this reason, they may in fact be less problematic. By contrast, OpenDocument files with embedded fonts typically contain the original font file as part of the ZIP archive, and that can definitely be very problematic. —LX (talk, contribs) 13:39, 15 July 2014 (UTC)

    At the same time, the contents of a ZIP file are very easily checked while a PDF is generally far more intransparent. darkweasel94 15:25, 15 July 2014 (UTC)

Possible compromise: allow PDF files with embedded OpenDocument

Yesterday evening I tried uploading PDF files I had created using the LibreOffice export dialog, with the option to embed an OpenDocument file for easier editing enabled. The software didn't allow me to do that. I think allowing that would have certain advantages:

• It would already be possible to thumbnail such files as normal PDFs.
• People who want to only view the file would be able to do so like a normal PDF without any security/privacy problems.

So far, no one has replied to my question what exactly macros can do, and this could still be a concern. What do others think of that idea? darkweasel94 06:31, 11 July 2014 (UTC)

I have never used this feature, but this seems a good comprise, at least until questions about macros are answered. Regards, Yann (talk) 20:17, 16 July 2014 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Locating articles which used to link to a newly restored image

Anyone who has worked at OTRS will probably recognize this fairly common scenario:

Someone sends in a permission email, and a deleted image is restored. Sometime later, they write back and ask why the image still doesn't show up in some article.

I handled two such situations in the last ten minutes.

In one case, the photo was a head shot, so I went to see if there was an article in en wiki about here; there was, so I put the link back. What I missed was that there was also an article about her in the Polish Wikipedia, so I fielded a query from someone who did not understand why the photo did not re-appear in that article. The other one I should has found myself, but OTRS is badly backlogged, so I was moving on to the next issue, rather than spending time thinking about what articles might have contained that image.

We all know why it happens, but it is quite understandable that outsiders would not.

So I either have a question or a proposal.

The question is whether, when an image is restored, is there an easy way to find out all pages that have linked to it ever, so those can be checked to see if the image should be added back?

I hope the answer is yes, but if it is no, I have a proposal: could we keep such information. One possibility is to leave all links, even ones that have been removed, on the file page. I can imagine there are situations where this is problematic, so a second option is to have a hidden category to keep track of all old links. If that is too onerous, I'd be happy with access to all link in the last n days, where I'd like 365, but could live with 30. It is quite common that we get a permission statement a few days after something has been deleted, and if I knew about all links that had existed in the last 30 days, I bet I could deal with most such cases.--Sphilbrick (talk) 21:18, 20 July 2014 (UTC)

Are you looking for something like "CommonsDelinker recent delinks"? --> example --> just open File:Vista aerea Retiro.JPG and click on the "delinker log". Gunnex (talk) 17:27, 21 July 2014 (UTC)

That was fast :) Sorry, did not know that existed, although something in the back of my head was telling me that this is such a common need, it must have been addressed. I'll know to use it next time. Thanks.--Sphilbrick (talk) 20:11, 21 July 2014 (UTC)

@Gunnex's example: Enwiki and dewiki has a own delinker bot. Maybe we should add a notice to the delinker page? --Steinsplitter (talk) 21:47, 21 July 2014 (UTC)

A tool collecting global usage information upon deletion and offering one-click-revert of those bot's edits would be great. -- Rillke^(q?) 22:16, 21 July 2014 (UTC)

There is some code in MediaWiki:Common.js providing a link to CommonsDelinker log nearby deletion log entries, and the is something similar for de:Benutzer:Dateientlinkerbot described on it's user page which also works for en:User:Filedelinkerbot. Regarding the bot run be myself, you may also decide to simply not take care of this, as restored files will be listed at de:Benutzer:Dateientlinkerbot/wiederhergestellte Dateien / en:User:Filedelinkerbot/restored files and processed quite regularly. --Krd 06:33, 22 July 2014 (UTC)

Distinguishing Wikimedia Foundation staff accounts for official actions and personal use

Note: This proposal has been copied to Meta for discussion there as well. Zellfaze (talk) 23:13, 28 July 2014 (UTC)

It is proposed that Wikimedia Foundation staff members should consistently use accounts with a personally identifiable name with "WMF" appended when acting on-wiki in their capacity as staff and reserved for that purpose. This will reduce confusion when Wikimedia Commons users are dealing with a fellow member of the community or a representative of the Foundation acting with special power. Personal accounts of staff members shall be considered members of the community and shall be treated as such, including following standard processes for granting access to user rights or advanced permissions.

A proposal from the Wikimedia Commons community is not binding for the Wikimedia Foundation, however this change is intended to improve relations between our project and the Foundation and we further believe the Foundation can institute this minor change with little to no disruption of their activities, and we further ask that they consider making this a requirement not just here but at all WMF projects.

Supporting links:

• Related English Wikipedia Arbcom case, 'MediaViewer RfC', created after a threat (diff) to desysop a community member as a "WMF action", outside of current definitions of office actions. The staff account involved is used for both office actions and personal editing.
• Wikimedia Foundation staff powers are summarized at Office actions with a full definition at meta:Office actions.
• A table of all staff accounts with rights granted outside of any community process is maintained at meta:WMF Advanced Permissions, this shows a mix of account naming styles.
• Related discussion for how the recently changed Terms of Use may affect staff accounts, meta:Talk:Terms_of_use#Impact for WMF employees and contractors.
• Commons:Username policy ensures that account names with a "WMF" suffix are reserved for Wikimedia Foundation staff.

--Fæ (talk) 05:50, 13 July 2014 (UTC)

Additional links:

• meta:Wikimedia_Foundation_Board_noticeboard#Request:_clarify_policy_for_on-wiki_Office_actions

--Fæ (talk) 07:51, 13 July 2014 (UTC)

surely any such proposal should be at meta. Having every wiki have different rules for staff account naming in a world with SUL, seems like it would be too confusing for staff to reasonably follow. Bawolff (talk) 06:56, 13 July 2014 (UTC)

I disagree, as this can only serve to decrease participation. If the English Wikipedia Community and the Commons Community can be shown to have the same viewpoint, then meta will doubtless follow. As can be seen in the Arbcom discussion, there have been several assertions by staff and well known Wikimedians that RFCs by the community may be dismissed by the Foundation as not meaningful, unless thousands rather than hundreds take part. In terms of numbers, having this discussion on meta makes that view more extreme as the level of participation is invariably significantly lower than if we have discussions on the largest projects instead.

By the way, for this discussion, it would seem appropriate and in the interest of transparency if WMF staff would declare their status in this discussion, rather than expecting readers to check every participant's user page for possible notes, as this is a WMF policy related proposal. You can see how this has been done in the Arbcom case linked above. --Fæ (talk) 07:35, 13 July 2014 (UTC)

Fascinating -- @Fæ: , you seem to be making the argument that the Commons community is a better barometer of the international Wikimedia community than Meta, though Meta is more intended for the purpose of general deliberation. This is a compelling point, based on usage statistics alone. But it's also a pretty bold claim, and one that seems worthy of consideration on its own, before being taken as a given. (Also, kudos forr your "by the way" note. This is a very good point, and one that is frequently overlooked by staff.) -Pete F (talk) 17:07, 14 July 2014 (UTC)

More a question of pragmatism. This RfC is to gauge the views of the Commons Community, not to give general forcast of "the international Wikimedia community". However I do doubt that anyone would believe that measurable participation in an RfC would ever be higher on meta than the most popular projects. So, if the WMF are going to make the objection that 100 or 200 participants in an RfC is too low to be a basis for change, then RfCs like this one, which is running in parallel to the discussion on the English Wikipedia, are a necessary step.

Again, to the many people saying something like "oh why, oh why, is this not on meta?", nothing and nobody is stopping you from making a similar proposal on meta written from a more generic viewpoint than this Commons Community RfC; get those fingers working. --Fæ (talk) 17:36, 14 July 2014 (UTC)

Very sensible -- thanks for breaking that down. -Pete F (talk) 18:28, 14 July 2014 (UTC)

• Support. We regularly have (newish) staff accidentially misusing their staff rights to delete photos, etc, causing mini-dramas. They should consistently use staff role accounts and, as their induction seems a bit lax, we should detect staff accounts and add notices on the top of key action pages to remind them they are required to follow staff procedures when using their staff account. John Vandenberg ^(chat) 10:47, 13 July 2014 (UTC)
• Oppose I don't like red tape. Not needed. Trying to solve a problem that doesn't exist. Multichill (talk) 13:27, 13 July 2014 (UTC)
•  Support → User: Perhelion 14:15, 13 July 2014 (UTC)
•  Support as per Fae and Vandenberg. russavia (talk) 16:03, 13 July 2014 (UTC)
•  Support, per Fae and Vandenberg. I’m really surprised this is not established mandatory policy, and I’m shocked (by the example) that it is acutely necessary. -- Tuválkin ✉ 19:52, 13 July 2014 (UTC)
•  Support it seems there is a problem here, and more clear lines would help.--Prosfilaes (talk) 21:52, 13 July 2014 (UTC)
•  Oppose - this is a typical topic where having local policies only makes confusion more likely to happen. Keep this discussion at meta. Also, I'm worried as this would make it harder for beginning staffers to identify themselves as WMF employees, while testing out stuff and practicing. I am in favor of clearly identifying what is an office action and what not, I just don't think this particular approach is helpful to that effect. Effeietsanders (talk) 22:11, 13 July 2014 (UTC)
  • Feel free to set up an RFC on meta, there's no harm in it. Many Commons contributors are uninterested in reading pages on meta, this RFC is intended to represent the views of this community for how staff accounts are expected to be used here. --Fæ (talk) 22:16, 13 July 2014 (UTC)
  • @Effeietsanders: Can you explain how requiring a user to register an account John Doe (WMF) would make things harder for them than if they were able to operate under the name Dilaritad? Thanks. odder (talk) 08:04, 14 July 2014 (UTC)
  • Yes, Effeietsanders, please reply to odder’s question above. Besides I’m intrigued by the notion that something «would make it harder for beginning staffers to identify themselves as WMF employees, while testing out stuff and practicing.» Why would a WMF employee need any significant “practicing”? (Unless you’re hiring people without basic Mediawiki experience, which is utterly incompetent and unacceptable.) -- Tuválkin ✉ 06:10, 15 July 2014 (UTC)
  • WMDE staff use '(WMDE)' suffixed accounts religiously, and most (all?) of them even use WMDE in their IRC handles. It isnt hard, and it helps. There are a few people I didnt know had become staff in either org until I saw their WMDE/WMF accounts. John Vandenberg ^(chat) 12:33, 14 July 2014 (UTC)
    • I agree, WMDE set a great example that we should admire. Unfortunately this proposal is a case study for the issue of non-transparency. There are WMF staff and Chapter staff commenting here using personal accounts (some do not even declare that they have an "official" account on their "personal" account user page, it is not a firm requirement that they do so). Most readers/unpaid volunteers would have no idea how much influence paid staff have over project policy proposals, volunteer surveys and RfCs that are related to the paid activities of paid staff. This proposal is a minor issue, but common-sense would indicate that participants would do well to openly declare their professional interest in this discussion, or use their "official" accounts, it is neither expensive nor particularly inconvenient to do so and avoids any potential later claim of covert lobbying. --Fæ (talk) 12:46, 14 July 2014 (UTC)

      The problem with the current proposal is that if every community sets their own rules, the situation becomes terrible, thanks to Single User Login. Commons may require WMF, maybe the French Wiki required FWM, and arwiki requires it to be in arab script. This doesn't scale. Another problem is that it requires to /only/ use it for editing in their capacity as staff. That means that testing, playing around etc wouldn't be allowed under some interpretation. The argument that only people should be hired who already have MediaWiki experience is... surprising, but well. Whatever. Lets just say that I would like it if the WMF accountants also make a few edits as part of their introduction week, to get to know the projects a bit. And that I would like them to worry about what they're editing, and not what complicated naming policy on each wiki they would have to follow. And that for uploading a picture, maybe different rules apply than for editing text. Effeietsanders (talk) 21:44, 16 July 2014 (UTC)

      This is an odd reason for not doing anything, and appears to presume that there are WMF employees who would collapse into a heap at the idea of keeping their professional account separate from their personal account, please give them more credit. Almost everyone I know with a work mobile phone would never dream of using it for sexting or keeping their Grindr profile, the same basic standards should be expected of WMF employees. As for the argument that SUL makes it impossible, please, this is technical detail that can be worked out with a few example cases. The number of WMF employees with active accounts on the arabic wiki is probably 2 or fewer. The alternative is that we end up with a succession of divisive and increasingly damaging dramafests, every time someone uses the same account for WMF paid work and for personal fun, meaning that when challenged they can retrospectively choose whether their edits or comments were as part of their job or not. This RFC is a case study in point, as far as I am concerned this RFC is directly about WMF employee policies on the Wikimedia projects, as such only "official" comments are possible from employees here, and yet we see several employees choosing to use their declared personal accounts to contribute. The lines are so blurred that they do not exist, time to draw the simplest possible line that everyone can understand and stick to. --Fæ (talk) 22:25, 16 July 2014 (UTC)

•  Support I believe that any RfC started on Meta would be met with the same attitude from the Foundation as the MediaViewer RfC on the English Wikipedia, ie. considered not representative of the global Wikimedia community (unless we invest a lot of time and energy in promoting it on all wikis). The only viable alternative for us is to make it a de facto global policy by having the biggest wikis accept the proposal as their local policy, and having Meta and other wikis follow our example (if they wish so — if not, it will still be a local policy on this project). As for the actual wording of the proposal, I wholeheartedly agree: having all Wikimedia Foundation employees use an account with a (WMF) suffix for actions representing the Foundation would make things absolutely clear for everyone involved. I do not accept @Effeietsanders' argument that this requirement would make it harder for beginning staffers to identify themselves as WMF employees — on the contrary, the moment they register an account (or have someone else register an account for them), it will be clear that they are affiliated with the Foundation. odder (talk) 07:59, 14 July 2014 (UTC)
•  Support for reasons already mentioned above and per the recent clash on :en of Erik Möller versus :en-admin User:Peteforsyth. --Túrelio (talk) 08:08, 14 July 2014 (UTC)
•  Support Make sense. Yann (talk) 09:23, 14 July 2014 (UTC)
•  Oppose Opposing on a procedural point. This is a discussion which should be happening on meta, with input from WMF staff, so that they can explain what their current internal policies are. Chase me ladies, I'm the Cavalry (talk) 12:15, 14 July 2014 (UTC)

  Sorry but that isnt a valid procedural point. Commons has its own policies, which are frequently different to other projects. We also host discussions on Commons when they pertain to Commons policies. e.g. we flag accounts with access to OTRS, which doesnt happen elsewhere. WMF is welcome to put their policies on meta, and we would keenly look to see how our procedures and policies and compliment theirs. John Vandenberg ^(chat) 12:53, 14 July 2014 (UTC)

Since usernames are global, all new username policies should be global, otherwise you end up with a situation like we have now where usernames named after GLAM institutions are allowed on Commons but blocked on Wikipedia. Policies that made sense to keep local before SUL, now should be kept on meta. --Jarekt (talk) 15:26, 14 July 2014 (UTC)

Jarekt, Im sorry but you are wrong. Not all Wikipedia block accounts which are an institution name, also known as 'role accounts'. English Wikipedia is the one with a special policy for this, with sysops blocking zero-edit improperly named new accounts. There are Wikipedias which welcome such username, and help the institution verify their right to use that account. There are many other differences in local username policies.

Provided an institution knows in advance that they might be blocked on English Wikipedia, even if they havent edited there, they often wish to use an official-like account name on the wikis which allow it. John Vandenberg ^(chat) 07:18, 17 July 2014 (UTC)

• oppose because 0 use-case provided is silly, the staff clearly stated what is happening; 1 you said this is non-binding, so that whatever outcone we have here is imo not actionable, 2 this needs to be addressed by software, not by paperwork or by hand, 3. The thing about newish staff account misuse needs more detail and thought for all, not here. -- (mobile) Gryllida 14:41, 14 July 2014 (UTC)
  • Could you explain why a software change would be needed? This RfC is intended to provide a vehicle for the Commons community to express a consensus view, use-cases or definitions of specific actions are not needed in order to do that, this is a policy issue rather than a technical change request. --Fæ (talk) 15:07, 14 July 2014 (UTC)

 Oppose this seem to be a solution in search of a problem. I think it should be encouraged for rare edits they do in their official capacity, like office actions, but I do not see a need to require it. I also think Foundation staff should be encouraged to identify themselves as such on their user pages. --Jarekt (talk) 15:32, 14 July 2014 (UTC)

This diff shows what happens right now by the WMF head of development, i.e. a current problem that needs fixing. Leaving the policy unwritten and "encouraging" desired behaviours would be lovely, but this path seems to have been ineffective over the last couple of years. This is a very simple, easy to understand improvement, that costs nothing to implement and ensures that WMF management understand their responsibility for consistent and supportive behaviour towards the unpaid volunteers that create content that the donors invest in. --Fæ (talk) 15:52, 14 July 2014 (UTC)

•  Support Seems sensible, with few negatives, and easy enough to implement. Hchc2009 (talk) 16:40, 14 July 2014 (UTC)
•  Support The larger problem, of course, is that Staff are active in places they should not be and they have absolute power. Anything that constrains WMF is a good idea. Chris Troutman (talk) 16:53, 14 July 2014 (UTC)
•  Oppose What problem do we want to solve here ? (Per Multichill or Jarekt). --PierreSelim (talk) 16:59, 14 July 2014 (UTC)
•  Support This seems logical, and I thought it was standard practice. This shouldn't just be the WMF, though - it should also apply equally to any staff member of a Wikimedia-affiliated organisation. Thanks. Mike Peel (talk) 17:50, 14 July 2014 (UTC)
• The need for this proposal is really unfortunate. I believe WMF carries the primary responsibility for conducting itself in a way that is not unnecessarily disruptive to the communities it serves; and I do think that recent events (including many that haven't been brought up) have demonstrated that the WMF has really messed up in this regard. Since this proposal is intended to be advisory but not binding, I strongly  Support it -- but the important thing is not so much what we decide here, but what kind of action the WMF takes. I suspect something a bit more sophisticated and nuanced is needed. It will probably need to be a change from the internal policy as expressed by the previous Executive Director; I believe the "hands-off" approach, in which staff members are expected to do the best thing without clear guidance on these matters, has proven to be the wrong approach. -Pete F (talk) 18:33, 14 July 2014 (UTC)

  Also:

  1. I don't think any recommendation toward other organizations is necessary, though I do think other organizations would be wise to consider WMF's approach (whatever it turns out to be) when determining their own.
  2. I think it's important to note: just because an organization or a user says that an action is "in a personal capacity" does not automatically make it so. We have seen many actions taken by WMF staff members that relate very closely to their professional duties, with a claim that they are done in a personal capacity. Such claims, in my view, are always legitimate topics for careful consideration and varying opinions. -Pete F (talk) 18:53, 14 July 2014 (UTC)

Personally I view all my edits to any wiki as being in a personal capacity. My understanding (Based on how I read my contract) is that I am not allowed to make edits or otherwise make statements on behalf of the foundation. Arguably though, edits like this or this are very related to my job even if I deem them "personal". Lines are blurry. Surely though, the main issue here is when staff try to do some action they would normally not be allowed to do (Or otherwise invoke the authority of the foundation in their edit), and not the blurry cases like devs updating help pages after software changes, etc. Bawolff (talk) 21:43, 14 July 2014 (UTC) (Per Fae's request, for those who don't know, I work as a part time contractor for the foundation. This edit is in my personal capacity)

Thanks @Bawolff: . I think this underscores my point. The organization itself cannot, by a simple declaration, immunize itself from the possibility that certain actions will be understood to reflect the organization's official position. A recent example here in California: the sheriff of a rural county has taken place in, and more recently sponsored, a controversial and illegal coyote hunt. From his perspective, he does this in a personal capacity. However, it has been covered widely in the news (e.g. [3]); why is his participation so widely known? It's not because of his hunting prowess, or his articulate leadership -- it's because his participation in the illegal activity very clearly and obviously relates to his job, which is enforcing the law. Now, of course there is a difference in his case -- this sheriff is surely willfully exploiting those blurry lines for political advantage, while I very much doubt that any WMF staff are trying to play political games. But I do think this kind of case proves my point: just because the lines can be blurry, does not mean that the distinction does not exist, nor that the organization is the final authority of what is or is not an official action. -Pete F (talk) 21:58, 14 July 2014 (UTC)

•  Support - as a general principal, any official of any type acting in an official capacity should be immediately apparent to be an official. Beyond My Ken (talk) 18:36, 14 July 2014 (UTC)
•  Comment I propose extending this to people doing GLAM work or are working on behalf of something or someone else in general. -- Rillke^(q?) 18:39, 14 July 2014 (UTC)
•  Support Like Mike Peel and Hchc2009 --Packa (talk) 21:24, 14 July 2014 (UTC)
•  Comment A "special" user-name alone does not solve a thing but only makes it more complicated for WMF staff to participate (because they'd have to change accounts constantly) and easier for individuals to point fingers in case a personal opinion was voiced under a WMF account in error or vice versa. The real challenge is to make it easily possible for WMF staff to easily communicate whether they are contributing in their official capacity or as an individual and this is something everyone at WMF has to get right on his/her own. A policy will not fix this easily. A guideline sounds reasonable however and many people from the WMF staff already do it exemplary. --Patrick87 (talk) 21:54, 14 July 2014 (UTC)
  • Exactly, it would make it «easier for individuals to point fingers in case a personal opinion was voiced under a WMF account» — that’s precisely what this proposal addresses. It is called accountability and it is beautiful. -- Tuválkin ✉ 06:10, 15 July 2014 (UTC)

  It's not beautiful at all because it would result in WMF people talking even less as they already do (Who doesn't say anything can't say something wrong). I'd rather live with a personal opinion of a WMF employee that is somewhere near what the foundation will actually do than with no hint into any direction at all because nobody dares to say something that might not be 100 % true in the end. If you'd want to change that, you'd have to exchange WMF... --Patrick87 (talk) 19:29, 15 July 2014 (UTC)

Exactly: Change the WMF, this being only a simple thing, but a step in the right direction. We already know what they do, we have to deal with it. Useful additions and maintainance gets stalled and forgotten, while the most outlandish, frivolous, and even harmful bells and whistles are lavishly funded and rammed down our throats with inane announcements starting with «We’re excited to share with the community that…» so and so. Let them all be immediately recognizable when they do anything in any official capacity (both staffers and board members). They wont be talking much in comment threads? Their choice, but the especially named user accounts are also useful to trace edits, deletions, and any loggable action. And that helps enforce accountability the beautiful. -- Tuválkin ✉ 01:25, 16 July 2014 (UTC)

• Oppose. This discussion belongs on meta. It is unlikely to have any effect if enacted locally. Also, the proposed guideline is already followed by pretty much all WMF employees besides Erik, so I'm not sure how much it's actually needed. Kaldari (talk) 23:16, 14 July 2014 (UTC)
  • There are 17 active staff accounts listed at meta:WMF Advanced Permissions which are not in any obvious way marked as staff accounts (Sue Gardner recently being changed). This can be taken as a minimum number, as these are only those that happen to have been granted additional rights on projects outside of a community process. An undefined number of additional staff accounts which are not qualified as "WMF", may be used for office actions; for example the staff account Kaldari or the trustee account Sj. The scope of "office action" may be adapted without advance notice or discussion with the community of unpaid volunteers. --Fæ (talk) 05:31, 15 July 2014 (UTC)
    • @Fæ: Staff members who are also active community members are strongly encouraged to have separate accounts. You are correct that they are not consistently marked as "(WMF)", however, so it can be hard to tell the difference. For example, my staff account is Ryan Kaldari, not Kaldari. The separation was a bit more clear when all staff accounts actually had "staff" rights. Kaldari (talk) 03:38, 16 July 2014 (UTC)
      • @Kaldari: Come on, that's as clear as mud, hence this proposal. We have met in real life and worked together on various excellent volunteer projects, yet I was unaware that you made this distinction between your accounts. Wikimedia Commons and the Wikimedia Community have a shared value of openness and transparency, this inconsistent and at times misleading way of using accounts lacks true openness or transparency apart from in a legalistic way. Since Erik's disheartening behaviour on en.wp, this complexity is highly likely to lead to more significant communication problems between the WMF and unpaid volunteers. It's time to fix this, and it is such an easy concession that I am really puzzled to see the resistance to the idea from all employees choosing to write in this discussion (and as has been pointed out, most readers will be unable to even tell who they are). --Fæ (talk) 05:05, 16 July 2014 (UTC)
        • @Fæ: I agree it's confusing. I just don't see that there's an actual problem to fix. If Erik had made the threat from a designated community account or a designated "WMF" account, how would either of those have changed anything? Either way, he would still retain the right to desysop people from his staff account. And either way, people would have complained about it. What's the actual problem that this would solve? FWIW, I don't have a strong opinion on the proposal, but I think it's a waste of time discussing it on Commons. Kaldari (talk) 05:08, 17 July 2014 (UTC)
          • At least we agree that it is confusing, so there is something here to solve. As a tangent, I believe one the points of the Arbcom case against Erik is that even if he was using his staff account, he may have the power to desysop, but not the authority; a part of that being that Erik's threat to desysop was not supported by the current definitions, or understanding of, office action for the English Wikipedia; anyway I would hope all WMF employees understand that if they were to start desysopping accounts without the community understanding why, then they would shift the projects from community managed to employee managed, a scenario with many unhappy bunnies. --Fæ (talk) 07:45, 17 July 2014 (UTC)

• Oppose for two reasons: 1) this is an issue for Meta, and not individual Wikis as it's not sensible to have different policies and 2) per Jarekt: it's not clear what the problem is here or why its appropriate for Commons contributors to impose special requirements on the WMF staff who help keep it going through their work. Nick-D (talk) 08:19, 15 July 2014 (UTC)

  Regarding (1) -- the proposal is very clearly not intended to be adopted as a policy, but is explicitly framed as a recommendation to the WMF. So where would conflicting policies come from? -Pete F (talk) 08:43, 15 July 2014 (UTC)

  Meta is the correct forum to make this proposal and discuss it so that we don't end up with differing arrangements on the different Wikis. Fragmenting the discussion of this issue, or trying to lobby the WMF from different Wikis, doesn't seem like an efficient approach to me. Nick-D (talk) 08:48, 15 July 2014 (UTC)

•  Oppose 1. An edit note "This is a WMF action." is merely sufficient to distinguish an office action from other edits. 2. Not only staffs; members of the Board of Trustees too can take such actions. 3. Reverting any other edits other than Office Actions are NOT blockable offenses. 4. Per their official disclaimer, "Although I work for the Wikimedia Foundation, contributions under this account do not necessarily represent the actions or views of the Foundation unless expressly stated otherwise." So any other actions/comments unless expressly stated otherwise need not require any preference even if they come from those so called "_(WMF)" tailed accounts. Jee 15:07, 15 July 2014 (UTC)
•  Support I was under the impression that this was a requirement already in place. Mlpearc (powwow) 16:39, 15 July 2014 (UTC)
• I think it is a good idea to have usernames note when they are being used is an official capacity. Why not just give WMF employees global logins when they join so that they are ready and able to contribute to any Wikimedia project under their WMF user name account? --Another Believer (talk) 17:16, 16 July 2014 (UTC)
•  Neutral It's not a "local policy" if other projects are going to be affected by the requirement to rename accounts. The idea itself makes perfect sense to me, though. --Lewis Hulbert (talk)
  • I think this is exactly why it's worded as a recommendation, not a policy or a requirement. -Pete F (talk) 14:27, 19 July 2014 (UTC)
•  Oppose that's a Meta, not a Commons discussion. --Jcornelius (talk) 03:23, 19 July 2014 (UTC)
•  Neutral see Jcornelius commment above. --Steinsplitter (talk) 14:18, 19 July 2014 (UTC)
•  Support, Mlpearc. Rehman 04:15, 20 July 2014 (UTC)
•  Support, it is a simple question of politeness and transparency.-- Gürbetaler (talk) 19:49, 20 July 2014 (UTC)
•  Oppose 1) This is not a problem, so this does not need a solution. 2) If I become once official of WMF (probably this never happens, but anyway), I do not want to change my username. Taivo (talk) 21:35, 21 July 2014 (UTC)
•  Support This discussion can be held here. In short, we're instructing people not to take Office actions without using an official account. This doesn't hinder staff from making Office actions, and it makes it somewhat easier for everyone else, because it be knowable at a glace whether a declaration is made by John Doe the editor or by John Doe the Foundation official. Nyttend (talk) 03:39, 22 July 2014 (UTC)
•  Support We are long past the days when staff actions were done by a small number of well-known people. The WMF now has more than 200 people so it is reasonable to ask WMF staff to clearly identify themselves when they carry out actions in an official capacity. There is no need to rename any accounts, because those staff that don't have separate official accounts can just create a new one with "(WMF)" at the end. Green Giant (talk) 12:09, 25 July 2014 (UTC)
•  Oppose While it sounds like a good idea, what would we do if WMF and its employees (including contractors) ignore it, just look at MV and even VE? Blocking them for violating the "proposed policy" on Commons is grounds for war between the WMF and Commons, and even if blocking is ruled out makes the whole thing a pointless exercise. Meta is where it should be discussed, whether it should be a Meta policy or a WMF (as part of its inner workings) policy. Bidgee (talk) 13:30, 27 July 2014 (UTC)
•  Support. Yes, this is largely symbolic, as will be any statement the English Wikipedia ArbCom ends up making about it. But if they hear it from enough projects it will increase the probability that the foundation will go ahead and make what is really a very minor change that will facilitate clear communication between staff and volunteers. The suggestion that this has to be at Meta is silly. Meta's community does not have any more authority to dictate WMF policy than en.WP or Commons. There can and probably should be a parallel discussion there. Beeblebrox (talk) 17:33, 27 July 2014 (UTC)
•  Support as a nod to tracking and controlling WMF staff members. They should not have by default any more privileges than regular users.→StaniStani  21:36, 27 July 2014 (UTC)
•  Oppose per Jcornelius.--Jebulon (talk) 09:15, 28 July 2014 (UTC)
•  Support I think that this proposal is a great idea. For all of those who oppose it because it is not on Meta. I have copied the proposal to Meta! Zellfaze (talk) 23:07, 28 July 2014 (UTC)