@@ -23,10 +23,10 @@ your contribution or address the issue you're having.
23
23
to see that the PR does indeed pass all the tests.
24
24
- Back-compatiblitiy ** really** matters. Pandas already has a large user-base and
25
25
a lot of existing user code. Don't break old code if you can avoid it
26
- Explain the need if there is one in the PR.
27
- Changes to method signatures should be made in a way which doesn't break existing
28
- code, for example you should beware of changes to ordering and naming of keyword
29
- arguments. Add deprecation warnings when needed.
26
+ Explain the need if there is one in the PR.
27
+ Changes to method signatures should be made in a way which doesn't break existing
28
+ code, for example you should beware of changes to ordering and naming of keyword
29
+ arguments. Add deprecation warnings when needed.
30
30
- Performance matters. You can use the included "test_perf.sh"
31
31
script to make sure your PR does not introduce any performance regressions
32
32
in the library.
@@ -43,6 +43,8 @@ your contribution or address the issue you're having.
43
43
- BLD: Updates to the build process/scripts
44
44
- PERF: Performance improvement
45
45
- CLN: Code cleanup
46
+ - Commit messages should have subject line <80 chars, followed by one blank line,
47
+ and finally a commit message body if there's a need for one.
46
48
- RELEASE.rst and doc/source/vx.y.z.txt contain an on-going changelog for each
47
49
release as it is worked on. Add entries to these files as needed in
48
50
a separate commit in your PR, documenting the fix, enhancement or (unavoidable)
0 commit comments