Side effect: Working with Build WG to change description on Nodejs.org ? about automation HOT 9 CLOSED

Oh yeah, we'd want to have consensus from everyone in nodejs/automation about joining nodejs/build, that's the default for Node projects.

The PR that's blocking it needs doing anyway, nothing to do with this.

from automation.

I don't mind putting the team under build, my concern was:

1. Meetings (although technically we don't have to attend build WG meetings)
2. Notifications (although technically we don't have to add people to the Github build team or make it a sub team)

Those are the two things that seem to drive people away from OSS/Node.js WGs, also there were many teams under i18n WG and I don't think put them under the WG made a lot of difference, most of them are inactive now. Being in an informal team has the benefit of flexibility, people can come and go as they choose, because we cannot expect people to always spend their own time on OSS. If we start listing people in a document, removing people would get difficult when they become inactive due to various personal reasons (which is totally fine and reasonable, but makes things complicated if there were such a document).

I can see the argument for putting the team under the build WG as well so if people in the team think it's a good idea and don't mind the consequences (OK I might be a bit exaggerating here lol) , I won't block it.

from automation.

Given the recent founding of our team, I know things aren't always pretty clear, but I think I remember that we are a separate team, not a subteam of the Build WG. Am I correct?

You are correct.

And on a side note: if we're not a WG, how do we stand in the organization chart?

This is just a team, so AIUI we don't really have standing, we're just a group of people doing stuff, but it's not official.

It says it's purpose is "to create and maintain a distributed automation infrastructure."
If so, shouldn't we try and see with them if we can rework their description to better suit their purpose?

That description is accurate, and I don't think it conflicts with nodejs/automation.

• nodejs/automation - develop tools for automation
• nodejs/build - create and maintain infrastructure used for automation

I still think the ideal solution is for automation to be a team within build. nodejs/build is mainly concerned with automating building/testing of node, and automating setup of machines.

Take something like @joyeecheung 's node-core-utils, or the existing github-bot. If we implement a commit-queue, then we'll be running that in CI and possibly installing dependencies through Ansible. We're going to have a lot of overlap, and I think it'd be easier if we were part of the same WG.

from automation.

I still think the ideal solution is for automation to be a team within build. nodejs/build is mainly concerned with automating building/testing of node, and automating setup of machines.

You've got a fair point on this. I may be too strict, but I don't like a team like our own having responsabilities and not being "official". And this solution would indeed be the simplest.

But wouldn't that require any member of the team to also be member of the WG?

from automation.

But wouldn't that require any member of the team to also be member of the WG?

Yes, but that's not a big deal, the Build team are quite welcoming! We do a similar thing with release, where nodejs/release are a team within the LTS/Release WG.

It depends on a PR to the build repo to change the default structure though, it's on my backlog (unless someone else does it first).

from automation.

Well, I'm not a specialist, but maybe the question should be asked here too in that case.
I don't mind joining the build WG personnally, but on principle, it should be a choice, no?

At the very least, @joyeecheung should have a say for having founded this team IMHO

from automation.

One thing worth mentioning.

Under release we have the CITGM team... there are members on that team who have permissions to work on CITGM, and even do releases, without being members of the top level working group.

So it seems fair to me that we could have an automation team under build with members who are not part of the working group

edit: not being part of the workign group would then mean they wouldn't have the same responsibilities / expectations

from automation.

@MylesBorins If it works for the CITGM team then yes, I think it should work for us as well.

from automation.

Unarchived this repo so I could close all the PRs and issues. Will re-archive when I'm done.

from automation.