@@ -7,35 +7,134 @@ previous-page: procedures-testing
77next-page : arch-intro
88---
99
10- Once you solved an issue, you likely want to see your change added to the [ Scala 3 repo] [ lampepfl/dotty ] .
11- To do that, you need to prepare a [ pull request] [ pull-request ] with your changes. We recommend you
12- follow these guidelines, [ also consult the full requirements] [ full-list ] :
10+ Once you solved the issue you were working on, you'll likely want to see your
11+ changes added to the [ Scala 3 repo] [ lampepfl/dotty ] . To do that, you need to
12+ prepare a [ pull request] [ pull-request ] with your changes. Assuming that the team
13+ is aware of what you've been working, here are some final steps that you'll want
14+ to keep in mind as you create your PR.
1315
1416### 1. Sign the CLA
1517
16- Make sure you have signed the [ Scala CLA] [ cla ] , if not, sign it.
18+ Make sure you have signed the [ Scala CLA] [ cla ] . If you have any questions about
19+ what this is and why it's required you can read further about it [ here] [ cla ] .
1720
18- ### 2: Is It Relevant?
21+ ### 2. Make sure your work is on its own branch
1922
20- Before starting to work on a feature or a fix, it's good practice to ensure that:
21- 1 . There is a ticket for your work in the project's [ issue tracker ] [ issues ] ;
22- 2 . The ticket has been discussed and there is desire for it to be implemented by the
23- Scala 3 core maintainers .
23+ When submitting your pull request it's always best to ensure the branch name is
24+ unique to the changes you're working on. It's important not to submit your PR on
25+ your ` main ` branch as this blocks maintainers from making any changes to your PR
26+ if necessary .
2427
2528### 3: Add Tests
29+
2630Add at least one test that replicates the problem in the issue, and that shows it is now resolved.
2731
2832You may of course add variations of the test code to try and eliminate edge cases.
2933[ Become familiar with testing in Scala 3] [ testing ] .
3034
3135### 4: Add Documentation
36+
3237Please ensure that all code is documented to explain its use, even if only internal
33- changes are made.
38+ changes are made. This refers to scaladocs and also any changes that might be
39+ necessary in the reference docs.
40+
41+ ### 5: Double check everything
42+
43+ Here are a couple tips to keep in mind.
44+
45+ - [ DRY (Don't Repeat Yourself)] [ dry ]
46+ - [ Scouts Rule] [ scouts ]
47+ - When adding new code try use [ optional braces] . If you're rewriting old code,
48+ you should also use optional braces unless it introduces more code changes
49+ that necessary.
50+
51+ ### 6: Commit Messages
52+
53+ Here are some guidelines when writing commits for Dotty.
54+
55+ 1 . If your work spans multiple local commits (for example; if you do safe point
56+ commits while working in a feature branch or work in a branch for long time
57+ doing merges/rebases etc.) then please do not commit it all but rewrite the
58+ history by squashing the commits into one large commit which is accompanied
59+ by a detailed commit message for (as discussed in the following sections).
60+ For more info, see the article: [ Git Workflow] [ git-workflow ] . Additionally,
61+ every commit should be able to be used in isolation—that is, each commit must
62+ build and pass all tests.
63+
64+ 2 . The first line should be a descriptive sentence about what the commit is
65+ doing. It should be possible to fully understand what the commit does by just
66+ reading this single line. It is ** not ok** to only list the ticket number,
67+ type "minor fix" or similar. If the commit has a corresponding ticket,
68+ include a reference to the ticket number, prefixed with "Closes #", at the
69+ beginning of the first line followed by the title of the ticket, assuming
70+ that it aptly and concisely summarizes the commit in a single line. If the
71+ commit is a small fix, then you are done. If not, go to 3.
72+
73+ 3 . Following the single line description (ideally no more than 70 characters
74+ long) should be a blank line followed by an enumerated list with the details
75+ of the commit.
76+
77+ 4 . Add keywords for your commit (depending on the degree of automation we reach,
78+ the list may change over time):
79+ * `` Review by @githubuser `` - will notify the reviewer via GitHub. Everyone
80+ is encouraged to give feedback, however. (Remember that @-mentions will
81+ result in notifications also when pushing to a WIP branch, so please only
82+ include this in your commit message when you're ready for your pull
83+ request to be reviewed. Alternatively, you may request a review in the
84+ pull request's description.)
85+ * `` Fix/Fixing/Fixes/Close/Closing/Refs #ticket `` - if you want to mark the
86+ ticket as fixed in the issue tracker (Assembla understands this).
87+ * `` backport to _branch name_ `` - if the fix needs to be cherry-picked to
88+ another branch (like 2.9.x, 2.10.x, etc)
89+
90+ Example:
91+
92+ ```
93+ fix: here is your pr title briefly mentioning the topic
94+
95+ Here is the body of your pr with some more information
96+ - Details 1
97+ - Details 2
98+ - Details 3
99+
100+ Closes #2
101+ ```
102+
103+ ### 7: Create your PR!
104+
105+ When the feature or fix is completed you should open a [ Pull
106+ Request] ( https://help.github.com/articles/using-pull-requests ) on GitHub.
107+
108+ If you're not actually finished yet and are just looking for some initial input
109+ on your approach, feel free to open a [ Draft PR] [ draft ] . This lets reviewers
110+ know that you're not finished yet. It's also a good idea to put a [ wip] in front
111+ of your pr title to make this extra clear.
112+
113+ Shortly after creating your pull request a maintainer should assign someone to
114+ review it. If this doesn't happen after a few days, feel free to ping someone on
115+ the [ Scala Contributors Discor] [ discord ] or tag someone on the PR. Depending on
116+ the type of pull request there might be multiple people that take a look at your
117+ changes. There might also be community input as we try to keep the review
118+ process as open as possible.
119+
120+ ### 8: Addressing feedback
121+
122+ More than likely you'll get feedback from the reviewers, so you'll want to make
123+ sure to address everything. When in doubt, don't hesitate to ask for
124+ clarification or more information.
34125
126+ Once you finally see the "LGTM" (Looks Good To Me or Let's Get This Merged)
127+ you're PR will be merged in!
35128
36129[ pull-request ] : https://docs.github.com/en?query=pull+requests
37130[ lampepfl/dotty ] : https://github.com/lampepfl/dotty
38131[ cla ] : http://typesafe.com/contribute/cla/scala
39132[ issues ] : https://github.com/lampepfl/dotty/issues
40133[ full-list ] : https://github.com/lampepfl/dotty/blob/master/CONTRIBUTING.md
41134[ testing] : {% link _ overviews/scala3-contribution/procedures-testing.md %}
135+ [ discord ] : https://discord.gg/TSmY9zkHar
136+ [ dry ] : https://www.oreilly.com/library/view/97-things-every/9780596809515/ch30.html
137+ [ scouts ] : https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html
138+ [ optional-braces ] : https://docs.scala-lang.org/scala3/reference/other-new-features/indentation.html
139+ [ draft ] : https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests
140+ [ git-workflow ] : http://sandofsky.com/blog/git-workflow.html
0 commit comments