Docs: clarify process for adding committers

[kaicataldo]

What is the purpose of this pull request? (put an "X" next to item)

[X] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)
Added a bullet point highlighting that we should get confirmation from a new committer before adding them to the team.

Is there anything you'd like reviewers to focus on?
Nothing in particular.

[platinumazure]

Not sure if this is a governance change-- if so, should we run by the TSC (or at least wait for a majority of 👍s here)?

[kaicataldo]

@platinumazure That's a good point. I had assumed this was what we were doing (since it's how it worked for me, though that was a long time ago now!), but it probably would be best to run it by the TSC. If we don't reach consensus here I'll bring it up in the next TSC meeting.

[not-an-aardvark]

Should we add a step to run the Jenkins job that updates the team page on the website?

[nzakas]

I agree this seems to just better explain what we are already doing, so it's not really a governance change, just a documentation change (changes to the way we do things should definitely be discussed in a TSC meeting).

The job to update the team page is currently setup to run after an ESLint release job completes, so I'm not sure we need to manually run the job unless there is a concern about a time lag.

[platinumazure]

@nzakas

The job to update the team page is currently setup to run after an ESLint release job completes, so I'm not sure we need to manually run the job unless there is a concern about a time lag.

Is that the case? I remember there was some difficulty integrating this with the release, although maybe the goal at that time was to include it in gensite and that didn't work? I guess I'm not 100% sure where this landed-- if it's really working after the release, then I'm okay with not manually running the job as committers are added.

[nzakas]

That is the case. Originally I tried putting it in gensite and that turned into a horrible mess, so I pulled it out into a separate job on Jenkins. That job watches for the completion of the ESLint Release Jenkins job and then runs. We can, of course, also run it manually if we need to.

[kaicataldo]

It looks like we have 5 TSC members (including myself) in favor of this change (either through approval or a 👍) and no 👎, so I don't think this needs to be discussed in the TSC meeting. I'll wait a little bit longer before merging to give @ilyavolodin and @mysticatea a little more time to voice their opinions.

[not-an-aardvark]

I pulled it out into a separate job on Jenkins. That job watches for the completion of the ESLint Release Jenkins job and then runs. We can, of course, also run it manually if we need to.

Are you sure this is working? Looking at https://jenkins.eslint.org/job/eslint.org%20Team%20Data/ it seems like the job hasn't run since December 6th, but the ESLint Release job has been run several times since then.

[nzakas]

@not-an-ardvark Yeah, I realized it was misconfigured and fixed it. Let's check today to see if it runs.

…

On Thu, Jan 17, 2019 at 8:05 AM Kai Cataldo ***@***.***> wrote: Merged #11272 <#11272> into master. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11272 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACWkuv3mVCwVVCCQ5vWprfayc6GFHPZks5vEJ9RgaJpZM4Z-luO> .

--

______________________________ Nicholas C. Zakas @SlickNet Author, Principles of Object-Oriented JavaScript <http://amzn.to/29Pmfrm> Author, Understanding ECMAScript 6 <http://amzn.to/29K1mIy>