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