-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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.
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
doc: s/origin/upstream/ collaborator guide #12436
Conversation
Are you sure this works? I thought 'origin' was still the only default remote in git? If we're going to use 'upstream', then there needs to be a command showing the adding of such a remote before executing those commands. |
I’m not sure what you mean by “works”… yes, calling it |
I think
to the start of "Technical HOW TO" |
I guess I'm in the minority, as I've always used 'origin' to point to the original repo and then used 'github-fork' to point to my fork of the original repo. However I still think adding the line that @benjamingr shows will make it more clear, especially for first-time/new git users. |
@mscdex @benjamingr we already suggest
in the contributing guide, and I suppose that new collaborators start with being contributors, and all existing collaborators already know how to land PRs with or without this change :) Besides being inconsistent with the contributing guide, the collaborator guide is even inconsistent with itself and therefore confusing (line 454 implies that PRs are opened from |
No opinion on how much material to add (if any) to show how to create upstream, but I will say that my experience is identical to what @addaleax says: Every collaborator I've ever onboarded had Is it still a good idea to add an extra sentence or two here and a shell command example to clarify that's what's going on? I don't have an opinion on that either way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like this might be more clear? LGTM anyway.
COLLABORATOR_GUIDE.md
Outdated
@@ -361,8 +361,8 @@ $ git checkout master | |||
Update the tree |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update the tree (assumes your repo is set up as detailed in CONTRIBUTING.md)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gibfahn sounds good to me, done. :)
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup.
29453e9
to
6a30353
Compare
@mscdex LGTY now (after #12436 (comment))? I get that it's different to what you do, but at least now it's (hopefully) explicit. FWIW I never use |
[silly question] can we discuss moving or linking these guides to the wiki? Personally that's the first place I look at for such information. |
@refack not a silly question, but AFAIK the main reason we don't use the Wiki is that you can't PR against it, which means updates have to be done by a select few. There is stuff in the Wiki, but I don't think it's updated very often. I'd be in favour of not using it at all (or just having it be links to these docs). |
I'm going on memory here, so I could be way off, but I thought it was a bit of the opposite problem: Anybody can update it directly and immediately, but there's no notification/watching mechanism so pages can be vandalized and we don't know until someone reports it. Regardless of the specifics, the general picture is that the feature set on the Wiki is very limited, or at least it used to be. (I don't keep track of every new GitHub improvement and feature.) At least in the past, the Wiki was definitely not ideal for this sort of thing. I rather like having the docs in with the code they refer to. I know for a fact that not all contributors have reliable internet and can lose access for days at a time. So it's a plus for that reason too. They can still refer to the docs as needed and work on stuff until they get back online. |
AFAIK the wiki can be reflected on as a git repo (https://github.com/nodejs/node.wiki.git). And also we can limit access to people with push access Alternatively just turn it into a one page table of content, with a rudimentary explanation about who should read what. Also maybe move some of the stuff from the root to Note to self. Make a PR of my ideas. |
Right, but you can't have PRs. The benefits for me are:
I don't think it makes sense to have the wiki and docs in the repo and docs on the website. The current split is:
SGTM |
You can. you clone it into a second repo, manage issues and PRs on it, then land in main |
@refack but then you lose the wiki part of it anyway - so making it a wiki wouldn't solve anything. |
hmmm 🤔🤔🤔🤔 right |
@refack doesn't making the wiki link to the other docs solve the discoverability/clarity issues? If you do that, what else do you gain from having a separate repo? I think you'd still want to put the User Info on the website, so you're basically just putting the contributor/collaborator info in a separate repo, which doesn't really make sense to me. |
Not a totally well formed idea... But I'm assuming there is good stuff in the current wiki (63 pages) that could appreciate from some loving? Anyway I agree that curating a good ToC is more important |
Sure, but again, I think that should join the stuff in the website or |
@refack that you look at project wikis is a good argument for deleting our wiki... there is already too many repos, and lack of clarity about what goes where. We have been trying to fix this by moving to a layout where
|
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup. PR-URL: #12436 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in 42d0f8b |
Fine with me. I just like it that it's a dedicated meta-docs section in the repo. P.S. vanity pages a like https://github.com/nodejs/node/wiki/Node-Users could probably just stay there? |
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup. PR-URL: #12436 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup. PR-URL: #12436 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup. PR-URL: #12436 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup. PR-URL: #12436 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup. PR-URL: #12436 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Use `upstream` to refer to `nodejs/node` instead of `origin`, because that’s the more common setup. PR-URL: nodejs/node#12436 Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Use
upstream
to refer tonodejs/node
instead oforigin
, becausethat’s the more common setup.
Checklist
Affected core subsystem(s)