Docs/new contributor misc

[nicholsonjf]

Summary

Removes a redundant step in the New Contributor Guide

See the below comment for more detail.

#15712 (comment)

Test plan

N/A

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/15712

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 4 Unrelated Failures

As of commit 4b0acf3 with merge base 6de1f4e ():

NEW FAILURE - The following job has failed:

• pull / test-moshi-linux / linux-job (gh)
  RuntimeError: Command docker exec -t 8593c12840126040b0fa4020f8ea03fc45d549847239673f1126ff4591e32b9f /exec failed with exit code 1

BROKEN TRUNK - The following jobs failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / unittest / linux / linux-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe
• pull / unittest / macos / macos-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe
• pull / unittest-editable / linux / linux-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe
• pull / unittest-editable / macos / macos-job (gh) (trunk failure)
  backends/xnnpack/test/recipes/test_xnnpack_recipes.py::TestXnnpackRecipes::test_int8_static_quant_recipe

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[meta-cla]

Hi @nicholsonjf!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[lucylq]

Curious - why remove this section?

[nicholsonjf]

Apologies @lucylq I should have included notes in the PR description. Let me know your thoughts about my recommendation below and I can update the PR if needed.

tl;dr

I actually think this guide would be clearer if Step 4 (how to sync a branch from the GitHub UI) was removed (see the last paragraph below)

Background

When I was working through this guide setting up my dev env, it was a bit confusing why the reader is being instructed to sync their local fork at the end of Step 3, and then again at the beginning of Step 5.

End of Step 3:

Let's sync from both your fork and the main ExecuTorch branch, getting the latest changes from each of them. To do this, run:

git fetch --all --prune

Beginning of Step 5:

5. Now you have the latest fork on your GitHub account, it's time to download it onto your dev machine. For this, you can run the following commands in your terminal:

git fetch --all --prune   # pull all branches from GitHub
...

It seems like the original intent of Steps 4 and 5 is to demonstrate the two ways you can sync your fork with the ExecuTorch upstream (from GitHub, or from your terminal).

IMO though, I think the part about syncing from the GitHub UI can be removed entirely. If someone is onboarding as a contributor, the more common workflow will be syncing from the terminal. I think it would be clearer to explain how to sync from the terminal, and then mention at the end that it's also possible to sync an individual branch from the GitHub UI, i.e. if you're comparing code in the browser.

[lucylq]

Thanks for the detailed explanation! I didn't realize it was duplicated in step 5, that makes sense.

[lucylq]

Btw, feel free to publish and merge.

[nicholsonjf]

Thanks @lucylq. I published the PR, but some checks failed so I don't think I can merge? Let me know what you recommend to resolve those, or if it's not needed because this is just a documentation change. Also it looks like @mergennachin is marked as an approver so I'm assuming I need to to wait for their approval.

[lucylq]

Hi @nicholsonjf this is a docs change and shouldn't cause these test failures - I think they're all pre-existing. hud shows the current status of the executorch tests on main.

The 'approver/owner' tags are not merge-blocking, so the team can approve and unblock land. This PR meets merge requirements (you can click the 'squash and merge' button) but also feel free to wait for Mergen's review.

[nicholsonjf]

Thanks @lucylq just merged

[lucylq]

Nice, thanks