You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/github/contribute-open-source/includes/4-exercise-create-pr.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ To write a good commit message, and subsequently your pull request, follow these
9
9
- Include a succinct description of the change by using the imperative, present tense. For example, use *add* not *added* or *adds*.
10
10
- Limit your subject line to 50 characters.
11
11
- Start with a capital letter, and don't end with a period (.).
12
-
- You can use emojis in your subject line and `@mention` other GitHub users, but not everyone is a fan of such frivolity.
12
+
- You can use emojis or `@mention` other GitHub users in your subject line, but be mindful that not all projects allow or encourage this.
13
13
14
14
For the body of your message and pull request, continue to use present tense. Make sure to include the motivation for the change. Contrast your change with the previous behavior. Use the space at your disposal to explain the *what* and *why* versus the *how*.
15
15
@@ -19,6 +19,9 @@ Your commit message is only as much to the point as the content that you're abou
19
19
20
20
Before you submit your pull request, check the sidebar for ways to complete your PR. Select **Reviewers** or **Assignees** if you're familiar with the project's team structure. Add *labels* when there's guidance on using labels in, for instance, the CONTRIBUTING.md file. You can use labels as a visual clue for what you're trying to accomplish. A maintainer might also add a label or multiple labels.
21
21
22
+
> [!TIP]
23
+
> If the repository has a CONTRIBUTING.md file or a PR template, follow its guidance when filling in your pull request.
24
+
22
25
Some of the labels we use in the repository for this Learn module are:
23
26
24
27
-**Bug** (red): Something isn't working
@@ -38,4 +41,4 @@ Using the [First Contributions](https://github.com/firstcontributions/first-cont
38
41
39
42
With the lessons from the previous unit and this one in mind, go back to a pull request you opened recently. Or, you can go to the pull requests tab of a project you're watching. Notice how a good subject line can make all the difference. Consider updating a pull request accordingly. Put roughly as much time into writing your PR as you did in making the change to the project. Your efforts will help the maintainers categorize and prioritize (triage) community contributions.
40
43
41
-
**Bonus:** Check Microsoft's Accessibility Guidelines and Requirements. In particular, see the information about [describing interactions with UI](/style-guide/procedures-instructions/describing-interactions-with-ui) to avoid ableist language in your contributions. Customers interact with products by using different input methods. For example, they can use the keyboard, a mouse, touch, voice, and more. You'll want to use generic verbs that work with any input method. For instance, use *select* instead of the input-specific *click* or *swipe*.
44
+
**Bonus:** Check Microsoft's Accessibility Guidelines and Requirements. In particular, see the information about [describing interactions with UI](/style-guide/procedures-instructions/describing-interactions-with-ui) to avoid ableist language in your contributions. Customers interact with products by using different input methods. For example, they can use the keyboard, a mouse, touch, voice, and more. You'll want to use generic verbs that work with any input method. For instance, use *select* instead of the input-specific *click* or *swipe*.
0 commit comments