ubuntu-phone team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Schroll wrote on 20/12/14 02:59:
> 
> On Fri, Dec 19, 2014 at 9:29 PM, Victor Thompson 
> <victor.thompson@xxxxxxxxx> wrote:
>> 
>> This requires more 2 way communication and the ability to respond
>> to ratings. Or maybe just simply obsoleting things regarding
>> older platforms or development releases.

In 2012 I designed a UI for replying publicly to reviews.
<https://wiki.ubuntu.com/SoftwareCenter/RatingsAndReviews#replying>

> I think the two-way communication is crucial.  I have a review/bug 
> report describing a problem that I cannot reproduce.  Has the user 
> messed up their system in some strange way, or do I actually have
> a bug in my app?  I need the user to run some diagnostics, but I
> cannot contact them.
> 
> ...
> 
> I feel like this could be implemented in a person-week.  Less, 
> perhaps, if that person were already a scopes and Launchpad
> expert. Once that's working and insanely popular, we could add
> other backends.

When designing anything that involves multiple people, an important
use case to consider is: What if someone is a jerk?
<http://floate.com.au/2014/10/next-project-needs-white-hat-jerk/>

What if a *user* is a jerk? They may give a one-star review
complaining that your spreadsheet app doesn't appeal to their toddler,
or that one particular level of your game makes the entire game terrible.

Letting developers reply publicly is an indirect solution to this: it
gives other users context to understand that "yeah, that review isn't
really fair", so they can then mark the review as unhelpful.

But while replying publicly is good for that, it's not so good for
troubleshooting. Other users, reading reviews, don't want to have to
wade through the developer's requests for someone else to attach this
or that log file in an e-mail message to such and such an address.
(Even if Ubuntu Touch's app permission policy allowed that, which it
wouldn't.)

For interactive troubleshooting, you instead want the developer to be
able to contact the user privately. Some users may feel comfortable
with that, while others aren't. So you might think the solution would
be a checkbox on the review form, "Let the developer contact me about
issues with this app" or something like that.

But then what if the *developer* turns out to be a jerk? If your
livelihood depends on good reviews, you may be tempted to lash out at
people who leave bad reviews.
<http://mashable.com/2014/08/06/hotel-apologizes-bad-reviews/>
<http://www.bbc.co.uk/news/uk-england-30111525>
<http://krazykiwi.booklikes.com/post/1024442/the-richard-brittain-case>

A reviewer usually can't predict, ahead of time, whether a particular
developer will be like that. So either you don't implement this form
of communication at all (relying instead on adjustable automatic
error-reporting recipes), *or* you implement a method of reporting and
dealing with harassment if it does occur -- and fund staff to monitor
it. Which probably means that it's not just a person-week of work.

- -- 
mpt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEUEARECAAYFAlSqo2IACgkQ6PUxNfU6ecr/CQCeNEvs0/glGBv9SY2ynxnUhsEK
pxQAmKZVJxO5YFW9wAx1kA+c0TRd8WE=
=A3k9
-----END PGP SIGNATURE-----