Add docs required by TSC

[williamkapke]

As promised in the 2016-08-11 TSC meeting , here are the boilerplate docs required by the TSC for repos entering the Node.js GitHub org.

[phillipj]

Only thing which comes to mind, is what WG this project is governed by. You raised that question in #23, but no one has answered, and we haven't really discussed it directly in other occasions afaik.

[Starefossen]

what WG this project is governed by

Build or Website would be candidates. The Bot WG has some resemblance/overlap with the Testing WG which is supposed? to be under the Build WG.

[phillipj]

ATM I agree with Build, but that decision belongs to the Build overlords I assume?

In the future we might end up spawning a separate WG too handle this, e.g Automation, but that sounds like overkill for the current size of the project and amount of collabs.

/cc @jbergstroem @rvagg

[jbergstroem]

I think build is a good place and would be happy to work towards that.

[rvagg]

but that decision belongs to the Build overlords

that includes you now overlord @phillipj

[williamkapke]

I removed my accidental reference to a "WG".

After the bot has a deployment process, I don't find the Build group to be the appropriate group to oversee the development of the work it does.

The bot's scope is very crosscutting and will extend beyond the reach of even the CTC. This is why I pointed the Governance to the TSC.

I hope to discuss this as the Collaboration Summit in Amsterdam and will likely continue the discussion in Austin.

[Starefossen]

The bot's scope is very crosscutting and will extend beyond the reach of even the CTC. This is why I pointed the Governance to the TSC.

While I agree with you, there are two point I would like to make.

1. The development of the bot is primarily a technical task which means that the governing body should be one of developers who have time to sit down and write the code.

2. I see the governing body of the bot more of a service agency for the rest of the organisation - taking requests from other WGs and implementing them. This is similar to how the Build WG is operating today. It has the responsibility to maintain the CI and takes requests from other WGs to implement changes without necessarily being the driving force behind the change.

[williamkapke]

@Starefossen I see it more like the docs WG where the process of publishing is automated by the build WG, but their content is within their own oversight.

[phillipj]

I hope to discuss this as the Collaboration Summit in Amsterdam and will likely continue the discussion in Austin.

Any reason these discussions can't happen publicly and async, like we're doing right now, rather than requiring devs to show up at summits to be part of the discussions?

[jbergstroem]

I was hoping to have a hangout call prior the summit if that works for everyone? Can suggest something in a new issue.

[williamkapke]

@phillipj certainly! The summit is just an opportunity to bring awareness and solicit feedback from folks that aren't watching this progress.

[phillipj]

As for Build WG vs TSC, I'd say start with Build WG and possibly elevate it to TSC when we know for a fact that it would benefit the project.

[Fishrock123]

Should the license be defaulting to Apache-2.0 nowadays?

[Fishrock123]

@mikeal should we be using Apache-2.0?

[williamkapke]

From today's TSC meeting: At the moment, MIT is the correct license according to the Governing Documents. There is a desire to switch to Apache-2.0, but it will require some work. (Ongoing conversation here)

Governance was discussed also with the conclusion that it should be listed as the TSC- but the people belonging to the GitHub team are the ones running it.

Can I get some LGTMs?

[Starefossen]

Thanks for the update! LGTM

[jbergstroem]

I think we would spend some time improving the goals/rationale of this (to be) wg; this - taken from the README - isn't necessarily reflecting what we discussed: All repositories that use this bot have the same webhook url & secret configured (there is only 1 bot instance). Org-wide webhooks are not allow.

Lets try and come up with something that better reflects what we want to achieve.

[williamkapke]

@jbergstroem Agreed that we should update the readme. It would be nice to see "Guiding Principles" or similar.

The TSC didn't seem too keen on creating a new WG. My guess is that it is because there are a bunch of WGs that have lost their steam.

All repositories that use this bot have the same webhook url & secret configured (there is only 1 bot instance).

I added that in to remove confusion for anyone. It is true at the moment- but maybe not in the future.

Org-wide webhooks are not allow.

This definitely needs to hold true. Otherwise we leak from private repos.

[phillipj]

Org-wide webhooks are not allow.

This definitely needs to hold true. Otherwise we leak from private repos.

That's obviously a big issue for 3rd party GitHub apps, but wouldn't it be very different for this bot which we (the nodejs org) have full control over?

[williamkapke]

This week's TSC meeting expressed a desire to merge this as-is and iterate as needed.