##// END OF EJS Templates
fix links
Paul Ivanov -
Show More
@@ -1,41 +1,40 b''
1 ## Opening an Issue
1 ## Opening an Issue
2
2
3 When opening a new Issue, please take the following steps:
3 When opening a new Issue, please take the following steps:
4
4
5 1. Search GitHub and/or Google for your issue to avoid duplicate reports.
5 1. Search GitHub and/or Google for your issue to avoid duplicate reports.
6 Keyword searches for your error messages are most helpful.
6 Keyword searches for your error messages are most helpful.
7 2. If possible, try updating to master and reproducing your issue,
7 2. If possible, try updating to master and reproducing your issue,
8 because we may have already fixed it.
8 because we may have already fixed it.
9 3. Try to include a minimal reproducible test case
9 3. Try to include a minimal reproducible test case
10 4. Include relevant system information. Start with the output of:
10 4. Include relevant system information. Start with the output of:
11
11
12 python -c "import IPython; print(IPython.sys_info())"
12 python -c "import IPython; print(IPython.sys_info())"
13
13
14 And include any relevant package versions, depending on the issue,
14 And include any relevant package versions, depending on the issue,
15 such as matplotlib, numpy, Qt, Qt bindings (PyQt/PySide), tornado, web browser, etc.
15 such as matplotlib, numpy, Qt, Qt bindings (PyQt/PySide), tornado, web browser, etc.
16
16
17 ## Pull Requests
17 ## Pull Requests
18
18
19 Some guidelines on contributing to IPython:
19 Some guidelines on contributing to IPython:
20
20
21 * All work is submitted via Pull Requests.
21 * All work is submitted via Pull Requests.
22 * Pull Requests can be submitted as soon as there is code worth discussing.
22 * Pull Requests can be submitted as soon as there is code worth discussing.
23 Pull Requests track the branch, so you can continue to work after the PR is submitted.
23 Pull Requests track the branch, so you can continue to work after the PR is submitted.
24 Review and discussion can begin well before the work is complete,
24 Review and discussion can begin well before the work is complete,
25 and the more discussion the better.
25 and the more discussion the better.
26 The worst case is that the PR is closed.
26 The worst case is that the PR is closed.
27 * Pull Requests should generally be made against master
27 * Pull Requests should generally be made against master
28 * Pull Requests should be tested, if feasible:
28 * Pull Requests should be tested, if feasible:
29 - bugfixes should include regression tests
29 - bugfixes should include regression tests
30 - new behavior should at least get minimal exercise
30 - new behavior should at least get minimal exercise
31 * New features and backwards-incompatible changes should be documented by adding
31 * New features and backwards-incompatible changes should be documented by adding
32 a new file to the [development](docs/source/whatsnew/development) directory,
32 a new file to the [pr](docs/source/whatsnew/pr) directory, see [the README.md
33 see [the README.md there](docs/source/whatsnew/development/README.md) for
33 there](docs/source/whatsnew/pr/README.md) for details.
34 details.
35
34
36 [Travis](http://travis-ci.org/#!/ipython/ipython) does a pretty good job testing IPython and Pull Requests,
35 [Travis](http://travis-ci.org/#!/ipython/ipython) does a pretty good job testing IPython and Pull Requests,
37 but it may make sense to manually perform tests (possibly with our `test_pr` script),
36 but it may make sense to manually perform tests (possibly with our `test_pr` script),
38 particularly for PRs that affect `IPython.parallel` or Windows.
37 particularly for PRs that affect `IPython.parallel` or Windows.
39
38
40 For more detailed information, see our [GitHub Workflow](https://github.com/ipython/ipython/wiki/Dev:-GitHub-workflow).
39 For more detailed information, see our [GitHub Workflow](https://github.com/ipython/ipython/wiki/Dev:-GitHub-workflow).
41
40
@@ -1,17 +1,17 b''
1 Documenting What's New
1 Documenting What's New
2 ----------------------
2 ----------------------
3
3
4 When making a new pull request that either adds a new feature, or makes a
4 When making a new pull request that either adds a new feature, or makes a
5 backwards-incompatible change to IPython, please add a new `.rst` file in this
5 backwards-incompatible change to IPython, please add a new `.rst` file in this
6 directory documenting this change as a part of your Pull Request.
6 directory documenting this change as a part of your Pull Request.
7
7
8 This will allow multiple Pull Requests to do the same without conflicting with
8 This will allow multiple Pull Requests to do the same without conflicting with
9 one another. Periodically, IPython developers with commit rights will run a
9 one another. Periodically, IPython developers with commit rights will run a
10 script and populate [developement.rst](../developement.rst) with the contents
10 script and populate [development.rst](../development.rst)
11 of this directory, and clean it up.
11 with the contents of this directory, and clean it up.
12
12
13 Files which describe new features can have any name, such as
13 Files which describe new features can have any name, such as
14 `antigravity-feature.rst`, whereas backwards incompatible changes should have a
14 `antigravity-feature.rst`, whereas backwards incompatible changes should have a
15 filename of `incompat-switching-to-perl.rst`. Our "What's new" files always have
15 filename of `incompat-switching-to-perl.rst`. Our "What's new" files always have
16 two sections, and this prefix scheme will make sure that the backwards
16 two sections, and this prefix scheme will make sure that the backwards
17 incompatible changes get routed to their proper section.
17 incompatible changes get routed to their proper section.
General Comments 0
You need to be logged in to leave comments. Login now