Move Gzemnid into the org

[ChALkeR]

Refs: nodejs/node#7935

Gzemnid is the tool which I use to build grep-able datasets from the latest versions of all packages in npm registry. I would like to see it moved to the org.

Previous resolution was to

1. Prep repo for migration.
2. Open issue in nodejs/tsc.

But I think that I never understood what exactly does the first point mean and this got stuck because of that, so moving to the second one now ;-).

[devsnek]

perhaps we could also spin up a small server for people to use, seeing as the functionality exists.

[ChALkeR]

@devsnek A server for online usage would require some more work (mostly usability/auth related), but a server would also be useful to keep the dataset up-to-date.

It is now hosted on my €10 vps, and I would like to be moved it somewhere else 😉.

As for API/interface for making it usable over https — I think that the best way forward would be to integrate GitHub auth, like we do for the CI.

[gibfahn]

LGTM

perhaps we could also spin up a small server for people to use, seeing as the functionality exists.

Sounds good, but separate from moving it into the foundation (which we should probably do first).

[mcollina]

LGTM

I was wondering if we need a separate server at all. Can we run it as a cron job in our jenkins infrastructure and upload it somewhere that's easy to pull from?

[mhdawson]

@ChALkeR "Prep repo for migration." means adding the required governance files so that when its moved over they are present:

These include:
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENCE.md
README.md

[Trott]

This might not apply due to the previous issue, or maybe it does--I'm not sure--but unfortunately, the GitHub management policy still says this:

No repository may be deleted, transferred into, or transferred out of the Node.js Foundation GitHub Organization without a simple majority of both the TSC and CommComm in favor of the action.

It also strongly implies that this needs to go in the admin repo rather than the TSC repo.

I would strongly support a PR that altered policy to reflect our current practice. If we want to change that practice, let's actually road-test the change before documenting (and forgetting) it (because forgetting it is what you do if you don't actually do it for a while first--people much more strongly take their cues from what everyone else is doing than from documented policies).

[jasnell]

SGTM. The most likely best home for this is under the @nodejs/automation team

[maclover7]

@ChALkeR Can you open up an issue at nodejs/build explaining the computing resources necessary to use the tool? It might make sense to sort that out first before going forward.

[ChALkeR]

@mhdawson

"Prep repo for migration." means adding the required governance files so that when its moved over they are present:

These include:
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENCE.md
README.md

I am not entirely sure what those should look like exactly for that repo.
@nodejs/collaborators perhaps someone could help me with a PR with those?

[benjamingr]

Regarding server - I think it would be awesome if our CI did that.

Regarding files:

CODE_OF_CONDUCT.md - this is just an empty file that links to Node's, example:
CONTRIBUTING.md - this one you have to write, although it's best that if you're going to maintain it you specify this as other members are likely unfamiliar
LICENCE.md - this is a copy of Node's license
README.md - you already have that

[ChALkeR]

@benjamingr Thanks!

CODE_OF_CONDUCT.md - this is just an empty file that links to Node's, example:

I don't see an example in your comment. Note that many of nodejs repos (e.g. nan, node-gyp, http-parser) don't have it.

CONTRIBUTING.md - this one you have to write, although it's best that if you're going to maintain it you specify this as other members are likely unfamiliar

Ok, will think about what can I put there. Many of nodejs repos also don't have that, btw.

LICENCE.md - this is a copy of Node's license

I don't think that an exact copy of Node's LICENCE.md is fit there — it contains some stuff that is not applicable.

I just added a standard MIT one, but I assume that copyright information should be changed. If yes — how exactly should it look like?

README.md - you already have that

It needs some fixes, but yes, I guess that should be enough for now.

[ChALkeR]

@benjamingr I added a link to the Node.js Code of Conduct to CODE_OF_CONDUCT.md, does that look fine?

[benjamingr]

Yeah looks fine, I think the modules repo has a license and CoC you can copy-paste:

• CODE_OF_CONDUCT.md
• LICENSE.md

The README looks good to me, I'd add a link to contributing, the COC and the license there after you've written CONTRIBUTING.md - the package.json needs an update but that likely waits for the move and apart from that I think it's "up to Node standards". For what it's worth I took a look at the code and it's fairly readable, so I think CONTRIBUTING.md can just be a standard "Clone the repo, run npm install, please be nice and play by our CoC". I might be wrong here though.

[ChALkeR]

@benjamingr I fixed those two files, LGTY?

[benjamingr]

Yeah, this looks good and ready to me

[mhdawson]

This is the example the contributing file in another repo: https://github.com/nodejs/node-report/blob/master/CONTRIBUTING.md. I think the key thing is the DCO. I think you could just copy that one, update to reflect that module name and that it is under the jurisdiction of the TSC directly and then (optionally) if there is any additional info you want to give people on how to contribute add that as well.

[fhinkel]

Another, please vote whether this tooling can move to the foundation. Ping @nodejs/tsc and @nodejs/community-committee. Please vote whether you're in favor of moving Gzemnid to the foundation, see #492 (comment).
Please use thumbs up/down on the first post.

[mhdawson]

Adding TSC agenda since we don't seem to be making progress here.

[fhinkel]

This got a lot of thumbs up (votes) on the first post, I think it's ready to merge.

[mhdawson]

@fhinkel can you see all of them, it gives me a list but then +X so I can't see if we have enough for quorum.

[Trott]

I can't see if we have enough for quorum.

Perhaps the thing to do is to close this issue and open another issue in nodejs/admin pointing people at this issue for discussion. Then there's no need to be concerned about counting votes, quorum, or any of that stuff unless someone objects. As long as there are no objections, it's just a matter of waiting 72 hours and then doing the transfer. From https://github.com/nodejs/TSC/blob/master/GitHub-Org-Management-Policy.md#repositories:

Any organization member may request the management of repositories within the Node.js Foundation GitHub Organization by opening an issue in the Node.js admin repository. The actions requested could be:
...
Transferring a repository into or out of the organization

Provided there are no objections from any TSC or CommComm members raised in the issue, such requests are approved automatically after 72 hours.

This was opened before the rules quoted above went into effect, I think, so that might explain why it was opened here rather than in the admin repo. Part of the reason for the change in procedure was to avoid items stalling.

[mhdawson]

Reading that text, would we have concerns assuming that having copied both the TSC and commcomm that it is ok that it is not in the admin repo? That would avoid additional noise generated by a new issue.

I'm thinking its probably ok and if we have the sanity check from a few more people then I'd say we can go ahead.

[mhdawson]

I'm going to remove from the TSC agenda since we seem to be making progress again.

[Trott]

would we have concerns assuming that having copied both the TSC and commcomm that it is ok that it is not in the admin repo?

I know I'm a pain about these things sometimes, so apologies, but I'd greatly prefer that we stick closely to our written rules/policies. (And if we're not going to do that, let's change them.) Our written policy specifically says the admin repo, so I'd prefer it be opened there.

If we let things slide for ourselves from time to time, we have less credibility when we need to uphold rules when they apply to others.

I'll open the admin repo issue and close this one, if that's A-OK with you. (And if not, re-open this after I've closed it. :-D )

[Trott]

Moved to nodejs/admin#130.