launchpad developmentMatthew 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.
