Andrew Gray, 30/04/2014 21:47:
It's certainly simpler to implement, but anything
that involves
on-wiki recording has two main problems:
* friction in saving the entry (eg edit conflicts, login required,
user IP blocked)
Edit conflicts are supposed to be avoided, when appending text to a page
via API. Please file a bug if this is not working, we have some reports
but they're all quite incomplete.
The rest may skew a survey from a scientifical point of view, but won't
significantly spoil a simple collection of comments IMHO.
* privacy problems (comments are public and
effectively attributed)
On the other hand you don't have to worry about private data, you're
left only with public data. Of course users need to be informed.
This isn't much of an issue for things like "please give us feedback
on the new fancy upload tool" - where everyone can be expected to have
a functioning account and aware of how the wiki works,
Sure. In fact the goal is «capture user feedback about Upload Wizard as
soon as they have completed their upload, while it’s still fresh on
their minds» and that's exactly what mediawiki.feedback.js does
currently within Special:UploadWizard, just not very prominently. (Even
MoodBar does/did that I suppose.)
but if you're
going to be gathering feedback on reader-focused things it breaks
down.
True. However the surveys we're talking about here are in the order of
10³ respondents. It's a lot compared to e.g. the few hundreds per year
in
<http://vs.aka-online.de/cgi-bin/wppagehiststat.pl?lang=commons.wikimedia&page=Commons:Upload_Wizard_feedback>,
but not so explosive. pl.wiki's
<http://vs.aka-online.de/cgi-bin/wppagehiststat.pl?lang=pl.wikipedia&page=Wikipedia:Zgłoś_błąd_w_artykule>,
fed by a popup in sidebar, seems to work well.
Nemo