Request for comments: Special Interest Groups (SIGs) for the Jenkins project

89 views
Skip to first unread message

R. Tyler Croy

unread,
Mar 22, 2018, 5:04:38 PM3/22/18
to jenkin...@googlegroups.com

I have been looking at some of the great things the Kubernetes community has
been doing for ideas we can borrow, and one idea which really sticks out is:
Special Interest Groups (SIGs)
<https://github.com/kubernetes/community/blob/master/governance.md#sigs>

A full list of the Kubernetes community SIGs can be found here:
<https://github.com/kubernetes/community/blob/master/sig-list.md>

I think we already have some groups, which are almost informal SIGs, such as
Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
formalize, and support from a community infra standpoint are:

* Clear problem domain/focus area.
* Regularly scheduled and published meetings. I can easily imagine re-using
#jenkins-meeting or our public YouTube channel for regularly scheduling
and hosting weekly meetings for these various groups. I run a weekly
infra team sync on jenkins.io/hangout for example, but that's not
recorded anywhere :(
* "Chairs" (i.e. team leads)
* Dedicated discussion channel/group (i.e. mailing list)


Some SIGs which I would love to see for starters, would be:

* Security, lead by Daniel
* GSoC, lead by Oleg
* Infra, lead by Olivier and myself
* Cloud Native (Kubernetes, Jenkins X, CLOUD, etc), lead by Carlos
* Essentials, lead by myself
* LTS, lead by Oliver
* Automation/Configuration (config as code, puppet, chef, etc), lead by Ewelina


From my part on the infrastructure side, I'm more than willing to do the
necessary work to support SIGs, as I really feel like they will help bring more
folks to the table for focused contribution to the Jenkins project.


I'm curious how others feel about a SIG structure and whether you all agree
that it will help channel/focus discussions and contributions?



If there's strong interest, I'm happy to take point on writing a Process JEP.


Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
signature.asc

Jesse Glick

unread,
Mar 22, 2018, 5:21:26 PM3/22/18
to Jenkins Dev
On Thu, Mar 22, 2018 at 5:04 PM, R. Tyler Croy <ty...@monkeypox.org> wrote:
> Regularly scheduled and published meetings. I can easily imagine re-using
> #jenkins-meeting or our public YouTube channel for regularly scheduling
> and hosting weekly meetings for these various groups.

gitter.im feels more accessible than IRC, and automatically archived.

R. Tyler Croy

unread,
Mar 22, 2018, 5:31:04 PM3/22/18
to jenkin...@googlegroups.com
(replies inline)
Gitter is logged, but that's a far cry from the meeting notes which we're able
to automatically generate and archive on http://meetings.jenkins-ci.org/ :-/

I haven't found a preponderance of good "gitter" bots out there on the
internets yet.


That said, in the context of the SIGs proposal, I don't have a strong opinion
on where people have meetings, so long as they're published on a calendar ahead
of time, are open, and are recorded in some form or fashion.
signature.asc

Oleg Nenashev

unread,
Mar 22, 2018, 7:11:31 PM3/22/18
to Jenkins Developers
The proposal looks good to me though it overlaps with "teams" a bit.

In GSoC we already use the channels and have regular meetings there. Regarding Youtube, it would be great to extend the number of participants beyond the current number (10) and to give "subject leaders" a permission to run HoA recordings for shareable sessions.

Gitter vs. IRC... I would vote for Gitter for 24/7 discussion rooms. #jenkins-meeting could be used for formal meetings tho.

BR, Oleg

Ewelina Wilkosz

unread,
Mar 23, 2018, 3:09:08 AM3/23/18
to Jenkins Developers
I like the idea! And I'd love to be involved

I have no strong opinion regarding tools, I'm just finding myself drowning in couple of mail accounts, couple of slack accounts, gitter and IRC... and I find IRC complicated (I know... but really), probably because I have never used it before (I know... but really) and I was surprised to discover it is still alive :)
I will adjust, just wondering about people EVEN YOUNGER than me :P 

One comment regarding hangout - google has another tool: meet.google.com, which, as far as I understand, is a better hangout. We used it when we had first sessions with Kohsuke regarding JCasC and I was surprised by the quality of sound and video. Any chance we could have an official meet.google.com room instead of hangout? Has anyone else tried both and has the same observation?

Carlos Sanchez

unread,
Mar 23, 2018, 8:04:42 AM3/23/18
to Jenkins Developers
I think the materialization of SIGs would be a great addition to the community, thanks Tyler for the write up

I am working on draft JEPs to be proposed regarding "cloud native": external storage, external logging,... you'll be reading more from me in the following weeks :) 


--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20180322210421.4ikcudf7m65yilvo%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.

Baptiste Mathus

unread,
Mar 26, 2018, 4:54:00 AM3/26/18
to Jenkins Developers
I think this is a good initiative to keep us moving forward. As the Jenkins Project keeps growing, we definitely have various people with various interests, and anything that can help people contribute without feeling they're getting spammed by dozens of "unrelated" emails seems a good idea.

I'm slightly worried about the segmentation/explosion of number of mailing lists though, and the segmentation of the community too. 
I guess we'll need to be even cautious finding a way to still "keep us together", and be more aggressive with regard to JEPping things even more commonly to make sure important things are not decided in the deep of a given thread of a given sub-ML.

My 2 cents


Ewelina Wilkosz

unread,
Mar 26, 2018, 7:12:34 AM3/26/18
to Jenkins Developers
+1 to that Baptiste, let's try to make it in a way that
1. will not isolate us, but "keep us together"
2. will make it easy for us to keep the track

and easy to say without providing ideas, but for now I just wanted to highlight I believe those two are important things to keep in mind while setting things up
I will try to come up with some specifics when I'm done with "fire fighting" in the office :)
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

Daniel Beck

unread,
Mar 26, 2018, 10:58:27 AM3/26/18
to jenkin...@googlegroups.com

> On 22. Mar 2018, at 22:04, R. Tyler Croy <ty...@monkeypox.org> wrote:
>
> I think we already have some groups, which are almost informal SIGs, such as
> Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
> formalize, and support from a community infra standpoint are:
>
> * Clear problem domain/focus area.
> …
>
> Some SIGs which I would love to see for starters, would be:
>
> * Security, lead by Daniel

What's the intended relation between existing teams and SIGs?

I'm asking mostly about security, which is more narrow in scope that what a potential 'security SIG' would be.

Would there be a security team with the narrow scope, and a security SIG with much wider scope?

R. Tyler Croy

unread,
Mar 26, 2018, 11:13:56 AM3/26/18
to jenkin...@googlegroups.com
(replies inline)

On Mon, 26 Mar 2018, Daniel Beck wrote:

>
> > On 22. Mar 2018, at 22:04, R. Tyler Croy <ty...@monkeypox.org> wrote:
> >
> > I think we already have some groups, which are almost informal SIGs, such as
> > Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
> > formalize, and support from a community infra standpoint are:
> >
> > * Clear problem domain/focus area.
> > ???
> >
> > Some SIGs which I would love to see for starters, would be:
> >
> > * Security, lead by Daniel
>
> What's the intended relation between existing teams and SIGs?
>
> I'm asking mostly about security, which is more narrow in scope that what a potential 'security SIG' would be.
>
> Would there be a security team with the narrow scope, and a security SIG with much wider scope?


I'm curious why you assume that the security SIG would be broader in scope than
the present day CERT?

Based on the Kubernetes project's descriptions of SIGs, I think cERT is more or
less a SIG already :P
signature.asc

Daniel Beck

unread,
Mar 26, 2018, 1:11:34 PM3/26/18
to jenkin...@googlegroups.com

> On 26. Mar 2018, at 17:13, R. Tyler Croy <ty...@monkeypox.org> wrote:
>
> I'm curious why you assume that the security SIG would be broader in scope than
> the present day CERT?

Well, it _could_ be broader in scope. It certainly could be more open. Security isn't just finding and fixing vulnerabilities.

Right now, general improvements (like Wadeck's API token PR[1] in core) or discussions related to security (perhaps about Jenkins' integrations with various auth providers) have no real home. Some of that happens in CERT sort of by default, but unless it's about an actual vulnerability, it's not necessary to keep it in a closed group only few can participate in. People without special permissions can still contribute.

1: https://github.com/jenkinsci/jenkins/pull/3271

R. Tyler Croy

unread,
Apr 10, 2018, 9:57:35 PM4/10/18
to jenkin...@googlegroups.com
(replies inline)

On Thu, 22 Mar 2018, R. Tyler Croy wrote:

>
> I have been looking at some of the great things the Kubernetes community has
> been doing for ideas we can borrow, and one idea which really sticks out is:
> Special Interest Groups (SIGs)
> <https://github.com/kubernetes/community/blob/master/governance.md#sigs>
>
> A full list of the Kubernetes community SIGs can be found here:
> <https://github.com/kubernetes/community/blob/master/sig-list.md>
>
> I think we already have some groups, which are almost informal SIGs, such as
> Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
> formalize, and support from a community infra standpoint are:


Here's an update, I've written out my first draft of what SIGs might look like
for us here: https://github.com/jenkinsci/jep/pull/81

Please let me know what you all think, I'm especially curious for Daniel,
Oliver, Ewelina, and Carlos's thoughts as I am hoping this helps you all get
more contribution and focus :)



Cheers
signature.asc

Ewelina Wilkosz

unread,
Apr 11, 2018, 2:50:46 AM4/11/18
to Jenkins Developers
Good job!

I'll just comment what I think could be clarified, really small things...

- "Record SIG meeting, such as via YouTube Live Streaming, and make it publicly available. Text-based meetings can use #jenkins-meeting on Freenode.." - So is it obligatory to record a meeting or not? should we user YouTube AND #jenkins-meeting or one of those?
- "Submit a PR to add a row for the SIG to the table in the kubernetes/community README.md file, to create a kubernetes/community directory, and to add any SIG-related docs, schedules, roadmaps, etc. to your new kubernetes/community/SIG-foo directory." - maybe I'm missing something here but is 'kubernetes' here an example or what? What's the repository? sorry if it's a dumb question :) I'm simply disoriented  

Is SIG Lead one person responsible for all the administration - recording, maintaining communication channels, github accounts etc? Or can this role be shared? 

In general I like the document, easy to read, explain motivation behind the SIG idea in a nice way. And I do believe we can benefit from having those. Just want to make sure SIG Lead won't drown in an "office work" - maintaining all the accounts, documents etc :) Meeting every 3 weeks sound like a good balance.

BR
Ewelina

Baptiste Mathus

unread,
Apr 11, 2018, 4:05:12 AM4/11/18
to Jenkins Developers
2018-04-11 8:50 GMT+02:00 Ewelina Wilkosz <ewel...@gmail.com>:
Good job!

I'll just comment what I think could be clarified, really small things...

- "Record SIG meeting, such as via YouTube Live Streaming, and make it publicly available. Text-based meetings can use #jenkins-meeting on Freenode.." - So is it obligatory to record a meeting or not? should we user YouTube AND #jenkins-meeting or one of those?

My understanding, but so yes it should probably be clarified in any case to avoid having people have their own understanding :), is that it's an OR. 
So some SIGs could decide to have their meetings as text, or via hangout. 

For one, I definitely would welcome text-based ones depending on the hour of the day. It's easier when it's late, you're home and cannot easily speak out loud with family around.

About, I think it would be more inclusive to (strongly?) recommend to try and have meetings at various hours to help interested people attend.
For instance, the current Jenkins governance meeting time is very unfriendly for Aussies (it's roughly 4 AM IIRC).

 
- "Submit a PR to add a row for the SIG to the table in the kubernetes/community README.md file, to create a kubernetes/community directory, and to add any SIG-related docs, schedules, roadmaps, etc. to your new kubernetes/community/SIG-foo directory." - maybe I'm missing something here but is 'kubernetes' here an example or what? What's the repository? sorry if it's a dumb question :) I'm simply disoriented  

I commented in the PR. It seems like a copy-paste issue from the inspiration :).
 

Is SIG Lead one person responsible for all the administration - recording, maintaining communication channels, github accounts etc? Or can this role be shared? 

In general I like the document, easy to read, explain motivation behind the SIG idea in a nice way. And I do believe we can benefit from having those. Just want to make sure SIG Lead won't drown in an "office work" - maintaining all the accounts, documents etc :) Meeting every 3 weeks sound like a good balance.

BR
Ewelina

On Wednesday, April 11, 2018 at 3:57:35 AM UTC+2, R Tyler Croy wrote:
(replies inline)

On Thu, 22 Mar 2018, R. Tyler Croy wrote:

>
> I have been looking at some of the great things the Kubernetes community has
> been doing for ideas we can borrow, and one idea which really sticks out is:
> Special Interest Groups (SIGs)
>     <https://github.com/kubernetes/community/blob/master/governance.md#sigs>
>
> A full list of the Kubernetes community SIGs can be found here:
>     <https://github.com/kubernetes/community/blob/master/sig-list.md>
>
> I think we already have some groups, which are almost informal SIGs, such as
> Security, GSoC, Infra, etc. The aspects of SIGs which I really would like to
> formalize, and support from a community infra standpoint are:


Here's an update, I've written out my first draft of what SIGs might look like
for us here: https://github.com/jenkinsci/jep/pull/81

Please let me know what you all think, I'm especially curious for Daniel,
Oliver, Ewelina, and Carlos's thoughts as I am hoping this helps you all get
more contribution and focus :)



Cheers

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8cb01ce8-6cbe-4452-b36e-0aa0b306fd17%40googlegroups.com.

Baptiste Mathus

unread,
Apr 11, 2018, 4:14:33 AM4/11/18
to Jenkins Developers
I am fine and love the general idea of giving us progressively more useful structure as we grow, to help make it easier for people to feel welcome to contribute without feeling overwhelmed.

Also fine by me the meetings part, recording it makes sense indeed, for people interested, but unable to attend for whatever reason. Or offer a way for newcomers to start lurking before they dare start interacting (I've been there :)).

Some comments :

* I guess the "Report activity in the weekly community meeting at least once every 6 weeks" could be rephrased like "Report activity in the bi-weekly governance meeting at least once every 6 weeks"?

* About 
"Name convention:
jenkinsci-foo (the discussion group)
jenkinsci-foo-leads (list for the leads, to be used with Zoom and Calendars)
jenkinsci-foo-misc
jenkinsci-foo-test-failures
jenkinsci-foo-bugs
jenkinsci-foo-feature-requests
jenkinsci-foo-proposals
jenkinsci-foo-pr-reviews
jenkinsci-foo-api-reviews"

Eeek. Do we really want that? Is this really meant to be 9 mailing lists to be created per SIG?

If the answer is yes, I guess we'll have to start writing tooling around this to make creating SIGs easier. Same for GitHub teams.

Overall, I do not understand very clearly the intent and pros of that high level of separation, both on MLs and GH side. But I might be missing something.


Cheers!

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

Ewelina Wilkosz

unread,
Apr 11, 2018, 4:22:10 AM4/11/18
to Jenkins Developers
I must say I only briefly scanned the part with all the jenkinsci-foo and sig-foo :( it seemed like a lot indeed. I like the rest of the document though! but this part was almost verwhelming... 
that's why I asked about SIG Lead responsibility. If we want to do a good job we should make it as easy as possible - not that I'm lazy, but let's be realistic 

We can see people being confused about Jenkins Developers and Jenkins Users mailing list - if we have too many groups to choose from I would probably spend so much time trying to figure out which one is the one I should post in

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

R. Tyler Croy

unread,
Apr 16, 2018, 10:17:22 AM4/16/18
to jenkin...@googlegroups.com
(replies inline)

On Wed, 11 Apr 2018, Ewelina Wilkosz wrote:

> I must say I only briefly scanned the part with all the jenkinsci-foo and
> sig-foo :( it seemed like a lot indeed. I like the rest of the document
> though! but this part was almost verwhelming...
> that's why I asked about SIG Lead responsibility. If we want to do a good
> job we should make it as easy as possible - not that I'm lazy, but let's be
> realistic
>
> We can see people being confused about Jenkins Developers and Jenkins Users
> mailing list - if we have too many groups to choose from I would probably
> spend so much time trying to figure out which one is the one I should post
> in


Thanks Ewelina and Ba(p)tiste, I've made some changes and removed the manymany
recommended mailing lists as I don't think we're at the point of needing them
yet.


Filed as a proper Draft now: https://github.com/jenkinsci/jep/pull/81

signature.asc

Oleg Nenashev

unread,
Apr 17, 2018, 4:44:13 PM4/17/18
to Jenkins Developers
Hi,

We are starting GSoC meetings next week. If you need somebody to dry-run the SIG infrastructure, sign us up :)

Reasoning: Having recorded GSoC sessions would be definitely helpful so that we can share meetings with students/mentors who miss meetings. OTOH I am not sure whether this content is useful for other community members.

Actually I would propose to have 2 SIGs:
  • GSoC - special for GSoC. All infrastructure is ready
  • Newcomer onboarding - Another SIG for newcomers in Jenkins community + Q&As + discussions about contributor experience
    • We could split generic GSoC meetings to there (e.g. plugin development intros & Co)
Best regards,
Oleg

R. Tyler Croy

unread,
Apr 17, 2018, 5:58:14 PM4/17/18
to jenkin...@googlegroups.com
(replies inline)

On Tue, 17 Apr 2018, Oleg Nenashev wrote:

> Hi,
>
> We are starting GSoC meetings next week. If you need somebody to dry-run
> the SIG infrastructure, sign us up :)
>
> Reasoning: Having recorded GSoC sessions would be definitely helpful so
> that we can share meetings with students/mentors who miss meetings. OTOH I
> am not sure whether this content is useful for other community members.
>
> Actually I would propose to have 2 SIGs:
>
> - GSoC - special for GSoC. All infrastructure is ready
> - Newcomer onboarding - Another SIG for newcomers in Jenkins community +
> Q&As + discussions about contributor experience
> - We could split generic GSoC meetings to there (e.g. plugin
> development intros & Co)


I'll add you as a manager to the Brand Account so you can use Hangouts on Air
for the GSoC discussions. I agreed that a GSoC Special Interest Group makes
sense, I don't think a "Newcomer" one does because I don't understand what the
"regular business" of the SIG would be. For example, it's very clear to me
what the purpose and mission of a GSoC SIG would be, and why they would meet
regularly.

I don't think we need to carve up everything we do into SIGs for the record, I
think there's a need for SIGs on specified "business" which requires a group's
regular attention, but that doesn't mean everything fits into the model IMHO.


If I'm misunderstanding or missing something about the mission for a
prospective Newcomer SIG, let me know.



Cheers
signature.asc

Oleg Nenashev

unread,
Apr 27, 2018, 8:49:07 PM4/27/18
to Jenkins Developers
I think I will need to work a bit on the "Newcomer" idea, so let's park it for now.

Just to provide some heads-up, we will be establishing Gitter channels for EDA Plugins and Remoting over Message Queue/Bus GSoC projects. In both cases they could be SIGs according to the definition in the beginning:
  • Electronic Design Automation plugins are unlikely interesting to a significant part of Jenkins developers, so maybe it makes sense to call it a SIG (e.g. "Electronic Design Automation and Hardware") and to move some specific discussions there.
    • Me and Martin could be chairs, for example
  • Remoting is already listed as subproject, and it's more tricky.
    • Remoting is a part of the core, and IMHO it does not make sense to keep mailing lists separate.
    • Having a Remoting/Agent-specific **dev** chat could be useful so that Remoting maintainers can synchronize with agent plugin maintainers (e.g. adopting features like -workDir, etc.)
    • Not sure it qualifies as SIG, feedback would be appreciated
BR, Oleg

Oleg Nenashev

unread,
Jun 29, 2018, 5:24:51 AM6/29/18
to Jenkins Developers
Hi all,

I am about creating a JEP for a SiG next week.
Currently I am following the original proposal from Tyler in my draft (what to define in the specification).

Since everybody is fine in this thread, is it fine to proceed with SiGs? Or should we wait till there is a JEP for the SiG process?

Best regards,
Oleg

Liam Newman

unread,
Jul 11, 2018, 6:19:41 PM7/11/18
to Jenkins Developers
Hello all,
Oleg has submitted a pull request with changes from his recent creation of the Platform SIG: 


Please take a look and provide feedback and edits.  

-L.

Oleg Nenashev

unread,
Jul 12, 2018, 3:09:24 PM7/12/18
to Jenkins Developers
Hi all,

Feedback will be appreciated.
I have also added the engine to the jenkins.io, so now it is possible to define SIG metadata and to create SIG pages.
We are also beta-testing the SIG creation process, so everybody is welcome to try it out and provide feedback.

Best regards,
Oleg
Reply all
Reply to author
Forward
0 new messages