doc: add "Troubleshooting" & "best practices"#12791
doc: add "Troubleshooting" & "best practices"#12791refack wants to merge 8 commits intonodejs:masterfrom
Conversation
|
@addaleax I commented out the "Tricks" section so there is no |
|
@vsemozhetbyt fixed |
|
Maybe this is a nice and handy hotchpotch addition to the docs as we do not maintain our Wiki) |
Exactly |
|
/cc @nodejs/documentation |
|
I'm not sure whether or not it might be, so... is "rules of thumb" an overly "english" colloquialism? Would there be a better phrase / title? Note: I know what it means. |
|
Sometimes the phrase "best practices" is used in it's stead. |
There was a problem hiding this comment.
do these work in files?
There was a problem hiding this comment.
There was a problem hiding this comment.
it is faster on both platforms, might want to just mention it alltogether
There was a problem hiding this comment.
Ok. it's just that on windows the difference is amazing!
There was a problem hiding this comment.
This title seems a bit too vague. I'm not fond of junk-drawer documents (that is to say, a document you throw information in when you don't know where else to put it). So I'd prefer a specific title.
There was a problem hiding this comment.
(Not being cheeky but) do you have a suggestion? (Please don't say FAQ...)
Maybe "Tips & Best Practices"
P.S. usually the main problem with the "junk drawer" is finding stuff, but here we have the search function, for example if you search unknown encoding: cp65001 this will pop up.
There was a problem hiding this comment.
Maybe Tips and Troubleshooting for Fhqwhgads where Fhqwhgads is some specific activity? Like, is it "Tips for Proposing Pull Requests"? Maybe it's more broad than that, but some kind of thing that at least provides context for someone coming from Google that this isn't about troubleshooting running Node.js in production or something like that.
There was a problem hiding this comment.
Ok, that's good. I'll figure it out.
There was a problem hiding this comment.
Called it "Tips & Troubleshooting for working with the node code"
Move the "Best practices" to a different doc
| [2]: https://github.com/nodejs/node/blob/master/.eslintrc.yaml "eslintrc" | ||
| [3]: https://github.com/nodejs/node/tree/master/tools/eslint-rules "Our Rules" | ||
| [4]: https://github.com/nodejs/node/blob/master/doc/STYLE_GUIDE.md "MD Style" | ||
| [5]: https://blog.gitprime.com/why-code-churn-matters "Why churm matters" |
|
|
||
| ## Tips | ||
|
|
||
| 1. If you build the code often, you should check out [`ninja`]. You may |
There was a problem hiding this comment.
ninja may not need code highlight.
There was a problem hiding this comment.
I tend to ` wrap program names, but in this case, I agree it makes more sense not to
| ## Tips | ||
|
|
||
| 1. If you build the code often, you should check out [`ninja`]. You may | ||
| find it to be faster than `make`, much much faster than `MSBuild` (Windows), and less eager to rebuild unchanged |
There was a problem hiding this comment.
Can we break this line at 80 chars?
There was a problem hiding this comment.
ccache makes more of a difference in build speed than ninja, in my experience
sam-github
left a comment
There was a problem hiding this comment.
Looks helpful to me.
I suggest adding a section explicitly saying that if you are proposing a new or changed API, that you include docs, because its much easier to review code that has docs. And maybe mention as a meta-goal for the PR "making it easy to review and accept".
I think this could be helpful as a link in the PR template, so it might be found at the time its most relevant.
| @@ -0,0 +1,38 @@ | |||
| # Best Practices | |||
There was a problem hiding this comment.
make heading be full title? "Best Practices for a Successful PR"
| @@ -0,0 +1,38 @@ | |||
| # Best Practices | |||
| <sub>(a.k.a "Rules of thumb")</sub> | |||
There was a problem hiding this comment.
I don't think this adds anything.
There was a problem hiding this comment.
It's a search keyword trap
| ## Tips | ||
|
|
||
| 1. If you build the code often, you should check out [`ninja`]. You may | ||
| find it to be faster than `make`, much much faster than `MSBuild` (Windows), and less eager to rebuild unchanged |
There was a problem hiding this comment.
ccache makes more of a difference in build speed than ninja, in my experience
|
|
||
| [1]: http://bugs.python.org/issue1602 "python bug" | ||
| [2]: http://stackoverflow.com/questions/878972/windows-cmd-encoding-change-causes-python-crash "stack overflow" | ||
|
|
There was a problem hiding this comment.
should removing trailing whitespace
Good 👍
Yea it's definatly one of the goals of the doc, I'll put it explicitly.
Maybe, but IMHO it might be too late. We need to catch them when they start conceptualizing a PR 🤔 |
There was a problem hiding this comment.
Can you leave a blank line under each heading? Some Markdown renderers require that.
There was a problem hiding this comment.
I agree with Sam, this should be removed.
There was a problem hiding this comment.
This seems like a sentence fragment?
There was a problem hiding this comment.
I’m not a fan of this entire paragraph. Some small, especially first, but meaningful contributions would fall under these categories – I would say anything that improves the codebase should be welcome; whether those changes are necessary or not is a completely different question.
There was a problem hiding this comment.
Even I thought so. Apparently "judgment" is also valid it seems :-|
There was a problem hiding this comment.
huh, TIL :D feel free to disregard this then
There was a problem hiding this comment.
It might help to know what you mean by “pieces” – different commits, different PRs, or something else? I am not sure how specific you can get here without conflicting with “use good judgement”, but this sounds a little vague. If in doubt, remove the extra text – just saying that contributors should keep in mind that their changes will need to be reviewed in some way should help with most of the trouble that comes from large changes.
There was a problem hiding this comment.
I don’t really think most people can figure out our code style from looking at the actual ruleset – looking at surrounding code or other files should be much easier.
|
In my mind the For the harder requirements we have I'll add this "disclaimer" |
|
Ping @refack |
|
Need some follow up, but time is limited. |
More discussion on the "Rules of thumb" is in #12744
Help wanted: let's find these "tips" a better home 🏡
Fixes: #12636
[edit]
As I understand the term "rules of thumb" or "best practices", they are guidelines one should have in mind and try to adhere to, but are not necessarily hard requirements. Our requirements should be stated in the other parts of the document.
[/edit]
My suggestion for a few "rules of thumb" for code contributions.
These are obviously my personal opinion, so this PR welcomes edit and suggestions. I do think that we should put some loose guidelines in writing.
The following made me think of this, and are not critique!
Ref: #12603 - motivation
Ref: #12735 - size
Open questions:
Add a "catch all" document for tips & trick.
When adding an item, try to include the original error message or some keyword so that this doc will popup in Search.
Ref: #12786
Checklist
Affected core subsystem(s)
doc
/cc @vsemozhetbyt @gibfahn