Dear Roan,
Thank you very much for your detailed explanations. I appreciate it very much.
Even though, I do not fully agree with all your design decisions (regarding two different feedback mechanisms), they are understandable from your position (as far as I can anticipate it).
Last comment on this, wouldn't be great to integrate both mechanisms in a way. I mean that the user can simply decide whether and when she wants to send some additional information (about the browser used etc.) by just selecting a checkbox (that explains the difference). So in every situation (before and after editing) the user can provide some feedback. The user can easily and understandable (at least I believe) decide about the extent of the feedback. Maybe is this (=my) feedback useful for the beta-testing-version :)
Claudia
On Apr 29, 2013, at 9:52 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
On Fri, Apr 26, 2013 at 11:37 AM, Claudia Müller-Birn clmb@inf.fu-berlin.de wrote:
Hi James,
Thanks for clarifying.
I am just wondering why the two feedback mechanisms send to different targets which I personally find a bit confusing. What has been the decision behind it?
They are different feedback mechanisms with different privacy expectations. The "Leave feedback" flow collects general, free-form feedback about the editor and posts it publicly. Only the text the user types into the form is collected and published. The "Something is wrong" flow is intended to collect data about cases where users see a diff they don't expect. It collects a lot of information to help us figure out what happened and why; this not only helps us find bugs, but it also collects the information we need to track it down and fix it. Because the information collected includes the text the user was attempting to save but apparently chose not to save, we treat it as private information.
So one flow collects general feedback and the text field is all we collect, whereas the other collects data about a specific failure and the text field just serves as a footnote on a lot of technical data we collect along with it and is narrowly focused on the specific problem at hand: what did the user do to trigger the bug. In the general feedback flow, we communicate to the user that what they submit will be public, and it's very easy to explain what will be public (the text they put into the field). In the bad diff report flow, the data we collect (editor contents with an unsubmitted edit, among other things) is a bit more privacy-sensitive and it's hard to explain to the user what we'll be collecting.
And why is the "Something is wrong" or "Etwas ist schief gelaufen" a privately sent feedback? Wouldn't be great to have here an open process and not sending the feedback to a black hole?
This flow is mostly for reporting bugs, and the form asks them to provide details about the specific bug they encountered rather than general feedback. These comments wouldn't be particularly useful without the associated debugging data. The debugging data isn't particularly interesting to the general public, only to developers (that's not an argument for why it shouldn't be public, just one for why it doesn't hurt too much that it's not public). We feel like it would be against the spirit if not the letter of the privacy policy to publish this data without telling the user what we're publishing (especially since unsaved editor contents are privacy-sensitive: there is no expectation they'll be published because they're unsaved). But it's also difficult to explain to the user what exactly it is that we would be publishing.
Contrary to the confusion and other reports on this thread, I can assure you that the data submitted through the "Report problem" interface isn't sent to a black hole. It's being collected by the Parsoid team, and they have in the recent past analyzed it and discovered bugs in both Parsoid and VE.
Roan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l