So you want to be a PTL? Here is a list of items that you can expect to perform. This document is meant to serve as a general guide for current and future PTLs. It is not all encompassing, nor are all sections required, it is simply a guide that you may refer to. Each OpenStack project is different and will release, plan, and delegate differently, too.
Organize the team meeting agenda. Most teams will use a wiki or etherpad.
Follow the weekly [release] guidelines email to keep track of the development cycle tasks (unless you have an appointed release liaison to follow it for you). It is also very useful to subscribe into the release calendar.
Attend Technical Committee and Cross-Project meetings when possible. For more information see meetings.
If the team does not have an appointed bug czar, then perform a bug triage. Ensure all new bugs that have been reported are triaged. The below is a URL to view all new bugs for keystone.
If the team does not have an appointed bug czar, then remember to also tag bugs accordingly. The below is a URL to view all untagged bugs for keystone.
This will vary greatly from team to team, but here is a general guide you may consider.
A successful appointment can be made solely by the PTL, however it is encouraged to hear the opinions of the existing core team. This can be done through private messages on IRC or publicly through the openstack-dev mailing list.
Once a person is ready, perform the following:
Announce new core member on mailing list
Give them voice on IRC (if applicable):
/msg chanserv flags <room> <irc_handle> +V
Add them to the project drivers group in launchpad.
Update the core team in Gerrit.
- Take notes on the etherpad (or delegate a scribe)
- Act as a moderator rather than actively participate (or delegate a moderator)
Alternatively, the responsibilities in this section can be delegated to a local stable maintenance czar.
When necessary, the following can be performed at unscheduled times.