User affiliation with context in person picker is unclear

[Diogo Matsubara]

When you choose a person with the person picker, it's unclear what the affiliation the returned person has with the project.
Some comments from the exploratory testing:

     * When I try to assign a bug in Launchpad and search for "huw" I notice there is a little LP icon next to my name but no explanation of what it means. I'm guessing it means I'm a member of the team that owns the project of the bug I'm assigning someone to. If so it might be better to indicate that in a more obvious way (quite possibly with text) as it would seem quite important.
     * when I search for matsubara on the oops-tools project to assign driver, there's no UI saying matsubara is related to the project (I'm the owner). Must #2 from the LEP says the context should show the affiliation

[Curtis Hovey (sinzui)]

Clear user affiliation (UI Test)

Project affiliation is not clearly conveyed to the beta testers viewing the person picker.
• The project icon does not clearly state that the user is affiliated with the project, thus is more likely to be the user to choose.
• The icon does not state how the user is affiliated, which confirms the reason to choose.
I happen to know that the first effort to show implementation only the project icon when the user is the project maintainer, Yet I am surprised sometimes when I see, or do not see, the icon.

I need to know if the user is a maintainer, driver, bug supervisor, or security contact for the project. The project icon can be helpful, but not every project has an custom icon. The user's role in a project is important. I am more like to to assign a bug or blueprint to a driver than a maintainer or a bug supervisor. Know that the user is in many roles might be helpful.

In the special case of a bug, I may want to know if the user is affiliated with one or more the affected projects. I am more likely to assign a bug to a user affiliated with both the upstream project and Ubuntu than to another user.

I believe a successful presentation of affiliation would also work with comments. I want to know who speaks for a project. When I can which users are drivers or bug supervisors in the comments of a bug, I will have better knowledge about the importance of what is written.

[j.c.sackett (jcsackett)]

I'm unassigning myself as I haven't made progress on this while I'm dealing with privacy display issues. I'll come back to this if no one else takes it in the meantime.

We do have UI direction on this now, between discussion and mockups here and on bug 800361.

[Curtis Hovey (sinzui)]

Based of the feedback from the person-picker test (see http://people.canonical.com/~curtis/person-picker/person-picker-0.html) we have a better idea about what we want to do to convey affill=iation. There is already a branch that added the text "Affiliation:" to the picker entry.

We are missing details information in the expander that explains *how* the user is affiliated.
IHasAffiliation only supports bug tasks. It does not support blueprints, questions, projects, distributions and series yet.

1. Extend bugtask IHasAffiliation to check drivers, bug supervisors, and security contacts. Drivers is essential. bug supervisors, and security contacts is expects, but we can consider not supporting the case if we are concerned about performance.

2. This should also be true of blueprints, questions, teams projects, distributions and series. Assigning users to these artefacts should have the same presentation. We want to know who and how someone is officially associated with the primary context (pillar or team).

[Ian Booth (wallyworld)]

A branch has been created to address item 1 above - extending the bugtask affiliation check.
A separate bug will be used to do item 2 - adding affiliation checks for blueprints, questions etc

[Launchpad QA Bot (lpqabot)]

Fixed in stable r13636 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13636>.