[wp-meta] [Making WordPress.org] #8007: Rewrite and clarify “Adding your GitHub fork to your WP trunk copy” section for accuracy and readability

[Making WordPress.org]

#8007: Rewrite and clarify “Adding your GitHub fork to your WP trunk copy” section
for accuracy and readability
-------------------------+-----------------------
 Reporter:  tomd6r       |       Owner:  psykro
     Type:  enhancement  |      Status:  assigned
 Priority:  low          |   Milestone:
Component:  Handbooks    |  Resolution:
 Keywords:               |
-------------------------+-----------------------

Comment (by tomd6r):

 Looks great, @psykro! The only thing I’m a little hesitant about is
 whether it might be a bit too wordy, which could make it a bit harder to
 follow for some contributors.

 I’d be totally fine with this being published as-is, but I’d like to offer
 one more suggestion:

 ----

 == Submitting a patch via GitHub

 If you prefer using GitHub for code reviews and collaboration, the
 WordPress core code is available as a [GitHub
 mirror](https://github.com/wordpress/wordpress-develop) where you can
 submit patches.

 1. Fork the GitHub mirror to your own account using the Fork button on the
 GitHub page.
 2. Clone your fork locally (replace `your-username`).
 {{{
 git clone git at github.com:your-username/wordpress-develop.git
 }}}
 3. Create a new branch to work on a specific Trac ticket — never work
 directly on trunk. Name it after the Trac ticket number, and a brief
 description of the change.
 {{{
 git checkout -b 44722-fix-issue-in-component
 }}}
 4. Make your changes, commit, and push.
 {{{
 git push origin 44722-fix-issue-in-component
 }}}
 5. Go to your fork on GitHub. If your GitHub account is linked to your
 WordPress.org profile, GitHub will prompt you to open a Pull Request. Make
 sure the title includes the Trac ticket number (e.g., #44722: Fix X issue
 in Y component).

 ----

 I left out the second part about adding your fork to an existing local
 clone. I initially kept it because it was in the original version, but I
 think more advanced users will already be familiar with that workflow. For
 newer contributors, it could be a bit disorienting or feel like an
 alternate path they have to consider. The examples (like naming the
 branch) are already covered implicitly in the example commands, so I
 figured simplifying it helps keep the focus clearer.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/8007#comment:8>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org