Improving the security community during the maverick cycle

Work items:
[mdeslaur] training session on preparing security updates: DONE
[jdstrand] put existing documentation on how security team creates schroots and VMs into wiki: DONE
[jdstrand] put how to setup UCT into the wiki: DONE
[jdstrand] update GettingInvolved to point to d2u: DONE
[stefanlsd] blog to invite members in, etc: POSTPONED
[stefanlsd] d2u merges / documentation: POSTPONED
[stefanlsd] merge and test (build somewhere): POSTPONED
[kees] export JSON to harvest: POSTPONED

From gobby notes:
 * Ways to encourage / retain new members
   - Training sessions
   - Team spirit / Identity
   - Documentation / examples on how to do common tasks
     - How do i test this fix
   - Understand the motiviations of people joining the team
     + Work with the wide spectrum of Ubuntu
     + Ability to make an important contribution
   - Challenges of contributing to security team (testing?)
   - Recommended requirements (things to know?)
 * Barrier to entry for uploads to 'universe' - some packages are important
 * Mentoring by members - case by case basis, encourage to help

 Encourage fix for current release, would be nice if they could fix others but not required

 * Clarification of proposed archive re-org and how community members would fit into this framework
 * Assistance from existing security team

Cool tools / scripts exist - make people more aware of these tools. QA tools, d2u + security-fake-sync

 * encouragement involment since our team feels like a team and therefore others
   would probably stay once involved (reword)
 * continue to be helpful to people
   - someone wants to do something -- suggest d2u

Encourage teams to maintain security in their packages (TB - integration CVE into ubuntuwire)
 * qa.ubuntuwire.com has stuff for package maintainers. have links for
   - package sets that show CVEs in people's packages
   - d2u
 * export CSV and JSON for integration with harvest

Motivations:
 * feel useful by fixing large number of packages
 * skill building (packaging, Ubuntu processes)
 * opportunity to learn Ubuntu processes (though there are better places to do this)
 * satisfaction in fixing a security bug (more than "just" a bug)
 * security team has influence, so being on it creates opportunity to contribute
   at a high level
 * fixing the software they use themselves
 * learning about security in particular (flaws, fixes, etc)
 * becoming part of the community, security or not

Frustrations:
 * (in the past) stale processes
 * doing security patching can be dull
 * process and knowledge required creates a high barrier to entry
 * overwhelming amount of work to do

Going forward:
documentation maybe simplied for easier steps - how to use the security tools
all - helpfulto people in channels - done already but concerted effort
all - possibly blog package of the week