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).
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).