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: CONTRIBUTING.md
-9Lines changed: 0 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -49,18 +49,11 @@ A new language feature requires a SIP (Scala Improvement Process) proposal. For
49
49
Here is some advice on how to craft a pull request with the best possible
50
50
chance of being accepted.
51
51
52
-
### Merging
53
-
54
-
A pull request should merge cleanly. (If enough time passes after
55
-
your initial submission, we may ask you to rebase it onto the current
56
-
mainline code.)
57
-
58
52
### Tests
59
53
60
54
Bug fixes should include regression tests -- in the same commit as the fix.
61
55
62
56
If testing isn't feasible, the commit message should explain why.
63
-
(Consider discussing on scala-internals first.)
64
57
65
58
New features and enhancements must be supported by a respectable test suite.
66
59
@@ -137,5 +130,3 @@ A reviewer gives the green light by commenting "LGTM" (looks good to me).
137
130
A review feedback may be addressed by pushing new commits to the request, if these commits stand on their own.
138
131
139
132
Once all these conditions are met, and we agree with the change (we are available on scala-internals to discuss this beforehand, before you put in the coding work!), we will merge your changes.
140
-
141
-
Please note: you are responsible for meeting these criteria (reminding your reviewer, for example).
0 commit comments