Commons:Requests for comment/Feedback

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

AFT (or similar) when available for files can be tested on commons. –Be..anyone (talk) 04:10, 2 January 2015 (UTC)

---

Background

See also: mediawiki.org > Article feedback.

The Article Feedback Tool (AFT) was developed for Wikipedia, as a way to help encourage reader engagement with content. Early versions simply asked for quality ratings, but the tool was developed through several versions into a system to invite free-text comments and provide a workflow for handling these.

The deployment on the English Wikipedia was highly controversial, with concerns that it:

1. produced too many comments for editors to handle effectively,
2. had too much "noise" - unhelpful or irrelevant comments,
3. discouraged readers from editing by providing another avenue for interaction.

After lengthy debate in early 2013, it was disabled on the English Wikipedia (with opt-in exceptions allowed); later on it was disabled on the German Wikipedia after a trial; French Wikipedias were under way as of March 2013. The project may be rolled out to other wikis through 2013, with local consensus.

Use for Commons

See also: Commons:Village pump/Archive/2013/01#"Article feedback" for images?.

Over the past ten years, Commons has acquired a large number of bulk uploads from institutions and other external partnerships. One of the things that is of interest to the donors is getting more information about the collections; we know from past experience, such as with the Bundesarchiv project, that exposing the material on Commons can produce very helpful feedback. Wikimedians, and our readers, are engaged and interested, and can provide very detailed information.

However, Commons is not very well set up to collect this feedback. Leaving notes directly on image description pages or image talk pages may not be noticed for months or years (many bot-uploaded files are never watchlisted by a human), and the centralised pages for gathering comments are difficult for a user who is not already familiar with Commons.

A version of the Article Feedback Tool would potentially be a good fit for this problem. It will help gather more comments, while able to be restricted to only files where we want such comments and are able to handle them effectively. A similar proposal was made for a "report a problem" tool in March 2013, which addresses a different use case -

Alternatives

A "report a problem" wiki-based interface was proposed, as used on other projects since a few years ago: Commons:Village_pump/Proposals/Archive/2013/03#Report a file (feedback) tool.

Proposed actions

I propose the following:

1. We ask WMF ops to enable Article Feedback for Commons, set up to work on a selective basis (ie, opt-in per page on a category/template system).
2. We adopt a policy that says:

   • AFT can be enabled on individual files or groups of files on an opt-in basis.
   • AFT should not be enabled without a contributor willing to handle the feedback for that collection (this contributor may be an existing Commons user, or an institutional representative).
   • AFT can be disabled if there is no activity in handling comments after a reasonable period of time.

3. We work out a suitable method for wording the feedback request form and titling the system.

For more details on the practical implementation, see Commons:Requests for Comment/Feedback/roadmap

Common questions

Please feel free to ask further questions in the comments below.

1. How many files would it apply to?

   This would depend on individual uploaders/contributors opting in! I am currently working on an upload of the Canadian Copyright Photograph Collection - this will be around 4,000 files from a previously unpublished collection, where we have variable metadata and reader contributions could be very valuable. The contributing institution is willing to help take in and handle any feedback recieved.

2. How will it be enabled?

   Technically, AFT is enabled for specific pages by categorization. The simplest way to do this would be to have tracking templates from specific bulk uploads include that category.

3. Won't we get a lot of useless comments?

   On Wikipedia, an awful lot of the comments were useless - they were personal opinions about the subject of the article, irrelevant questions (eg looking for phone numbers), or simply vandalism. However, readers using Commons tend to be more focused on the content of images, and this should hopefully mean we're less likely to get personal opinions about the subject. There will certainly be less traffic!

4. But these aren't "articles"...

   The Commons version can be given a different name - "image feedback" or "media feedback", for example.

5. How much will this cost in terms of WMF employee time to develop, implement and maintain?

   The direct costs is unpredictable, given the experience on the English Wikipedia.

Comments

Support

• I support enabling it on a selective basis, what's to lose? I can see it could be useful for instance for unidentified subjects (eg people/places in historical photographs). Perhaps have it only for specific wikiprojects where there is a group who want to utilise it, perhaps a common template for adding the appropriate category tag and fields so they can specify the sort of feedback they're looking for. --Tony Wills (talk) 01:47, 17 March 2013 (UTC)
• I support the general idea of establishing a userfriendly, low-hanging-fruit-approach on getting user feedback to improve our descriptions & metadata. The Library of Congress is using Flickr for the very same reason. Some images like this feature +400 comments - some of them useful, some of them not. A technically AFT based comment feature on Commons is a tool worth experimenting with and could be the incentive for a more sophisticated solution. File discussion pages are rarely used by an average user/IP to improve descriptions & metadata and error report (like the Bundesarchiv's) are an exception so far. Regards, Christoph Braun (talk) 20:10, 18 March 2013 (UTC)
•  Support - I know the experience on English Wikipedia was poor; there are good reasons to think even turning it on globally on Commons would be nothing like as bad. Turning it on in a way that allows control over where it's applied seems like a good way to see whether it can be useful here - especially where we can get engagement from institutional contributors. (I suspect one of the things it will end up catching a lot of is frustration from people not sure about whether they can use an image or how to credit it, etc; but if that's a pattern that emerges, that's something we can try harder to address.) Rd232 (talk) 22:44, 18 March 2013 (UTC)
•  Support Mono 15:59, 19 March 2013 (UTC)
•  Support - I was a critic of the software on the English Wikipedia but I can see it being much more useful on Commons to gain feedback on descriptions and the quality of the image, particularity as traffic is a lot lower and talk pages are hardly used at all in practice. Deploying it on a category-by-category basis will mean people won't have to use it if they don't want to. CT Cooper · talk 15:16, 14 April 2013 (UTC)
•  Support I did not find the tool useful on ENWP but think an opt-in scheme could be beneficial here, especially for those bot-uploaded batches of files. -- Daniel Mietchen - WiR/OS (talk) 21:26, 23 April 2013 (UTC)
•  Support worth doing even if the initial sample is small, as an experiment for later expansion.--KTo288 (talk) 07:53, 27 April 2013 (UTC)
•  Support Let’s do this. If it turns out useless, we will just shut if off and forget about it. The software is here, let’s be bold and use it. Deployment on group of files can be very easy through our Source/Partnership templates. Jean-Fred (talk) 13:56, 27 April 2013 (UTC)
•  Support JKadavoor Jee 16:14, 27 April 2013 (UTC)
•  Support Good one, particularly if we have interested content donors who really want this stuff who will go through it - David Gerard (talk) 19:20, 2 August 2013 (UTC)
•  Support John Vandenberg ^(chat) 02:59, 8 August 2013 (UTC)
•  Support Commons have less visitors than Wikipedia, more specialized, and less vandalism. Eloy (talk) 18:54, 13 June 2014 (UTC)

Oppose

• ...

Neutral

• ...

Discussion

• Why would this be a greater priority for WMF developer time compared to fixing the search function, improving the edit interface or speeding up responses to critical fixes such as the broken delinker? (Fae)

I don't believe developer priority is an issue here; this is routine operations, configuring and deploying an already-created piece of software, rather than developing it from scratch. We don't have a fixed budget of "WMF hours assigned to Commons", in any case, that this would be using up!

I've spoken to the AFT people about the practicalities, and while I don't have a firm answer in terms of person-hours, it doesn't look like it will be unduly burdensome to them. (I'll ping Oliver for more details.) Andrew Gray (talk) 09:18, 18 March 2013 (UTC)

We're working on a 'turnkey solution' - in other words, something that can be deployed with minimal effort. The nature of the objection confuses me somewhat, so I'll start from first principles and try to explain how software development works at the Foundation:

• Engineers are divided, in Features, at least, into different teams seconded to a Product Manager. Each team is, these days, relatively permanently constituted and works on features in a particular area; we have the Editor Engagement team, which works on, well, editor engagement features, we have the Visual Editor team (which does what it says on the tin), we have the Mobile team, so on and so forth. Outside of Features and Product we have Platform and Operations, who do the necessary and unfortunately largely thankless work - fixing bugs in MediaWiki itself, keeping the servers and infrastructure working, so on and so forth. These sub-departments are also relatively fixed.

  AFT5 was developed by the Editor Engagement team; I say 'was' because we've pretty much finalised development and are switching our efforts over to Echo. In other words, if porting to AFT5 was (or became) a massive effort, we'd simply apologise and have to not undertake it - although I'm relatively sure it isn't. Even if we were to all go slightly mad(der) and decide that, despite the high barrier to making it work here, that was work we wanted to do, and if Erik was somehow to sign off on this, we would not be taking any resources away from 'fixing the search function' (which is something Operations have hired an Engineer specifically for, I believe) or 'improving the edit interface' (which is the job of the Visual Editor team) or 'speeding up responses to critical fixes such as the broken delinker' which would, I believe, be Platform's job. And if we decided that deploying here, however trivial, was not something we wanted to do, we wouldn't be taking any resources away from those projects - first because AFT5 has pretty much already been finished, and second because none of the examples given draw on the same pool of resources as AFT5. Yes, theoretically we would be marginally slowing down developing Echo or a replacement for talk pages, but the key word is 'marginally'; as said, deployment is merely deployment, not the development of new software. Okeyes (WMF) (talk) 09:46, 18 March 2013 (UTC)

• Which extension are we actually talking about here? ArticleFeedback (where you rate various qualities with stars) or ArticleFeedbackv5 (which is like a comment moderation system)? I have no idea why the Foundation gave two completely different extension such similar names, but it seems like a pretty important think to clarify. Kaldari (talk) 06:13, 15 May 2013 (UTC)
• Hi folks, thanks for your interest in the Article Feedback Tool for Commons. As the product manager for AFT5, I am happy to hear that you think this tool could be useful for multimedia files, and would love to help adapt it for that purpose. The Wikimedia Foundation is in the process of forming a new multimedia team, which would be responsible for this project, along with other goals outlined in this original plan. I have been invited to join that team as product manager, and expect that enabling feedback for images will be a high priority for us, along with curation tools and better display of images on other sites. In the meantime, I encourage you to check the specification for a new feature we recently developed to quickly enable or disable feedback on an article: this tool could be adapted to meet the goals outlined above (the main difference I see is that we would need to add the ability to enable feedback for a batch of images -- assuming that we are comfortable with the tool's other features). That said, Kaldari's question above is an important one to resolve early on: what are the pros and cons of enabling comments (vs. simple ratings) for this application? Comments enable users to provide specific suggestions about an image, but require a lot more moderation. Ratings are much easier to manage, but do not provide as much actionable information about why a user likes or dislikes an image. In any case, I look forward to continuing this discussion in coming months, as we ramp up our multimedia initiative over the summer. :) Fabrice Florin (WMF) (talk) 20:37, 3 June 2013 (UTC)

I would say "simple ratings" by users would be of absolutely no use whatsoever, what's the point? Maybe low rating means delete it? You might want to rate the usefulness of an image on a particular wikipedia page, but that's not relevant to work done here. --Tony Wills (talk) 02:52, 15 June 2014 (UTC)

---

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