Canonical–community collaboration

Jono Bacon, with all respect, you are not always so awesome. I wholeheartedly agree with much of what Lionel, the lead developer of Xubuntu, said in his blog when he wrote about doing community survey reports the wrong way.

Any survey report that doesn’t do any analysis with the content in any way is useless. Especially if you have large amount of data gathered from very different groups of people, you should do some correlation between different questions, to actually spot possible problems in the community. For example, I’d really like to see some correlations and differences in the answers by Canonical employees and volunteers.

A word of few about collaboration

The survey shows that there is various problems with collaboration between the Canonical teams and the community. While this might not be objectively the biggest problem, it is a multi-layered one, with hard-to-find solutions. Especially if there is no change from the Canonical side of things.

There’s a few specific reasons why I think Canonical employees working on Ubuntu should collaborate more with the community.

While 1+1 is not three when you collaborate with other people, it usually does reduce the workload for everybody, since you wouldn’t need to do duplicate work and you would be able to brainstorm with other people to get better results with the first try.

Volunteers in derivatives would have much more information on what is going on, and it would be much easier to get things working again, when you could collaborate with the person who (accidentally) broke something you need. Currently it is nearly impossible to get any non-volunteer to help with broken things in Xubuntu, even if the reason for being broke was a direct outcome of any change in Ubuntu, or the core packages.

With derivative developers not having to use most of their time fixing bugs others made appear, they will have more time in getting the derivatives more user-friendly, stable and even more feature-rich. The more interesting and well-working a product is the more people want to use it. This applies to Ubuntu and it’s derivatives too, so this would certainly attract more users to Ubuntu, too.

First step forward, but are we going the right way?

I heard there is a new “If you break it, you fix it” -policy coming up. I really hope this works as expected and applies to new versions of packages breaking other packages too. My main concern is that this will not apply to Canonical employees or other core developers, permanently or via exceptions.

Only future will tell.

This article is part of the article series .

Discussion

  1. Mackenzie
    November 9, 2011

    “With derivative developers not having to use most of their time fixing bugs others made appear”

    More fun phrasing: cleaning up other people’s messes

  2. Jono Bacon
    November 9, 2011

    Hi Pasi,

    I just responded Lionel’s blog post; thanks for referencing it in your post.

    As I mentioned in my comment on his post – I never set out to analyse the results in the report – I wanted to just provide the data so that we as a community can analyse the results together and identify corrolations. This is why I presented the data in full, complete with the open ended comments.

    The goal of the report was to identify areas of weakness or concern in the project but to assess these areas not from what myself or my team *think* are the areas, but to get solid objective data from our collaborative community.

    Now, I am not denying that the survey could have probably been better put together, and better executed (surveys are not my area of expertise), but I do believe the survey identified the primary areas of concern in the community. I also asked for email feedback in addition to the survey, and the areas expressed in the emails are pretty much inline with the feedback expressed in the survey.

    Of course, there will be many other areas, some subtle and some less so that we will need to focus on, but the goal of the survey was for us to get some data-driven first steps in place so we can start making some improvements. Much of this data drove the agenda at UDS and we had some great discussions and put some good plans in place.

    I am not going to pretend I have all the answers, and I am not going to pretend all is well, but my team are committed to doing our best to resolve the areas of concern expressed in our community.

    I would love to learn more about what you and Lionel consider problematic areas – would you be interested in hopping on a conference call next week when I am back? (I am off work this week)

    Thanks,

    Jono

  3. Pasi Lallinaho
    November 9, 2011

    Hey Jono, thanks for replying.

    The problem with the data you presented to us is that you can’t do any correlation with it. For example, I’m unable to extract the data for how many hours the Canonical employees use working on Ubuntu per week. This makes the presented data useless. Please give us the raw data, if you want the community to be able to analyze.

    The problem with UDS is that people tend to be hyperactive and -interested in all kind of things in there, but when they get back home, nobody is willing to help you with your project, because real life has kicked in once again. I was warned about this by Emmet in UDS Jaunty when I had a session about cooperation between *buntu* flavors, and what he said became the reality. In fact, some of the flavor leaders didn’t care to take part, neither you.

    There is only one way to start making things better. Start communicating.

    For example, I left a RT ticket for the IS team about getting a staging site for Ubuntu Studio’s new website on October 20, but there is still no response at all. What’s going on? Are the IS not interested? Can’t this be done? Are they overwhelmingly busy? Can I have some response, please?

    You probably should read both On Freedom – Part I by Steve Dodier, a former Xubuntu developer, and What is freedom anyway? by me, so you can see with what kind of problems we have been struggling just because the lack of communication before.

    I’ll get to you on IRC about the conference call and stuff.

  4. Jono Bacon
    November 9, 2011

    Hi Pasi,

    If you would like me to run some data correlation, as I invited to Andrew on Lionel’s blog, I am to do so. Just drop me an email with what you would like me to do.

    As for your comments on UDS, I am not sure that is entirely fair. While I am not denying that many people sign up to work and don’t do it, many people do indeed follow through on their responsibilities. I think the key point is that many people need reminding to follow through on their work items – I spend some time in each cycle asking people to tend to their work items and most of the time people comply and complete them. To your point though, if I didn’t do this, I am not sure if it would get done. I don’t think this is a specific issue with UDS though; I have seen this at many collaborative community events.

    When you say “There is only one way to start making things better. Start communicating”, can you elaborate a little better? Your IS example is a good example, and we have faced some challenges with IS due to them being oversubscribed with work. In this particular example, what do you feel would be a scalable solution? I am wondering if IS currently provide a community point of contact (such as a Vanguard) where such queries could be sent – I would be happy to look into this.

    To be clear, I am not resistant to your feedback, I am just keen to know more specifics about how “communication” could be improved.

    Let’s try and schedule a call soon and we can talk more. Thanks, Pasi.

  5. Pasi Lallinaho
    November 10, 2011

    Hey Jono,

    It’s really hard to tell what’s interesting unless you do several correlations. Maybe there is somebody at Canonical who could help you with the survey, as you said you are not an expert on the surveys yourself? This way we might get the interesting bits out of the data without you releasing it to the wider public. Or you can give it to a specified group of volunteers to work on. This would be a clear sign of better Canonical–community collaboration.

    In my opinion, what I said about UDS is completely true. I agree with you that reminding people of the things they promised to do would probably help on actualizing the ideas planned at UDS. However, most of the volunteers naturally work on Ubuntu on their limited free time, and they really don’t have time to poke other people to do their work in addition to working on their own tasks in the community. It is also probably true this is a problem that is common to most, of not all, of the collaborative community events. Also to UDS.

    I don’t know what are the exact actions needed to take to make the communication actually better. Right now it doesn’t really feel that Canonical, or the core developers, are in any kind of collaboration with Xubuntu. While I understand that Canonicals (and its employees) focus is on Ubuntu Desktop, I’d like to see somebody from Canonical in #xubuntu-devel, for example, so we can discuss probable breakages and stuff. Seriously, I’d be very surprised they would even attend our developer meetings now and then.

    It would also help our developers a lot if they knew something is going to change in advance. For example, we found only today that the Xfce xfapplet plugin is removed from Oneiric via our users, not Martin Pitt, the committer. We don’t understand why Xfce packages are removed, since this applet clearly isn’t visible in GNOME, and doesn’t affect GNOME any way. What we definitely don’t understand is why we were not informed about this, even if it was a necessary thing to do (which it clearly isn’t, for GNOME).

    As I understand it, the IS should already get back to you if you report an issue to the RT (request tracker), so there is a point of contact already. The perfect solution would be that there was enough people working at IS so they can help the community in a fair amount of time. The IS team has been the single bottleneck for us to get anything done with any issue with our website, ever.

    It would be acceptable to have some delay in getting the actual thing done, if the IS only replied to us with an estimate when they can get back to that. Even then, I don’t think simple tasks like getting xubuntu.com redirected to xubuntu.org should take over two years (bug opened 2008-07-25, closed 2011-01-10).

    I will be in contact with Lionel and see when we could have the call, and I’ll get back to you after that. Or you can join #xubuntu-devel yourself too and communicate with the community.

  6. Jono Bacon
    November 18, 2011

    Hi Pasi,

    Apologies for the delay. Comments inline:

    “It’s really hard to tell what’s interesting unless you do several correlations. Maybe there is somebody at Canonical who could help you with the survey, as you said you are not an expert on the surveys yourself? This way we might get the interesting bits out of the data without you releasing it to the wider public. Or you can give it to a specified group of volunteers to work on. This would be a clear sign of better Canonical–community collaboration”.

    I think getting more expertise in working on surveys could be useful, I agree. I would also like to hear your thoughts on what I should have done differently with the survey I did run — how should the questions have been presented differently etc.

    “In my opinion, what I said about UDS is completely true. I agree with you that reminding people of the things they promised to do would probably help on actualizing the ideas planned at UDS. However, most of the volunteers naturally work on Ubuntu on their limited free time, and they really don’t have time to poke other people to do their work in addition to working on their own tasks in the community. It is also probably true this is a problem that is common to most, of not all, of the collaborative community events. Also to UDS”.

    I agree that there are always some folks who agree to actions and don’t follow through, but the whole point of UDS is define work and next steps and I think the overall value of UDS and number of actions that do get completed means that it is a good venue for discussing the kind of topics raised in the survey.

    “I don’t know what are the exact actions needed to take to make the communication actually better. Right now it doesn’t really feel that Canonical, or the core developers, are in any kind of collaboration with Xubuntu. While I understand that Canonicals (and its employees) focus is on Ubuntu Desktop, I’d like to see somebody from Canonical in #xubuntu-devel, for example, so we can discuss probable breakages and stuff. Seriously, I’d be very surprised they would even attend our developer meetings now and then”.

    To be fair, the focus isn’t on Xubuntu, and I would not want you to have the unrealistic expectations that Canonical developers should be, or are even interested in contributing to Xubuntu. The Xubuntu project is awesome, and the work that you do there is a true credit to our community, but I can only think of one Canonical developer who I would associate as working with Xubuntu (Cody).

    This is nothing specific to Xubuntu, the same policy and approach applies to other derivs. Canonical’s commitment to derivs is in providing infrastructure to encourage interested community members to build derivs. Of course, while Canonical staff time is not spent on derivs, our staff are welcome to work on anything when they are not at work.

    “It would also help our developers a lot if they knew something is going to change in advance. For example, we found only today that the Xfce xfapplet plugin is removed from Oneiric via our users, not Martin Pitt, the committer. We don’t understand why Xfce packages are removed, since this applet clearly isn’t visible in GNOME, and doesn’t affect GNOME any way. What we definitely don’t understand is why we were not informed about this, even if it was a necessary thing to do (which it clearly isn’t, for GNOME)”.

    I think this is a reasonable request, and I recommend you post to ubuntu-devel to suggest this to the community. To be honest, I am not sure how scalable this is though. There are many packages in our repos, and I can’t think of a way in which everyone with an interest in those packages should be notified before changes happen in advance – I think though that a wider discussion on ubuntu-devel is well worth doing. Would you be happy to do this?

    “As I understand it, the IS should already get back to you if you report an issue to the RT (request tracker), so there is a point of contact already. The perfect solution would be that there was enough people working at IS so they can help the community in a fair amount of time. The IS team has been the single bottleneck for us to get anything done with any issue with our website, ever.

    It would be acceptable to have some delay in getting the actual thing done, if the IS only replied to us with an estimate when they can get back to that. Even then, I don’t think simple tasks like getting xubuntu.com redirected to xubuntu.org should take over two years (bug opened 2008-07-25, closed 2011-01-10)”.

    I understand your concerns here, but you are not the only team who has to wait a while for IS to get to the tickets. :-)

    The challenge with IS is that they have many, many RT tickets and a limited set of resources, so prioritization determines how they get to which tickets first. Saying this, one option could be to see if we can get you a point of contact in IS to take urgent RT related needs to. I can’t guarantee this is an option as I am not on the IS team, but I would be happy to see if I can make something happen. Who would be the point of contact on the Xubuntu side for working with this person?

    “I will be in contact with Lionel and see when we could have the call, and I’ll get back to you after that. Or you can join #xubuntu-devel yourself too and communicate with the community”.

    I just joined the channel and I look forward to our meeting tomorrow.

  7. Pasi Lallinaho
    November 18, 2011

    Jono,

    Without taking a stance on how the questions were presented, I’d say you can still make the survey worthwhile. This means you will have to do correlation for the data, as said many times. If you don’t understand much about surveys, I don’t think it makes much sense to try to explain this much more.

    Why don’t you contact somebody from Canonical who understands surveys (I’m sure there are several!) and take some time to go through the survey again, and do some correlations together? The other option is to release the data to the public, either as it is (even without the comments on open text fields), or as random sets, as Jef Spaleta suggested. In either case, it comes down to the fact that you did underestimate the time you need to put into a well executed and analyzed survey.

    I’m sure UDS would be a perfect place to discuss the topics rising from a community survey – with the analyzed and correlated results. With correct correlations, you could exactly pinpoint the problematic areas in the community. (As said before though, you can’t know which are the correct correlations before you have executed them. As like you don’t know which coffins contain treasures, before you’ve opened them all.) Currently, you can’t get any deeper than the surface, and with these results, you can only guess if the problem is what it looks like being.

    I completely understand that the focus is not on Xubuntu, and I’m not asking for that. I would just like you to understand that if a Canonical developer breaks a thing in Xubuntu, it would be nice if the developer would be able to collaborate us with the issue, even if it was as little as telling what he changed just before things got broken. (I’m hoping we will see some improvement in this area with the new policies, but to be honest, I’m not expecting anything else than having more bureaucracy thrown at our team – we must report what we’ve done during the week – but majority of the Canonical developers still unwilling to collaborate the least with us.)

    What comes to the issue I mentioned earlier about an Xfce component being removed from the repositories, I can’t see how that is “providing infrastructure” in any way. I don’t say everybody with an interest at specific packages should be notified before or even after changes to those packages, but I’d expect there would be some communication about bigger things, like dropping packages completely. To be honest, I think that any discussion in ubuntu-devel about increasing communication towards the derivatives is a waste of my time, since as you said, none of the developers shouldn’t, and probably aren’t, interested in Xubuntu.

    I understand that the IS do have a lot of tickets to work with. I don’t expect lightning fast service, but I do expect that I get some kind of confirmation that a ticket has been received and at least briefly read, and an estimate about how long we should wait for an issue to be resolved. In any case, with any kind priorisation, I simply don’t expect any ticket to take more than two years to be resolved.

    A point of contact in the IS team does sound intriguing, but I have my concerns. If no higher priority can’t be promised for the tickets we specify as urgent for us, it’s just waste of our, and their time. Rather than assigning any point of contact in the Xubuntu team, I’d love to see a single person in the IS that any of the derivatives could contact and who could give estimates about ticket resolving times in a reasonably timely manner (even up to one week would suffice) if not anything else.

    Nice to have the community manager on the community channels too!

  8. Lionel Le Folgoc (mr_pouit)
    November 18, 2011

    Just to clarify a possible misunderstanding, the xfapplet-plugin was removed in Debian, and Ubuntu at our request: it’s unmaintained and it only supports GNOME2 applets, so it blocked the GNOME3 transition in Debian; in Ubuntu, gnome3 is more or less in oneiric, so it was removed as well (I mean, pitti didn’t go berserk and removed the plugin without notice ;-).

    @Jono:
    Sorry, I didn’t have time to read my blog lately (my last post probably received more comments than my complete blog in the last 6 months…). I’ll try to do it this weekend.

    I just want to react to something you said above: when I describe things, I focus on Xubuntu, because that’s my only involvement remaining in Ubuntu. I don’t really check what happens outside of it, especially for other universe packages not in a package set (but some issues affect universe too, not only Xubuntu)…

    And it is again with my Xubuntu developer hat on, when I say that interactions with some teams, e.g. the Desktop Team, are terrible (it doesn’t mean everyone in the team is an incompetent idiot, I’ve never written that and whoever thinks I’ve said that and wants to wave the CoC at me is a troll).

    For instance, https://bugs.launchpad.net/indicator-application/+bug/804618 is a good example of what not to do (again, it *doesn’t* mean everyone works like that): they make a signal name change in an indicator library, they fix the indicator stack for unity/gnome/main (look at the affected packages), and Xubuntu/Lubuntu/universe packages have to fix themselves _magically_, because we don’t even receive a notice about that change. I’d be an euphemism to say it’s not a really good way to handle a transition (and there are even tools to help handling transitions).

    (In the past, e.g. for natty and before, an api bump was also introduced in the indicator stack during feature freeze, but at that time, everything in the archive was fixed to work again, by Didier – who’s in the desktop team too, afaik. And one change introduced a bug in an xfce package, and he fixed it in a SRU after the release. Just to show that it’s possible, and has been done before. Most people don’t need new policies such as “you break it you fix it” to make good work. And the other ones will continue to ignore policies anyway :)

  9. Pasi Lallinaho
    November 18, 2011

    I didn’t know the Xfapplet-plugin was removed at our request. I must have had a misunderstanding earlier, too. I’m sorry to have suggested that the transition was a surprise. I’m sorry, Martin.

    I agree with Lionel that there are people who do take responsibility for their actions, including their unwanted effects on the derivatives. Now, I think, the area of improvement in the community is to make everybody work like that. I think the new policy is a good way to drive the community, including Canonical employees, in the right direction, as long as it works as expected and with no exceptions.