Switch branches/tags
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


JEP-4: Special Interest Groups


As the Jenkins community has grown, there have been ad hoc groups sprouting up to tackle specific areas of focus within the project. This proposal describes a "Special Interest Group" (SIG) model to provide structure so that these groups can become more formalized, with consistent expectations of their operation, to help new contributors join areas of effort which align with their interests.


Much of this specification is modeled after the Kubernetes project’s "SIG" model. [1]

In order to standardize Special Interest Group efforts, create maximum transparency, and route contributors to the appropriate SIG, SIGs should follow the guidelines stated below:

  • Meet regularly, at least for 30 minutes every month

  • Keep up-to-date meeting notes, somewhere publicly linked from the SIG’s page on jenkins.io

  • Announce meeting agenda and minutes after each meeting, on their SIG mailing list

  • Record SIG meeting, either via YouTube Live Streaming, or via text-based meetings which can use #jenkins-meeting on Freenode. SIG meetings must be public and should have their meeting recorded (video or text) or the meeting minutes published afterwards.

  • Ensure the SIG’s mailing list, and optional chat channel are archived

  • Report activity in the bi-weekly Governance Meeting at least once every 6 weeks

  • Participate in Governance meetings, as needed.

  • Ensure related work happens in a project-owned GitHub org and repository, with code and tests explicitly owned and supported by the SIG, including issue triage, PR reviews, test-failure response, bug fixes, etc.

  • Use the above forums as the primary means of working, communicating, and collaborating, as opposed to private emails and meetings

All Special Interest Groups are subject to the Jenkins project Code of Conduct.


  • SIG Participant: active in one or more areas of the project; wide variety of roles are represented

  • SIG Lead: SIG organizer. SIG may have multiple leaders

Creation and Maintenance


  • Propose the new SIG publicly, including a brief mission statement, by emailing jenkinsci-dev@googlegroups.com and jenkinsci-users@googlegroups.com, then wait a couple of days for feedback

  • Define a unique SIG identifier (${sigId} below):

    • Permitted symbols: a-z, 0-9, -

    • Length: up to 32 symbols

    • Examples: platform (Platform SIG), cloud-native-jenkins, etc.

  • Organize meetings using video or text as needed. No need to wait for the a regularly scheduled Jenkins Governance meeting to discuss. Please report summary of ad hoc SIG meetings to the the SIG mailing list.

  • Use existing proposal and PR process

  • Announce new SIG on jenkinsci-dev@googlegroups.com

  • Submit a pull request to the jenkins-infra/jenkins.io repository

    • Create a /content/sigs/${sigId} directory. This directory can be used to store any SIG-related pages, docs, schedules, roadmaps, etc.

    • Create a /content/sigs/${sigId}/index.adoc file. It will be used as a landing page for your SIG. The index.adoc will also contain metadata about the SIG. See other files in the directory for examples of what that should look like.

SIGs and JEPs

Creation of new SIGs does NOT require creation of new JEPs. As documented above, am email to the Developer mailing list is enough.

Additional JEPs may be created if SIG Leaders want to define special processes and requirements for the Special Interest group (e.g. requirements to be a Security SIG member). If such JEPs are created, they will be a subject to the common review process defined in JEP-1.

Creating service accounts for the SIG

With a purpose to distribute the channels of notification and discussion of the various topics, every SIG may use multiple communication channels. Below the procedure is explained step-by-step.


This procedure is largely maintained by the Jenkins Infrastructure team, please file INFRA tickets in JIRA or post to the Infra mailing list in case of questions or suggestions.

Google Groups creation

Create Google Groups at https://groups.google.com/forum/#!creategroup, following the procedure:

  • Each SIG must have at least one discussion group. This group must be added to the SIG metadata.

  • SIGs may also have a number of groups for mirroring relevant github notifications;

  • Create groups using the name conventions below;

  • Groups must be created as e-mail lists with at least three owners (including tyler at monkeypox.org and verninol at gmail.com to ensure SIG continuity);

  • To add the owners, visit the Group Settings (drop-down menu on the right side), select Direct Add Members on the left side and add Tyler and Olivier via email address (with a suitable welcome message); in Members/All Members select Tyler and Olivier and assign them to an "owner role" for long term maintenance.

  • Set "View topics", "Post", "Join the Group" permissions to be "Public"

Naming convention: jenkins-${sigId}-sig (the discussion group)


At the discretion of the SIG Lead(s), organizations may also join SIGs. Organizations may request to join a SIG and will then be listed on the SIG page. It is expected that organizations that join a SIG will actively participate in the dicusssion and interation on the SIG. Organization membership is in SIG informational only and grants the organization no special power or voice in that SIG.

Recorded Video Meetings

Video meetings should be recorded with Hangouts on Air via the Jenkins projects YouTube Channel.

Each SIG Lead wishing to host video meetings should file an INFRA ticket to request Manager access to the YouTube channel. Manager access allows SIG Leads to schedule a Live Streaming Event which will allow meeting contributors to use Google Hangouts to discuss, while allowing participants to view the YouTube live stream, or after the fact, the recording.

All recorded events should be filed into a YouTube Playlist titled "SIG <Name> Meetings" to keep the YouTube channel properly organized.

Recorded IRC Meetings

The Jenkins project already operates a #jenkins-meeting channel on the Freenode network which can be used for recording IRC-based meetings. While Video Meetings are preferred, text-based meetings are also allowed.

SIG Leads should request operator status for the #jenkins-meeting channel, and should consult the Jenkins Event Calendar to make sure their meetings do not overlap with those already scheduled.


SIGs can optionally create dedicated channels for chats. These chats may be located in IRC, Gitter, Slack, or other channels. SIG leaders set up channels on their own, unless special permissions are needed (in that case, INFRA tickets should be created). If such chats are created, they should be referenced in SIG metadata.

Create the GitHub teams

In order to allow GitHub mentioning, SIGs can optionally have GitHub teams. To create a team, a SIG lead should file an INFRA ticket linking to the SIG proposal on the jenkinsci-dev@googlegroups.com mailing list with a mention of which GitHub organizations in which the team should be created.

Naming convention: ${githubOrg}/sig-${sigId} (e.g. jenkinsci/sig-platform)

Changing leaders and adopting SIGs

If there is no activity in SIGs for more than 2 months (2 meeting intervals), a SIG may be marked for adoption. In such case any SIG participant will be able to take leadership of the SIG.

"Marking for adoption" process:

  • The process is similar to adopting plugins

  • If a SIG leader wants to step down, he/she may propose the leadership transfer

  • If there is no activity, a SIG participant or other Jenkins contributor may raise a question about SIG ownership transfer

  • Leadership change proposals should be sent to the primary SIG mailing list, the current SIG leader(s) should be in CC.

  • Leadership transfer may happen if there is a consensus between SIG participants in the thread

  • In the case of adopting SIG due to inactivity, there is a 2-week response timeout to give a chance to the SIG leader(s) to process the request

  • SIG leadership transfer happens by changing SIG metadata on jenkins.io and announcing the change in the Developer mailing list

  • The new SIG leader(s) are expected to create INFRA tickets to get the permission transfer for SIG resources


As Jenkins continues to grow and evolve the "main" community discussion forums and channels have become increasingly busy, causing contributor fatigue and unproductive discussions for more specialized focus areas.

The Jenkins project already has some loose conventional structure around groups with specialization such as:

  • Infrastructure: group responsible for maintaining the Jenkins project’s primary infrastructure.

  • Google Summer of Code: group of organizers and mentors for the Jenkins project’s participation in Google Summer of Code.

  • LTS: group led by the Release Office organizing the Long Term Support release line.

These groups have vaguely consistent structure but lack consistent representation and process which leads to confusion about how these groups should be operated, what qualifies as a "group", and how new-comers should participate.


As mentioned in the Specification, much of this is modeled after the Kubernetes SIG process [1], which is a much larger open source community at this point than the Jenkins project. This design is well-tested and provides a reasonable middle-ground between flexibility for SIG Leads, without encouraging each SIG to reinvent their own bespoke process.

Backwards Compatibility

Nothing relevant for this JEP.


Nothing relevant for this JEP.

Infrastructure Requirements

This document describes avenues for many more Jenkins contributors to have access to resources which have traditionally only been accessed by infrastructure administrators.

This requires that access control must be shared for:

  • the YouTube channel, via the Brand account

  • Newly created Google Groups.

  • #jenkins-meeting on Freenode.


Nothing relevant for this JEP.