Display team emblem on bugs from project contributors

sounds like a good idea to me.

How interesting! Very cool idea. It is a bit expensive to implement the lookups but I am thinking abou tit.

If we just want to display comments from developers differently, we could do it with one extra query:

1. After assembling all the bug comments, we have a set of all the message authors.
2. For each bug task, get the context and grab the person IDs that would cover developers (owners and drivers would cover it, I think).
3. Query the TeamParticipation table for rows where person is in the list of people from (1) and team is in the list of people from (2).
4. Take the set of TeamParticipation.person values from the above query. If the author of a comment is in this set, then it can be marked as coming from a developer.

Using raw SQL, this could probably be included in the main query used to get all the bug comments, but that is probably a bit difficult to do with our ORM. However, the extra query shouldn't add much overhead.

As an addition to the above solution, if we care about showing team emblems, the result set from (3) gives us the team team the user is a member of too, so we can get the emblem too.

That said, I reckon that displaying comments from developers differently goes a long way to solving the problem, even without the emblems.

On Mon, Jan 29, 2007 at 06:23:02AM -0000, James Henstridge wrote:
> If we just want to display comments from developers differently, we

We want to display both comments and the report(er) itself differently, so
the identity of the reporter is clear even they haven't commented.

Of course, both are individually useful.

> could do it with one extra query:
>
> 1. After assembling all the bug comments, we have a set of all the message authors.
> 2. For each bug task, get the context and grab the person IDs that would cover developers (owners and drivers would cover it, I think).

For a distro, this would be:

- Registrant
- Bug contact
- Security contact
- Uploaders to the various components

In current Ubuntu practice, of course, some of these are the same (or
contain one another), but the above should apply equally well to other
distributions and upstream products.

--
 - mdz

Reassigning to Curtis to work into the Badges spec.

Testing reassignment behaviour of milestone in production. Sorry for the spam. But for anyone truly interested in this bug, I will start on it as soon as OfficialProjectMembersSpec is approved.

I'm pushing this back two releases because I have no approval to work on the OfficialProjectMembers spec, and my 1.1.9 bugs will take most of my development time.

upgrading from wishlist to low.

I'm pushing this back a release because the OfficialProjectMembers spec is being rewritten.

Curtis, is this something you will work on during 1.2.2? If not, please re-assign to to another milestone, or unassign it completely.

We have not committed to work on this so I removed the milestone.

The launchpad-registry must provide the infrastructure to answer the question who is a project contributor before this feature can be added.