Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
Help deskVillage pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

England by county[edit]

I think we should revise the England by county (for example, Category:2010 in England by county) so they are no longer locked into twelve monthly categories for CatScan and allow us to include the actual counties into them. As you can see Category:2010 in England now has 72 subcategories but many dozens are the actual counties. It seems both complicated and confusing to have categories for counties (and to include the same counties there on a monthly basis) but not the county there for the year. -- Ricky81682 (talk) 06:20, 7 January 2021 (UTC)

Also note that a number of cities (Leeds, for example) are in both England and the county subcategory at the same time rather than the city subcategory (Category:History of England by city) so it gets confusing very quickly. In contrast, the US categories are organized by state and city separately. -- Ricky81682 (talk) 06:49, 8 January 2021 (UTC)
  • Alright, I've done it myself. Does anyone think it makes more sense to incorporate Wales (principal areas now, districts pre-1996) and Scotland's council areas into a whole subdivisions of the UK group as it's a mess across the nation over time? -- Ricky81682 (talk) 06:28, 3 February 2021 (UTC)
I notice this with countries all the time, for example departments in France Vs. cities in France. Municipalities in the Netherlands Vs. cities in the Netherlands. I personally prefer to use "cities" exclusively as they rarely change borders as much, meanwhile counties can be reformed by political decisions. The problem is that counties are an abstract country subdivision in which their geography is determined by culture, history, and whatever the central government of the United Kingdom wants, cities are cities. While cities merge from time to time, counties reform all the time. I think that "Places in England by location" should have counties and cities and then each county can have all the cities (note that "city" here means any human settlement regardless of size) within them. Note that "Leeds" refers to the city but the "City of Leeds" actual describes a more abstract subdivision. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:10, 5 February 2021 (UTC)
  • @Donald Trung: By location becomes more complicated as you have civil parishes and villages which some counties have trees for (but not a full history tree). To be 'complete' (that will never happen), you sort of end up with a 2020 in England by location followed by England by village/by civil parish/by city/by county with the county at least being a sensible container category. I only got involved because city is only international consistent subdivision. And yes, Category:Canterbury versus Category:City of Canterbury is what it is. In the end, it's all about trying to create a "useful" organization, not a perfect one. -- Ricky81682 (talk) 18:45, 5 February 2021 (UTC)
  • Ah, I misread it and worded it wrong, I meant that "by location", for example "museums by location" would contain the individual sub-categories of "museums by county" and "museums by city" but not for example "Museums in North Yorkshire" or "Museums in York", while the former would include the latter and "museums by cities" also the latter. I actually didn't check if this was already the case. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:01, 5 February 2021 (UTC)
  • It works well enough as it is. Counties in England do not vary much- that last major reorganisation/renaming was in 1974. Cities are within counties. No need to change anything. Just consider them as separate, parallel but side-ways linked trees. Please leave well alone. Rodhullandemu (talk) 18:28, 5 February 2021 (UTC)
  • @Rodhullandemu: They are separate parallel trees at least within England. I built them all that way for the most part. The question was for Northern Ireland, Scotland and Wales which have cities and sort of organization by the other subdivision. -- Ricky81682 (talk) 18:45, 5 February 2021 (UTC)
  • I spent years working on Scottish Council Areas, the current major subdivisions. Ceremonial counties are historic and have only two minor purposes today. Pretty much the same in Wales except they are Principal Areas, some being called county boroughs. But in both, cities are within the next level up division, except possibly Swansea and Cardiff, which are cities, counties and principal areas all at the same time. I don't know about NI, but again, the distinction should be obvious. Rodhullandemu (talk) 19:10, 5 February 2021 (UTC)

Basic upload form[edit]

The basic upload form input box is only 11 lines high. I use this a lot as I have prepared information templates ready to use. However, these are typically 15-20 lines high (depending on the number of categories to add), which means I have to resize the box with every upload, which is somewhat tedious. Can the Basic upload form input box be increased to 20 lines high, please? - MPF (talk) 18:33, 16 January 2021 (UTC)

Symbol support vote.svg Support, makes sense.   — Jeff G. please ping or talk to me 23:57, 16 January 2021 (UTC)
Symbol support vote.svg Support yes, please, that's been bothering me as well on occasion. --El Grafo (talk) 06:21, 22 January 2021 (UTC)
Pictogram voting comment.svg Comment - thanks @Jeff G., El Grafo: for the support! What is the next step in the process? Do I just wait for it to be done (in roughly how long?), or is there some other action needed? - MPF (talk) 21:53, 22 January 2021 (UTC)
@MPF: One of your colleagues should judge the consensus, and then someone can start a phabricator task for it.   — Jeff G. please ping or talk to me 21:59, 22 January 2021 (UTC)
  • Symbol support vote.svg Support, makes sense. What would even be better if it had settings users can customise for however they see fit. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:02, 5 February 2021 (UTC)
  • Symbol support vote.svg Support, makes sense.--Vulphere 04:16, 6 February 2021 (UTC)
  • Symbol support vote.svg Support, definitely yes! -- Tuválkin 21:44, 13 February 2021 (UTC)
  • Symbol support vote.svg Support, yes, please, it's quite useful.-- Darwin Ahoy! 04:22, 14 February 2021 (UTC)
  • Pictogram voting comment.svg Comment Practical suggestion: I would imagine that there is some way to change the size of this box also in your personal css. Wouldn't that be a cleaner approach? Don't have a fundamental objection to 20 over 11 though, but this way you could make it easily 30 without bothering anyone else's setup/preferences. Effeietsanders (talk) 02:25, 17 February 2021 (UTC)
    @MPF, El Grafo: This worked for me: [1]. But I would appreciate it if someone more technically minded can confirm this is the best solution (I don't know if there's a downside to using CSS for this - given that it uses ID, I would be surprised if there is a side effect). Effeietsanders (talk) 02:42, 17 February 2021 (UTC)
    @Effeietsanders: - thanks, but too complicated for me :-) MPF (talk) 18:15, 23 February 2021 (UTC)
    @MPF: Out of curiosity, what is the complicated part? You can copy the single line to user:MPF/common.css and click save. That should do the trick. Given the history of this request, I don't know how long this will take to get processed, even if there is deemed to be enough of a consensus. Effeietsanders (talk) 22:52, 23 February 2021 (UTC)
    @Effeietsanders: making any changes to that page - I don't dare touch that sort of thing (technophobe here!) - MPF (talk) 22:56, 23 February 2021 (UTC)

Keeping PDF and DjVu duplicates[edit]

This proposal is to establish the community consensus that when PDF and DjVu copies of documents exist on Commons, both should be kept. This would exclude corrupted files, and allow for upgrading file quality, such as recompiling the document with better scan images or embedded OCR text.


In the last four months, the COM:IA books project has released over a million documents on Commons, mostly public domain books, and this has highlighted the need to establish this rule as many are available in both formats. If this is established then we can proceed with cross-linking versions, and consider the conditions for a project that might mass upload DjVu versions of specific documents or types of document that are of interest to sister projects.

In the non-Wikimedia world, PDF for documents is the de facto standard for documents that can be read by our reusers and stored across all platforms, browsers and mobile apps. The Internet Archive abandoned the DjVu format in 2016 due to unreliability, though they are still available for a significant proportion of the collection of several million documents. We also recognize that DjVu is considered a more convenient format for supporting our editors on WikiSource, and for this reason some notable documents uploaded in PDF by default, would benefit from having the DjVu format also being made available.

There is a precedent for defaulting to keeping multiple formats of the same file, because it is a norm to keep alternate formats of jpeg and potentially superior SVG versions created from them, or TIFF and jpeg formats created from those which are far more compact and have more accurate thumbnail rendering. Commons' project scope was adapted back in 2008 to address PDF and DjVu formats, and since then there never has been a consensus to prefer one format over the other.


Thanks -- (talk) 20:23, 20 January 2021 (UTC)

Vote on keeping both PDF and DjVu duplicates[edit]

  • Symbol support vote.svg Support as proposer. -- (talk) 20:23, 20 January 2021 (UTC)
  • I have questions. IAUpload will re-ocr texts but not when the pdf exists here and uses the IA template. So, that is a big problem for "co-existance" arguments. Also, is popularity really a thing? How is that measured? Use, maybe? Which filetype is used more? I really have no problem keeping both formats, but IAUpload being disabled due to shared templates is a problem that should be handled before any voting proceeds.--RaboKarbakian (talk) 22:05, 20 January 2021 (UTC)
  • Symbol support vote.svg Support same with all duplicates in different formats. Better linking of these files could be done by structured data in the future. --GPSLeo (talk) 22:19, 20 January 2021 (UTC)
  • Symbol support vote.svg Support Retaining duplicates of PDF and Djvu , but Issues with IA upload 'blocking' upload of the sister format need to be resolved. The other concern is that in some cases the PDF quality is lower than the DJVU, with no automatable metric for determining where this from in scan quality on conversion has occured. Ideally for some works, doing the PDF/DJVU generation on a WMF server directly from the JP2 or TIFF scans, to ensure the highest quality possible would be the way of gettingrealyl high quality. However, this has a disadvantage of large file sizes. A possible third solution is for ProofreadPage and the Commons media viewer/thumbnailer to be extended so it can retrieve JPEG/JP2/TIFF page scans directly from a ZIP file, and treat the entire ZIP file the way it would a multi-page documents. IA seems to do soemthing like this for showing indvidual scanned pages in it's web based viewer. ShakespeareFan00 (talk) 11:46, 21 January 2021 (UTC)
  • Symbol support vote.svg Support I'm concerned about replacement; when I build a DJVU file, I often remove duplicate pages, which means it's not a drop-in replacement for Wikisource. Going forward, I'd love to say we should be using only PDF, but compare the pages at s:Index:Weird_Tales_Volume_3_Number_1_(1923-12).pdf to the PDF at File:Weird Tales Volume 3 Number 1 (1923-12).pdf in your webbrowser. The second is perfectly readable, but the first is unusable.--Prosfilaes (talk) 00:45, 22 January 2021 (UTC)
  • Symbol support vote.svg Support per Fæ.   — Jeff G. please ping or talk to me 01:39, 22 January 2021 (UTC)
  • Symbol support vote.svg Support makes sense to me. --El Grafo (talk) 06:20, 22 January 2021 (UTC)
  • Symbol neutral vote.svg Neutral I do not really have an preference. There is an vocal majority on en.wikisource on DjVu´s side and I copy that sometimes. Mainly wikisource users need to have the option to upload an improved version (as OCR is stored in the file itself), but I do not think the file extension is a big deal. It is also a fact that DjVu will die out eventually, as PDF is much more prominent and the number of DjVu programs in active development are dwindling.--Snaevar (talk) 01:26, 23 January 2021 (UTC)
  • Symbol support vote.svg Support, as different file types make them different files, even if the content is identical, it is important that both are usable. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:56, 5 February 2021 (UTC)
  • Symbol support vote.svg Support, per GPSLeo reasoning.--Vulphere 04:17, 6 February 2021 (UTC)
  • Symbol support vote.svg Support--Tesla - 💬 08:32, 6 February 2021 (UTC)
  • Symbol support vote.svg Support When they're based on the same scan, I do wish we had a way of linking them together beyond just adding a link, but that's a whole other deal. I don't see a downside, based on current practice, to keeping both at this time. — Rhododendrites talk |  15:45, 13 February 2021 (UTC)

Discussion on PDF and DjVu duplicates[edit]

Briefly picking up on some of the points raised in votes so far:

  1. Wikisource:DjVu vs. PDF states as a matter of known fact that PDFs are more widely known and supported than DjVu files. Many users can find it easier to create and edit PDFs for this reason and PDFs may be easier to acquire than DjVu files. I don't have a survey or similar to assess this, perhaps someone can find an expert reliable source or article that is more recent than the IA blog post of 5 years ago?
  2. References to blocking and coexistence issues, I think are in relation to the exists-normalized error which the MediaWiki software returns when an upload attempt is for a file with the same filename apart from file extension type (this is actually a misnomer, potentially an undesirable bug, ref mw:Extension:UploadWizard/Error behavior, as the error trap has been extended beyond the "normalization" of file mimes but is triggered on any extention, i.e. ".jpeg" is treated as equal to ".JPG" but also ".jpeg" trips this error when ".tiff" exists). In my own batch upload projects this has been necessary for mass uploading jpegs when the TIFF exists. This can be ignored by an upload bot, and I don't know if the upload wizard has a trick to ignore it, but there is really no "security" issue in having this as an option when the error is encountered, so in my view it should be allowed more easily for experienced contributors.
  3. I would not use structured data to hold information about duplicates, keep in mind that these currently invisible fields are not possible to handle using the API, while if the information is in the image page text (as it is for literally millions of files in GLAM collections with embedded galleries, crops and cross-links) then these can be instantly found and mass corrected using either special API based scripts or existing well understood tools like VFC.

The comments about shared templates I don't understand, that's not an error condition as far as I'm aware.

The comment about re-OCR text I don't understand, unless this is about WikiSource parsing, which is outside the intent of this proposal. All PDFs from the Internet Archive have been OCR'd and this text is available inside the file metadata and can be queried using the Commons API without having to locally download the whole PDF, which is important considering the PDFs may be hundreds of megabytes while the text for the same file is often a fraction of a meg. As a tangent, let's jointly recognize that document display on Commons is TERRIBLE, and there should be a more urgent WMF development project to make it at least as nice as the Internet Archive has made available, for free, for years. -- (talk) 11:30, 21 January 2021 (UTC)

{{Internet Archive link}}. Pick a favorite or random pdf from your uploads, and put the "assession" number into it. Adjust the form to request djvu. You will see that the "machine" there will check and deny. Release the pdf from the template and try again. That brings you to the next set of options. Adjust those form elements to new ocr from jp2 origs. 2021 tessaract is soooo much better than 2005 or 2009 versions. The sourcerers had many problems to solve and did. On a personal note, my combined edit count (previous user accts) for here is great -- yet, there was so much the sourcerers had to teach me. Dismissive attitudes should be to Flickr experts and the like. The 'pedia experts are here and commons serves them.--RaboKarbakian (talk) 12:45, 21 January 2021 (UTC)
Dismissive attitudes, that's not the intent here. We are discussing a factual guideline that can work for Commons and WikiSource users, and that Commons tools can be aligned with.
Remaking the OCR would be worth doing, no contest, but that's an upgrade project we can discuss for any format, not just PDF. Similarly Shakespeare's point about fully remaking documents from scratch using the JP2 which we cannot currently host on Commons, but could potentially host in a different way as an archive backup on WMF servers.
It would be neat if we could host a "document" in multiple formats using one object (folder) on Commons, including the OCR text as an accessible raw text file that itself could be refreshed with better recognition when available. Fundamentally the MediaWiki software already handles "documents" as a package of images, so potentially that can be a much more useful design principle. But these are scenarios for significant improvement projects that this proposal does not encompass.
With regard to the IA-upload tool, I have never used it. I understand there are basic problems with it, and if it does not allow a DjVu or a PDF when the other format exists on Commons, that's a bug in my book and it happens to be one that I know can be fixed. On a practical note the number of uploads by IA-upload run at at least two magnitudes less than the IA books project is running at, so in terms of volunteer time, the prioritization remains on IA books. -- (talk) 13:45, 21 January 2021 (UTC)
IAUpload uses the template I linked to. If a bot could change your uploads to just use the url as sourcd, all would be well. Its a pity you didn't try it and then "create" an index file at source. The <pages /> magic there is impressive.--RaboKarbakian (talk) 15:37, 21 January 2021 (UTC)
Ref User_talk:Fæ/IA books#Metadata, the suggested template is used. -- (talk) 18:34, 21 January 2021 (UTC)

Add Instant Save button[edit]

@Gryllida:If your computer or your browser crashes in the middle of your hard editing work, it'll be very frustrating that you'll have to do it ALL over again. Or, if you want to take a break from editing, you'll need a save button so your work is saved but not published. Gryllida (not me) created this code which adds a "Instant save" button to the editing page if you have the code. If somebody would add this to everybody or make it a setting you could choose it would be awesome. --Red-back spider (talk) 03:25, 24 January 2021 (UTC)

Note: untested with edit conflicts. Gryllida (talk) 03:26, 24 January 2021 (UTC)
  • Symbol support vote.svg Support, but as this is a general software proposal it should be proposed in the Phabricator. As this is a basic software feature it likely won't need community approval (as it's optional and not going to alter the nature of the content by itself). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:54, 5 February 2021 (UTC)
  • Well this is weird, the script doesn't seem to work. When I click on "Instant Save", it only stays in "Saving". It doesn't save at all. I thought it was a problem with Pale Moon, but testing it in Firefox didn't work either. pandakekok9 09:27, 17 February 2021 (UTC)

Share wiki[edit]

I'm just a end user of wiki and came up with the idea of adding a share button on wkipedia pages so you can send the URL to fb, twiiter, messenger, eauidio, etc. At the moment, the page I'm trying to share has links for bookmark and save but I am not able copy/paste the url, but a share button would make things easier. —Preceding unsigned comment was added by 2600:1700:29E0:17E0:E1BF:AC7F:D3F4:499C (talk) 02:55, 1 February 2021 (UTC)

Have you seen the "Permanent link" tool?   — Jeff G. please ping or talk to me 03:14, 1 February 2021 (UTC)
I think they are talking about Wikipedia's mobile app. On iOS, you can share an article by touching the share button, as seen in this FAQ. Not sure about Android though, because I haven't used that version in a while. pandakekok9 03:36, 1 February 2021 (UTC)

Use of off-wiki surveys using third-party tools[edit]

It is proposed that on Wikimedia Commons that there must be no promotion of surveys or questionnaires which rely on third party sites and closed source tools, such as Google Forms. This should be interpreted as a ban against engaging volunteers by mass messaging, use of banners or posts on noticeboards.

Recommended consequential action

Banners and posts which go against this proposal may be removed by anyone.

Posting account(s) may be blocked or have group rights removed at the discretion of administrators, such as all rights that enable mass messaging. In a persistent case, blocks and rights removal may apply to all accounts of the person responsible. A rationale of doing their job as part of being a WMF employee is not considered an exemption.

Background, somewhat technical

There have been several years of successive and significant use of closed source third party tools for WMF funded surveys and WMF contracted work such as Google docs, Google forms and SurveyMonkey. These have been complained about using normal correspondence, mostly with WMF employees, but each year this continues, and each year there are the same types of complaint.

Though the WMF has made statements about privacy and surveys like wmf:Universal Code of Conduct Feedback Survey Privacy Statement, these rely on independent terms by the third party, which further compromize privacy by the third party retaining rights to release data for legal investigation or potentially speculative investigation by the third party, police or state actors. Further the third party terms may change over time and may be legally retrospective and potentially run counter to any commitment made by the WMF for their management of the data. The WMF, naturally, has no liability for the actions of the third party.

Though the WMF does commit to deleting "data" after 90 days, there is no such commitment from the third party, nor is there any transparency from either the WMF or the third parties as to what secondary analysis or reports they may retain indefinitely which can compromise privacy or anonymity for volunteers. For example if only one openly non-binary identifying person is in the data and only one openly non-binary person was approached, then it's obvious that a report of anonymized data is completely ineffective. The terms are written so that there is no commitment by the WMF or third parties to respond correctly to information requests by participants, to date the WMF has rejected such requests, nor is there any statement about legal liability (damages) if there is a data breach.

This is not a ban against second party tools, where a contract between the WMF or an Affiliate can provide full legal assurance that customized software meets data control, anonymity and privacy requirements within the same legislation of the first party. In a second party contract the data may remain fully managed and owned by the first party with no second party access of any kind.

  1. This proposal is constrained to the promotion of surveys using notices and mass messaging on Wikimedia Commons. By definition this excludes the notification of other matters such as conferences, which may use a variety of tools for project management, registration or team working, none of which is specifically a survey. This extent to how the choice of tools to ensure event management is as open source and secure, is a matter for the ethical funding and organization of conferences.
  2. This proposal extends to the use of mass messaging and notices on Commons, which are governed by Wikimedia Commons policies. Specifically mass messaging may have local project specific policies, including the option to disallow it entirely. No Meta policies or WMF terms and policies exist that do anything other than support the implementation of a consensus by local project communities for mass messaging and site notifications about projects, such as surveys.
  3. "Third party" means there is no direct contract between the survey creator, who is legally responsible for the terms and conditions that apply to volunteers taking part in the survey, and the supplier of the service that operates the survey. In comparison, a "second party" would be a service where a specific contract exists with the organization creating the survey and may contain an agreement for how data must be kept private, restrict the conditions by which lawful requests for access may be respected, or limit the countries where the data may be held. See a US legal definition.

Vote (off-wiki surveys)[edit]

  • Symbol support vote.svg Support as proposer. -- (talk) 11:04, 13 February 2021 (UTC)
  • Symbol support vote.svg Support Wouter (talk) 11:20, 13 February 2021 (UTC)
  • Symbol support vote.svg Support Rodhullandemu (talk) 11:23, 13 February 2021 (UTC)
  • Symbol support vote.svg Support Eissink (talk) 12:10, 13 February 2021 (UTC). Let me remind here, although it is a slightly different issue, that the different off-wiki, yet "official" Wikimedia & Wikipedia IRC-channels are also very unwelcome to me: there is no backlog (and it's even forbidden to make screenshots or other archives of what is discussed, as I know because I was blocked on-wiki by a bureaucrat when I revealed corruption in the off-wiki IRC that the same bureaucrat had been part of and who of course banned me from me IRC also, and there was no policy to object), there is no oversight, there are no rules to object against a ban, and I have seen them turn out to be nothing but a cesspool of corruption and a seat for coordinated discussion of and even group attacks on users who are unaware that they are targeted from within the ambush of an "official" but off-wiki discussion room of very dark character. Eissink (talk) 14:58, 13 February 2021 (UTC).
Symbol support vote.svg Support.   — Jeff G. please ping or talk to me 13:15, 13 February 2021 (UTC)
  • Symbol support vote.svg Support Ainali (talk) 13:28, 13 February 2021 (UTC)
  • Symbol support vote.svg Support Grüße vom Sänger ♫ (talk) 13:32, 13 February 2021 (UTC)
  • Symbol support vote.svg Support 1989 (talk) 13:59, 13 February 2021 (UTC)
  • Symbol support vote.svg Support, the Wikimedia Foundation (WMF) has a lot of resources and receives multitudes of millions of Dollars in donations all the time, yet Wikimedia volunteers are asked to go to third (3rd) party websites (or "go off-wiki") to leave feedback. While anonymous feedback should be able to be submitted, I would rather see a website like the English-language Wikipedia's ArbCom voter site (which is within Wikimedia) for surveys. Data should be made public and responses should be anonymous by default but made public by option. Alphabet, Inc. (or "Google") is the world's largest advertising company and is known for its unethical methodologies of data collection. There are plenty of volunteers that would make a "Wikisurvey" for free, or the WMF can always ask the highly talented individuals at Wikimedia Deutschland (WMDE). There's no need to force us to go to another website to communicate with the Wikimedia Foundation. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:21, 13 February 2021 (UTC)
  • Symbol support vote.svg Support Undoubtedly, and it's a relief that this is finally being proposed in a Wikimedia project. I've always felt quite uncomfortable with those surveys commissioned by Wikimedia parts but managed by Google and other 3rd part companies, without the least guarantee that sensitive data will not be used for unwanted, or even dangerous purposes. It's quite bizarre that even the survey about the above mentioned UCOC is being made through Google Forms. This really went too far.-- Darwin Ahoy! 15:18, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose - This proposal would apply not just to specific WMF surveys, but all surveys. MediaWiki itself is not suited to handling surveys, and most researchers are not in the position of developing their own tools, such that some third party tool is required. These should be handled on a case-by-case basis. If the goal is specifically to send a message to WMF or to deal with WMF surveys, please restrict the proposal to that. I quite like research into our projects and communities, and this does not seem like a productive restriction to foster such research IMO. Other than research, Google Forms and other platforms are used e.g. in connection with off-wiki events like edit-a-thons and Wikimedia-related conferences. — Rhododendrites talk |  15:36, 13 February 2021 (UTC)
    This proposal does not recommend surveys using MediaWiki, nor that researchers need to develop new tools, it's entirely solvable. See the discussion section. -- (talk) 15:52, 13 February 2021 (UTC)
    Right. My point is that third party survey programs are inevitable. Within that category, very few people use the open source options for various reasons. People use Qualtrics, SurveyMonkey, Google Forms, etc. I get that there are privacy concerns, and am sympathetic to the idea that open source platforms are more aligned with the spirit of Wikimedia projects (so FWIW I do think WMF should use them when reasonable). But if anything I would prefer to see a proposal to require a disclaimer than to just turn away any research that uses any of the most popular platforms. But again, it's not just research. Google Forms and SurveyMonkey are also common and easy tools for groups within our community to get some basic feedback from, say, event participants (we've used GForms for a past Wikipedia Day event in NYC, for example). — Rhododendrites talk |  16:25, 13 February 2021 (UTC)
    Surveys on Google Forms asking the participants of Wikimedia events and members Wikimedia affiliates about their ethnicity, sexual options, etc, often promoted by WMF staff with the pretext of showing "diversity" inside the movement, and often made in a very non-anonymously way (asking real name, email, Wikimedia username, etc) should be completely forbidden inside the movement. At the very minimum they should be anonymous, and never feed such data to 3rd parts, even more 3rd parts with a long historic of misusing private information, such as Google.-- Darwin Ahoy! 16:51, 13 February 2021 (UTC)
Sorry @DarwIn:, but this is not an issue of using the Google Form as a tool, if anything, is about the questions included on the form. For me that discussion has arisen a new opportunity to criticize WMF for all the bad in the world. --Camelia (talk) 14:38, 15 February 2021 (UTC)
@Camelia.boban: It's part of the same thing. It's very bad already that there are surveys going around asking those questions. That they are made in Google Forms or other unreliable 3rd part only makes everything worst.-- Darwin Ahoy! 15:04, 15 February 2021 (UTC)
  • But most of this is not relevant to this proposal. This proposal just limits the kinds of tools one can use to those that are open source if you want to publicize a survey. It doesn't address the kinds of questions, the privacy requirements, etc. beyond that. If I use mass message to ask "did you enjoy Wikipedia Day" anonymously via Google Forms, I would not be allowed to do so. But if I used LimeSurvey to ask lots of personal questions, it does nothing to stop me on its own. — Rhododendrites talk |  17:04, 13 February 2021 (UTC)
Just to confirm, this proposal does not stop analysis and research using any survey tools you want, and asking whatever you want in those surveys. The proposal is limited to notices and banners on Commons. If you wish to mass email Commons volunteers, that's a separate matter. -- (talk) 21:54, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose I must concur with Rhododendrites. Right now there are limited, effective free surveying tools immediately available to the broader community and this could have severe impacts on volunteer efforts since this proposal is so broad. The main alternative Limesurvey has to my understanding a long history of critical security issues which is why it's never become a mainstay at the Foundation. Surveying options within MediaWiki suck and would be a major undertaking. There are regularly discussions about open source alternative but the reality is not so simple nor as rosy as the proposer suggests. I suspect the most likely outcome is a disenfranchisement of the commons community which quite frankly would be the worst possible outcome. Seddon (talk) 16:10, 13 February 2021 (UTC)
    In the context that the UCoC survey could with hardly any effort have been supplied as a PDF with responses emailed in to a WMF project address, rather than relying on Google forms, the end of the world language seems to be over-egging the case. -- (talk) 16:27, 13 February 2021 (UTC)
    If that is what you are suggesting for all cases, then that is an even worse privacy option. Seddon (talk) 16:52, 13 February 2021 (UTC)
    I don't see how. An email account controlled by the WMF is not open to third parties releasing them to investigators without the knowledge or permission of the WMF.
    For clarity, you are a WMF employee according to your Meta page. It would be useful if this was declared considering the nature of this proposal. -- (talk) 18:14, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Rhododendrites. Wikimedia is not an open source purist cult, it is devoted to the freedom of and access to information, and to get the most people and the most accessibility sometimes a closed source tool is required. Gamaliel (talk) 16:32, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Rhododendrites and Seddon. dwf² 16:45, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose on several grounds. I agree with the points raised by Rhododendrites and Seddon. I also think calling a vote on one wiki to ban WMF from doing things on that wiki, and as result force the WMF to change its approach, is not a helpful or healthy way for community members to make their voice heard to the WMF. The Land (talk) 17:02, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose The principle is good and forcing WMF's hand at supporting and hosting viable open source alternatives is good, but this broad ban can screw over volunteer efforts in the meantime. There are surveys run throughout the movement by volunteers (both under WMF and non-WMF grants, or completely unfunded), and this proposal can stifle these efforts. It's also a bit unclear to me if this proposal would extend to things like conference registrations (I'm guessing it would as-is). Don't get me wrong—I would love to see good self-hosted open-source solutions being used for surveys, but I don't want volunteers tangled in this. If the primary goal here is to force WMF's hand, then I could support a proposal that's more limited to that scope. ~Kevin Payravi (talk) 17:06, 13 February 2021 (UTC)
    Correction, conference registrations are not surveys and are outside the scope of this proposal. With regard to volunteers running surveys, unaffiliated surveys using third party tools would obviously be a significant risk to participants, nobody would be liable for personal data being mishandled, or even, say, posted on wikileaks. -- (talk) 18:05, 13 February 2021 (UTC)
    @: Thanks for clarifying conference registration. The reason I bring it up is that conference registrations (and scholarship applications for that matter) include a survey-like component and the submission of personal details, and I think the concerns this proposal brings up re. usage of third-party tools for surveys also goes for conference registration tools (e.g. Wikimania registrations have used Eventbrite in the last few years, though the scholarship apps are done through in-house OSS, which is cool). If you don't intend to restrict conference registration as well, I'd add a note about that in the proposal so it's clear. ~Kevin Payravi (talk) 20:50, 13 February 2021 (UTC)
    For clarity, you are employed by the WMF according to your WMF account page. It would be useful if this was declared considering the nature of this proposal. -- (talk) 18:14, 13 February 2021 (UTC)
    I uh, don't have a WMF account, nor am I employed by the WMF. ~Kevin Payravi (talk) 18:20, 13 February 2021 (UTC)
    Thanks, I was seeing an own work claim and reading that as yours. -- (talk) 18:28, 13 February 2021 (UTC)
    Ahh gotcha. Alas, I am not that good at taking portraits. ~Kevin Payravi (talk) 18:30, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per above. This would also severely limit user groups and chapters. Multichill (talk) 18:24, 13 February 2021 (UTC)
    Do you have an example of any Commons mass messaged user group or chapter survey that could not have avoided Google forms or equivalent in the last 12 months? I'm having trouble finding one. -- (talk) 18:28, 13 February 2021 (UTC)
    In your example solution mentioned above (pdf forms emailed to an individual email address) would not only be a privacy nightmare (I don't necessarily want to see individual responses at all), any volunteer-run survey with over 25 responses would become prohibitively expensive in terms of resources. Such surveys can be valuable venues to gather constructive feedback from non-usual suspects in a non-public way (people may not want to be publicly known for certain opinions/feedback). Effeietsanders (talk) 03:52, 14 February 2021 (UTC)
    The pdfs would very likely be retyped into a Google Sheet spreadsheet, at which point the data within them would become subject to Google's privacy policy. Email is usually an insecure method of sending data, unlike typing something in to a form that uses https. Sending emails would also require someone to disclose an email address, which they may not wish to do. And the confidentiality of the emails, as well as the IP address of whoever is sending it and probably other personal data, would be reliant on the policies and/or goodwill of whoever runs the email system. It would take a lot of care to design an email collection mechanism more robust than Google Forms. The Land (talk) 10:05, 14 February 2021 (UTC)
    The answer is no, so the rest appears too hypothetical compared to measurable risks to real volunteers. Let's actually stick to the evidence rather than debating how many angels might fit on a pin head. Thanks -- (talk) 15:05, 15 February 2021 (UTC)
    I guess we're reading a different conversation? Effeietsanders (talk) 18:22, 15 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose This !vote is misplaced, it should be on meta if you think that the Wikimedia Terms of Use or the Wikimedia Foundation's Privacy Policy are being violated. Thanks. Mike Peel (talk) 18:33, 13 February 2021 (UTC)
    No, this is perfectly correct as a Commons proposal about Commons policies. Projects can even set their own policies with regard to whether they allow MassMessaging at all. -- (talk) 18:52, 13 February 2021 (UTC)
    @: So you agree that this is allowed by the ToU and the privacy policy, then? Which Commons policy are you proposing to change? Thanks. Mike Peel (talk) 20:06, 13 February 2021 (UTC)
Sorry, that's a weird bit of logic, perhaps it's reductio ad absurdum but missing a step. The Commons community can switch off mass messaging or prohibit types of external links on its own blacklist, such as links to Google forms, if it wishes. There's no need to change WMF policies for that to happen, nor has the WMF ever published policies that even make that difficult to do, it's just a question of community consensus which the WMF takes great effort to repeatedly insist that they will respect unless there's a fundamental conflict such as legal requirements. As for which Commons guideline this might change, probably none, it's sufficient to be a community norm, i.e. the way we interpret our existing policies and blacklists, as an older contributor, you may recall the way Herby commented on this in the early days here. -- (talk) 20:54, 13 February 2021 (UTC)
@: So you can't point to a problem in the ToU and privacy policy, and you can't point to a Commons policy that you want to change? You seem to be arguing totalmente loco without a rational explanation. How do you expect to implement this? Also, why aren't you pinging the users you're replying to so they can follow up on the conversation here? Mike Peel (talk) 21:05, 13 February 2021 (UTC)
Once there's a consensus, we can discuss how such an effective blacklist would work. It's not a requirement of proposals to expect tail to wag the dog, and it's not entirely mad to establish the principle before choosing technical solutions. -- (talk) 21:49, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose Per proposer we should indeed encourage the use of better, open-source tools for surveys. This could go on some suggestion of best practices. I oppose bans and blocks as suggested on the proposal. --Joalpe (talk) 18:55, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose Clearly not the right platform to force such wide-ranging changes. Braveheart (talk) 20:23, 13 February 2021 (UTC)
  • Symbol support vote.svg Support, per Fæ’s o.p., Darwin, Donald Trung, and Eissink. -- Tuválkin 21:42, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Rhododendrites, Seddon and Mike Peel. Bidgee (talk) 22:04, 13 February 2021 (UTC)
  • Just to add further, This proposal is just a push against the WMF, however WMF isn't the only part of the movement who use "commercial" applications, rather than open source due to numerous reasons, in some cases evolves less administrative work (not just keeping software updated but also monitoring and dealing with local privacy laws for locally hosted data). Some chapters also don't have the resources to use open source, and it tends to be cheaper to purchase or use (some allow free-use for charities) commercial software than it is to hire people to look after software that is chapter hosted. Then you have events sometimes hosted by a very small group of people or individually who are not technically minded, which means commercial software is far more simple to use and in easy reach. Bidgee (talk) 01:20, 15 February 2021 (UTC)
+1. --Camelia (talk) 14:38, 15 February 2021 (UTC)
This proposal specifically and deliberately includes second party solutions. These would not need any people to be hired, nor even hosting costs, if it's more effective to let the second party do it all as a contracted service.
That could even be a Google or Amazon supplied service. -- (talk) 14:55, 15 February 2021 (UTC)
Fæ, I don’t think you get it! If you want to use FLOSS, you need people to maintain and support the software, some organisations do not have the expertise within and have to hire people to do that work. Lot of cases it is cheaper to outsource with commercial software.
WMAU use to have a Linux organisation based in Melbourne host and support the website, including email at no cost (WMAU was thankful at the time and still are). Not too sure what happened within the Linux organisation but WMAU started to see the website and email go offline randomly, which became more frequent and in the end the server failed including the hard drive. Now WMAU hosts its sites and email on separate hosting, web with Linode and email (with other apps included) with Google (originally paid, but I worked hard on getting the free Charity plan). WMAU is lucky to have two members who have IT running through their blood to help maintain everything.
I support the use of FLOSS (I use Piwigo on my personal site for example), however one needs to balance any vulnerabilities that FLOSS has, with the privacy policies of commercial software/operators. Some cases vulnerabilities in a FLOSS software are worse than privacy policies themselves.
Having undertaken two competitions on Commons, mixture of FLOSS and commercial software have been used, with the later being most used. Your proposal would severely limit everyone, making life in getting feedback, stats ect more difficult. Bidgee (talk) 00:39, 16 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose This proposal would hamper any future efforts from outside researchers to survey this community. Fences and windows (talk) 22:12, 13 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Kevin Payravi and Fences and windows. There are costs and risks to third-party and closed-source implementations but sometimes they may fit the purpose. I could support a positive agenda of making good OSS alternatives but not this ban. -- econterms (talk) 01:54, 14 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose This issue confuses several issues. If privacy is a concern, then informed consent is the best route to go: be transparent about what happens with the data, which service is being used and what kind of privacy arrangements are made (this probably needs rephrasing). I'm all in favor of open source solutions, but running an open source tool hosted as a service does not guarantee anything. Rather than focusing on the negative, I agree with others that it's better to focus on the positive: engage in a conversation with survey organizers to find an affordable alternative that meets your desired setup. Once that gravitates to a good solution with a support consensus, we can think about "forcing" that. Effeietsanders (talk) 03:13, 14 February 2021 (UTC) PS: as disclosure, I'm a member of the international team of Wiki Loves Monuments and we currently use the WMF-subscription of Qualtrics for our surveys, as well as Google Forms for others.
+1. --Camelia (talk)
Non-adult volunteers cannot give informed consent. The example survey ignores that fact.
To be informed consent, the volunteers would have had to read the details of the WMF terms and the full Google terms. They don't, and the risks are not even summarized for the volunteer to make a non-burdensome assessment of their personal risks.
You cannot be transparent about privacy arrangements involving third parties when you don't understand them, the creators of site notices have never claimed this level of understanding.
This proposal focuses on the positive of volunteers avoiding risks, this project can positively ban mass messaging and notices which actively promote risks to volunteers, especially where the organizations or funded projects behind them have provided no guarantees on liability when things go wrong. Removing a negative is a positive, by definition. -- (talk) 15:56, 15 February 2021 (UTC)
Consent would be required regardless, and age is equally an issue no matter the platform. That's just a matter of proper survey design, if that is a major concern of yours. Not of the software you're using.
Informed consent means that you make a participant aware of the risks, if any, before they engage in it. That is just a good matter of practice and again irrespective of the platform you're using. You can totally use private servers but if you then publish all the results without minding the recreation of individual entries - what good does that do? My assumption is that these surveys also carry an indirect value for the Commons community, and equally for other Wikimedia communities. They are ways that data gets aggregated, views are collected from participants who are not as well-versed as you and how we understand complex issues. We can have a separate conversation about what surveys are desirable of course, but lets assume there are a number that are. Then the question becomes what are good practices for organizing them. From this conversation it seems clear that there is strong disagreement about what a good survey platform is for that. Not surprising, because we have competing design objectives. This does not just include privacy and being open-source (two objectives already not necessarily correlated) but also important objectives such as accessibility, internationalization, user-friendliness, flexibility to ask the questions that need to be asked, option to mask individual responses or the amount of resources it takes to organize a survey.
But you mostly talk in hypotheticals - we could do this, we could do that. So far, each of those have been met with at an equal amount of concerns if not more. What about taking a more constructive route, rather than trying to ban something? What about setting up a proposed set of advisories on how to run a safe (and hopefully low-effort) survey? Then people can shoot at that, help improve the proposal, and try it out. If that works really well, we can start thinking about asking survey designers to use that. Effeietsanders (talk) 18:35, 15 February 2021 (UTC)
The proposed ban is not hypothetical. It is a positive act to stop the promotion of risks for our volunteers.
The legal terms and conditions that current surveys reference out to without warnings or guidance are not hypothetical.
Countries where opinions and statements in existing surveys could be used to prosecute or harass volunteers are not hypothetical.
We could spend another 10 years talking and taking no action whatsoever to ensure funded projects cease the avoidable risks of surveys with terms and conditions that those design them do not claim to understand, and are incapable of providing legal advice or commitments for volunteers about the risks that their survey project creates. The current status is unethical, I think you understand that, and no doubt you would also like to see this fixed in a short time frame.
Were I to write a survey policy right now, it be short, and be along the lines of "Surveys promoted on Wikimedia projects must not use any third party services with terms that may compromize the security and privacy of volunteers in any country." If you want something weaker, I don't really understand how that would benefit our volunteer community. -- (talk) 18:53, 15 February 2021 (UTC)
The hypotheticals referred to the hypothetical alternatives that you're trying to bring forward. I know many of us can have a flair of the framatic, but if it would take you ten years to come up with a reasonable set of advisories - does that not show the problem with your proposal? Without a clear alternative that is workable, I'm still unsure what your objective is at all. You say "privacy and security" but the way you suggest to implement that, does not reflect that. Effeietsanders (talk) 19:27, 15 February 2021 (UTC)
This proposal includes no hypothetical alternatives.
The proposal has a scope of mass messaging and notices on Commons, nothing is hypothetical about that, and the implementation is trivial.
Stopping the promotion of third party based surveys on Commons neither stops surveys, nor the use of third party tools/surveys, and does not stop funded projects finding their own alternatives and promoting those if they want to, like confidential subject interviews, which some past surveys have been entirely based on.
Creating tangents within a proposal vote, then claiming that responses to those tangential questions are too hypothetical, are still tangents not the proposal. Nothing raised here is a cogent reason to defend the ongoing use of Google products for surveys, as has been complained about every year for at least the last 10 years, nor has anything been raised that justifies exposing volunteers to known and avoidable risks when participating in funded surveys. -- (talk) 19:39, 15 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose, per Rhododendrites, Seddon, and Effeietsanders. ··· 🌸 Rachmat04 · 03:27, 14 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per the above, a purist vote/ban approach focused on self-sufficiency within the movement of only colleting data through a Wikimedia-hosted tool confuses to many issues to really break down. The arguments above cover just a few, but by banning easy to use survey tools, you are either effectively banning surveys altogether, or insisting that all of them be done transparently in public spaces (i.e. onwiki) or insisting that something be invested in that may not exist at this point (thus disenfrachising this community from sharing its information). If there are solutions that could be invested in (as is suggested below) then a ban of a tool, in one community (Commons) seems like a surefire way to a) stop collection of information from the commons community and b) not actually make progress on the core concern. This kind of ban policy, for example, would block Wiki Loves Campaign surveys, independent researchers, and affiliate surveys, just to name a few, Sadads (talk) 04:43, 14 February 2021 (UTC)
  • Symbol support vote.svg Support I would like to use software tools which do not spy me. If I work on something for articles or similar there could be a conflict of interests while using tools/ services which analysis personal data instead of protecting it. Nothing to hide? Take a look at Mr N (talk) 13:39, 14 February 2021 (UTC)
  • Symbol support vote.svg Support Lotje (talk) 13:58, 14 February 2021 (UTC)
  • Pictogram voting comment.svg Comment I would be completely in favor of the WMF putting some resources into developing and implementing a stand alone open source survey system. Even better if it can be connected to SUL in a way that personal identity is anonymized and protected, but we can also do analysis on contributions vs responses. For example, there is much ado about the gender gap, but say...what is the gender gap in image uploads? In pages created? In name space contributions? Not only that, but the ability of contributors to craft their own surveys. Pinging @Jtmorgan: since they're much more adept at this all than I am. GMGtalk 13:59, 14 February 2021 (UTC)
  • Symbol neutral vote.svg Neutral the idea is good but not practially defined and a ban is too hard. Cheers, VIGNERON (talk) 16:03, 14 February 2021 (UTC)
  • Symbol neutral vote.svg Neutral If there are no valid alternatives, why not using third party commercial software? Of course, an open source alternative should be privileged when available and when it offers exactly the same options than third party sites and closed source tools. --Ruthven (msg) 17:25, 14 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose I see no reason for banning this, because it does not harm our project in any kind. But why not start an proposal on meta asking the WMF for not using Google Forms? --GPSLeo (talk) 18:52, 14 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Rhododendrites and Gamaliel. Pursue development as suggested by GreenMeansGo, but don't blanket-ban outbound links.--Carwil (talk) 18:59, 14 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose this will hamper the ability of people running contribution drives (and GLAMs) from getting input and feedback from their stakeholders. When I worked for WMF, we really tried to make a self-hosted instance of LimeSurvey work for our research surveys. But there were security vulnerabilities in the code, and neither the functionality nor the user experience were sufficient to our needs. As far as I know, this hasn't changed; making secure and useful survey software is hard. Assuring that data is stored securely is hard. In fact the risks that personal data will leak may actually be somewhat greater if WMF chose to build/configure/host its own FLOSS survey tool (and the data that tool collects), compared to using Google Forms, SurveyMonkey, etc. because those companies have a lot more engineering resources devoted to hardening and maintaining their platforms against breaches than WMF does. I don't like the byzantine and somewhat skeezy terms of use that these platforms make you abide by when you use their free tools either, but realistically the potential for harm from however they might be trying to monetize your survey responses is low. Most of us leave a lot more valuable personal data lying around when we use the web for "safe" things, even if we have good browser hygiene practices. WMF is very unlikely to take this proposal as a direct order to drop everything and build a survey tool for Commons now. Furthermore, saying "WMF should build a FLOSS survey tool" isn't a good reason to categorically block people from using safe (from a data security perspective), free (as in beer), and user-friendly tools to further the movement goals. This proposal will cause immediate and lasting harm to the movement, and won't provide any benefits besides I guess some warm fuzzy feelings for people who a) prioritize OSS over every other consideration and/or b) like to grandstand about how bad WMF is. Even if WMF theoretically did decide to do what the editors in support of this proposal are implicitly ordering it to do, the solution would be a year or more in coming, and in the meantime the ability of movement organizers (who are already experiencing unprecedented challenges because of the pandemic) to do their work would be hampered. If the driving concern behind this proposal really is the safety of editors' personal information, let's come up with a policy about what kinds of questions people are allowed to ask in surveys, or even a survey review process. Otherwise, we have bigger fish to fry; let's not waste any more time on this. Jtmorgan (talk) 19:28, 14 February 2021 (UTC)
From your 220 edits in 12 years it doesn't seem like you waste a lot of time on Commons anyway, so please save us your "let's". Eissink (talk) 19:38, 14 February 2021 (UTC).
@Eissink: Whoever uses a tool and is a wikiuser has always a word to say, regardless of the edits in the wiki projects. Your arrogant and out of place comment is one of the many reasons I'm so happy for the new UCoc. Stammi bene ;-). --Camelia (talk) 10:29, 15 February 2021 (UTC)
@Eissink: To be clear, I pinged Jonathan to the discussion because I know he is a long time researcher with Wikimedia projects. So any presumptiveness in his participation is on me and not him. GMGtalk 14:03, 15 February 2021 (UTC)
Just to note that the proposer has promoted this on Wikimedia-l and other venues as being of much broader interest than 'just' commons. It's clearly a meta discussion which for some reason has been held here. So not surprising that people who don't normally show up to Commons policy discussions are here to talk about it. Regards, The Land (talk) 19:57, 14 February 2021 (UTC)
"For some reason" might just be that the proposal only concerns Commons and its users. While it might have broader consequences, the vote subject isn't meta at all – no need to bring this vote to meta (or to enwiki, dewiki, etcetera). Please correct me if I'm wrong. Eissink (talk) 21:08, 14 February 2021 (UTC).
Well, who should comment on this discussion on privacy violation is always relative, Eissink. For instance, I do see you have been permanently blocked on what I believe is your home wiki for violating privacy! Jtmorgan, your comment is welcome, and thanks for participating! --Joalpe (talk) 23:14, 14 February 2021 (UTC)
What you think you see, isn't necessarily how it is, Joalpe. You might be shocked if you found out what really went on there, but your mind appears to be made up already, so off you go with your misinformed guidance into an ever darker night – I know most people are not interested in truth, only in pre-cooked judgments that seem convenient, so they don't have to think any further. Eissink (talk) 23:43, 14 February 2021 (UTC).
The same goes for anyone joining this discussion. The remark you made above fails the very perspective you have laid out... Make sure to remain friendly and considerate, that's it. Good contributions. --Joalpe (talk) 17:03, 15 February 2021 (UTC)
In hindsight, my comment might have been a bit on the harsh side, and it lacked nuance. My apologies to those who have taken offense to it. Eissink (talk) 09:52, 16 February 2021 (UTC).
  • Symbol oppose vote.svg Oppose as this would not benefit this or any other project but rather hinder communication. Jonathunder (talk) 21:32, 14 February 2021 (UTC)
Warum auch immer in der vote section diskutiert wird und nicht in der diskussions section. Ein survey tool so super califragilistisch es auch immer sein mag, ist absolut flawed, wenn es nicht auf WMF servern läuft, weil dann ich und andere, die so denken wie ich, an dieser Befragung keinesfalls teilnehmen werden. Und damit ist das Ergebnis nicht repräsentativ und kann direkt in der Rundablage entsorgt werden oder in die Tonne getreten. --C.Suthorn (talk) 21:33, 14 February 2021 (UTC) (eine unfreie Software mit dem freien Lexikon zu vermanschen ist genauso sinnvoll, wie in einem Satz mehrere sprachen zu mishmashen.)


  • Symbol oppose vote.svg Oppose I certainly share the concern that the WMF may be moving toward a more top-down management strategy, and that is something we should all be wary of. However, I don't see this particular issue as being emblematic of that trend. This proposal seems more like saber-rattling against the WMF than an actual solution to a problem. Beeblebrox (talk) 22:39, 14 February 2021 (UTC)
  • Symbol support vote.svg Support. Agree w/ DarwIn (talk · contribs) and (talk · contribs). Banners on Commons shouldn't be sending people off to Google and urging them to compromise their privacy. Either several of the "oppose" votes oppose something that wasn't proposed or I am misunderstanding the proposal, could someone clarify which? Yes, in general people can use whatever research tools they want. But if it's something this official and this tied to Commons, we should not be shepherding our users into dangerous terrain. - 23:26, 14 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose I'm all for technical sovereignty, I even built m:Wikimedia Meet and m:Wikimedia Chat so people would be able to use social tools without relying on third party systems (funnily enough, the proposer of this RfC bashed me and was against using those for discussions of Wikimedia LGBT+ and pushed for using Telegram, a third party tool, for discussions *shrugs*). I also do share concerns on how some parts of WMF operate. That all being said, this proposal is just unconstructive being up in the arms at WMF instead of pushing for a solution. Amir (talk) 01:12, 15 February 2021 (UTC)
    @Ladsgroup: To clarify: Are you suggesting that the community should require a particular specific solution to the problem to be implemented, as opposed to leaving it up to the WMF (and/or other surveying orgs) to determine their own solution? --Yair rand (talk) 11:30, 15 February 2021 (UTC)
    Disagreeing is not "bashed" and knowing you from real life I'm surprised to see this assertion.
    This proposal is not a ban on third party tools, nor is "technical sovereignty" part of it, there's even a clarification on scope that spells this out. -- (talk) 13:02, 15 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose Surveys are a very valuable tool that are used for a variety of purposes. This solution offers no alternative as there is currently absolutely no WMF survey tool. There is currently no way to organise a survey that would neither use a third party site nor a closed source tool: while there are open-source survey tools, they are all on third party sites. It would be natural to create an better, open-source and internal survey tool and only after that ban third party tools, but not the other way around. I have personally organised surveys for Wiki Loves Monuments and Wiki Loves Earth participants, and they are extremely valuable for improving the contest. These surveys would not have been possible without MassMessage, as we rely on participation of dozens to hundreds of users. Organising these surveys with wiki pages only basically means either personally sending forms to hundreds of people or using wiki pages for collecting hundreds of answers, both are neither user-friendly nor practical ways of doing that. @: Here is an example of a survey I was involved in in the last 12 months, and I am not and have never worked for any Wikimedia organisation (WMF of affiliate). This is a survey I was involved in as a volunteer, and I don't want to shoot myself in the foot by making any future surveys impossible (or have to invest in building an internal WMUA survey tool which is absolutely not our priority) — NickK (talk) 02:08, 15 February 2021 (UTC)
  • Symbol neutral vote.svg Neutral Weak support. I agree that it would be good to use free software, but a ban from Commons seems improper. Benjamin (talk) 05:56, 15 February 2021 (UTC)
  • Symbol support vote.svg Support at least the off-WMF part. WMF should be sufficiently staffed to handle this inhouse. --- Jura1 (talk) 08:56, 15 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose Tools are used if are working fineː they have the functionality we need (and have a good integration with other software we are already using), are doing their job better than other, they have ease of use and an easy learning curve, and (first of all) are secure for privacy/data. Plain support and preference if an open source has all this, but if not, sorry, is not useful for my scope. --Camelia (talk) 10:15, 15 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose Mostly per User:Kevin_Payravi, User:Effeietsanders, User:Rhododendrites, User:Bidgee, User:Ladsgroup, User:NickK.
    I do sympathize with the spirit of the proposal − I am also not pleased whenever I have to fill up a Google Forms or a SurveyMonkey. I think that the convenience of using 3rd-party closed-sourced, unethical webservices can be a by-product of a certain laziness − in many places, and WMF is no exception (well, I’m no exception either!). Me getting really annoyed to have to fill Doodle polls was part of the reason I dedicated a couple of evenings to set up a Framadate instance under the Wikimedia cloud as toolforge:wudele − and I am very pleased to see its use gather steam (including by WMF staff :-) ). It definitely was not that hard to do (but see below for some caveats) and retrospectively I find all these Doodle polls hard to justify. But the situations are not comparable: polls are not nearly as senstive PII-wise ; and one cannot ignore the realities of the open-source survey software world described by others above.
    Coming back to the proposal, the intent seems to be against "evil" third-parties but it’s far more wide-ranging. Many in the French wikiverse have switched to use FramaForms, an ethical FLOSS-based (Drupal/Webforms) alternative webservice, operated by the high-profile free culture charity Framasoft. A very fine choice − no doubt more ethical than Google Forms − except that as I understand the proposal, Framaforms is a third-party it would be banned just as-well. And also, while I have the utmost respect for the Framasoft folks, the fact is that it’s a small charity of 10 staff operating many various webservices on a shoestring budget − is that really a safer choice from a data-security standpoint?
    The same actually applies to Wikimedia Cloud services like Wudele: it’s still « off-wiki » strictly speaking, and would presumably also be banned. And even if it were allowed − should you really trust it? 1/ as admin, I have access to the contents of all polls, and as a user all you have is my pinky promise that I won’t peak ; 2/ the Cloud Services Terms of Use are a relevant read on the guarantees regarding PII.
    Jean-Fred (talk) 11:38, 15 February 2021 (UTC)
    Enjoyed your comment here, however the proposal is not against "evil" third-parties, come on, there are plenty of super and life-enhancing free to use third party tools and apps. However when a funded or 'official' project globally canvasses a survey where volunteers are asked to identify their ethnic groups, income levels, gender identification and sexuality, and more, then those running the project must be accountable for ensuring that the volunteer is not tracked, and no consequent use or access of the survey data and unintended "envelope" (like IP, timings, cookie harvesting and browser headers) can cause harm or become a trojan for harm. Currently the WMF, Google (or other 3rd party) and funded projects are not liable for these risks and 100% the risk is on the volunteer who chooses to open the survey link. -- (talk) 13:28, 15 February 2021 (UTC)
    Maybe I was unclear, as I do not understand your answer to the quote you make. I am not implying that all 3rd-parties are evil. My impression is that the proposal aims to ban especially the ones that have unclear privacy commitments (or are known to have light privacy standards, like Google), which I shortcut as "evil" (some support statement above imply that understanding as well, I think). However since the proposal would apply to all third-parties, I wanted to point out that there is at least one ethical, FLOSS, privacy-concerned surveying webservice out there that is being used by Wikimedians (namely Framaforms) which would also fall under the current proposal. Jean-Fred (talk) 14:06, 15 February 2021 (UTC)
    Thanks for the clarification. Certainly if Framaforms means that our funded projects can offer meaningful guarantees that volunteers have no risk of being tracked, outed or speculatively investigated by anyone, even you, then that would be a good response to a on-wiki ban on promotion of third party tools where we cannot. -- (talk) 14:24, 15 February 2021 (UTC)
    @: Your proposal would actually harm more than help.
    A reasonable solution would be introducing some basic rules on sharing survey links on Commons, for instance, clearly stating what privacy policy applies and who will have access to the data. In Wikimedia Ukraine we always explain how any collected data will be used per Ukrainian data protection law, and we do not collect excessive private data (e.g. we don't ask for ethnicity to send souvenirs by post). A quick check that everybody follows basic standards would be beneficial.
    The outright ban does not mean people would stop using surveys, it mean they would just have to do it differently. This can lead to some nightmare scenarii like forcing people to give their contact data online on their talk page (e.g. we want to send you WLM souvenirs, we wanted to send you a Google form but we cannot, so please just leave your postal address on your talk page). Alternatively, people can send surveys using Special:Emailuser where basically nobody can control how the data will be used.
    Please do not forget that the major risk of data leakage is not Google. It is either sharing source data with an unreasonable number of people (e.g. making a Google spreadsheet with postal addresses of all WLM participants public) or using some custom tools with poor data protection (e.g. having a chapter volunteer write your own survey tool that publishes all answers on a public page on the chapter website). This is especially true for the less technically-savvy users, especially those from historically discriminated groups who likely do not know any alternatives to Google tools — NickK (talk) 16:46, 15 February 2021 (UTC)
This proposal is for Commons, agree that ideally for surveys basic rules should exist for all funded projects. This issue has been discussed for several years, yet this first step has not been taken.
The scenarios you mention have nothing to do with this proposal. Asking people for contact data is not promoting a survey. Yes, if someone want to email everyone with survey links, this proposal would not stop them. That's deliberate.
The further risks about casual use of Google tools are well recognized. On many occaisions we have seen what should have been private shared documents being shared on an open URL by accident. There are no guidelines, no policies to stop such links being shared as if they were "safe" for volunteers on our projects.
Nothing you have stated here is evidence that an outright Commons ban would do more harm than good for Commons contributors, as by definition removing a known risk to Commons volunteers is a fundamental good despite fears about impact to funded projects, and the risks to volunteers are a fundamental harm; nobody disputes this as fact. -- (talk) 18:40, 15 February 2021 (UTC)
@: I am speaking of Commons where we can perfectly introduce some local rules instead of banning all external tools.
A common use case: I am an organiser of Wiki Loves Khokarsa but I am not really into technology. I want to send certificates to all 100 participants. I know MassMessage and I know Google Forms, so I create a form asking participants to submit their full name, postal address and phone.
Now I learn Google Forms are banned. Well, I will collect their data manually then. I use MassMessage asking them to answer my message by submitting their full name, postal address and phone. Their data is now public.
Or instead, I MassMessage them on their talk pages asking to email their full name, postal address and phone to our shared mailbox But as there are so many of us using this mailbox, obviously we had to choose an easy password, so we opted for 'qwerty123456'. Well, obviously the team mailbox was hacked and all of the data was leaked.
Do you really think a Google form is really that evil compared to these two options? — NickK (talk) 19:46, 15 February 2021 (UTC)
This proposal is not a ban against your use of Google forms. Were this proposal to pass, it would not apply to using a mass massage to ask users to send their contact details in using a Google form. This is because it specifically addresses the promotion of surveys, nothing else.
The question you ask is a false dilemma. -- (talk) 19:58, 15 February 2021 (UTC)
@: Well, I am happy mass massage is not banned but I am not a masseur. I am using MassMessage to run surveys collecting little to no private data (honestly I have never even thought of asking for anything sensible like ethnicity or sexual orientation). Instead, I ask how we can improve Commons experience for photo contest participants and organise better campaigns. As just over the latest 12 months I contributed to campaigns bringing 150K photos on Commons, I think these surveys were pretty useful.
The distinction you want to introduce is completely illogical. You want to ban a Google form asking questions on how to improve projects, but you want to allow a Google form asking to send contact data. A survey on improving projects is usually harmless, in most cases such surveys are anonymous and collect no private data. Even if there is a leak that a man aged 35-44 thinks that Commons categories are hard to use, this information has zero privacy risk (but is useful for campaign organisers). At the same time, a form collecting contact data poses a significant data leakage risk but is not banned. If there is a leak that User:WLMphotographer is Mr. John Smith living at 99 High Street in Anyplace and can be reached at 0123456789, this is a major problem. Banning the former (low leakage risk) but allowing the latter (significant leakage risk) just does not make sense — NickK (talk) 23:44, 15 February 2021 (UTC)
  • Symbol support vote.svg Support. We should not ever push people into using closed-source or privacy-violating tools. Maybe also add requirements for free text licensing and open research practices (which are technically mandatory within the WMF, at least in theory). "Problematic tools" vs "no surveys" is a false choice; I have no doubt that if the WMF had to choose between using an acceptable surveying method and no surveys, a system would become available, even if it meant using some fraction of their survey-info-related budget on building a system in Mediawiki. (Honestly, even if it weren't a false choice, I'd support the ban.) --Yair rand (talk) 11:23, 15 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose We should indeed encourage the use of better, open-source tools for surveys and clearly push best-practices. This would require suggestions for replacement. I oppose bans and blocks as suggested. Anthere (talk)
  • Symbol oppose vote.svg Oppose. This proposal seems, at a minimum, to be unclear. Is it about using free open source software? Is it about not using any third party software? Is it about the security of the software, or the presence of a party other than WMF in a survey? The "consequential action" described seems delinked from the concept of banning only specific sources; it seems to purport to ban any engagement of community members entirely, regardless of source. I would likely oppose a proposal based purely on FOSS concerns, I think security problems should be addressed but it's not clear that even properly conceived this ban would do that, and overall it seems to clear to me that this proposal needs a great deal more thought and consideration before it could possibly be implemented. NathanT 18:49, 15 February 2021 (UTC)
There are lot of questions here. It appears that they are answered by the proposal text and the clarifications. If after checking you have remaining questions, it may help to raise them in the discussion section and ping me there. If a third clarification is necessary, it can always be added. Thanks -- (talk) 20:15, 15 February 2021 (UTC)
The clarifications aren't that helpful and speak to the fact that the proposal is premature, even if for you its an attempt to declare victory over the WMF after a long-running dispute. Want to solve a data retention problem? Do that. A research methods problem? Do that. A data security problem? Ok, propose something that would address it. But banning advertising of third party surveys on Commons doesn't seem to resolve any of those issues, except to say "I don't like this, and I don't like how people are doing this, so mainly for that reason I don't want to see it here where I spend my time." That's an insufficient basis for a community decision. NathanT 21:08, 15 February 2021 (UTC)
It appears there are no real questions here. Try to avoid unfounded speculation as to the motivations of others, it's better to focus on the issue if you wish to see risks to volunteers removed. Thanks -- (talk) 21:14, 15 February 2021 (UTC)
I'd be happy to support any proposal that has a realistic chance of eliminating risks to volunteers. It's just clear that this isn't that proposal. NathanT 21:20, 15 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Rhododendrites and per the fact this project could be completely isolated if this change is made especially when surveys may affect Commons as a whole. –Davey2010Talk 00:10, 16 February 2021 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose. I'm absolutely appalled by this appeal to purism. Much of the good work we do in the movement has been done on proprietary software (and this includes work by affiliates that I've been involved with), and we risk shutting out entire groups of people who neither have the time nor the patience to use open-source tools, particularly in the developing world where we deliberate use proprietary tools because they're tools that people are already accustomed to. --Sky Harbor (talk) 04:44, 16 February 2021 (UTC)
    • As a Filipino, I can confirm that open-source is pretty much not what most of my countrymen heard about, and if they even hear about it, they'd probably just prefer using proprietary instead. As much as I love free software and try to encourage my friends and school to switch to it, we just can't force other people. There's a reason most schools here still use Google Suite for their online classes, even though alternatives exist. We are not the FSF or GNU where they voluntarily dedicated themselves to free software only. pandakekok9 09:07, 16 February 2021 (UTC)
      • Actually using free software only is the founding pillar of Wikipedia. Only free licenses are allowed (mainly creative-commons, even GNU is today seen as to restrictive), only free formats are allowed. MP4 (the one most used Video-format in the world) is forbidden and this does cause that many people do not upload significant videos to commons. DNG and other RAW-Formats are forbidden, therefore mainly jpeg (which is a delivery format, that is not meant for editing) is used (even lossless jpeg is forbidden), svg is the onliy accepted vector format (an svg is practically only used be web-pages and wikipedia, every significant vector softwaere uses its own file format), a number of audio formats are allowed, but ohters are not. You can upload pdf and djvu, but not doc, kindle or other proprietory formats. Wikipedia has always accepted this limitations for the sake of free knowledge, free software, free content. --C.Suthorn (talk) 18:22, 16 February 2021 (UTC)
        • Sorry, but according to WP:5P, you're just wrong. Free content != free software. Even the English Wikipedia have to accept some non-free content in order to properly document their articles. Of course I'm not suggesting to introduce non-free files on Commons, that's just against our mission to provide a free media repository for everyone. I have no doubt that Wikipedia and other sister projects love free software and encourage it, but whether we like it or not, we will not be as purist as FSF and GNU. We are more like Debian. pandakekok9 02:34, 17 February 2021 (UTC)
          • Also, speaking about the FSF and GNU, they are actually okay with licensing stuff like speeches and opinion pieces under the CC-BY-ND, which is a non-free license. They may be dedicated to free software, but they are quite lax when in comes to free content. They only want software and its documentation to be free. pandakekok9 02:38, 17 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Gamaliel. Also, WMF already goes too far in using open source tools only. Much of the good stuff is commercial/proprietary. Refusal to use them leads to poor results. ProcrastinatingReader (talk) 04:56, 16 February 2021 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose. Per Rhododendrites and others.--Catlemur (talk) 11:51, 16 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose I see the problem. But as many others have already pointed out above, this is not the right way to solve it. --El Grafo (talk) 11:55, 16 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose per Gamaliel. There are organisation and movement whose aims are the promotion of free or open source software, that's not the aims of Commons or the wider Wikimedia movement. Take it into account when selecting what tools and platform to use for sure, but we should use the best tools for the job at hand, which sometimes may be closed source options or that hosted elsewhere. It's also not advisable spending resources to host your own solution when other does it much better and actually have the expertise to do it. -- KTC (talk) 12:50, 16 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose Per Rhododendrites. --Frank Schulenburg (talk) 19:06, 16 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose While there is a problem to solve, I agree with those above saying that this is not the way to solve it. Frsitly we should discuss before voting and secondly any solution should be movement-wide, not limted to one projet Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:04, 17 February 2021 (UTC)
  • Symbol oppose vote.svg Oppose not the right form. Please find another solution. LaMèreVeille (talk) 14:07, 18 February 2021 (UTC)
  • Symbol support vote.svg Support a ban on proprietary software. It's extremely easy to use free software like Framaforms or LimeSurvey, as several initiatives in Wikimedia have already successfully done for a number of years. On the other hand, it's impossible to guarantee respect of privacy with proprietary software providers like Google, Microsoft or SAP (Qualtrics). Using such software also gives unreliable results, as it introduces a sampling bias by discriminating against people who believe in Wikimedia values like free software and free culture. It therefore makes sense for the Wikimedia Commons community to denounce such surveys as not belonging to this project, whatever the enforcement ends up being. Nemo 16:21, 21 February 2021 (UTC)
    @Nemo bis: As I understand it, the proposal as it is would also apply to a hosted-web-service like Framaforms (since regardless of how ethical it is, it remains a “third-party”) − unless you are suggesting to self-host Framaforms, but then it should be clarified (and I am not aware of any initiatives in the Wikiverse that ever used a self-hosted Framaforms) Jean-Fred (talk) 12:48, 22 February 2021 (UTC)
    Correct, unless there was a 2nd party contract, something that's not impossible to negotiate. However the Framaforms terms are worth analysing against other exemplar third party terms. Their assertion that no user data (including envelope and metadata) will ever be shared with anyone else, has no exemption for cooperating with authorities or legal investigations, whilst the others I've seen specifically do, such as for the UCoC survey. No doubt someone might spin off a weaker proposal that caters for these important distinctions. -- (talk) 13:07, 22 February 2021 (UTC)
  • Symbol strong support vote.svg Strong support hoping to be useful, see this: m:Wikimedia Italia/LimeSurvey (any help or idea to improve or inherit this initiative is welcome! thank you!) --Valerio Bozzolan (talk) 07:46, 22 February 2021 (UTC)
    Nice to see WMIT taking a lead, and the real life case for running Wikimania 2021. Protestations against simply getting on with using LimeSurvey, really does look like claiming "there ain't no such animal". -- (talk) 11:47, 22 February 2021 (UTC)
    Thanks for offerring this service to the movement, it’s awesome :) However, I’m not entirely sure this service would be allowed under the current proposal: it’s still off-wiki, and Wikimedia Italia could arguably be considered a third-party − it’s certainly not part of the WMF, and it’s certainly not hosted on the same servers as Wikimedia Commons ¯\_(ツ)_/¯ Jean-Fred (talk) 14:53, 22 February 2021 (UTC)
    No, it's fine under this proposal. The proposal does not declare the WMF as the 1st party. The intention always was that the 1st party is however our community is represented legally, in this case WMIT is the 1st party. Nor does the proposal say anything about servers or which server happens to be reponding to a Commons project request at any point in time. If the WMF paid for a secure virtual server hosted by a specialized hosting service (which is normal practice), it's still their server, and the same goes for WMIT. That's secure enough for government contracts, it's good enough for us. -- (talk) 15:46, 22 February 2021 (UTC)
    Then I'm afraid your proposal is unclear and would gain by being (again) clarified. Perhaps it's clear to you what is really meant by first/third party, or by “however our community is represented legally” (what is that even supposed to mean?), perhaps by virtue of being a native speaker (which is not going to be the case of most people taking part in this conversation) − it certainly is not to me. This would raise more questions to me − let’s say I’m Wikimedia Germany, can I use Wikimedia Italia’s survey tool (are’t they a third-party to me as first-party?) Let’s say I’m the Wiki Loves Earth team (an entity with no formal legal existence), can I use the Wikimedia Italia survey tool? etc. etc. Jean-Fred (talk) 16:55, 22 February 2021 (UTC)
It's the normal meaning you can find by searching around how contracts work. The 1st party is the obvious sense of whoever is legally responsible for running the survey, it can mean nothing else in this proposal. To have "terms and conditions" this always starts with a statement of who that is. A 3rd party has no direct agreement with them. This is a Commons proposal, not a legal whitepaper for the House of Commons. -- (talk) 20:06, 22 February 2021 (UTC)
It is not, yet you seem to expect people to either be familiar with these English-terms (for what it’s worth, while they probably exist, I have no idea what would be the French equivalents), or to do additional research on contracts and whatnot to understand what your proposal really entails . It is quite apparent from the support/oppose statements above that various folks have very different interpretations of it. Jean-Fred (talk) 21:49, 22 February 2021 (UTC)
To make it very easy to understand, another clarification has been added to explain the plain English meaning of the words used, and so that folx do not have the burden of looking them up. -- (talk) 14:31, 23 February 2021 (UTC)
  • Symbol support vote.svg Support The Wikimedia projects are fundamentally based on free and open knowledge. Why should the way that the way we manage knowledge about our own community be non-free? Because it's convenient to use non-free software? The arguments above that argue against the proposal seem to be based on this tyranny of convenience argument. Evidence against the tyranny of convenience argument is that the Wikimedia wikis have had incredible success by refusing that argument. We do not accept non-free-licensed content (apart from a few exceptions such as fair use images on en.Wikipedia). Right from the start, we insisted on strict application of free-licensing of our content. The sceptics were proved wrong. We refused the tyranny of convenience and chose ethics instead. Some compromises are necessary, but in those rare cases, the onus is on the compromisers to show very clear, detailed, falsifiable evidence of why violating the ethics of free knowledge is needed. A vague statement, "oh, someone said that at a meeting of which I cannot report the details, I'm terribly sorry about the distress that you feel" is not a falsifiable justification for an exception. Boud (talk) 21:29, 27 February 2021 (UTC)
  • Symbol support vote.svg Support At the very least, a clear roadmap should be established to adress the WMF needs with libre tools, if it wants to take seriously its statement of "becoming the essential infrastructure of the ecosystem of free knowledge". I see that Wikimedia Italia already deployed an insance of m:LimeSurvey. Surely they should be able to give us some feedback on this experience. Others tools such as Framadate allow more narrow but often useful polling, and although the non-profit which maintain it provides an instance of Framadate. Surely WMF should maintain instances of that kind tools, contribute to close the gap where features are lacking, and strive to cover all its needs through libre tools both for its interaction with the community (critical to its mission) and internally (very important as it most likely will have side effects on its communications with the community). --Psychoslave (talk) 08:38, 28 February 2021 (UTC)

Discussion (off-wiki surveys)[edit]


Hi. This is something I had not thought on before. I have a couple of questions.

  1. Is there an alternative to these technologies that would not violate our terms?
  2. For mass messaging and posts on notice boards, why not work with a mandatory standard disclaimer on the issue, instead of a full ban?
  3. If we follow the rationale that substantiates this proposal, wouldn't links to most corporate social media --in which some sort of registration is needed-- and media outlets from which cookies are downloaded be banned as well?

Thanks. --Joalpe (talk) 14:26, 13 February 2021 (UTC)

  • Is it possible to create an internal "Wikisurvey" website and request of the WMF to exclusively direct users there? I think that Wikimedia websites should aim to become "a software autarky" specifically to prevent off-wiki abuses from taking place, we can't know what Google does with our data, plus Google logs your IP address and MAC address when you visit websites that aren't even a part of their domains, so "anonymity" isn't even an option when it concerns Alphabet. The most reliable option seems to be creating a Wikimedia internal website specifically for this. It can't be that difficult, can it? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:28, 13 February 2021 (UTC)

My bad. Edit conflict. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:30, 13 February 2021 (UTC)

Some general answers but off the cuff based on past discussions:

  1. LimeSurvey is an example alternative, it's open source and free, and yes the WMF has plenty of capacity to create a survey tool like this, perhaps by (cheaply) forking the open source code that exists already, and making this available to all Affiliate groups by hosting on a WMF managed server... for free
  2. A disclaimer would not be a completely ethical approach, effectively that's what is happening now, but it is unrealistic to expect volunteers to do the background research to understand third party terms or the legal implications of agreeing to release your opinions in a way you may think is confidential, but is being processed in other countries and other jurisdictions than the one where you are typing on your keyboard. Further there is no such thing as consent for Google terms for non-adults as defined differently in different countries, so a "disclaimer" would still disenfranchise our legally non-adult contributors, or result in them breaking the terms without realizing
  3. This proposal relates to surveys. Links to other stuff, like Facebook groups, are not addressed here, nor is the ethical use of tracking cookies should users click on links that take them off-wiki

-- (talk) 15:01, 13 February 2021 (UTC)

@: Thanks for the replies.
  1. Thanks for suggesting LimeSurvey. I had heard of it, and I am glad it tackles concerns you have raised. I will check and eventually work with this technology for surveys our affiliate might run.
  2. Wouldn't a more comprehensive disclaimer with a specific point for non-adults suffice? I understand a long-ish disclaimer does not make sense on a banner, but still makes sense for mass and noticeboard messaging.
  3. Thanks.
--Joalpe (talk) 16:32, 13 February 2021 (UTC)
A disclaimer, long or short, would not solve the list of issues raised by contributors at the VP UCoC discussion. As mentioned disclaimers are hand washing, making the risks of directing volunteers to release their personal information and views on third party tools entirely their fault for engaging, rather than the surveying organizers problem to protect privacy for volunteers. We could add a large bold notice on every banner or massmessage saying "do not follow this link as you may connect your account, IP address and every key press while at the third party site and we have no idea what tracking cookies may remain on your computer afterwards" may be accurate, but it remains unethical. -- (talk) 18:24, 13 February 2021 (UTC)
  • Pictogram voting comment.svg RE: Eissink, I've had the exact same experience with the IRC, during my global ban I wanted to ask for information on how to request a global unlock and a member of the OTRS set up a bot to automatically notify him when I got online and then ban me from that IRC (with the message "Get out troll"). I managed to find a helpful person at the Dutch Wikipedia IRC but then that same (American) OTRS member banned me from there as well. I wouldn't be surprised if the IRC serves as a way for admins to band together to censor dissenting opinions on-wiki but without the scrutiny. Nothing is logged and nothing is ever transparent, I wouldn't be surprised if the WMF doesn't believe in transparency because they see that a very antagonistic portion of "the community" acts like this. At the Dutch-language Wikipedia a scandal happened where a Moderator (or “admin”) used the admin mailing list to get more support to vote in a way to give admins more power and less scrutiny, an admin leaked this and then the leading admin was de-sysopped before the original admin was also de-sysopped. Another incident at the Dutch-language Wikipedia's IRC occurred when two users used it to visit another user in real life when she talked about where she lived. Plenty of abuse happen at these “official” off-wiki spaces. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:08, 13 February 2021 (UTC)
I know more people who had the same experience as you and I. It's scandalous. I did feel the need to mention it here, but perhaps there will be a better time and opportunity to address this (and of course bring it up again whenever it seems right), but for now let's stick to the current proposal – it's hard enough to have issues like this resolved. Thanks, Donald Trung 『徵國單』. Eissink (talk) 15:13, 13 February 2021 (UTC).
  • @: how about where Enwiki ArbCom voting is done now? Isn't that a good alternative platform? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:14, 13 February 2021 (UTC)
    This proposal does not recommend solutions. As it happens all I know about the en.wp Arbcom systems is that they have leaked in the past, I have no idea what legally enforceable guarantee or liability underpins it. Certainly Arbcom do not guarantee that if you choose to correspond with them in any form, that your correspondence will be encrypted or protected from anyone with potential or historic access to those systems, WMF employees, investigating authorities or state actors. So, for example, it would be "unwise" to use those systems to make legally meaningful allegations or to report criminal activity in a way that would expose you to later claims of damages. This is not legal advice, BTW. -- (talk) 15:23, 13 February 2021 (UTC)
  • Die Abstimmerei nimmt hier gerade einen seltsamen Verlauf. Irgendwie soll also die Freiheit der Forschung gefährdet sein, wenn ein externer Forscher, der ein übergriffiges Formular verwenden will, zu dessen Verwendung nicht die Massen-Benachrichtigungsfunktion auf Commons verwenden darf? Dieser Forscher kann ohne weiteres von Hand einen Artikel in die VP schreiben, in dem er seine Forschung vorstellt und begründet warum er ein proprietäres Ausforschungswerkzeug verwendet, oder wird vielleicht statt einer Massennachricht gezielt Accounts anschreiben, die für seine Forschung relevant sind. Commons wird wirklich ganz massiv dadurch behindert, dass es nicht erlaubt ist MP4 oder DNG (oder RW2, ...) zu verwenden. Und obwohl dieses Verbot wirklich eine Katastrophe ist, ist es da. Warum? Weil diese weit verbreiteten Formate im Prinzip (und nur im Prinzip, nicht in der Verwendung in der realen Welt!) nicht frei sind. Aber die Welt soll untergehen, wenn Mitarbeiter der WMF (die per Definition jede Menge von IT, FOSS, Open Knowledge, Menschenrechten und dem Guten in der Welt verstehen) oder Forscher (die als Wissenschafter - im Gegensatz zu Entwicklern in Konzernen - den Prinzipien der Wissenschaft (also Freiheit von Forschung und Lehre, Publish (!) or Perish, Nachvollziehbarkeit, Wiederholbarkeit, Offenlegung von Quellen (Zitierpflicht!) und Daten (Überprüfbarkeit) verpflichtet sind) bei der Verwendung des Massenbenachrichtiungswerkzeugs auf die Einhaltung jener Prinzipien verpflichtet werden sollen, die die Grundlage und Rechtfertigung ihres originären Tuns sind und deren Verletzung ihre Ergebnisse nullifiziert? --C.Suthorn (talk) 05:16, 14 February 2021 (UTC)
  • What the heck has this too do with some academical surveys? This is about internal surveys, done at untrustworthy sites like Google or amazon, or any other off-wiki sites. Why not simply host everything on internal servers, with self-maintained open source software? We, i.e. the Wikiverse, has tons of Dollars and tons of staff to do this, imho this is just the work we, the online community, that generates all this wealth by generating the content, pay those (WMF)ers for. Grüße vom Sänger ♫ (talk) 22:39, 14 February 2021 (UTC)
The wording of the proposal covers all surveys. WMF, academic, affiliate, volunteer, the lot. It is clearly aimed at the WMF, as you can see from the language about blocking WMF staff if they don't follow the 'rules' the proposer wants to create. But it covers other kinds of surveys as well. As to whether the WMF should have its own open-source solution - well, possibly it should, I believe that WMDE does for instance. And I would like to hear from the WMF about why they don't already have one, and how much it would cost. But starting this conversation with "do what we say or we will ban you from Commons" does not help. The Land (talk) 22:47, 14 February 2021 (UTC)
But what then does help? Eissink (talk) 23:08, 14 February 2021 (UTC).
@Eissink: @Donald Trung: I'm shocked reading your statements. I'm really shocked. Lotje (talk) 13:34, 15 February 2021 (UTC)
  • Pictogram voting comment.svg An alternative proposition. Perhaps some volunteers here can create a WikiSurvey using MediaWiki software and then relaunch this proposal two (2) or so years afterwards. At the time of my original “vote” I wasn't aware of academic surveys as I’ve seen the Wikimedia Foundation create Google Forms surveys for years. My problem is perhaps the opposite of Fæ’s, while they are concerned about privacy I am more concerned about transparency (though Alphabet, Inc. clearly offers neither of those). I think that “technical sovereignty” is something Wikimedia websites should strive for, but working together with reliable third (3rd) parties should not be neglected. Honestly blocking WMF employees would be a bit extreme as they create these surveys in good faith, while I can see that some might consider it to be “spamlinking” I see that they just want to have as much data as possible. Last year the English-language Wikipedia launched “a WMF Village pump” and I think that the WMF should have more “embassies” on local projects. I am sure that this poll wouldn't have had so many people voting against third party surveys if the WMF was more transparent in its practices. Note that I am not “changing my vote”, I would rather just see alternatives than the current situation as at least if the policy was successful it would force the WMF to create their own survey software. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:47, 15 February 2021 (UTC)
  • It seems to me that this proposal is kinda rushed, thus I'm not going to cast a "vote". I suggest scrapping up this proposal and opening a proper request for comments instead, and hold off any polling until all issues have been resolved. There's a reason why m:Polls are evil exist in the first place. pandakekok9 08:58, 16 February 2021 (UTC)
    Your link is off-project to an essay that was last touched by anyone over 10 years ago, and even then the history shows that some of the accounts literally only ever edited meta to change that essay. Please make an effort to use Wikimedia Commons policies and guidelines that are agreed by consensus here if you wish to make a meaningful point about Commons processes. -- (talk) 12:16, 16 February 2021 (UTC)
    It being a 10-year-old essay doesn't mean it's meaningless. Consensus is not a vote, nor is it defined by policies. Policies and guidelines only document consensus. And consensus can change. pandakekok9 13:53, 16 February 2021 (UTC)
We agree that consensus is important. The essay you link to has none, all of the policies on Wikimedia Commons do, so use those to put a case, not haphazard off-project documents with no evidence of consensus nor even a vote. -- (talk) 15:48, 16 February 2021 (UTC)

Future of this page[edit]

Note that the future of this page is under discussion at COM:VP#Is COM:VPP still necessary?.   — Jeff G. please ping or talk to me 07:55, 17 February 2021 (UTC)

I want Commons:Deletion requests/NoFoP templates discussion ends soon.[edit]

This discussion is started by someone who saw NoFoP templates mixed into the same category as FoP templates.

So users participated in the discussion, and when multiple users' opinions were combined, it was suggested that the following should be done.

NoFoP templates are moved to NoFoP category. And add a notice that NoFoP templates can only be used for photos of general cityscapes or for photos that can be used, excluding copyrighted parts.

Currently, this discussion has not been running since February 10th, so I think it is correct to end this discussion.

When the discussion is over, I will take action as agreed in the discussion. (I will create Category:NoFoP templates and move NoFoP Templates to NoFoP templates category. And FoP-countries categories of NoFoP countries will be also renamed to the NoFoP-countries categories.)

Ox1997cow (talk) 15:22, 18 February 2021 (UTC)

what is the correct copyright tag for the photos described below.[edit]

My father is deceased. He has many photos he personally took during the 1920s-1960s that fit the qualifications for Wikimedia. I have digitized them and would like to upload them. I am an heir, and I also have permission from my mother who is 104 years old. I would like to give him credit for the photos. What should I enter as the copyright information? — Preceding unsigned comment added by Karen Lindberg (talk • contribs) 05:22, 20 February 2021 (UTC)

@Karen Lindberg: Thank you for taking care of this. You need to contact Commons:OTRS, they will tell you what to do.--Ymblanter (talk) 12:39, 20 February 2021 (UTC)
If you are in the United States, and these photos have never been published (I'm assuming), copyright would last for 70 years past when your father died. The same would be true in European countries, as well. If that copyright still exists, then your mother or other heirs would own the copyright, and it would be your choice as to the license -- Commons:Licensing#Well-known_licenses has the recommended ones (the Creative Commons licenses are preferred). Some of the templates have an "heirs" version to make it more obvious what the situation is -- {{Cc-by-sa-4.0-heirs}}, for example. There is no legal difference between the regular templates and the -heirs versions, just that it can help explain why uploads of old photos can have new licenses. COM:OTRS might have better information as well, as mentioned. Carl Lindberg (talk) 19:36, 20 February 2021 (UTC)

So, I have figured out that I need to use this code and an associated template. How do I do that? Do I edit the picture and paste it in somewhere? {{PD-heirs}} {{PD-heirs}} – for works released into the public domain by the heirs of the creator. — Preceding unsigned comment added by Karen Lindberg (talk • contribs) 21:04, 20 February 2021 (UTC)