Notes on working with GitHub
In general: When in doubt, mark with next release. We can always push back when we have more specific plans for a given release.
Issues should always be labeled once they are confirmed (not necessary for issues that are still being clarified, or may be duplicates or not issues at all).
Some significant labels:
needs-info: issue needs more information from submitter before progress can be made
type-bug: errors are raised, or unintended behavior occurs
type-enhancement: improvements that are not bugs
backport-X.Y.Z: Any fix for this issue should be backported to the maintenance branch.
prio-foo: a priority level for ranking issues - nonessential, but prio-high/low are useful for explicitly promoting/demoting issues, particularly when nearing release.
ClosedPR: This issue is a reminder for a PR that was closed for going stale.
quickfix: Obvious or easy fixes.
All confirmed issues should at least have a
type-foo label, and be marked with any affected components (e.g
htmlnotebook), or particular sources of error (e.g.
quickfix labels are the best places for new contributors to start.
Travis does a pretty good job testing IPython and Pull Requests, but it may make sense to manually perform tests (possibly with our
test_pr script), particularly for PRs that affect
IPython.parallel or Windows.
When opening a new issue, please take the following steps:
Include relevant system information. Start with the output of:
python -c "import IPython; print(IPython.sys_info())"
And include any relevant package versions, depending on the issue, such as matplotlib, numpy, Qt, Qt bindings (PyQt/PySide), tornado, web browser, etc.
0.13.1. This way, there is only one maintenance branch per release series.
Last edited by Brian E. Granger,