Increasing user testing and feedback (was Re: Bad-mouthing and hostility)

[Bill Nottingham]

Tom spot Callaway (tcallawa at redhat.com) said: 
> I posit an alternative suggestion:
> 
> * At firstboot, the installing user is asked if they would be willing to
> participate in user-driven updates testing. It is explained to them that
> in Fedora, updates to packages need to be tested by users, and that if
> they opt-in, they will be prompted from PackageKit about updates which
> need user testing. They can choose an update which needs testing from a
> list. Once an update is selected from the list, PackageKit will apply
> the update from updates-testing, then open a new window which contains:
> 
> * General update testing advice
> * Package specific update testing advice (this can live on the wiki)
> * A graphical selector for giving +1 (works great!), 0 (cannot determine
> state) or -1 (something didn't work)
> * A text box for inputting comments
> 
> The user then submits the results, which go into Bodhi. Once results are
> submitted, that update no longer appears in the PackageKit "updates
> which need testing" list.
> 
> If they report a 0 or -1, they are then prompted to back out the update
> by PackageKit (at their choice).
> 
> * On the backend, should a user choose to opt-in, they would be prompted
> to create a FAS account (or authenticate to an existing FAS account)
> (e.g. RHN handling in the past). They would _NOT_ be required to sign
> the Fedora CLA in order to participate in user-driven testing, as
> reported results from QA testing has already been determined to be
> non-copyrightable and thus, not considered a contribution.

I'd genericize this. On firstboot, *EVERY* user should be asked if
they want to create a fedora account.  It would describe the privacy
policy (in brief, with a link), describe the things that can be done
(comment on updates, file bugs [*], respond to surveys, participate
in leadership, other stuff here.) They'd then enter their proposed
account name (which would do an online check), an e-mail address, and
a password. It's sort of a 'register your product' approximation.

Then, whatever update-testing tool you create can just use this existing
infrastructure - I wouldn't gate the account registration on just wanting
to do updates-testing. Heck, you could extend this into the initial
'create a user' dialog.

Bill

[*] The idea being that with an e-mail + password, you can *also* register
for a bugzilla account at the same time. Woo, faked single-sign on!