QA summaries script should infer which team summary a test item belongs to from the associated bug, when the fix is community's

[Diogo Matsubara]

Now that we're receiving external contributions, there's no way to map those contributions to an specific team. See, for instance, https://dev.launchpad.net/LaunchpadTestPlan/2.2.8. A lot of wgrant's fixes belong to the Bugs test plan <https://dev.launchpad.net/BugTrackerTestPlans/2.2.8>. The test plan tool should infer the right test plan by querying LP for the project the bug was filed on.

[Ursula Junque (ursinha)]

This is something tricky to fix, because we split teams as groups of people, not to one specific project. With the tagging script, those bugs are targetted to the correct project, but in the qa summaries the items are grouped by team, not by project. What could workaround this problem would be the team to check the project once in a while to see if there are externally fixed bugs to QA.

[Diogo Matsubara (matsubara)]

I don't understand why the QA summary code can't use the project info to know which team the item belongs to?
For instance, in https://devpad.canonical.com/~lpqateam/testplans/qa-summary-launchpad-10.03.html the item fixed by James Westby <http://bugs.edge.launchpad.net/bugs/89150> is assigned to the soyuz project, so it should go to the soyuz summary <https://devpad.canonical.com/~lpqateam/testplans/qa-summary-soyuz-10.03.html>.

[Ursula Junque (ursinha)]

Teams are virtual groups of people. The way the script is structured now I can't just add an item of the soyuz project in the soyuz team summary directly, because the committer could be a member of another team and in this case the item should go to another summary. I need to create something in between that connects a project to a team, and if the committer isn't part of any Launchpad teams the item should go to the team linked to the project. I guess this way it should work the way you want.