add Joyee to jenkins-admin?

[Trott]

Doing some stuff with Joyee at Node+JS Interactive, and we set up a temporary job to test some stuff out, but I had to do it even though she knows more than me because I'm in jenkins-admin and she's not. I'd propose adding her, and also cleaning up some folks who haven't been around for a long time (Jon, George, insert joke about leaving Paul and Ringo in the team here).

[gireeshpunathil]

+1

[joaocgreis]

+1

cc @nodejs/jenkins-admins

[richardlau]

+1

[rvagg]

This is fine by me; but we have to do something about the many-hands problem across Jenkins because we're adding more hands. We're not coordinating or communicating very well and Jenkins doesn't provide any good mechanisms for doing that (and the history feature is mostly borked these days too!).
I keep on running in to strange behaviours configured in Jenkins that I can't find a reason for but are intentional. There's no paper-trail and it's hard to know if something's in place for a good reason or not. I'm likely doing a lot of this myself too so I'm not claiming to be blame free either (I'm probably even doing it to myself knowing how bad my memory for these kinds of details can be!).

I don't know what the answer is, but it probably starts with being more chatty here in the issue tracker about what we're doing when we're touching jobs that are managed by many people (the special purpose jobs aren't as concerning since there's generally one or two people).

[mhdawson]

+1

[sam-github]

I don't have a problem giving access to credible people (like @joyeecheung , a long-time active collaborator and TSC member). +1 from me.

I think the question of tracking and documenting changes is an issue, but not directly related.

Maybe it should be in a seperate issue, but continuing here since its where we are: if Jenkins itself had a way of tracking and explaining config changes, that'd be ideal, though I haven't bumped into it (but I'm far from a Jenkins expert).

If its not a Jenkins featue, our options seem limited.

A github centric expectation would be that for any config change there should be an issue open that its related to, and perhaps there should be a config label applied to every issue that resulted in or is related to a jenkins config change.

I think this is pretty reasonable, but is not perfect:

1. its hard to describe UI made changes in github issues, and screenshots are painful to make and not searchable
2. the opposite flow, that @rvagg describes, is the one we want, wherein we get a git blame-like ability to look at something in the Jenkins UI, and then can somehow follow a trail back the github issue that motivated the change

[richardlau]

+1 to the issue at hand (adding Joyee).

I've spun off the discussion about tracking changes to Jenkins to #2133.

[Trott]

I added Joyee. Closing. Thanks!