Liaison to Launchpad

[Henrik Nilsen Omma]

Jordan Mantha wrote:
> Well, as I've said before, Canonical QA is welcome to do whatever they
> need to do and like to see transparency there. However, that doesn't,
> in my estimation, negate the need for there to be an Ubuntu QA Liaison
> to Launchpad to represent the community and renew my original call for
> volunteers per the original post.

I think it might help if I take a moment to be a bit more clear about 
what my reservations are about the QA-LP Liaison proposal. I'm not 
opposed to better links with the LP team for everyone but I have 
concerns about this particular proposal.

Since you use MOTU as an example I'll start there. The way the Liaison 
role works in MOTU can be described as either:

a) A representative for the MOTU group, who happens to be non-Canonical. OR

b) A representative for the MOTU group, who is by design non-Canonical.

If we are to model a QA liaison role on the one from MOTU we first need 
to decide which of those definitions should apply.

(a) Makes good sense for MOTU because although there are Canonical 
members of MOTU they are the minority and often less active in MOTU 
affairs - it's very natural that the Liaison be non-Canonical. In the 
case of QA there are a number of Canonical employees who are very active 
in every aspect of the team and who already have good contacts with the 
LP team. If we were to use interpretation (a) then they would be good 
candidates for the role, but with model (b) they would be disqualified.

Most structures in Ubuntu are open to both Canonical and community 
members, including the CC, so opting for definition (b) in our case 
would need special justification. From my perspective we already have 
good communication within the QA team where both Canonical and community 
members participate. I'm weary of initiatives that drive a separation 
between Canonical and other members, whether it be by accident or by design.

I personally think that defining a role filled by a single person is not 
going to do us any favours here because it will either have to be a 
Canonical-employee or not - there is no room for a mix. In the former 
case there will continue to be objections about a lack of transparency 
and participation. In the latter case the Canonical QA folks who already 
talk with LP would still do so and since the Liaison would never be able 
to be involved in all those discussions (which are often ad hoc and 
informal) there would be suggestions that there is still a Canonical 
back channel and that the position of the Liaison is being undermined.

This is why I have suggested that instead of a single Liaison we set up 
a small working group for LP issues that could have 1 Canonical and 2 
community members which would clarify feature requests, follow up on 
bugs and be in touch with both the LP team and the QA team. 
Alternatively I suggested that a community member should participate in 
the QA-LP meetings and that and an LP bugs team member should 
participate in QA team IRC meetings (and I prefer the latter two items 
since it does not require a new structure).

Jordan, you and I had a phone call about this 10 days ago where I 
thought we had agreed that a working group would be a good solution 
specifically because it eliminates the tension of whether this should be 
a Canonical person or not. I'm therefore slightly puzzled to see you 
again propose the single Liaison model.

I think you need to be clear about whether you are advocating a Liaison 
of type (a) or (b).

My reading of your messages so far is that you envision this as an 
explicitly non-Canonical role which would fit into a group of 3 
non-Canonical Liaisons that would represent the entire community in most 
LP-related matters. Is that correct? If so, that should be made clear 
and the QA team should discuss it.

Henrik