Skip to content

Update transfer repo instructions to be nodejs/.github-aware #682

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
aduh95 merged 2 commits into from
Mar 22, 2023
Merged

Update transfer repo instructions to be nodejs/.github-aware #682

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8668108
Update transfer repo instructions to be `nodejs/.github`-aware
aduh95 May 1, 2022
6b93619
Update transfer-repo-into-the-org.md
aduh95 Mar 22, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 13 additions & 6 deletions transfer-repo-into-the-org.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,16 +4,23 @@

Ideally, the repository should have the following documents in place:

- `CODE_OF_CONDUCT.md`: it can be a reference to
[the Node.js Code of Conduct][coc].
- `CONTRIBUTING.md`: if there isn't one already, [the contributing guide][]
of Node.js core could be a good example. Consider including the Developer's
Certificate of Origin section in the document to avoid potential copyright
conflicts.
- `LICENSE`, or other kind of documents that describe the license of
the project.
- `README.md`

Ideally, it would not have the following documents to inherit them from
Copy link
Copy Markdown
Member

@mhdawson mhdawson May 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there was some discussion that when you clone a repo that inherits like this you don't get a copy of the files and that might be a concern.

I don't remember if/where that concern was discussed/addressed but it's probably good to document that it's understood that there will not be copies in case of a clone (unless that has changed or I've got that wrong) and its a choice that we have made on purpose.

@nodejs/tsc any concerns with the code of conduct or contributing files not showing up in a clone?

Copy link
Copy Markdown
Contributor

@bnb bnb Jun 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct that you do not get a copy of the Code of Conduct checked into the repo.

Copy link
Copy Markdown
Member

@ljharb ljharb Jun 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point, the .github pattern is pretty prevalent and I don't think people expect the files to be always present.

Copy link
Copy Markdown
Member

@mhdawson mhdawson Jun 13, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljharb I can understand that, but that is independant from the decision within the project that it's ok not to have a copy in the checked out repo. That is what I thought would be good add to this documentation. That they won't be there AND that the project decided that was ok.

[nodejs/.github](https://github.com/nodejs/.github):

- `CODE_OF_CONDUCT.md`.
- `CONTRIBUTING.md`: if there is one already, consider including the Developer's
Certificate of Origin section in the document to avoid potential copyright
conflicts.

Comment thread
aduh95 marked this conversation as resolved.
Note that if the above documents are not checked out on the repository, they
will appear on the GitHub web UI but not on local clones of the repository. The
upside is that if the upstream document updates, no action needs to be taken for
the downstream repository to stay up-to-date.

It's recommended to set the default branch to `main` before transferring the
repository to the org, assuming that's possible without breaking existing
tooling or workflows.
Expand Down