Skip to end of metadata
Go to start of metadata

So you want to be a PTL? Here is a list of items that you can expect to perform. This guide 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 to which you may refer.

Weekly Tasks

  1. Organize the team meeting agenda. Most teams will use an etherpad or the project's wiki space

  2. Follow the release guidelines established by the TSC and Release Manager

  3. Attend Technical Committee and Cross-Project meetings when possible. For more information see meetings.

  4. If the team does not have an appointed bug czar, then perform  bug triage. Ensure all new bugs that have been reported are triaged and tagged accordingly

Core Committer Maintenance

This will vary greatly from team to team, but here is a general guide you may consider:

Criteria When Considering New Committers

Committers are nominated and elected by existing Committers.

  1. Are their review numbers (quantity and disagreements) similar to those of existing Committers?
  2. Does the person follow up on reviews?
  3. Are the reviews helpful, critical, and nice to authors?
  4. Does the person help in triaging bugs? (For example: reproducing the issue)
  5. Does the person provide bug fixes?
  6. Does the person create and implement new features?
  7. Does the person review specifications?
  8. Does the person participate in weekly meetings?
  9. Does the person participate in mailing list discussions?
  10. Does the person participate in Acumos developer gatherings?
  11. Does the person know the project direction and priorities?
  12. Does the person help others on IRC?

Actions to Perform When Adding New Committers

  1. Send a nomination email to the distribution list acumosai-technical-discuss@lists.deeplearningfoundation.org listing the person's contributions and requesting a vote by all active committers.
    1. Active committer is defined as two or more merges in the last six months
  2. Collect the votes, which must be sent to the same distribution list
  3. When the voting is concluded according to the guidelines set out on the TSC page, assuming the votes are favorable:
    1. Send email to acumosai-tsc@lists.deeplearningfoundation.org to inform the TSC members of the change
    2. Send email to helpdesk@acumos.org to have the LF Release Engineering team send an email invitation to the new committer
    3. After the invitation arrives and the new person accepts, update the INFO.yaml file in the affected repository and submit as a new change set
    4. Have the new person merge the changed INFO.yaml file as a test of the newly granted committer privileges.

Criteria for Removing Committers

  1. Is the Committer reviewer reviewing enough? Use data to determine if the Committer is similar to  the other Committers in terms of overall review count.
  2. Does the Committer have enough time to review? Job responsibilities may have changed.
  3. Does the Committer no longer have knowledge of the code base and new features?
  4. Does the Committer still provide useful feedback, even if infrequently?

The process for removing an inactive Committer is defined here.

For most situations, the PTL should email the inactive Committer and ask if he/she wants to be removed.

  • If yes
    • send an email to the TSC mailing list, including the email thread with the inactive Committer wherein he/she agrees to be removed
    • email the Acumos Helpdesk and ask to have the Committer removed (this means removal from the LDAP group); include a link to the email sent to the TSC email list
    • once the Committer has been removed, update the repo's INFO.yaml file
  • if no or the Committer doesn't reply

At the Beginning of a New Cycle

  1. Add placeholder migrations, these should be the first things to merge once the n-1 stable branch has been created. Do not merge any migrations before this is done
  2. Appoint cross project liaisons (Docs, release, QA, etc.).
  3. Check if the meeting time works for most active contributors
  4. Track removed and deprecated features
  5. Organize the specifications page


During the Cycle

  1. Help first time contributors, they will be struggling the most.
  2. Lack of reviews? Reach out to the core team and remind them.
  3. Release libraries as necessary but don’t wait too long! Some teams will release after 4 weeks even if the changes are minor. More often is better than less often.


Before a Face-to-Face Gathering

  1. Start an etherpad to brainstorm potential session topics.
  2. Based on that brainstorming, propose sessions. Create an etherpad for every session, prime the content. List these etherpads on the wiki.

During the Face-to-Face Gathering

  1. Reach out to potential new contributors to the project, participate in project on-boarding sessions.
  2. Attend as many cross-project sessions as possible.
  3. In the discussion sessions you moderate:
    • Take notes on the etherpad (or delegate a scribe)
    • Act as a moderator rather than actively participate (or delegate a moderator)
  4. After the discussion, post a summary of the session outcome to the mailing list and wiki, for the benefit of those who could not be present.


At the Ed of the Cycle

  1. Clean up release notes.
  2. Clean up Jira
  3. Coordinate with the release management team for deliverables, unless a liaison has been appointed
  4. Expect queries from the release marketing staff to name release highlights and major features
  5. Perform a retrospective via an etherpad. Suggested sections include: What went well?What didn’t go well.
  6. Analyze how complete each new feature is. Documentation? Does the install guide need to be updated?


Stable

Alternatively, the responsibilities in this section can be delegated to a local stable maintenance czar.

  1. Ensure the stable branches gates are not broken.
  2. Co-ordinate with the stable release team to ensure releases are performed when a critical fix is backported, or sufficient smaller fixes have landed.

One-Offs

When necessary, the following can be performed at unscheduled times.

  1. Bug smashes
  2. API sprints
  3. Docs sprints

Staring a New Project

After the project proposal has been approved by the TSC:

  • repos
  • jenkins jobs
  • coordinate creation of new wiki space and inclusion in the top navigation bar with the  LF Helpdesk or Docs PTL
  • decide on a mailing list tag and put that on your wiki space

Requesting Committer Rights in Gerrit

During the transitional phase, PTLs may be appointed/approved by the TSC. If you do not have Committer rights in your repos, contact the Acumos helpdesk (helpdesk@acumos.org), list the repos, and include the TSC meeting minutes in which your PTL role was approved.

Schedule Weekly Meetings

  1. Create a Doodle poll here for your project - https://doodle.com/create (example: https://doodle.com/poll/h47cwxa2nhzhxzf6) and please send the poll link to acumosaidevdiscuss@lists.acumos.org.
  2. Keep the poll open for a week
  3. Update the “Project Meetings” wiki page with your scheduled meeting

Create an IRC Channel

Create an IRC channel for your project: #acumos-<your project name> 

See See IRC Basics#CreateandRegisteranIRCChannelonFreenode  for instructions on how to create an irc channel.

  • create a helpdesk ticket to have gerrit bot installed on that channel (note: as of May 2018, the LF cannot install gerritbot for acumos repos)
  • create a helpdesk ticket to have the meetbot installed on that channel if you plan to conduct meetings on your project channel instead of on #acumos-meeting


  • No labels