Show More
@@ -1,95 +1,95 b'' | |||
|
1 | 1 | ## Triaging Issues |
|
2 | 2 | |
|
3 | 3 | On the IPython repository, we strive to trust users and give them responsibility. |
|
4 | 4 | By using one of our bots, any user can close issues or add/remove |
|
5 | 5 | labels by mentioning the bot and asking it to do things on your behalf. |
|
6 | 6 | |
|
7 | 7 | To close an issue (or PR), even if you did not create it, use the following: |
|
8 | 8 | |
|
9 | 9 | > @meeseeksdev close |
|
10 | 10 | |
|
11 | 11 | This command can be in the middle of another comment, but must start on its |
|
12 | 12 | own line. |
|
13 | 13 | |
|
14 | 14 | To add labels to an issue, ask the bot to `tag` with a comma-separated list of |
|
15 | 15 | tags to add: |
|
16 | 16 | |
|
17 | 17 | > @meeseeksdev tag windows, documentation |
|
18 | 18 | |
|
19 | 19 | Only already pre-created tags can be added. So far, the list is limited to: |
|
20 | 20 | `async/await`, `backported`, `help wanted`, `documentation`, `notebook`, |
|
21 | 21 | `tab-completion`, `windows` |
|
22 | 22 | |
|
23 | 23 | To remove a label, use the `untag` command: |
|
24 | 24 | |
|
25 | 25 | > @meeseeksdev untag windows, documentation |
|
26 | 26 | |
|
27 | 27 | We'll be adding additional capabilities for the bot and will share them here |
|
28 | 28 | when they are ready to be used. |
|
29 | 29 | |
|
30 | 30 | ## Opening an Issue |
|
31 | 31 | |
|
32 | 32 | When opening a new Issue, please take the following steps: |
|
33 | 33 | |
|
34 | 34 | 1. Search GitHub and/or Google for your issue to avoid duplicate reports. |
|
35 | 35 | Keyword searches for your error messages are most helpful. |
|
36 | 36 | 2. If possible, try updating to master and reproducing your issue, |
|
37 | 37 | because we may have already fixed it. |
|
38 | 38 | 3. Try to include a minimal reproducible test case. |
|
39 | 39 | 4. Include relevant system information. Start with the output of: |
|
40 | 40 | |
|
41 | 41 | python -c "import IPython; print(IPython.sys_info())" |
|
42 | 42 | |
|
43 | 43 | And include any relevant package versions, depending on the issue, such as |
|
44 | 44 | matplotlib, numpy, Qt, Qt bindings (PyQt/PySide), tornado, web browser, etc. |
|
45 | 45 | |
|
46 | 46 | ## Pull Requests |
|
47 | 47 | |
|
48 | 48 | Some guidelines on contributing to IPython: |
|
49 | 49 | |
|
50 | 50 | * All work is submitted via Pull Requests. |
|
51 | 51 | * Pull Requests can be submitted as soon as there is code worth discussing. |
|
52 | 52 | Pull Requests track the branch, so you can continue to work after the PR is submitted. |
|
53 | 53 | Review and discussion can begin well before the work is complete, |
|
54 | 54 | and the more discussion the better. |
|
55 | 55 | The worst case is that the PR is closed. |
|
56 | 56 | * Pull Requests should generally be made against master |
|
57 | 57 | * Pull Requests should be tested, if feasible: |
|
58 | 58 | - bugfixes should include regression tests. |
|
59 | 59 | - new behavior should at least get minimal exercise. |
|
60 | 60 | * New features and backwards-incompatible changes should be documented by adding |
|
61 | 61 | a new file to the [pr](docs/source/whatsnew/pr) directory, see [the README.md |
|
62 | 62 | there](docs/source/whatsnew/pr/README.md) for details. |
|
63 | 63 | * Don't make 'cleanup' pull requests just to change code style. |
|
64 | 64 | We don't follow any style guide strictly, and we consider formatting changes |
|
65 | 65 | unnecessary noise. |
|
66 | 66 | If you're making functional changes, you can clean up the specific pieces of |
|
67 | 67 | code you're working on. |
|
68 | 68 | |
|
69 | 69 | [Travis](http://travis-ci.org/#!/ipython/ipython) does a pretty good job testing |
|
70 | 70 | IPython and Pull Requests, but it may make sense to manually perform tests, |
|
71 | 71 | particularly for PRs that affect `IPython.parallel` or Windows. |
|
72 | 72 | |
|
73 | 73 | For more detailed information, see our [GitHub Workflow](https://github.com/ipython/ipython/wiki/Dev:-GitHub-workflow). |
|
74 | 74 | |
|
75 | 75 | ## Running Tests |
|
76 | 76 | |
|
77 |
All the tests can by |
|
|
77 | All the tests can be run by using | |
|
78 | 78 | ```shell |
|
79 | 79 | iptest |
|
80 | 80 | ``` |
|
81 | 81 | |
|
82 | 82 | All the tests for a single module (for example **test_alias**) can be run by using the fully qualified path to the module. |
|
83 | 83 | ```shell |
|
84 | 84 | iptest IPython.core.tests.test_alias |
|
85 | 85 | ``` |
|
86 | 86 | |
|
87 | 87 | Only a single test (for example **test_alias_lifecycle**) within a single file can be run by adding the specific test after a `:` at the end: |
|
88 | 88 | ```shell |
|
89 | 89 | iptest IPython.core.tests.test_alias:test_alias_lifecycle |
|
90 | 90 | ``` |
|
91 | 91 | |
|
92 | 92 | For convenience, the full path to a file can often be used instead of the module path on unix systems. For example we can run all the tests by using |
|
93 | 93 | ```shell |
|
94 | 94 | iptest IPython/core/tests/test_alias.py |
|
95 | 95 | ``` |
General Comments 0
You need to be logged in to leave comments.
Login now