Repository: pytorch/executorch
Pull request #9977: New Contributor Guide documentation for newcomers to ExecuTorch or open-source
Author: login: jhelsby
Labels: name: CLA Signed
description: This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
name: topic: not user facing
name: community: contribution
description: PRs coming from community (excluding hardware partners)
Created: 2025-04-08T20:09:21Z | Merged: 2025-04-11T00:13:26Z

### Summary

New Contributor Guide for people new to ExecuTorch, GitHub and/or open-source. Submitting PR as requested in the #executorch-just-works Discord channel.

**Note:** May need to confirm the `github-action` `release notes` label point discussed in the guide - I don't have permission to assign labels, but this may be a permissions issue rather than intentional.

#### Todos For Later

As discussed in the comments, we'd like to make the following additions to this guide over time (not in this PR):

* Build Instructions: Since the build process is not detailed here, consider providing a brief overview or common pitfalls users might encounter. This could reduce the number of questions on your Discord server.

* Review Process: Clarify the expected timeline for reviews and what contributors should do if they don't receive feedback within a certain period.

* Common Issues: Consider adding a FAQ or common troubleshooting section for issues that new contributors frequently encounter.
  * Draft FAQ intro text:
    ```
    ## FAQ
    
    Some answers to some frequently asked questions are given below. If you still can't find what you're looking for, please feel free to:
    * ask on our [Discord Server](https://discord.com/invite/Dh43CKSAdc).
    * search or post on our [GitHub Discussions forum](https://github.com/pytorch/executorch/discussions).
    
    [Insert actual FAQ questions and answers here.]
    ```


Diff:
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 82076c2727d..957772b3c5c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -103,6 +103,8 @@ executorch
 ## Contributing workflow
 We actively welcome your pull requests (PRs).
 
+If you're completely new to open-source projects, GitHub, or ExecuTorch, please see our [New Contributor Guide](./docs/source/new-contributor-guide.md) for a step-by-step walkthrough on making your first contribution. Otherwise, read on.
+
 1. [Claim an issue](#claiming-issues), if present, before starting work. If an
    issue doesn't cover the work you plan to do, consider creating one to provide
    context about it, and to build consensus about the scope and solution.
diff --git a/docs/source/_static/img/new-contributor-guide/ci1.png b/docs/source/_static/img/new-contributor-guide/ci1.png
new file mode 100644
index 00000000000..ba26f572913
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/ci1.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/cla1.png b/docs/source/_static/img/new-contributor-guide/cla1.png
new file mode 100644
index 00000000000..0e9918bd542
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/cla1.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/cla2.png b/docs/source/_static/img/new-contributor-guide/cla2.png
new file mode 100644
index 00000000000..e62d90b46fd
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/cla2.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/end_of_draft_pr1.png b/docs/source/_static/img/new-contributor-guide/end_of_draft_pr1.png
new file mode 100644
index 00000000000..4bd8d085a9f
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/end_of_draft_pr1.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/end_of_draft_pr2.png b/docs/source/_static/img/new-contributor-guide/end_of_draft_pr2.png
new file mode 100644
index 00000000000..0de46229b22
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/end_of_draft_pr2.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/good_first_issues.png b/docs/source/_static/img/new-contributor-guide/good_first_issues.png
new file mode 100644
index 00000000000..0c3a0564678
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/good_first_issues.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_clone.png b/docs/source/_static/img/new-contributor-guide/how_to_clone.png
new file mode 100644
index 00000000000..6a8ba7e9a35
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_clone.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_draft_pr1.png b/docs/source/_static/img/new-contributor-guide/how_to_draft_pr1.png
new file mode 100644
index 00000000000..b92a7016d52
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_draft_pr1.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_draft_pr2.png b/docs/source/_static/img/new-contributor-guide/how_to_draft_pr2.png
new file mode 100644
index 00000000000..46110ba7886
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_draft_pr2.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_draft_pr3.png b/docs/source/_static/img/new-contributor-guide/how_to_draft_pr3.png
new file mode 100644
index 00000000000..ca5bb03436c
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_draft_pr3.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_fork1.png b/docs/source/_static/img/new-contributor-guide/how_to_fork1.png
new file mode 100644
index 00000000000..c8f56d5a841
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_fork1.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_fork2.png b/docs/source/_static/img/new-contributor-guide/how_to_fork2.png
new file mode 100644
index 00000000000..ea4b2e9dfa2
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_fork2.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_pr1.png b/docs/source/_static/img/new-contributor-guide/how_to_pr1.png
new file mode 100644
index 00000000000..454c86a6a02
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_pr1.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_pr2.png b/docs/source/_static/img/new-contributor-guide/how_to_pr2.png
new file mode 100644
index 00000000000..b3eb7900e81
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_pr2.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/how_to_pr3.png b/docs/source/_static/img/new-contributor-guide/how_to_pr3.png
new file mode 100644
index 00000000000..6c5037f78f4
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/how_to_pr3.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/release_notes.png b/docs/source/_static/img/new-contributor-guide/release_notes.png
new file mode 100644
index 00000000000..8f5d34cf03d
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/release_notes.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/synced_fork.png b/docs/source/_static/img/new-contributor-guide/synced_fork.png
new file mode 100644
index 00000000000..a2ba263df84
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/synced_fork.png differ
diff --git a/docs/source/_static/img/new-contributor-guide/unsynced_fork.png b/docs/source/_static/img/new-contributor-guide/unsynced_fork.png
new file mode 100644
index 00000000000..916b08424d5
Binary files /dev/null and b/docs/source/_static/img/new-contributor-guide/unsynced_fork.png differ
diff --git a/docs/source/new-contributor-guide.md b/docs/source/new-contributor-guide.md
new file mode 100644
index 00000000000..562db57d981
--- /dev/null
+++ b/docs/source/new-contributor-guide.md
@@ -0,0 +1,276 @@
+# New Contributor Guide
+
+Welcome to **ExecuTorch** — a runtime for efficient deployment of PyTorch AI models to edge devices, including mobile phones, wearables, and embedded systems. ExecuTorch is proudly open-source and welcomes contributions from developers of all backgrounds.
+
+If you're new to ExecuTorch, open-source projects, or GitHub, this guide is for you. We're excited to have you on board!
+
+If you have any questions, issues, comments, or just want to say hello to our community, please feel free to introduce yourselves on our **[Discord Server](https://discord.com/invite/Dh43CKSAdc)**. We'd love to speak with you.
+
+---
+
+## 🔑 Prerequisites
+
+### Git
+
+This guide assumes a basic knowledge of Git, and how to run Git commands in your terminal. If you've never used Git before, you can read [this quick guide](https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/), [git guide](https://rogerdudler.github.io/git-guide/), [cheat sheet](https://towardsdatascience.com/git-commands-cheat-sheet-software-developer-54f6aedc1c46/), the [Setup Git](https://docs.github.com/en/get-started/git-basics/set-up-git) page from GitHub’s documentation, or watch one of the many tutorials on YouTube.
+
+Git is a powerful version control system for coding projects — it enables you to collaborate, record code changes, and avoid losing hours of work when you make a mistake. It is essential for projects like ExecuTorch with large codebases and many collaborators. Without it, the complexity of tracking everyone's changes, reviewing their code, and identifying bugs, quickly becomes unmanageable.
+
+Git is an industry standard in the coding world, and particularly in open-source. It can take a while to get used to at first, but we promise you it's well worth the effort! We believe that learning Git can make you a significantly stronger and more effective developer.
+
+### A GitHub Account
+
+We also assume that you have a GitHub account. If you don't, please [register here](https://github.com/signup), [verify your email address](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/verifying-your-email-address#verifying-your-email-address) (required for the steps below to work!), then [login](https://github.com/login) to your new account before proceeding further.
+
+---
+
+## 🧑‍💻 Your First Contribution
+
+The first step towards making a contribution is finding something you want to work on. If you're new to ExecuTorch or the wider world of open-source, it might seem hard to know where to start.
+
+To help you out with this, we've gathered together some beginner-friendly suggestions.  These are self-contained pieces of work — "issues" in GitHub parlance — specifically designed to help people new to ExecuTorch get started contributing code. We call these "good first issues", and you can view all of them here: [New Contributors Projects and Issues](https://github.com/orgs/pytorch/projects/102/views/1).
+
+Here's what the list looks like at the time of writing — you can see that they all have a purple `good first issue` label in the right-hand column:
+
+![](./_static/img/new-contributor-guide/good_first_issues.png)
+
+Please check it out and see if anything interests you! New issues are added to this list all the time.
+
+Once you've found an issue you like the look of, read our [Contribution Guide](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md). This comprehensive manual will help you:
+* build ExecuTorch on your machine.
+* understand the structure of the ExecuTorch codebase.
+* format, test, and document your code according to ExecuTorch best practices.
+* and finally, submit your code for review, so it can be polished, approved, and merged into the main codebase.
+
+If that seems like a lot of information, please read on — we'll walk you through your first contribution right now.
+
+---
+
+## 📤 Contributing Code, Step-By-Step
+
+### Prepare Your Workspace
+
+Before you can start writing any code, you need to get a copy of ExecuTorch codebase onto your GitHub account, and download it onto your dev machine. You'll want to build it, too — otherwise, you won't be able to test your solution.
+
+1. Fork the main ExecuTorch repository into your GitHub account. This creates a clone of the repository in your own space, so you can modify it freely. To do this, visit the [main repository page](https://github.com/pytorch/executorch) and click `Fork`:
+
+    ![](./_static/img/new-contributor-guide/how_to_fork1.png)
+
+    This will take you to another page. Click `Create fork`:
+
+    ![](./_static/img/new-contributor-guide/how_to_fork2.png)
+
+2. Clone your fork locally. This downloads a copy of your fork onto your dev machine, ready for you to make your changes.
+
+    In the example below, we clone using HTTP, but any of the provided methods on the `Local` tab are fine. For HTTP, copy the URL given here:
+
+    ![](./_static/img/new-contributor-guide/how_to_clone.png)
+
+    Then go to your terminal, enter the directory you want to clone the fork to, and run:
+
+    ```bash
+    git clone https://github.com/pytorch/executorch.git
+    ```
+
+    This will create an `executorch` folder in your directory containing your forked codebase.
+
+3.  Set the `upstream` pointing to the main ExecuTorch repository. This will allow you to easily synchronize with the latest development.
+
+    Assuming you're in the same directory you cloned into, run:
+
+    ```bash
+    cd executorch # enter the cloned project
+    git remote add upstream https://github.com/pytorch/executorch.git
+    ```
+
+    To see if it worked, run:
+
+    ```bash
+    git remote -v
+    ```
+
+    Depending on how you cloned your repo (HTTP, SSH, etc.), this should print something like:
+
+    ```bash
+    origin  https://github.com/YOUR_GITHUB_USERNAME/executorch.git (fetch)
+    origin  https://github.com/YOUR_GITHUB_USERNAME/executorch.git (push)
+    upstream        https://github.com/pytorch/executorch.git (fetch)
+    upstream        https://github.com/pytorch/executorch.git (push)
+    ```
+
+    What does this mean? Well:
+
+      * The `origin` entries show your forked GitHub repository. They tell you that when you run `git pull` or `git push`, your changes will go from/to your GitHub fork.
+
+      * The `upstream` entries show the main ExecuTorch repository. If you want to sync the latest changes from there, you can run `git fetch upstream`.
+
+    Let's sync from both your fork _and_ the main ExecuTorch branch, getting the latest changes from each of them. To do this, run:
+
+    ```bash
+    git fetch --all --prune
+    ```
+
+4. If you just cloned your fork, your GitHub repository will tell you your branch is up-to-date:
+
+    ![](./_static/img/new-contributor-guide/synced_fork.png)
+
+    However, ExecuTorch updates frequently — if it's been a while you visited your fork, you might not have the latest version anymore. It's important to keep your fork as up-to-date as possible. Otherwise, the code changes you're making might fix your issue for an old version of the codebase, but _not_ fix it for the current version.
+
+    GitHub will tell you if your fork is out-of-date. To synchronise the necessary changes, click `Sync fork`, then `Update branch` as shown:
+
+    ![](./_static/img/new-contributor-guide/unsynced_fork.png)
+
+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:
+
+    ```bash
+    git fetch --all --prune   # pull all branches from GitHub
+    git checkout main         # enter your local main branch
+    git merge upstream/main   # merge latest state from GitHub parent repo
+    git push                  # push updated local main to your GitHub fork
+    ```
+
+6. [Build the project](https://pytorch.org/executorch/main/using-executorch-building-from-source.html) and [run the tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing).
+
+    Unfortunately, this step is too long to detail here. If you get stuck at any point, please feel free to ask for help on our [Discord server](https://discord.com/invite/Dh43CKSAdc) — we're always eager to help newcomers get onboarded.
+
+One final note before we finish this section. It's very important to get your tests running at this stage, for two reasons:
+
+* If they work, it's a great sign that you've got things set up correctly.
+
+* As we'll discuss later, you'll want to run the tests _after_ making your changes to ensure you haven't broken existing functionality. Running them _before_ making your changes gives you a baseline you can compare with later test results.
+
+### Implement your changes
+
+Great job — you're all set up. Now you can actually start coding!
+
+1. Before making any changes, we recommend creating a new branch. To do this, just run:
+    ```bash
+    git checkout -b YOUR_NEW_BRANCH_NAME
+    ```
+
+    You can follow this naming convention: `type/<short-name>`, where the types are: `bugfix`, `feature`, `docs`, `tests`, etc. — or use something similarly descriptive. By way of example, here are a few branch names that were actually merged to ExecuTorch:
+
+    * [bugfix/op_eq](https://github.com/pytorch/executorch/pull/9794)
+
+    * [error-handling-log-intermediate-output-delegate](https://github.com/pytorch/executorch/pull/9759)
+
+    * [add-datasink-try-before-set-tests](https://github.com/pytorch/executorch/pull/9762)
+
+    Creating a new branch means that any changes you make will be isolated to your branch, allowing you to work on multiple issues in parallel. It also means that, if your fork gets behind the main repository and you have to synchronise, you won't need to deal with any merge conflicts — accidentally blocking your `main` branch can be very time-consuming.
+
+2. Make your changes. For bugfixes, we recommend a test-driven workflow:
+    - Find a test case that demonstrates your bug.
+    - Verify that your new test case fails on the `main` branch.
+    - Add that example as an automated test, and assert the expected failing results. If you can, try to make this test as minimal as possible to reduce interference with some other issue.
+
+    Once you have a failing test, you can keep working on the issue and running the test until it passes.
+
+    **Note:** Even if you do not find the solution, sending a PR with a test covering the issue is a valid contribution. From this point, we can help you find the solution, or even finish it with you.
+
+3. After every set of edits, checkpoint and commit your code changes with a "commit" message that describes the changes you made. For example, in terminal:
+
+    ```bash
+    git add my_changed_file1 my_new_test_case # Pick the files you changed
+    git commit -m "Fixed bug X and added a passing test case" # Describe your change
+    ```
+
+    Try to make your commit messages as descriptive as possible. This helps to maintain a clear project history. Not only will this help your own development, but it will make your code vastly easier for other developers to review and maintain.
+
+    Here are some example commit messages that were merged to ExecuTorch:
+
+    * [Delete examples/demo-apps/apple_ios/ExecuTorchDemo directory](https://github.com/pytorch/executorch/pull/9991/commits/df2f451e5e8fc217231975d7a0065a8cc36709cb)
+    * [[ET-VK][ez] Allow logit linear layer to be lowered to Vulkan](https://github.com/pytorch/executorch/pull/9951/commits/3fdd8cab8c58db0be666f3454c41f73ad5964743)
+    * [Allow emitting mutable buffer names in schema](https://github.com/pytorch/executorch/pull/9935/commits/773a34725afea6c0bf1b99d02a9cefb91c4960e1)
+
+4. When you are done making changes and the test case you added is passing, [run the same tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing) you ran earlier (at the end of the [Prepare Your Workspace](#prepare-your-workspace) section).
+
+    If any tests fail now which were working before, it means your changes have broken some existing functionality. You'll need to dig back into your code to figure out what's gone wrong.
+
+5. Once your new test _and_ the old tests are all working as intended, upload/push these changes to your fork:
+
+    ```bash
+    # Make sure you've committed all your changes first, then run:
+    git push
+    ```
+
+### Submit a PR
+
+Once you've successfully finished local development, it's time to send out your pull request. This is the final phase — here, we'll help you finetune your changes to get merged into the main repository.
+
+1. After pushing your last edit to remote, your GitHub fork will show your new changed branch — click `Compare & pull request`:
+
+    ![](./_static/img/new-contributor-guide/how_to_pr1.png)
+
+    Alternatively, you can click the same `Compare & pull request` button on the main ExecuTorch repo:
+
+    ![](./_static/img/new-contributor-guide/how_to_pr2.png)
+
+    Another way still is via the `Pull request` tab on the main repo — we won't go into that here though, as it takes a few more steps.
+
+2. This will take you to a page where you can format your PR and explain your changes. You'll see all the required details in our PR template. You should choose a title describing the proposed fix and fill in all the required details.
+
+    ![](./_static/img/new-contributor-guide/how_to_pr3.png)
+
+    In the description, you’ll describe all the changes you’ve made.
+
+3. If you want to submit your PR right away, you can go ahead and click the Green `Create pull request` button. However, please note that this will immediately notify all reviewers. We strongly recommend creating a Draft PR first. This will allow you to perform some extra checks first:
+
+    * You can get some early feedback on your PR without notifying everybody.
+
+    * It prevents anyone from accidentally merging your unfinished PR.
+
+    * Creating it will start CI (["Continuous Integration"](https://en.wikipedia.org/wiki/Continuous_integration)) checks to verify that all tests pass under various configurations. If some tests fail, you can fix them before creating the final PR.
+
+    To do submit a draft, click the arrow next to the `Create Pull Request` button, then click `Create draft pull request` in the dropdown menu:
+
+    ![](./_static/img/new-contributor-guide/how_to_draft_pr1.png)
+
+    This will change the green button's text to `Draft pull request`:
+
+    ![](./_static/img/new-contributor-guide/how_to_draft_pr2.png)
+
+    Click it to create your draft PR.
+
+4. This will take you to your Draft PR page. It might look something like this:
+
+    ![](./_static/img/new-contributor-guide/how_to_draft_pr3.png)
+
+    As you scroll down, you might see a number of comments and automated checks, some of which may come with alarming red warning signs and the word "Failure"! There's no need to panic, though — they are here to help. Let's go through some common checks one-by-one.
+
+    * The `pytorch-bot` will probably be the first comment. It runs regular CI checks. When your PR is passing, this comment will automatically update to let you know.
+
+      ![](./_static/img/new-contributor-guide/ci1.png)
+
+    * If this is your very first contribution to a Meta Open Source project, and you've not signed Meta's contributor license agreement (CLA), you may have a comment like this from `facebook-github-bot`:
+
+        ![](./_static/img/new-contributor-guide/cla1.png)
+
+        You will need to sign the linked CLA to contribute your code. Once your signature has been processed, the bot will let you know in another comment:
+
+        ![](./_static/img/new-contributor-guide/cla2.png)
+
+    * You may see a comment from `github-actions` requesting a "release notes" label:
+
+        ![](./_static/img/new-contributor-guide/release_notes.png)
+
+        Please ignore this message. It's directed at the ExecuTorch maintainers — they'll label your PR for you.
+
+    * At the end of your Draft PR, you'll see something like this:
+
+        ![](./_static/img/new-contributor-guide/end_of_draft_pr1.png)
+
+        This is a summary of all the CI checks and requirements which need to be satisfied before your PR can be merged. Ensure that all tests are passing. If not, click on a failing test to see what went wrong and make the required changes.
+
+        Once you're happy with your draft, you can click the `Ready for review` button to create your PR:
+
+        ![](./_static/img/new-contributor-guide/end_of_draft_pr2.png)
+
+5. Now you've created your PR, it's time for your changes to be reviewed by the ExecuTorch community and maintainers.
+
+    You'll need approval from one of our core contributors for your request to be merged. They may have questions or suggestions for you to address or respond to. Be aware that the review process may take a couple of iterations... Nevertheless, we hope that you'll find this feedback helpful. Code reviews can be a fantastic way to learn more about ExecuTorch and coding best practices from other contributors.
+
+    Those reviewers/maintainers are here to finetune your contribution and eventually catch some issues before we merge the PR. We aim for this process to be pleasing on both sides: we try to give and get the best.
+
+    Once the reviewers are happy, one of our core contributors will merge your PR. Congratulations — you're now an official ExecuTorch contributor!
+
+Great job making it to the end of our guide — we hope you enjoy contributing. Once again, please check out **[Discord Server](https://discord.com/invite/Dh43CKSAdc)** if you want to say hello, ask any questions, or talk about any and all things ExecuTorch. We look forward to receiving your contributions!


Reviews:
user: login: larryliu0820
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T16:35:14Z
user: login: larryliu0820
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T16:35:40Z
user: login: GregoryComer
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-04-09T16:56:28Z
user: login: jhelsby
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T16:57:00Z
user: login: jhelsby
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T16:58:19Z
user: login: GregoryComer
body: @jhelsby Thanks for writing this up. It looks great.
state: APPROVED
author_association: MEMBER
submitted_at: 2025-04-09T17:00:58Z
user: login: jhelsby
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T21:07:14Z
user: login: jhelsby
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-10T18:55:34Z
user: login: jhelsby
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-10T18:55:38Z
user: login: byjlw
body: Looks great! This will help new folks a lot 
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T00:13:10Z
user: login: jhelsby
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T05:48:30Z

Review comments:
path: docs/source/_static/img/onboarding/how_to_clone.png
user: login: larryliu0820
body: Nit: can you add a red circle or a cursor on "<> Code" button to show that you clicked that one
created_at: 2025-04-09T16:35:13Z
author_association: CONTRIBUTOR
path: docs/source/_static/img/onboarding/how_to_fork1.png
user: login: larryliu0820
body: Same here :)
created_at: 2025-04-09T16:35:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,149 @@
+# ExecuTorch – Open-Source Onboarding Guide
+
+Welcome to **ExecuTorch** — a runtime for efficient deployment of PyTorch AI models to edge devices, including mobile phones, wearables, and embedded systems. ExecuTorch is proudly open-source and welcomes contributions from developers of all backgrounds.
+
+If you're new to ExecuTorch, open-source projects, or GitHub, this guide is for you. We're excited to have you on board!
+
+---
+
+## 🔑 Prerequisites
+
+This guide assumes a basic knowledge of Git, and how to run Git commands in your terminal.
+
+If you've never used Git before, you can read [this quick guide](https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/), [git guide](https://rogerdudler.github.io/git-guide/), [cheat sheet](https://towardsdatascience.com/git-commands-cheat-sheet-software-developer-54f6aedc1c46/), the [Setup Git](https://docs.github.com/en/get-started/git-basics/set-up-git) page from GitHub’s documentation, or watch one of the many tutorials on YouTube. Git is a powerful version control system for large coding projects - it enables you to collaborate, record code changes, and avoid losing hours of work when you make a mistake.
+
+We also assume that you have a GitHub account. If you don't, please [register here](https://github.com/signup) and log in before proceeding further.
+
+---
+
+## 🧑‍💻 Your First Contribution
+
+The first step towards making a contribution is finding something you want to work on. If you're new to the world of open-source, it might seem hard to know where to start. To help you out with this, we've collated together many beginner-friendly "good first issues" here: [New Contributors Projects and Issues](https://github.com/orgs/pytorch/projects/102/views/1). Have a look and see if anything interests you — new issues are added to this list all the time.
+
+Once you've found an issue you like the look of, read our [Contribution Guide](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md). This comprehensive manual will help you:
+* build ExecuTorch on your machine.
+* understand the structure of the wider codebase.
+* format, test, and document your code according to ExecuTorch best practices.
+* and finally, submit your code for review, so it can be polished, approved, and merged into the main codebase.
+
+If that seems like a lot of information, please read on — we'll walk you through your first contribution right now.
+
+---
+
+## 📤 Contributing Code, Step-By-Step
+
+### Prepare Your Workspace
+
+Before you can start writing any code, you need to get a copy of ExecuTorch codebase onto your GitHub account, and download it onto your dev machine. You'll want to build it, too — otherwise, you won't be able to test your solution.
+
+1. Fork the main ExecuTorch repository into your GitHub account. This creates a clone of the repository in your own space, so you can modify it freely. To do this, visit the [main repository page](https://github.com/pytorch/executorch) and click `Fork`:
+
+    ![](./_static/img/onboarding/how_to_fork1.png)
+
+    This will take you to another page - click `Create fork`:
+
+    ![](./how_to_fork2.png)
+
+2. Clone your fork locally, and set the `upstream` pointing to the main ExecuTorch repository, so you can easily synchronize anytime with the latest development.
+
+    In the example below, we use HTTP, but any of the provided methods on the `Local` tab are fine. For HTTP, copy the URL given here:
+
+    ![](./_static/img/onboarding/how_to_clone.png)
+
+    Then go to your terminal, enter the directory you want to clone the fork to, and run:
+
+    ```bash
+    git clone https://github.com/pytorch/executorch.git
+    cd executorch            # enter the cloned project
+    git remote add upstream https://github.com/pytorch/executorch.git
+    git remote -v            # to see what you are pointing at...
+    git fetch --all --prune  # pull all branches and tags
+    ```
+
+4. If you just cloned your fork, your GitHub repository will tell you your branch is up-to-date:
+
+    ![](./_static/img/onboarding/synced_fork.png)
+
+    However, ExecuTorch updates frequently - if it's been a while you visited your fork, you might not have the latest version anymore. GitHub will tell you if your fork is out-of-date. To synchronise the necessary changes, click `Sync fork`, then `Update branch` as shown:
+
+    ![](./_static/img/onboarding/unsynced_fork.png)
+
+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:
+
+    ```bash
+    git fetch --all --prune   # pull all branches from GitHub
+    git checkout main         # enter your local main branch
+    git merge upstream/main   # merge latest state from GitHub parent repo
+    git push                  # push updated local main to your GitHub fork
+    ```
+
+6. [Build the project](https://pytorch.org/executorch/main/using-executorch-building-from-source.html) and [run the tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing).
+
+    Unfortunately, this step is too long to detail here. If you get stuck at any point, please feel free to ask for help on our [Discord server](https://discord.com/invite/Dh43CKSAdc) — we're always eager to help newcomers get onboarded.
+
+### Implement your changes
+
+Great job — you're all set up. Now you can actually start coding!
+
+1. Before making any changes, we recommend creating a new branch. To do this, just run:
+    ```bash
+    git checkout -b YOUR_NEW_BRANCH_NAME
+    ```
+
+    You can follow this naming convention: `<type>/<issue-id>_<short-name>`, where the types are: `bugfix`, `feature`, `docs`, `tests`, etc.
+
+    Creating a new branch means that any changes you make will be isolated to your branch, allowing you to work on multiple issues in parallel. It also means that, if your fork gets behind the main repository and you have to synchronise, you won't need to deal with any merge conflicts — accidentally blocking your `main` branch can be very time-consuming.
+
+2. Make your changes. For bugfixes, we recommend a test-driven workflow:
+    - Find a test case that demonstrates your bug.
+    - Verify that your new test case fails on the `main` branch.
+    - Add that example as an automated test, and assert the expected, failing results. If you can, try to make this test as minimal as possible to reduce interference with some other issue.
+
+    Once you have a failing test, you can keep working on the issue and running the test until it passes.
+
+    **Note:** Even if you do not find the solution, sending a PR with a test covering the issue is a valid contribution. From this point, we can help you find the solution, or even finish it with you.
+
+3. After every set of edits, checkpoint and commit your code changes with a "commit" message that describes the changes you made. For example, in terminal:
+
+    ```bash
+    git add my_changed_file1 my_new_test_case # Pick the files you changed
+    git commit -m "Fixed bug X and added a passing test case" # Describe your change
+    ```
+
+4. When you are done making changes and the test case you added is passing, upload/push these changes to your fork:
+
+    ```bash
+    # Make sure you've committed all your changes first, then run:
+    git push
+    ```
+
+### Submit a PR
+
+Once you've successfully finished local development, it's time to send out your pull request. This is the final phase — here, we'll help you finetune your changes to get merged into the main repository.
+
+1. After pushing your last edit to remote, your GitHub fork will show your new changed branch — click `Compare & pull request`:
+
+    ![](./_static/img/onboarding/how_to_pr1.png)
+
+    Alternatively, you can click the same `Compare & pull request` button on the main ExecuTorch repo:
+
+    ![](./_static/img/onboarding/how_to_pr2.png)
+
+    Another way still is via the `Pull request` tab on the main repo — we won't go into that here though, as it takes a few more steps.
+
+2. This will take you to a page where you can format your PR and explain your changes. You'll see all the required details in our PR template. You should choose a title describing the proposed fix and fill in all the required details.
+
+    ![](./_static/img/onboarding/how_to_pr3.png)
+
+    In the description, you’ll describe all the changes you’ve made.
+
+    Ensure that all tests are passing. If not, click on a failing test to see what went wrong and make the required changes.
+
+3. If everything looks good and you are ready for review, click the `Create Pull Request` button. We recommend starting with a draft PR, which will start CI (["Continuous Integration"](https://en.wikipedia.org/wiki/Continuous_integration)) to verify that all tests pass under various configurations before you notify all reviewers and get the first rounds of comments.
+
+    You'll need approval from 3 of our core contributors for your request to be merged. They may have questions or suggestions for you to address or respond to. Be aware that the review process may take a couple of iterations... Nevertheless, this feedback can be helpful for you as you learn more about ExecuTorch or coding best practices from other contributors.
path: docs/source/onboarding.md
user: login: GregoryComer
body: @byjlw Do we have guidance on number of reviewers? We've largely been operating on 1 review being sufficient.
created_at: 2025-04-09T16:56:28Z
author_association: MEMBER
path: docs/source/_static/img/onboarding/how_to_clone.png
user: login: jhelsby
body: Hi Larry, many thanks for reviewing. Yes, definitely, thank you!

As I mentioned in the PR description, none of the images have been annotated yet - I wanted to seek opinions on an initial draft first. In the next revision I will annotate all the images.
created_at: 2025-04-09T16:57:00Z
author_association: CONTRIBUTOR
path: docs/source/_static/img/onboarding/how_to_fork1.png
user: login: jhelsby
body: Hi Larry, many thanks for reviewing. Yes, definitely, thank you!

As I mentioned in the PR description, none of the images have been annotated yet - I wanted to seek opinions on an initial draft first. In the next revision I will annotate all the images.
created_at: 2025-04-09T16:58:19Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,149 @@
+# ExecuTorch – Open-Source Onboarding Guide
+
+Welcome to **ExecuTorch** — a runtime for efficient deployment of PyTorch AI models to edge devices, including mobile phones, wearables, and embedded systems. ExecuTorch is proudly open-source and welcomes contributions from developers of all backgrounds.
+
+If you're new to ExecuTorch, open-source projects, or GitHub, this guide is for you. We're excited to have you on board!
+
+---
+
+## 🔑 Prerequisites
+
+This guide assumes a basic knowledge of Git, and how to run Git commands in your terminal.
+
+If you've never used Git before, you can read [this quick guide](https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/), [git guide](https://rogerdudler.github.io/git-guide/), [cheat sheet](https://towardsdatascience.com/git-commands-cheat-sheet-software-developer-54f6aedc1c46/), the [Setup Git](https://docs.github.com/en/get-started/git-basics/set-up-git) page from GitHub’s documentation, or watch one of the many tutorials on YouTube. Git is a powerful version control system for large coding projects - it enables you to collaborate, record code changes, and avoid losing hours of work when you make a mistake.
+
+We also assume that you have a GitHub account. If you don't, please [register here](https://github.com/signup) and log in before proceeding further.
+
+---
+
+## 🧑‍💻 Your First Contribution
+
+The first step towards making a contribution is finding something you want to work on. If you're new to the world of open-source, it might seem hard to know where to start. To help you out with this, we've collated together many beginner-friendly "good first issues" here: [New Contributors Projects and Issues](https://github.com/orgs/pytorch/projects/102/views/1). Have a look and see if anything interests you — new issues are added to this list all the time.
+
+Once you've found an issue you like the look of, read our [Contribution Guide](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md). This comprehensive manual will help you:
+* build ExecuTorch on your machine.
+* understand the structure of the wider codebase.
+* format, test, and document your code according to ExecuTorch best practices.
+* and finally, submit your code for review, so it can be polished, approved, and merged into the main codebase.
+
+If that seems like a lot of information, please read on — we'll walk you through your first contribution right now.
+
+---
+
+## 📤 Contributing Code, Step-By-Step
+
+### Prepare Your Workspace
+
+Before you can start writing any code, you need to get a copy of ExecuTorch codebase onto your GitHub account, and download it onto your dev machine. You'll want to build it, too — otherwise, you won't be able to test your solution.
+
+1. Fork the main ExecuTorch repository into your GitHub account. This creates a clone of the repository in your own space, so you can modify it freely. To do this, visit the [main repository page](https://github.com/pytorch/executorch) and click `Fork`:
+
+    ![](./_static/img/onboarding/how_to_fork1.png)
+
+    This will take you to another page - click `Create fork`:
+
+    ![](./how_to_fork2.png)
+
+2. Clone your fork locally, and set the `upstream` pointing to the main ExecuTorch repository, so you can easily synchronize anytime with the latest development.
+
+    In the example below, we use HTTP, but any of the provided methods on the `Local` tab are fine. For HTTP, copy the URL given here:
+
+    ![](./_static/img/onboarding/how_to_clone.png)
+
+    Then go to your terminal, enter the directory you want to clone the fork to, and run:
+
+    ```bash
+    git clone https://github.com/pytorch/executorch.git
+    cd executorch            # enter the cloned project
+    git remote add upstream https://github.com/pytorch/executorch.git
+    git remote -v            # to see what you are pointing at...
+    git fetch --all --prune  # pull all branches and tags
+    ```
+
+4. If you just cloned your fork, your GitHub repository will tell you your branch is up-to-date:
+
+    ![](./_static/img/onboarding/synced_fork.png)
+
+    However, ExecuTorch updates frequently - if it's been a while you visited your fork, you might not have the latest version anymore. GitHub will tell you if your fork is out-of-date. To synchronise the necessary changes, click `Sync fork`, then `Update branch` as shown:
+
+    ![](./_static/img/onboarding/unsynced_fork.png)
+
+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:
+
+    ```bash
+    git fetch --all --prune   # pull all branches from GitHub
+    git checkout main         # enter your local main branch
+    git merge upstream/main   # merge latest state from GitHub parent repo
+    git push                  # push updated local main to your GitHub fork
+    ```
+
+6. [Build the project](https://pytorch.org/executorch/main/using-executorch-building-from-source.html) and [run the tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing).
+
+    Unfortunately, this step is too long to detail here. If you get stuck at any point, please feel free to ask for help on our [Discord server](https://discord.com/invite/Dh43CKSAdc) — we're always eager to help newcomers get onboarded.
+
+### Implement your changes
+
+Great job — you're all set up. Now you can actually start coding!
+
+1. Before making any changes, we recommend creating a new branch. To do this, just run:
+    ```bash
+    git checkout -b YOUR_NEW_BRANCH_NAME
+    ```
+
+    You can follow this naming convention: `<type>/<issue-id>_<short-name>`, where the types are: `bugfix`, `feature`, `docs`, `tests`, etc.
+
+    Creating a new branch means that any changes you make will be isolated to your branch, allowing you to work on multiple issues in parallel. It also means that, if your fork gets behind the main repository and you have to synchronise, you won't need to deal with any merge conflicts — accidentally blocking your `main` branch can be very time-consuming.
+
+2. Make your changes. For bugfixes, we recommend a test-driven workflow:
+    - Find a test case that demonstrates your bug.
+    - Verify that your new test case fails on the `main` branch.
+    - Add that example as an automated test, and assert the expected, failing results. If you can, try to make this test as minimal as possible to reduce interference with some other issue.
+
+    Once you have a failing test, you can keep working on the issue and running the test until it passes.
+
+    **Note:** Even if you do not find the solution, sending a PR with a test covering the issue is a valid contribution. From this point, we can help you find the solution, or even finish it with you.
+
+3. After every set of edits, checkpoint and commit your code changes with a "commit" message that describes the changes you made. For example, in terminal:
+
+    ```bash
+    git add my_changed_file1 my_new_test_case # Pick the files you changed
+    git commit -m "Fixed bug X and added a passing test case" # Describe your change
+    ```
+
+4. When you are done making changes and the test case you added is passing, upload/push these changes to your fork:
+
+    ```bash
+    # Make sure you've committed all your changes first, then run:
+    git push
+    ```
+
+### Submit a PR
+
+Once you've successfully finished local development, it's time to send out your pull request. This is the final phase — here, we'll help you finetune your changes to get merged into the main repository.
+
+1. After pushing your last edit to remote, your GitHub fork will show your new changed branch — click `Compare & pull request`:
+
+    ![](./_static/img/onboarding/how_to_pr1.png)
+
+    Alternatively, you can click the same `Compare & pull request` button on the main ExecuTorch repo:
+
+    ![](./_static/img/onboarding/how_to_pr2.png)
+
+    Another way still is via the `Pull request` tab on the main repo — we won't go into that here though, as it takes a few more steps.
+
+2. This will take you to a page where you can format your PR and explain your changes. You'll see all the required details in our PR template. You should choose a title describing the proposed fix and fill in all the required details.
+
+    ![](./_static/img/onboarding/how_to_pr3.png)
+
+    In the description, you’ll describe all the changes you’ve made.
+
+    Ensure that all tests are passing. If not, click on a failing test to see what went wrong and make the required changes.
+
+3. If everything looks good and you are ready for review, click the `Create Pull Request` button. We recommend starting with a draft PR, which will start CI (["Continuous Integration"](https://en.wikipedia.org/wiki/Continuous_integration)) to verify that all tests pass under various configurations before you notify all reviewers and get the first rounds of comments.
+
+    You'll need approval from 3 of our core contributors for your request to be merged. They may have questions or suggestions for you to address or respond to. Be aware that the review process may take a couple of iterations... Nevertheless, this feedback can be helpful for you as you learn more about ExecuTorch or coding best practices from other contributors.
path: docs/source/onboarding.md
user: login: jhelsby
body: I've updated this in the most recent commit to 1 review. Sorry, I copypasted this from another PyTorch contributing guide byjlw@ recommended.
created_at: 2025-04-09T21:07:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,283 @@
+# ExecuTorch – Open-Source Onboarding Guide
+
+Welcome to **ExecuTorch** — a runtime for efficient deployment of PyTorch AI models to edge devices, including mobile phones, wearables, and embedded systems. ExecuTorch is proudly open-source and welcomes contributions from developers of all backgrounds.
+
+If you're new to ExecuTorch, open-source projects, or GitHub, this guide is for you. We're excited to have you on board!
+
+If you have any questions, issues comments, or just want to say hello to our community, please feel free to introduce yourselves on our **[Discord Server](https://discord.com/invite/Dh43CKSAdc)**. We'd love to speak with you.
+
+---
+
+## 🔑 Prerequisites
+
+### Git
+
+This guide assumes a basic knowledge of Git, and how to run Git commands in your terminal. If you've never used Git before, you can read [this quick guide](https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/), [git guide](https://rogerdudler.github.io/git-guide/), [cheat sheet](https://towardsdatascience.com/git-commands-cheat-sheet-software-developer-54f6aedc1c46/), the [Setup Git](https://docs.github.com/en/get-started/git-basics/set-up-git) page from GitHub’s documentation, or watch one of the many tutorials on YouTube.
+
+Git is a powerful version control system for coding projects — it enables you to collaborate, record code changes, and avoid losing hours of work when you make a mistake. It is essential for projects like ExecuTorch, with large codebases and many collaborators. Without it, the complexity of tracking everyone's changes, reviewing their code, and identifying bugs quickly becomes unmanageable.
+
+Git is an industry standard in the coding world, and particularly in open-source. It can take a while to get used to at first, but we promise you it's well worth the effort! We believe that learning Git can make you a significantly stronger and more effective developer.
+
+### A GitHub Account
+
+We also assume that you have a GitHub account. If you don't, please [register here](https://github.com/signup), [verify your email address](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/verifying-your-email-address#verifying-your-email-address) (required for the steps below to work!), then [login](https://github.com/login) to your new account before proceeding further.
+
+---
+
+## 🧑‍💻 Your First Contribution
+
+The first step towards making a contribution is finding something you want to work on. If you're new to ExecuTorch or the wider world of open-source, it might seem hard to know where to start.
+
+To help you out with this, we've gathered together some beginner-friendly suggestions.  These are self-contained pieces of work — "issues" in GitHub parlance — specifically designed to help people new to ExecuTorch get started contributing code. We call these "good first issues", and you can view all of them here: [New Contributors Projects and Issues](https://github.com/orgs/pytorch/projects/102/views/1).
+
+Here's what the list looks like at the time of writing — you can see that they all have a purple `good first issue` label in the right-hand column:
+
+![](./_static/img/onboarding/good_first_issues.png)
+
+Please check it out and see if anything interests you! New issues are added to this list all the time.
+
+Once you've found an issue you like the look of, read our [Contribution Guide](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md). This comprehensive manual will help you:
+* build ExecuTorch on your machine.
+* understand the structure of the ExecuTorch codebase.
+* format, test, and document your code according to ExecuTorch best practices.
+* and finally, submit your code for review, so it can be polished, approved, and merged into the main codebase.
+
+If that seems like a lot of information, please read on — we'll walk you through your first contribution right now.
+
+---
+
+## 📤 Contributing Code, Step-By-Step
+
+### Prepare Your Workspace
+
+Before you can start writing any code, you need to get a copy of ExecuTorch codebase onto your GitHub account, and download it onto your dev machine. You'll want to build it, too — otherwise, you won't be able to test your solution.
+
+1. Fork the main ExecuTorch repository into your GitHub account. This creates a clone of the repository in your own space, so you can modify it freely. To do this, visit the [main repository page](https://github.com/pytorch/executorch) and click `Fork`:
+
+    ![](./_static/img/onboarding/how_to_fork1.png)
+
+    This will take you to another page - click `Create fork`:
+
+    ![](./_static/img/onboarding/how_to_fork2.png)
+
+2. Clone your fork locally. This downloads a copy of your fork onto your dev machine, ready for you to make your changes.
+
+    In the example below, we clone using HTTP, but any of the provided methods on the `Local` tab are fine. For HTTP, copy the URL given here:
+
+    ![](./_static/img/onboarding/how_to_clone.png)
+
+    Then go to your terminal, enter the directory you want to clone the fork to, and run:
+
+    ```bash
+    git clone https://github.com/pytorch/executorch.git
+    ```
+
+    This will create an `executorch` folder in your directory containing your forked codebase.
+
+3.  Set the `upstream` pointing to the main ExecuTorch repository. This will allow you to easily synchronize with the latest development.
+
+    Assuming you're in the same directory you cloned into, run:
+
+    ```bash
+    cd executorch            # enter the cloned project
+    git remote add upstream https://github.com/pytorch/executorch.git
+    ```
+
+    To see if it worked, run:
+
+    ```bash
+    git remote -v
+    ```
+
+    Depending on how you cloned your repo (HTTP, SSH, etc.), this should print something like:
+
+    ```bash
+    origin  https://github.com/YOUR_GITHUB_USERNAME/executorch.git (fetch)
+    origin  https://github.com/YOUR_GITHUB_USERNAME/executorch.git (push)
+    upstream        https://github.com/pytorch/executorch.git (fetch)
+    upstream        https://github.com/pytorch/executorch.git (push)
+    ```
+
+    What does this mean? Well:
+
+      * The `origin` entries show your forked GitHub repository. They tell you that when you run `git pull` or `git push`, your changes will go from/to your GitHub fork.
+
+      * The `upstream` entries show the main ExecuTorch repository. If you want to sync the latest changes from there, you can run `git fetch upstream`.
+
+    Let's sync from both your fork _and_ the main ExecuTorch branch, to get the latest changes from each of them. To do this, run:
+
+    ```bash
+    git fetch --all --prune
+    ```
+
+4. If you just cloned your fork, your GitHub repository will tell you your branch is up-to-date:
+
+    ![](./_static/img/onboarding/synced_fork.png)
+
+    However, ExecuTorch updates frequently - if it's been a while you visited your fork, you might not have the latest version anymore. It's important to keep your fork as up-to-date as possible. Otherwise, the code changes you're making might fix your issue for an old version of the codebase, but _not_ for the current version.
+
+    GitHub will tell you if your fork is out-of-date. To synchronise the necessary changes, click `Sync fork`, then `Update branch` as shown:
+
+    ![](./_static/img/onboarding/unsynced_fork.png)
+
+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:
+
+    ```bash
+    git fetch --all --prune   # pull all branches from GitHub
+    git checkout main         # enter your local main branch
+    git merge upstream/main   # merge latest state from GitHub parent repo
+    git push                  # push updated local main to your GitHub fork
+    ```
+
+6. [Build the project](https://pytorch.org/executorch/main/using-executorch-building-from-source.html) and [run the tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing).
+
+    Unfortunately, this step is too long to detail here. If you get stuck at any point, please feel free to ask for help on our [Discord server](https://discord.com/invite/Dh43CKSAdc) — we're always eager to help newcomers get onboarded.
+
+    * TODO: add a brief overview of the build process or common pitfalls users might encounter.
+
+One final note before we finish this section. It's very important to get your tests running at this stage, for two reasons:
+
+* If they work, it's a great sign that you've got things set up correctly.
+
+* As we'll discuss later, you'll want to run the tests _after_ making your changes to ensure you haven't broken existing functionality. Running them _before_ making your changes gives you a baseline you can compare with later test results.
+
+### Implement your changes
+
+Great job — you're all set up. Now you can actually start coding!
+
+1. Before making any changes, we recommend creating a new branch. To do this, just run:
+    ```bash
+    git checkout -b YOUR_NEW_BRANCH_NAME
+    ```
+
+    You can follow this naming convention: `type/<short-name>`, where the types are: `bugfix`, `feature`, `docs`, `tests`, etc. — or use something similarly descriptive. By way of example, here are a few branch names that were actually merged to ExecuTorch:
+
+    * [bugfix/op_eq](https://github.com/pytorch/executorch/pull/9794)
+
+    * [error-handling-log-intermediate-output-delegate](https://github.com/pytorch/executorch/pull/9759)
+
+    * [add-datasink-try-before-set-tests](https://github.com/pytorch/executorch/pull/9762)
+
+    Creating a new branch means that any changes you make will be isolated to your branch, allowing you to work on multiple issues in parallel. It also means that, if your fork gets behind the main repository and you have to synchronise, you won't need to deal with any merge conflicts — accidentally blocking your `main` branch can be very time-consuming.
+
+2. Make your changes. For bugfixes, we recommend a test-driven workflow:
+    - Find a test case that demonstrates your bug.
+    - Verify that your new test case fails on the `main` branch.
+    - Add that example as an automated test, and assert the expected, failing results. If you can, try to make this test as minimal as possible to reduce interference with some other issue.
+
+    Once you have a failing test, you can keep working on the issue and running the test until it passes.
+
+    **Note:** Even if you do not find the solution, sending a PR with a test covering the issue is a valid contribution. From this point, we can help you find the solution, or even finish it with you.
+
+3. After every set of edits, checkpoint and commit your code changes with a "commit" message that describes the changes you made. For example, in terminal:
+
+    ```bash
+    git add my_changed_file1 my_new_test_case # Pick the files you changed
+    git commit -m "Fixed bug X and added a passing test case" # Describe your change
+    ```
+
+    Try to make your commit messages as descriptive as possible. This helps to maintain a clear project history. Not only will this help your own development, but it will make your code vastly easier for other developers to review and maintain.
+
+    Here are some example commit messages that were merged to ExecuTorch:
+
+    * [Delete examples/demo-apps/apple_ios/ExecuTorchDemo directory](https://github.com/pytorch/executorch/pull/9991/commits/df2f451e5e8fc217231975d7a0065a8cc36709cb)
+    * [[ET-VK][ez] Allow logit linear layer to be lowered to Vulkan](https://github.com/pytorch/executorch/pull/9951/commits/3fdd8cab8c58db0be666f3454c41f73ad5964743)
+    * [Allow emitting mutable buffer names in schema](https://github.com/pytorch/executorch/pull/9935/commits/773a34725afea6c0bf1b99d02a9cefb91c4960e1)
+
+4. When you are done making changes and the test case you added is passing, [run the same tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing) you ran at the end of the [Prepare Your Workspace](#prepare-your-workspace) section. If any fail now that were working previously, it means your changes have broken some existing functionality. You'll need to dig back into your code to figure out what's gone wrong.
+
+5. Once your new test _and_ the old tests are all working as intended, upload/push these changes to your fork:
+
+    ```bash
+    # Make sure you've committed all your changes first, then run:
+    git push
+    ```
+
+### Submit a PR
+
+Once you've successfully finished local development, it's time to send out your pull request. This is the final phase — here, we'll help you finetune your changes to get merged into the main repository.
+
+1. After pushing your last edit to remote, your GitHub fork will show your new changed branch — click `Compare & pull request`:
+
+    ![](./_static/img/onboarding/how_to_pr1.png)
+
+    Alternatively, you can click the same `Compare & pull request` button on the main ExecuTorch repo:
+
+    ![](./_static/img/onboarding/how_to_pr2.png)
+
+    Another way still is via the `Pull request` tab on the main repo — we won't go into that here though, as it takes a few more steps.
+
+2. This will take you to a page where you can format your PR and explain your changes. You'll see all the required details in our PR template. You should choose a title describing the proposed fix and fill in all the required details.
+
+    ![](./_static/img/onboarding/how_to_pr3.png)
+
+    In the description, you’ll describe all the changes you’ve made.
+
+    Ensure that all tests are passing. If not, click on a failing test to see what went wrong and make the required changes.
+
+3. If you want to submit your PR right away, you can go ahead and click the Green `Create pull request` button. However, please note that this will immediately notify all reviewers. We strongly recommend creating a Draft PR first. This will allow you to perform some extra checks first:
+
+    * You can get some early feedback on your PR without notifying everybody.
+
+    * It prevents anyone from accidentally merging your unfinished PR.
+
+    * Creating it will start CI (["Continuous Integration"](https://en.wikipedia.org/wiki/Continuous_integration)) checks to verify that all tests pass under various configurations. If some tests fail, you can fix them before creating the final PR.
+
+    To do submit a draft, click the arrow next to the `Create Pull Request` button:
+
+    ![](./_static/img/onboarding/how_to_draft_pr1.png)
+
+    Then click `Create draft pull request` in the dropdown menu. This will change the green button's text to `Draft pull request`:
+
+    ![](./_static/img/onboarding/how_to_draft_pr2.png)
+
+    Click it to create your draft PR.
+
+4. After you click the `Draft pull request` button, it will take you to your Draft PR page. It might look something like this:
+
+    ![](./_static/img/onboarding/how_to_draft_pr3.png)
+
+    As you scroll down, you might see a number of comments and automated checks, some of which may come with alarming red warning signs and the word "Failure"! There's no need to panic, though — they are here to help. Let's go through some common checks one-by-one.
+
+    * The `pytorch-bot` will probably be the first comment. It runs regular CI checks. When your PR is passing, this comment will automatically update to let you know.
+
+      ![](./_static/img/onboarding/ci1.png)
+
+    * If this is your very first contribution to a Meta Open Source project, and you've not signed Meta's contributor license agreement (CLA), you may have a comment like this from `facebook-github-bot`:
+
+        ![](./_static/img/onboarding/cla1.png)
+
+        You will need to sign the linked CLA to contribute your code. Once your signature has been processed, the bot will let you know in another comment:
+
+        ![](./_static/img/onboarding/cla2.png)
+
+    * You may see a comment from `github-actions` requesting a "release notes" label:
+
+        ![](./_static/img/onboarding/release_notes.png)
+
+        Please ignore this message. It's directed at the ExecuTorch maintainers — they'll label your PR for you.
+
+    * At the end of your Draft PR, you'll see something like this:
+
+        ![](./_static/img/onboarding/end_of_draft_pr.png)
+
+        This is a summary of all the CI checks and requirements which need to be satisfied before your PR can be merged. Once you're happy with your draft, you can click the `Ready for review` button to create your PR.
+
+5. Now you've created your PR, it's time for your changes to be reviewed by the ExecuTorch community and maintainers.
+
+    You'll need approval from one of our core contributors for your request to be merged. They may have questions or suggestions for you to address or respond to. Be aware that the review process may take a couple of iterations... Nevertheless, we hope that you'll find this feedback helpful. Code reviews can be a fantastic way to learn more about ExecuTorch and coding best practices from other contributors.
+
+    Those reviewers/maintainers are here to finetune your contribution and eventually catch some issues before we merge the PR. We aim for this process to be pleasing on both sides: we try to give and get the best.
+
+    Once the reviewers are happy, one of our core contributors will merge your PR. Congratulations — you're now an official ExecuTorch contributor!
path: docs/source/onboarding.md
user: login: byjlw
body: once their PR is approved, they should merge it in.
i.e. contributor does the merge once it's been approved. The merge button will be greyed out until it gets approved. Once that happens it's active and they can do the merge themselves. 
created_at: 2025-04-09T21:42:56Z
author_association: CONTRIBUTOR
path: docs/source/_static/img/onboarding/how_to_clone.png
user: login: jhelsby
body: All images have now been annotated where appropriate.
created_at: 2025-04-10T18:55:34Z
author_association: CONTRIBUTOR
path: docs/source/_static/img/onboarding/how_to_fork1.png
user: login: jhelsby
body: All images have now been annotated where appropriate.
created_at: 2025-04-10T18:55:38Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,283 @@
+# ExecuTorch – Open-Source Onboarding Guide
+
+Welcome to **ExecuTorch** — a runtime for efficient deployment of PyTorch AI models to edge devices, including mobile phones, wearables, and embedded systems. ExecuTorch is proudly open-source and welcomes contributions from developers of all backgrounds.
+
+If you're new to ExecuTorch, open-source projects, or GitHub, this guide is for you. We're excited to have you on board!
+
+If you have any questions, issues comments, or just want to say hello to our community, please feel free to introduce yourselves on our **[Discord Server](https://discord.com/invite/Dh43CKSAdc)**. We'd love to speak with you.
+
+---
+
+## 🔑 Prerequisites
+
+### Git
+
+This guide assumes a basic knowledge of Git, and how to run Git commands in your terminal. If you've never used Git before, you can read [this quick guide](https://www.freecodecamp.org/news/learn-the-basics-of-git-in-under-10-minutes-da548267cc91/), [git guide](https://rogerdudler.github.io/git-guide/), [cheat sheet](https://towardsdatascience.com/git-commands-cheat-sheet-software-developer-54f6aedc1c46/), the [Setup Git](https://docs.github.com/en/get-started/git-basics/set-up-git) page from GitHub’s documentation, or watch one of the many tutorials on YouTube.
+
+Git is a powerful version control system for coding projects — it enables you to collaborate, record code changes, and avoid losing hours of work when you make a mistake. It is essential for projects like ExecuTorch, with large codebases and many collaborators. Without it, the complexity of tracking everyone's changes, reviewing their code, and identifying bugs quickly becomes unmanageable.
+
+Git is an industry standard in the coding world, and particularly in open-source. It can take a while to get used to at first, but we promise you it's well worth the effort! We believe that learning Git can make you a significantly stronger and more effective developer.
+
+### A GitHub Account
+
+We also assume that you have a GitHub account. If you don't, please [register here](https://github.com/signup), [verify your email address](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/verifying-your-email-address#verifying-your-email-address) (required for the steps below to work!), then [login](https://github.com/login) to your new account before proceeding further.
+
+---
+
+## 🧑‍💻 Your First Contribution
+
+The first step towards making a contribution is finding something you want to work on. If you're new to ExecuTorch or the wider world of open-source, it might seem hard to know where to start.
+
+To help you out with this, we've gathered together some beginner-friendly suggestions.  These are self-contained pieces of work — "issues" in GitHub parlance — specifically designed to help people new to ExecuTorch get started contributing code. We call these "good first issues", and you can view all of them here: [New Contributors Projects and Issues](https://github.com/orgs/pytorch/projects/102/views/1).
+
+Here's what the list looks like at the time of writing — you can see that they all have a purple `good first issue` label in the right-hand column:
+
+![](./_static/img/onboarding/good_first_issues.png)
+
+Please check it out and see if anything interests you! New issues are added to this list all the time.
+
+Once you've found an issue you like the look of, read our [Contribution Guide](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md). This comprehensive manual will help you:
+* build ExecuTorch on your machine.
+* understand the structure of the ExecuTorch codebase.
+* format, test, and document your code according to ExecuTorch best practices.
+* and finally, submit your code for review, so it can be polished, approved, and merged into the main codebase.
+
+If that seems like a lot of information, please read on — we'll walk you through your first contribution right now.
+
+---
+
+## 📤 Contributing Code, Step-By-Step
+
+### Prepare Your Workspace
+
+Before you can start writing any code, you need to get a copy of ExecuTorch codebase onto your GitHub account, and download it onto your dev machine. You'll want to build it, too — otherwise, you won't be able to test your solution.
+
+1. Fork the main ExecuTorch repository into your GitHub account. This creates a clone of the repository in your own space, so you can modify it freely. To do this, visit the [main repository page](https://github.com/pytorch/executorch) and click `Fork`:
+
+    ![](./_static/img/onboarding/how_to_fork1.png)
+
+    This will take you to another page - click `Create fork`:
+
+    ![](./_static/img/onboarding/how_to_fork2.png)
+
+2. Clone your fork locally. This downloads a copy of your fork onto your dev machine, ready for you to make your changes.
+
+    In the example below, we clone using HTTP, but any of the provided methods on the `Local` tab are fine. For HTTP, copy the URL given here:
+
+    ![](./_static/img/onboarding/how_to_clone.png)
+
+    Then go to your terminal, enter the directory you want to clone the fork to, and run:
+
+    ```bash
+    git clone https://github.com/pytorch/executorch.git
+    ```
+
+    This will create an `executorch` folder in your directory containing your forked codebase.
+
+3.  Set the `upstream` pointing to the main ExecuTorch repository. This will allow you to easily synchronize with the latest development.
+
+    Assuming you're in the same directory you cloned into, run:
+
+    ```bash
+    cd executorch            # enter the cloned project
+    git remote add upstream https://github.com/pytorch/executorch.git
+    ```
+
+    To see if it worked, run:
+
+    ```bash
+    git remote -v
+    ```
+
+    Depending on how you cloned your repo (HTTP, SSH, etc.), this should print something like:
+
+    ```bash
+    origin  https://github.com/YOUR_GITHUB_USERNAME/executorch.git (fetch)
+    origin  https://github.com/YOUR_GITHUB_USERNAME/executorch.git (push)
+    upstream        https://github.com/pytorch/executorch.git (fetch)
+    upstream        https://github.com/pytorch/executorch.git (push)
+    ```
+
+    What does this mean? Well:
+
+      * The `origin` entries show your forked GitHub repository. They tell you that when you run `git pull` or `git push`, your changes will go from/to your GitHub fork.
+
+      * The `upstream` entries show the main ExecuTorch repository. If you want to sync the latest changes from there, you can run `git fetch upstream`.
+
+    Let's sync from both your fork _and_ the main ExecuTorch branch, to get the latest changes from each of them. To do this, run:
+
+    ```bash
+    git fetch --all --prune
+    ```
+
+4. If you just cloned your fork, your GitHub repository will tell you your branch is up-to-date:
+
+    ![](./_static/img/onboarding/synced_fork.png)
+
+    However, ExecuTorch updates frequently - if it's been a while you visited your fork, you might not have the latest version anymore. It's important to keep your fork as up-to-date as possible. Otherwise, the code changes you're making might fix your issue for an old version of the codebase, but _not_ for the current version.
+
+    GitHub will tell you if your fork is out-of-date. To synchronise the necessary changes, click `Sync fork`, then `Update branch` as shown:
+
+    ![](./_static/img/onboarding/unsynced_fork.png)
+
+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:
+
+    ```bash
+    git fetch --all --prune   # pull all branches from GitHub
+    git checkout main         # enter your local main branch
+    git merge upstream/main   # merge latest state from GitHub parent repo
+    git push                  # push updated local main to your GitHub fork
+    ```
+
+6. [Build the project](https://pytorch.org/executorch/main/using-executorch-building-from-source.html) and [run the tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing).
+
+    Unfortunately, this step is too long to detail here. If you get stuck at any point, please feel free to ask for help on our [Discord server](https://discord.com/invite/Dh43CKSAdc) — we're always eager to help newcomers get onboarded.
+
+    * TODO: add a brief overview of the build process or common pitfalls users might encounter.
+
+One final note before we finish this section. It's very important to get your tests running at this stage, for two reasons:
+
+* If they work, it's a great sign that you've got things set up correctly.
+
+* As we'll discuss later, you'll want to run the tests _after_ making your changes to ensure you haven't broken existing functionality. Running them _before_ making your changes gives you a baseline you can compare with later test results.
+
+### Implement your changes
+
+Great job — you're all set up. Now you can actually start coding!
+
+1. Before making any changes, we recommend creating a new branch. To do this, just run:
+    ```bash
+    git checkout -b YOUR_NEW_BRANCH_NAME
+    ```
+
+    You can follow this naming convention: `type/<short-name>`, where the types are: `bugfix`, `feature`, `docs`, `tests`, etc. — or use something similarly descriptive. By way of example, here are a few branch names that were actually merged to ExecuTorch:
+
+    * [bugfix/op_eq](https://github.com/pytorch/executorch/pull/9794)
+
+    * [error-handling-log-intermediate-output-delegate](https://github.com/pytorch/executorch/pull/9759)
+
+    * [add-datasink-try-before-set-tests](https://github.com/pytorch/executorch/pull/9762)
+
+    Creating a new branch means that any changes you make will be isolated to your branch, allowing you to work on multiple issues in parallel. It also means that, if your fork gets behind the main repository and you have to synchronise, you won't need to deal with any merge conflicts — accidentally blocking your `main` branch can be very time-consuming.
+
+2. Make your changes. For bugfixes, we recommend a test-driven workflow:
+    - Find a test case that demonstrates your bug.
+    - Verify that your new test case fails on the `main` branch.
+    - Add that example as an automated test, and assert the expected, failing results. If you can, try to make this test as minimal as possible to reduce interference with some other issue.
+
+    Once you have a failing test, you can keep working on the issue and running the test until it passes.
+
+    **Note:** Even if you do not find the solution, sending a PR with a test covering the issue is a valid contribution. From this point, we can help you find the solution, or even finish it with you.
+
+3. After every set of edits, checkpoint and commit your code changes with a "commit" message that describes the changes you made. For example, in terminal:
+
+    ```bash
+    git add my_changed_file1 my_new_test_case # Pick the files you changed
+    git commit -m "Fixed bug X and added a passing test case" # Describe your change
+    ```
+
+    Try to make your commit messages as descriptive as possible. This helps to maintain a clear project history. Not only will this help your own development, but it will make your code vastly easier for other developers to review and maintain.
+
+    Here are some example commit messages that were merged to ExecuTorch:
+
+    * [Delete examples/demo-apps/apple_ios/ExecuTorchDemo directory](https://github.com/pytorch/executorch/pull/9991/commits/df2f451e5e8fc217231975d7a0065a8cc36709cb)
+    * [[ET-VK][ez] Allow logit linear layer to be lowered to Vulkan](https://github.com/pytorch/executorch/pull/9951/commits/3fdd8cab8c58db0be666f3454c41f73ad5964743)
+    * [Allow emitting mutable buffer names in schema](https://github.com/pytorch/executorch/pull/9935/commits/773a34725afea6c0bf1b99d02a9cefb91c4960e1)
+
+4. When you are done making changes and the test case you added is passing, [run the same tests](https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#testing) you ran at the end of the [Prepare Your Workspace](#prepare-your-workspace) section. If any fail now that were working previously, it means your changes have broken some existing functionality. You'll need to dig back into your code to figure out what's gone wrong.
+
+5. Once your new test _and_ the old tests are all working as intended, upload/push these changes to your fork:
+
+    ```bash
+    # Make sure you've committed all your changes first, then run:
+    git push
+    ```
+
+### Submit a PR
+
+Once you've successfully finished local development, it's time to send out your pull request. This is the final phase — here, we'll help you finetune your changes to get merged into the main repository.
+
+1. After pushing your last edit to remote, your GitHub fork will show your new changed branch — click `Compare & pull request`:
+
+    ![](./_static/img/onboarding/how_to_pr1.png)
+
+    Alternatively, you can click the same `Compare & pull request` button on the main ExecuTorch repo:
+
+    ![](./_static/img/onboarding/how_to_pr2.png)
+
+    Another way still is via the `Pull request` tab on the main repo — we won't go into that here though, as it takes a few more steps.
+
+2. This will take you to a page where you can format your PR and explain your changes. You'll see all the required details in our PR template. You should choose a title describing the proposed fix and fill in all the required details.
+
+    ![](./_static/img/onboarding/how_to_pr3.png)
+
+    In the description, you’ll describe all the changes you’ve made.
+
+    Ensure that all tests are passing. If not, click on a failing test to see what went wrong and make the required changes.
+
+3. If you want to submit your PR right away, you can go ahead and click the Green `Create pull request` button. However, please note that this will immediately notify all reviewers. We strongly recommend creating a Draft PR first. This will allow you to perform some extra checks first:
+
+    * You can get some early feedback on your PR without notifying everybody.
+
+    * It prevents anyone from accidentally merging your unfinished PR.
+
+    * Creating it will start CI (["Continuous Integration"](https://en.wikipedia.org/wiki/Continuous_integration)) checks to verify that all tests pass under various configurations. If some tests fail, you can fix them before creating the final PR.
+
+    To do submit a draft, click the arrow next to the `Create Pull Request` button:
+
+    ![](./_static/img/onboarding/how_to_draft_pr1.png)
+
+    Then click `Create draft pull request` in the dropdown menu. This will change the green button's text to `Draft pull request`:
+
+    ![](./_static/img/onboarding/how_to_draft_pr2.png)
+
+    Click it to create your draft PR.
+
+4. After you click the `Draft pull request` button, it will take you to your Draft PR page. It might look something like this:
+
+    ![](./_static/img/onboarding/how_to_draft_pr3.png)
+
+    As you scroll down, you might see a number of comments and automated checks, some of which may come with alarming red warning signs and the word "Failure"! There's no need to panic, though — they are here to help. Let's go through some common checks one-by-one.
+
+    * The `pytorch-bot` will probably be the first comment. It runs regular CI checks. When your PR is passing, this comment will automatically update to let you know.
+
+      ![](./_static/img/onboarding/ci1.png)
+
+    * If this is your very first contribution to a Meta Open Source project, and you've not signed Meta's contributor license agreement (CLA), you may have a comment like this from `facebook-github-bot`:
+
+        ![](./_static/img/onboarding/cla1.png)
+
+        You will need to sign the linked CLA to contribute your code. Once your signature has been processed, the bot will let you know in another comment:
+
+        ![](./_static/img/onboarding/cla2.png)
+
+    * You may see a comment from `github-actions` requesting a "release notes" label:
+
+        ![](./_static/img/onboarding/release_notes.png)
+
+        Please ignore this message. It's directed at the ExecuTorch maintainers — they'll label your PR for you.
+
+    * At the end of your Draft PR, you'll see something like this:
+
+        ![](./_static/img/onboarding/end_of_draft_pr.png)
+
+        This is a summary of all the CI checks and requirements which need to be satisfied before your PR can be merged. Once you're happy with your draft, you can click the `Ready for review` button to create your PR.
+
+5. Now you've created your PR, it's time for your changes to be reviewed by the ExecuTorch community and maintainers.
+
+    You'll need approval from one of our core contributors for your request to be merged. They may have questions or suggestions for you to address or respond to. Be aware that the review process may take a couple of iterations... Nevertheless, we hope that you'll find this feedback helpful. Code reviews can be a fantastic way to learn more about ExecuTorch and coding best practices from other contributors.
+
+    Those reviewers/maintainers are here to finetune your contribution and eventually catch some issues before we merge the PR. We aim for this process to be pleasing on both sides: we try to give and get the best.
+
+    Once the reviewers are happy, one of our core contributors will merge your PR. Congratulations — you're now an official ExecuTorch contributor!
path: docs/source/onboarding.md
user: login: jhelsby
body: Thanks @byjlw - I've made this correction in this PR: https://github.com/pytorch/executorch/pull/10101
created_at: 2025-04-11T05:48:30Z
author_association: CONTRIBUTOR

PR comments:
user: login: pytorch-bot[bot]
created_at: 2025-04-08T20:09:25Z
body: <!-- drci-comment-start -->

## :link: Helpful Links
### :test_tube: See artifacts and rendered test results at [hud.pytorch.org/pr/pytorch/executorch/9977](https://hud.pytorch.org/pr/pytorch/executorch/9977)
* :page_facing_up: Preview [Python docs built from this PR](https://docs-preview.pytorch.org/pytorch/executorch/9977/index.html)

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


## :white_check_mark: No Failures
As of commit e9662f7160c49191f47353913e0248b233d894c5 with merge base 8d8018500daa3aa8faafa4b2f5d634d5342199ca (<sub><sub><img alt="image" width=70 src="https://img.shields.io/date/1744141669?label=&color=FFFFFF&style=flat-square"></sub></sub>):
:green_heart: Looks good so far! There are no failures yet. :green_heart:


This comment was automatically generated by Dr. CI and updates every 15 minutes.
<!-- drci-comment-end -->
author_association: NONE
user: login: facebook-github-bot
created_at: 2025-04-08T20:09:27Z
body: Hi @jhelsby! 

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](mailto:cla@meta.com?subject=CLA%20for%20pytorch%2Fexecutorch%20%239977). Thanks!
author_association: CONTRIBUTOR
user: login: facebook-github-bot
created_at: 2025-04-08T20:16:44Z
body: Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!
author_association: CONTRIBUTOR
user: login: byjlw
created_at: 2025-04-08T20:54:22Z
body: This is looking really good! Here are some suggestions and potential areas where users might encounter confusion:

1. **Prerequisites Section:**
   - **Git Knowledge:** While you provide links to Git resources, consider adding a brief explanation of why Git is essential for this project. This could help users understand its importance and motivate them to learn it.
   - **GitHub Account:** Mention that users should verify their email address after creating a GitHub account, as this is a common step that can be overlooked.

2. **Finding Issues:**
   - **Good First Issues:** It might be helpful to explain what a "good first issue" is and why it's beneficial for newcomers. This can help set expectations for the complexity and scope of these tasks.

3. **Prepare Your Workspace:**
   - **Forking and Cloning:** The instructions for forking and cloning are clear, but consider adding a note about the difference between `origin` and `upstream` remotes. This is a common point of confusion for beginners.
   - **Syncing Forks:** The guide mentions syncing forks but doesn't explain why this is necessary. A brief explanation of why keeping your fork up-to-date is important could be helpful.

4. **Building and Testing:**
   - **Build Instructions:** Since the build process is not detailed here, consider providing a brief overview or common pitfalls users might encounter. This could reduce the number of questions on your Discord server.
   - **Testing:** Emphasize the importance of running tests before and after making changes. This can help prevent issues later in the process.

5. **Implementing Changes:**
   - **Branch Naming Convention:** While you provide a naming convention, it might be helpful to give an example of a well-named branch to illustrate the point.
   - **Commit Messages:** Encourage descriptive commit messages and provide examples. This can help maintain a clear project history.

6. **Submitting a PR:**
   - **Draft PRs:** Explain the benefits of starting with a draft PR, such as getting early feedback and running CI checks without notifying all reviewers immediately.
   - **Review Process:** Clarify the expected timeline for reviews and what contributors should do if they don't receive feedback within a certain period.

7. **General Suggestions:**
   - **Common Issues:** Consider adding a FAQ or common troubleshooting section for issues that new contributors frequently encounter.
   - **Community Engagement:** Encourage contributors to introduce themselves on Discord or in a specific GitHub discussion thread. This can help build a sense of community and make newcomers feel welcome.


author_association: CONTRIBUTOR
user: login: larryliu0820
created_at: 2025-04-09T18:44:04Z
body: @jhelsby can you also add a pointer in CONTRIBUTING.md to this file? You can consolidate this section: https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#contributing-workflow to reduce duplicate wording.
author_association: CONTRIBUTOR
user: login: jhelsby
created_at: 2025-04-09T21:04:42Z
body: Hi all, I have to stop for the day but have implemented the majority of @byjlw's suggestions in the most recent commit.

I also added TODOs for the suggestions I didn't add. I'd be grateful for any clarification on these - I have very limited experience with ExecuTorch and don't think I have the context required to write something meaningful here.

* Build Instructions: Since the build process is not detailed here, consider providing a brief overview or common pitfalls users might encounter. This could reduce the number of questions on your Discord server.
  * Is there an existing reference for this which I can use? Or recommendations?
* Review Process: Clarify the expected timeline for reviews and what contributors should do if they don't receive feedback within a certain period.
  * Could someone please advise on these points I couldn't find this information in `CONTRIBUTING.md` 
* Common Issues: Consider adding a FAQ or common troubleshooting section for issues that new contributors frequently encounter.
  * Are there any points here which you would recommend including here?

I'll try to implement everyone else's suggestions in the coming days. Thank you so much everyone for the reviews and kind words - I hugely appreciate it.
author_association: CONTRIBUTOR
user: login: jhelsby
created_at: 2025-04-09T21:15:20Z
body: > @jhelsby can you also add a pointer in CONTRIBUTING.md to this file? You can consolidate this section: https://github.com/pytorch/executorch/blob/main/CONTRIBUTING.md#contributing-workflow to reduce duplicate wording.

@larryliu0820 Many thanks for your comment. I'm sorry, but I'm not totally sure that I follow. Are you suggesting moving the "Contributing workflow" section from CONTRIBUTING.md to this onboarding file? I was under the impression that the documents served very different purposes:

* CONTRIBUTING.md is a guide suitable for anyone, including highly experienced developers.
* The onboarding doc is aimed at people who may not have contributed to open-source software (or even used Git) before.

I'm concerned that merging any part of one into the other could make things confusing for both parties - but I may have misunderstood you. Would you possibly be able to expand on your comment? Thank you very much for your time. 
author_association: CONTRIBUTOR
user: login: larryliu0820
created_at: 2025-04-09T21:20:03Z
body: > I'm concerned that merging any part of one into the other could make things confusing for both parties 

Most open source project uses CONTRIBUTING.md for an entry point to contributors. I'm just suggesting we should add a link to the new doc, in CONTRIBUTING.md.
author_association: CONTRIBUTOR
user: login: jhelsby
created_at: 2025-04-09T21:27:19Z
body: > @larryliu0820 Most open source project uses CONTRIBUTING.md for an entry point to contributors. I'm just suggesting we should add a link to the new doc, in CONTRIBUTING.md.

Many thanks for clarifying! I just added this in the [most recent commit](https://github.com/pytorch/executorch/pull/9977/commits/e8a719b676a8a3a0961e80402e20fa49b5908c46) - is this the sort of thing you had in mind?
author_association: CONTRIBUTOR
user: login: larryliu0820
created_at: 2025-04-09T21:31:52Z
body: > > @larryliu0820 Most open source project uses CONTRIBUTING.md for an entry point to contributors. I'm just suggesting we should add a link to the new doc, in CONTRIBUTING.md.
> 
> Many thanks for clarifying! I just added this in the [most recent commit](https://github.com/pytorch/executorch/pull/9977/commits/e8a719b676a8a3a0961e80402e20fa49b5908c46) - is this the sort of thing you had in mind?

Yes! thank you looks good to me.
author_association: CONTRIBUTOR
user: login: byjlw
created_at: 2025-04-09T21:46:38Z
body: > Hi all, I have to stop for the day but have implemented the majority of @byjlw's suggestions in the most recent commit.
> 
> I also added TODOs for the suggestions I didn't add. I'd be grateful for any clarification on these - I have very limited experience with ExecuTorch and don't think I have the context required to write something meaningful here.
> 
> * Build Instructions: Since the build process is not detailed here, consider providing a brief overview or common pitfalls users might encounter. This could reduce the number of questions on your Discord server.
>   
>   * Is there an existing reference for this which I can use? Or recommendations?
> * Review Process: Clarify the expected timeline for reviews and what contributors should do if they don't receive feedback within a certain period.
>   
>   * Could someone please advise on these points I couldn't find this information in `CONTRIBUTING.md`
> * Common Issues: Consider adding a FAQ or common troubleshooting section for issues that new contributors frequently encounter.
>   
>   * Are there any points here which you would recommend including here?
> 
> I'll try to implement everyone else's suggestions in the coming days. Thank you so much everyone for the reviews and kind words - I hugely appreciate it.

Nice work, I looked at your recent change and your note. I think it's good other than the comment i just added which is minor and consider a different name for the file so it's more explict `new-contributor-guide.md`or `new-contributor-onboarding.md` instead of `onboarding`which can onboarding to use of ExecuTorch

The other stuff can be added over time. Thanks so much!

author_association: CONTRIBUTOR
user: login: jhelsby
created_at: 2025-04-10T18:55:10Z
body: Hi all, I've made the final changes. This includes the renaming to `new-contributor-guide.md` which @byjlw suggested.

Please review and merge if you deem it ready. Thank you all for your help!
author_association: CONTRIBUTOR
user: login: mergennachin
created_at: 2025-04-11T13:55:27Z
body: Thank you @jhelsby for your contribution to the contributor guide :) 

This is awesome! 
author_association: CONTRIBUTOR
user: login: byjlw
created_at: 2025-04-11T16:06:44Z
body: @pytorchbot cherry-pick --onto release/0.6 -c docs
author_association: CONTRIBUTOR
user: login: pytorchbot
created_at: 2025-04-11T16:08:36Z
body: ### Cherry picking #9977
The cherry pick PR is at https://github.com/pytorch/executorch/pull/10110 The following tracker issues are updated:
* https://github.com/pytorch/executorch/issues/9253#issuecomment-2797359561


<details><summary>Details for Dev Infra team</summary>
Raised by <a href="https://github.com/pytorch/executorch/actions/runs/14407345292">workflow job</a>

</details>
author_association: COLLABORATOR