Jenkins Project Sub-teams

Problem

There are three current decision making models for the Jenkins project, as far as I (Unknown User (rtyler)) have seen are:

1. Just do something
2. Ask to do something in a Governance Meeting and have whoever is in the meeting +1 some proposal
3. The board decides something

As the project meeting only happens once two weeks, often it resulted in a long delay to decision. Also, there is an obvious bias to this, in that decisions and contributions are guided by those who are most able to attend project meetings and voice their opinions. Additionally, anything that cannot or should not be brought up in a project meeting must be taken directly to the board. This puts unnecessary burden on the board and creates a bottleneck for making decisions and for empowering members in the community to take ownership of different areas of the project.

Proposal

The proposal here is to: enable the board to appoint sub-team leaders who would have the responsibility and accountability for leading a particular facet of the project. This would enable members of the community who have proven themselves to be responsible and courteous, to act with the authority of the board in guiding and making decisions within the project. If we imagine the board to be a (currently) three-headed President of Jenkins, these sub-team leaders would be the cabinet members (e.g. Department of Transportation, Department of Justice, etc).

The board provides oversight and guidance to the team leaders. To reinforce this, the team leaders would also be responsible for preparing a quarterly report (e.g. FreeBSD Quarterly Report) for the Jenkins board which can be communicated out to the broader Jenkins community.

Sub-teams

The following teams I think we need today:

• Security
  • Directs triage/resolution of critical 'SECURITY' issues
  • Responsible disclosure of said security issues
  • Acts as point of contact for, and engages with external security researchers
• Infrastructure
  • Directs maintenance of Jenkins project infrastructure ('INFRA' issues)
  • Communicates maintenance windows and managing the execution of those windows
• LTS
  • Backporting of fixes, reviews of urgent fix requests
  • Release train model control, selection of LTS candidate versions
  • Orchestration of RC testing activities
• Website
  • Enables website/documentation contribution from the community
  • Editor for Jenkins blog
• Community
  • Processing on incoming requests for plugin forks, ownership changes, etc.
  • Dealing with non-technical conflicts within the community, escalation to Jenkins CI board on-demand
• Events
  • Point of contact for managing the Jenkins CIA Program and Jenkins Area Meetup outreach
  • Organizer/maintainer of Jenkins meetup.com account
  • Coordinates communication efforts around Jenkins community events (e.g. JUC, JAMs, FOSDEM)

(Note: these responsibilities are not exhaustive and should be further clarified if this proposal is accepted).

Appointment process

To help ensure as fair as possible of an appointment process, the community should have the opportunity to voice opinions or concerns about the appointment of team leaders. I propose the following process:

1. Board sends a request for applicants/nominations to the community for a Team Leader position. Expecting applicants/nominees to provide explanation on why they're suited for the job
2. After 7 days, Board sends an RFC (request for comment) on the appointment of a community member to a team leader position
3. Community sends comments (positive or negative) to the board directly
4. After at least 7 days, leaders are announced at the next governance meeting.

Term

A term of 12 months of for a team leader seems reasonable. If at the end of said term the team leader is asked to perform another term, the board should follow the appointment process anew.

Resignation

In the case of a resignation from a team leadership position, the board will be expected to follow the appointment process above.