CZ:Proposals/Enable external feedback

This proposal has been assigned to Approval and Feedback, and is now in the Approval and Feedback proposals queue.

Summary of Issue

Readers who notice errors, but aren't interested in creating accounts, should have an easy way to let us know without leaving the wiki. There is widespread agreement that non-Citizens should not be able to view feedback to prevent spam, but other details have yet to be decided. In the future we may explore allowing feedback in the form of machine-readable proposed edits, but for simplicity we are deferring that decision until we get experience with a simpler scheme.

Support

1. Allow casual good Samaritans to help us improve.
2. Submitting feedback is a low-commitment way for potential Citizens to get their feet wet. If we act on feedback, we can send the submitter an email thanking them for the feedback and encouraging them to sign up as a Citizen.
3. Allows for addition of interesting factoids and local knowledge, not readily apparent to an outsider.

Anti-support

1. We may get swamped with too much low-quality feedback
2. Probably requires modifying MediaWiki software.
3. Possible source of computer trojans, viruses, etc, and possibly gossip/slander/libel of Citizens.

Some preliminary discussion

1. [An old thread] (January 2007).
2. A related [discussion]
3. [A reader gives feedback through the forums]
4. [Discussion of anonymous edits, which is closely related to user feedback]
5. [Mention in brainstorming thread]

To be decided

1. Whether feedback should be routed specifically to authors of an article, or to whoever is watching the article whether authors or not
2. Whether to allow feedback on all articles or just approved ones

Arguments in favor of routing comments to authors:

1. Someone fill this in

Arguments in favor of routing comments to articles:

1. Citizens may be inspired to edit an article to address feedback.
2. Current policy is that articles are not owned by authors. Changing that would be an independent proposal that shouldn't be combined with this one.

Arguments in against routing comments to authors:

1. All authors may no longer be with CZ, therefore route comments to Workgroup AND Talk page for action.

Arguments in favor of allowing feedback on all articles:

1. Non-approved articles need substantial improvement, so allowing feedback on these will offer many more opportunities for readers to send feedback and get hooked on CZ. Feedback on approved articles will only happen when we mess up.
2. Readers may have local knowledge about a subject, that is hard to find, but which can be verified once it is pointed out.

Arguments in favor of allowing feedback only on approved articles:

1. Someone fill this in

Implementation details

wikiHow's "thank the authors" or discussion functionality might be adapted to our purposes.

Warren's Opinion

This section is not an official part of the proposal, but rather a summary of Warren's reasoning.

Why machine readability is important

Scenario A:

Suppose a reader is looking at Composting. They click on "send us feedback on this article" and send the following feedback:

In the introduction, "Actually it is one of the oldest forms of recycling of waste." in the introduction is not good english. Consider removing "actually", yielding "It is one of the oldest forms of recycling of waste."

A Citizen reads this feedback and does the following:

• finds the sentence in question
• deciphers the English change instructions and evaluates the edit.
• If the edit is a good idea, actually does the edit
• Marks the feedback as "resolved" in some way so another citizen does not repeat the work.

This is an unnecessary amount of work, both for the reader, who has to express a diff in English, and for the Citizen who parses, evaluates and executes it. Shouldn't we use computers to make this easier?

Scenario B:

A reader notices this error and clicks "send us feedback on this article". The reader puts "bad english" in the feedback box. Below the feedback text box is an ordinary Wiki edit interface, which the reader uses to fix the problem. The reader then submits the feedback. (Readers are of course free to use just only the feedback text box and ignore the edit box.)

A Citizen views the feedback and is presented with a diff for the proposed edit. If the Citizen likes the edit as proposed, s/he can endorse it with one click. If not, s/he can write a comment on the feedback.

Discussion:

Scenario B is less work for the reader and the Citizen alike.

Of course, feedback of the form "I don't understand X" would not benefit from the machinery of scenario B. Often readers will know how to fix it, so why make it harder than it needs to be in those cases?

Scenario B would save time for Citizens but would presumably be a lot harder to implement in the software, so we may want to start with scenario A and defer automation for later. I therefore describe two versions of the interfaces for readers and citizens, with and without automation to handle machine readable feedback.

Reader's interface, no automation

People who are not logged in, herein referred to as readers, have access to a "feedback" tab instead of the "edit" tab. There is no need for readers to give feedback on talk pages, so clicking on "feedback" on a talk page should send the reader to the feedback page for the corresponding article. The links for editing a section of an article should also be converted into feedback links.

The feedback submission page includes:

• A large text box for writing free-form comments
• An optional field where the reader can give an email address to allow us to let them know if their comment is acted upon or we have questions
• A "submit" button

Citizen's interface, no automation

There is a global page analogous to "recent changes" that shows all recently submitted feedback. There is also a "view feedback" tab for each article that shows feedback for that article.

There needs to be a way for Citizens to email the contributing reader without disclosing the readers' email address (analogous to the "email this user" feature).

Reader's interface, with automation

People who are not logged in, herein referred to as readers, have access to a "feedback" tab instead of the "edit" tab. There is no need for readers to give feedback on talk pages, so clicking on "feedback" on a talk page should send the reader to the feedback page for the corresponding article. The links for editing a section of an article should also be converted into feedback links.

The feedback submission page is very similar to an edit page, but with a few differences to reflect its distinct purpose. It includes, in this order:

• An explanation that the reader may either write a comment in prose, make a proposed edit using the wiki machinery, or both.
• A large text box for writing free-form comments
• An optional field where the reader can give an email address to allow us to let them know if their comment is acted upon or we have questions
• A "submit" button, for use of readers who don't want to use the wiki edit box
• An ordinary wiki edit text box
• "submit", "preview" and "show changes" buttons.

Unlike a citizen edit page, a feedback page does not have:

• "minor edit", "watch this page" or "content from WP" checkboxes
• An edit summary (that's subsumed by the free-form comments box)

Citizen's interface, with automation

Submitted feedback is essentially an edit, but is dealt with separately and a bit differently. The biggest difference is that feedback does not actually modify the articles immediately.

There is a global page analogous to "recent changes" that shows all recently submitted feedback. There is a "view feedback" tab for each article, analogous to history, that shows feedback for that article.

When viewing a piece of feedback, a Citizen gets:

• A list of actions taken by other Citizens in response to that feedback, if any.
• The free-form comments
• The diff for the proposed edit, relative to the version of the article that was current when the reader submitted the feedback
• An ordinary article edit interface
• Buttons to load into the edit interface either the current version of the article, or an automatic merge of the reader's suggestion and the current version.
• Information to help with the merging process
• A text box for sending questions or thanks to the reader, if they supplied an email
• A big red button

The big red button:

• Saves the changes to the article, creating a history item in the name of the Citizen who reviewed the feedback.
• Optionally sends email to the submitting reader, informing them of the change, thanking them, and suggesting that they become a Citizen
• Marks the feedback as "dealt with"; Citizens can choose to skip those when viewing feedback lists.

I'm pretty sure it is possible to revert a change that's not the most recent one, so there must be code for merging changes. I wonder why that code isn't used to suggest resolutions to edit conflicts?

Stephen's opinion

Note: this section quotes Stephen Ewen but was written by Warren Schudy.

[| Stephen Ewen writes:]

The code to allow something close to that in MediaWiki exists, is available just for the asking, and could be adapted for CZ. You can see it at work at WikiHow--the folks there developed it. Go to any article, say, [[1]], and scroll down to the bottom. You will see a link "Thank the Authors". This goes to a page where one writes a message that then goes to each of the main contributors of the article (that's another thing that could be added--you can view that at the bottom of the page there as well). The messages then aggregate at a special page, called "Kudos", for each author. The code that names the authors and allows reader feedback are dependent.

I am not sure we should implement it--maybe we should, maybe we should not--but the ability to do it is there. One issue is that we'd really not want to receive anon IP feedback (which is what all of it would be) on anything but approved articles, so that would mean writing code or, perhaps, placing all non-approved articles on a draft subpage. One good thing--and this is a major thing that would incline me to support it now, where I formerly argued strenuously against it--is that none of the comments would need to be moderated (meaning this would give constables no new tasks), since they are only viewable to the specific authors of the article. Someone could cuss the authors out and the outcome would be no greater than receiving a spam message in one's email inbox.

Again, however, naming principle contributors to an article through the mechanism mentioned above, and this anon IP feedback system to them, are dependent. We'd have to decide on the former before the latter, or come up with something other than adapting this code from Wikihow to allow the feedback. I very much think CZ should adopt the author attribution system, for reasons I've spelled out elsewhere.

Differences from Warren's proposal:

• Feedback only viewable by authors
• Limiting feedback to approved articles

Discussion

I think its a good idea as long as its technically feasible. --Denis Cavanagh 14:27, 9 February 2008 (CST)

This could be a source of malicious code. Saveguards would be needed to parse the text. -- David E. Volk 08:24, 11 February 2008 (CST)

It would be best if outsider's comments came somehow to the notice of the main author(s) of the articles commented on. These authors could read the comments and decide whether or not to include them in the article. I don't foresee in the near future so many comments that this process must necessarily be automatized. If it becomes too much work, we can always start a new discussion on how to parse and edit automatically (including the difficult problem of automatic saveguards). --Paul Wormer 08:53, 11 February 2008 (CST)

Is there some reason why we aren't working together on a single proposal? --Larry Sanger 11:32, 11 February 2008 (CST)

A single proposal is the eventual goal of course, but currently people disagree about some things, such as:

• Whether feedback should be routed specifically to authors of an article, or to whoever is watching the article whether authors or not
• Whether to allow feedback on all articles or just approved ones

If the proposal system had a distinction between issues and proposals, this would probably be an issue, not a proposal. I think it's best to flesh out in detail several different plans so we can make a decision based on a comparison of detailed plans rather than just rhetoric. I am also trying to make this document a summary of people's opinions similar to CZ:Summaries of policy arguments, so it needs to discuss differing views. Accepting feedback is an important step in the evolution of CZ, so it deserves a summary of arguments IMHO. Warren Schudy 18:58, 11 February 2008 (CST)

After spending some time recently thinking about the details, I've changed my mind and I now propose that the initial feedback system should not have machine-readable edits. I still strongly believe that machine-readability is the way to go long-term, but I think we should get some experience first with a simple system before implementing automation. I'll write/rewrite the basic proposal section sometime in the next few days. Warren Schudy 18:58, 11 February 2008 (CST)

The first three sections now summarize what I believe is uncontroversial, what is uncontroversial, and some arguments. Please comment. Warren Schudy 19:49, 11 February 2008 (CST)

Reader feedback must go the workgroup associated with the article, because the primary author, even possibly all of the authors, may no longer be with CZ at time of the comment. David E. Volk 10:56, 13 February 2008 (CST)

Approved articles or all articles?

Please sign your support in one section or the other depending on whether you think we should accept feedback on all articles or only on approved ones.

In favor of accepting feedback on all articles

Warren Schudy David E. Volk