Italian Translation Report: Node.js [Part 31 - 1533 words]

Sep 4th, 2018
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. This document is an outline of the things we tell new Collaborators at their onboarding session.
  2. One week before the onboarding session
  3. If the new Collaborator is not yet a member of the nodejs GitHub organization, confirm that they are using two-factor authentication
  4. It will not be possible to add them to the organization if they are not using two-factor authentication.
  5. If they cannot receive SMS messages from GitHub, try using a TOTP mobile app
  6. Announce the accepted nomination in a TSC meeting and in the TSC mailing list.
  7. Suggest the new Collaborator install and set up the credentials for it.
  8. Fifteen minutes before the onboarding session
  9. Prior to the onboarding session, add the new Collaborator to the Collaborators team
  10. Ask them if they want to join any subsystem teams.
  11. See Who to CC in the issue tracker
  12. Onboarding session
  13. This session will cover:
  14. local setup
  15. project goals & values
  16. managing the issue tracker
  17. reviewing PRs
  18. landing PRs
  19. Make sure you have
  20. Always continue to PR from your own GitHub fork
  21. Branches in the repository are only for release line
  22. See Updating Node.js from Upstream
  23. Make a new branch for each PR you submit.
  24. Membership: Consider making your membership in the Node.js GitHub organization public.
  25. This makes it easier to identify Collaborators.
  26. Instructions on how to do that are available at Publicizing or hiding organization membership
  27. Notifications:
  28. Use or set up email
  29. Watching the main repo will flood your inbox (several hundred notifications on typical weekdays), so be prepared
  30. on is the best place to interact with the TSC / other Collaborators
  31. If there are any questions after the session, a good place to ask is there!
  32. Presence is not mandatory, but please drop a note there if force-pushing to
  33. Collaborators are the collective owners of the project
  34. The project has the goals of its contributors
  35. There are some higher-level goals and values
  36. Empathy towards users matters (this is in part why we onboard people)
  37. Generally: try to be nice to people!
  38. The best outcome is for people who come to our issue tracker to feel like they can come back again.
  39. You are expected to follow and hold others accountable to the Code of Conduct.
  40. You have (mostly) free rein; don't hesitate to close an issue if you are confident that it should be closed
  41. Be nice about closing issues! Let people know why, and that issues and PRs can be reopened if necessary
  42. See "Labels"
  43. There is a bot that applies subsystem labels (for example, or) so that we know what parts of the code base the pull request modifies.
  44. It is not perfect, of course.
  45. Feel free to apply relevant labels and remove irrelevant labels from pull requests and issues.
  46. Use the label if a topic is controversial or isn't coming to a conclusion after an extended time.
  47. If a change has the remote chance of breaking something, use the label
  48. When adding a label, add a comment explaining why you're adding it.
  49. Do it right away so you don't forget!
  50. Please add the label for PRs where:
  51. the CI has been started (not necessarily finished),
  52. no outstanding review comments exist and
  53. This will come more naturally over time
  54. For many of the teams listed there, you can ask to be added if you are interested
  55. Some are WGs with some process around adding people, others are only there for notifications
  56. When a discussion gets heated, you can request that other Collaborators keep an eye on it by opening an issue at the private repository.
  57. This is a repository to which all members of the GitHub organization (not just Collaborators on Node.js core) have access.
  58. Its contents should not be shared externally.
  59. You can find the full moderation policy here
  60. The primary goal is for the codebase to improve
  61. Secondary (but not far off) is for the person submitting code to succeed.
  62. A pull request from a new contributor is an opportunity to grow the community.
  63. Review a bit at a time.
  64. Do not overwhelm new contributors.
  65. It is tempting to micro-optimize.
  66. Don't succumb to that temptation.
  67. We change V8 often.
  68. Techniques that provide improved performance today may be unnecessary in the future.
  69. Be aware: Your opinion carries a lot of weight!
  70. Nits (requests for small changes that are not essential) are fine, but try to avoid stalling the pull request.
  71. Note that they are nits when you comment:
  72. If they are stalling the pull request, fix them yourself on merge.
  73. Insofar as possible, issues should be identified by tools rather than human reviewers.
  74. If you are leaving comments about issues that could be identified by tools but are not, consider implementing the necessary tooling.
  75. Minimum wait for comments time
  76. There is a minimum waiting time which we try to respect for non-trivial changes so that people who may have important input in such a distributed project are able to respond.
  77. For non-trivial changes, leave the pull request open for at least 48 hours (72 hours on a weekend).
  78. If a pull request is abandoned, check if they'd mind if you took it over (especially if it just has nits left).
  79. Approving a change
  80. Collaborators indicate that they have reviewed and approve of the changes in a pull request using Github’s approval interface
  81. Some people like to comment LGTM (“Looks Good To Me”)
  82. You have the authority to approve any other collaborator’s work.
  83. You cannot approve your own pull requests.
  84. When explicitly using, show empathy – comments will usually be addressed even if you don’t use it.
  85. If you do, it is nice if you are available later to check whether your comments have been addressed
  86. If you see that the requested changes have been made, you can clear another collaborator's review.
  87. Use to indicate that you are considering some of your comments to block the PR from landing.
  88. What belongs in Node.js:
  89. Opinions vary – it’s good to have a broad collaborator base for that reason!
  90. If Node.js itself needs it (due to historical reasons), then it belongs in Node.js.
  91. That is to say, is there because of is there because of etc.
  92. Things that cannot be done outside of core, or only with significant pain such as
  93. Continuous Integration (CI) Testing:
  94. It is not automatically run.
  95. You need to start it manually.
  96. Log in on CI is integrated with GitHub.
  97. Try to log in now!
  98. You will be using most of the time.
  99. Go there now!
  100. Consider bookmarking it:
  101. To get to the form to start a job, click on
  102. (If you don't see it, that probably means you are not logged in!) Click it now!
  103. To start CI testing from this screen, you need to fill in two elements on the form:
  104. The box should be checked.
  105. By checking it, you are indicating that you have reviewed the code you are about to test and you are confident that it does not contain any malicious code.
  106. (We don't want people hijacking our CI hosts to attack other hosts on the internet, for example!)
  107. The box should be filled in with the number identifying the pull request containing the code you wish to test.
  108. For example, if the URL for the pull request is, then put in the
  109. The remaining elements on the form are typically unchanged with the exception of
  110. Check that if you want a CI status indicator to be automatically inserted into the PR.
  111. If you need help with something CI-related:
  112. Use to talk to other Collaborators.
  113. Use to talk to the Build WG members who maintain the CI infrastructure.
  114. Use the to file issues for the Build WG members who maintain the CI infrastructure.
  115. See the Collaborator Guide: Landing Pull Requests
  116. Note that commits in one PR that belong to one logical change should be squashed.
  117. It is rarely the case in onboarding exercises, so this needs to be pointed out separately during the onboarding
  118. Exercise: Make a PR adding yourself to the README
  119. For raw commit message:
  120. Collaborators are in alphabetical order by GitHub username.
  121. Optionally, include your personal pronouns.
  122. Label your pull request with the subsystem label.
  123. Run CI on the PR.
  124. Because the PR does not affect any code, use the CI task.
  125. Alternatively, use the usual <0>node-test-pull-request</0> CI task and cancel it after the linter and one other subtask have passed.
  126. After one or two approvals, land the PR (PRs of this type do not need to wait for 48/72 hours to land).
  127. Be sure to add the and appropriate metadata.
  128. automates the generation of metadata and the landing process.
  129. See the documentation of
  130. automates the validation of commit messages.
  131. This will be run during of the command.
  132. Don't worry about making mistakes: everybody makes them, there's a lot to internalize and that takes time (and we recognize that!)
  133. Almost any mistake you could make can be fixed or reverted.
  134. The existing Collaborators trust you and are grateful for your help!
  135. Other repositories:
  136. The Node.js Foundation hosts regular summits for active contributors to the Node.js project, where we have face-to-face discussions about our work on the project.
  137. The Foundation has travel funds to cover participants' expenses including accommodations, transportation, visa fees, etc. if needed
  138. Check out the repository for details.
RAW Paste Data

Adblocker detected! Please consider disabling it...

We've detected AdBlock Plus or some other adblocking software preventing from fully loading.

We don't have any obnoxious sound, or popup ads, we actively block these annoying types of ads!

Please add to your ad blocker whitelist or disable your adblocking software.