Matthew Revell interviewed Ryan Paul while at UDS-L in Dallas, November 2009.

{{{
From: Matthew Revell
Subject: User testing: Ryan Paul
Date: Tue, 17 Nov 2009 23:48:12 +0000

Hi guys,

Here are my unedited, badly typed notes from our session with Ryan.
I'll fix this up into something less raw.

Ryan: please reply-all if you spot anywhere that I misrepresent what
you said or you have something you'd like to add.

STARTS:

Runs Gwibber project.

Gwibber started as a testbed to experiemtn with things he was writing
about as a journo, wnated to write about distributed dev etc. Jorge
encouraged him to try LP and he did.

Compelling service. Best of those he tried. Also tried Trac (more
simplistic), Github.

Collaborative: by that he means that it provides a good platform for
dialogue around the code. Dialogue and building a conversation between
many people around a set of ideas and tasks is the function of a
collab devel platform.

Part of the adv of LP is that it has very tight integration with the
env that he develops in. In terms of collab, it provides a richer set
of tools, particularly version control -- branching and built-in code
review, the workflow that LP encourages is a lot nicer than some of
the alternatives. Really conducive to dialogue.

Ryan has the active branch proposals page bookmarked. This is where
contributors have created their own branches with fixes and things
they want to improve. Ryan can see what discussion there is, who else
involved.

An example comment is someone might say they're working on something
similar, or someone who is working on lower level stuff may say that
it's not poss to merge right now. People discuss the implication of
changes and how best to work with those changes.

Ryan can easily see who is saying what.

Likes voting feature on code review. Likes to be able to say "Approve", etc.

Great to have all of that in such a clean simple interface.

Merge proposals is his window into what's going on. Sometimes takes a
general look at the overall page of branches and it's ordered by date
so he can see what the most recent branches are and what sort of fixes
and ideas people have.

he may look at someone's been working on and merge it even if someone
has proposed it. The env. makes that really easy.

Other people do this too for Gwibber. Really easy for them to
coordinate. Can keep track by watching the commits. Gets emailed merge
reports -- likes email better than the web itnerface -- mostly prefers
working in the web interface but really likes getting an email with
the diff of a commit and that's pretty useful.

Finds that when communicating with Canonical it's easiest for him to
work through Jorge and Jorge knows everyone so he always knows who to
speak to and best way to reach that person. Usually irc or IM.

Uses the bug tracking system a lot. One of the main appeals of a system like LP.

Usually has a tab open with the bugs list. Not sure if you can sort by
most recent, never thought of that before. Usually clicks the "Last"
link and goes to the end but may now change workflow.

Sometimes looks over the list and his eye jumps to those that have
Confirmed status and so it's maybe worth looking at that in more
detail.

Doesn't look at New bugs that often as there's so many. When he sits
down to fix, he looks at confirmed but there are many other
contributors who want to triage because they don't have the tech
expertise to do other stuff and Ryan has limited time to do triage.

Would prefer it if Fix Committed bugs didn't show up in the main bug
list. He already knows that a bug has been fixed because he's seen the
change in the code.

There are a lot of parallel features that are a bit redundant. Not
always clear what to use and how they related together. What belongs
in Answers and what belongs in Bugs? Sometimes users get confused.
Doesn't really give Answers that much attention.

Prefers feature requests to go in Answers and software issues to go in
bug reports. Would like Answers to be like a web feedback service.
Would like a separate feature request system that's sort of integrated
with the bug tracker. Right now gets a lot of bug reports that are
actually feature requests and he marks them as wishlist. Can confuse
the bug report list. Would rather have a feature request and turn that
into a bug report when he starts working on the feature.

Too many different places to put things but also would like more
granularity. Maybe some way of separating out feature requests.

Almost always has to ask them for the version number or what revision
number of trunk they're using. He has no way to sort by the version
number, though. he wants to see all the bug reports that are
associated with a specific version. (TAGS?!)

Wants to require that when someone submits a bug report they submit
the version number.

Would like the same for platform.

Would like separate bug reports and merge proposals per platform.
(Series! Projects!)

Has to infer from comments etc what version they're using.

Looks at who's subscribed to a bug so he can see who cares about it.
Helps him guague the importance of the bug. He has certain people who
are reliable bug followers who he knows he can rely on to let him know
if there's a problem etc.

Tries not to spend too much time looking at bugs filed against
packaged versions of Gwibber. Depends on distros to come to him with
issues they feel need his attention. So, SELinux problem with Fedora
-- Fedora packager brought it to his attention and he spent some time
looking through similar bugs.

Treats Ubuntu the same way even though it's there in LP. Feels a bit
more responsible for quality of package in Ubuntu as there are more
users. PAckagers are good, though, so he waits for them to highlight
issues. Considers himself an upstream so he concentrates on that. Ken
Van Dine and asac will do Ubuntu-specific stuff.

Would like to see more social features. Github has the advantage that
he can go to the profiles of his firends and follow them and track
what tehy're doing, what they're committing. LP's collab capabilities
could be improved there. Likes the way that Github does it. An
activity stream lets you see exactly what your friends are doing ,
what commits they're pushing in.

He likes to have a feel for what his friends/co-workers are doing. He
sees the changes his co-workers make at ars technica because he's
following them.

He wants to follow people in LP, not just projects, because he's
interested in what those people do as they touch a lot of things.

He can easily click through, in Github, to what his friends are
working on. That's one the of the few advantages that github has over
LP.

Going back and looking at old code is hard on LP. Loggerhead is not
integrated well enough with LP. Sometimes when trying to go back and
find previous source it's very time consuming. Has to look at random
revision numbers. Wants to search, wants to go back and look at code a
year ago, wants to see the evolution of code.

The other day he was trying to go back and look at the drawing code he
was using for Gwibber's bubbles -- when he drew them manually rather
than using Webkit. So, to find that he went to the branhc, clicked on
latest revision and finds himself in Loggerhead. Tries to find the
specific revision he wants by changing the revision number. tries an
approximate revision number. There has to be a better way than
entering random revision numbers then looking at the code!

URL hacks to find the reivision with the specific thing that he's
looking for. When trying to find a very specific change there's no way
to do it. When looking for a module that's deleted, he can do that
through Loggerhead but that's about it.

Google site search doesn't work too well.

Whereas he can with his ars technica articles. Maybe Google doesn't
fully index the bzr stuff, be nice if it did, even better if there was
a built-in search. He usually knows what function name or module name
to look for.

Sometimes, he'll use the bzr viz command on the commandline. It gives
him a visualisation of the flow of the history of the project from
start to finish.

Wishes there was a way that LP could do that but has a feeling that it
might not be easy. Github has something like it in Flash that's not
very good. Would be nice to have a timeline interface that he could
drag around to descend into the history.

A lot of times, he'll do a major overhaul -- three so far -- removes a
feature to refactor the underlying code, wants to then add back and
look at the old code to see how he did it before, so he can decide how
to adapt those concepts to the new codebase.

There was a situation the other day wher esomeone blogged on Planet
Gnome. Someone asked how someone would use Gwibber's message bubbles
without using Webkit and he wanted to find that code to show them how.

bzr viz lets him scroll through really fast. Loggerhead would be
really slow. He's looking in viz at the date and the committer. Likes
having it all in one that he can scroll through quickly and get the
diff without having to do much waiting aroind.

Load times on LP are frustrating. Not fast enough, especially during
the end of an Ubuntu cycle.

Maybe he should build his own desktop tool to look through the bzr
history rather than asking for it on LP.

Once he's figured out the revision no. it's easy to then find that in
LP but finding the revision number is hard.

Not clear what Blueprint is for. Understands in scheme of Ubuntu
ecosystem, doesn't see their purpose in terms of an upstream. Weird
when people randomly submit blueprints.

Uses translations but there's a guy who has adopted it and takes care of it.

Looks at translations occasionally. Mindlbowing to see all those languages.

THe Ubuntu guys run the Gwibber PPA. Ryan doesn't even know who runs
it right now but doesn't have time to work out how packaging works.
Something he'll take over at some point in the future.

Very big fan of the PPAs in general. Even just as a end user and a
journo who likes to test things, that easy access to dev code is a
really useful feature.

Likes being able to have a large testing community which is only poss.
through PPA.

Doesn't feel like he knows LP very well. Knows what he works with but
feels like he's only just scratching the surface. Esp. with bzr. Maybe
culd be more efficient if he spent the time to learn more.

Runs on edge and that's pretty cool to see the changes as they come
in. Likes testing it.

Tends not to like documentation. What works best for him is
experimenting, or will ask someone for help or a better way. Asks Paul
Hummer quite a bit, big help. Releasing software wasn't really
immeditaely obvious, especially wrt series.

Paul walked him through on Skype. Best practices for release
management. Never done a release before Gwibber. New experience.

Perhaps lack of confidence meant he didn't know about release process.
How often? In what state should the code be?

How do we convey release process best practice? Not easy. Maybe an
interactive tutorial or UDS session.

Jorge is his personal guardian angel. If he hadn't been there he
probably wouldn't have discovered LP.

Probably be using Github if it wasn't for Jorge but he's glad he's using LP.

LP has always been asscoiated with Ubuntu -- he saw it as an Ubuntu
development tool, seemed counterintuitive at first, didn't want to
alienate people from other distros, but over time he's found that
other distros don't take offence.

Likes having a separation between distro bugs and upstream bugs.
Doesn't see it as his problem when there is a problem with packaging.

Likes the idea of LP say copying a bug report from Fedora's bug
tracker and putting it in his upstream bugs, if he asks it to in the
case where it's a problem in his upstream code.

Would really like built-in wiki support. Dumps his wiki stuff in the
gnome wiki so he has a place to put it.

On the project overview page, have tons of links to other resources,
would prefer to use markdown text to format that projet description
neatly.

For Answers, he'd really like to have some integration between his
site and Answers as a feedback mechanism. Wants it more like
getsatisfaction.

Thinks karma is kinda silly. Doesn't understand how it computes. Why
doesn't it update sometimes. Every other contributor had more karma
than him at one stage. Once he figured out that it doesn't mean
anything, he stopped caring.

Workflow recommendations would be helpful.
}}}