As of this writing, SymPy has 1648 issues open. That's more than numpy, scipy, or pandas (more than numpy and scipy combined!). Further, our issue tagging system is a mess. We can do better than this!
Many of these issues are imported from google code, and may be already fixed in master (some as old as 2008). Others may be duplicates. I've taken it upon myself to start cleaning these up. Here's the system I'm using:
Issue label breakdown:
Submodule tags (html #0000FF, blue):
Everything after `sympy.` for the specific submodule. Keep the naming and casing consistent with the sympy namespace. If the relevant submodule is small, group it in with it's parent submodule. Feel free to create new labels if needed. Multiple tags may be used, but only if needed.
Classifier tags (html #d4c5f9, light purple):
What kind of issue is this. Currently 3 supported:
- `valid`: valid bug *in current master* (will be renamed to bug later, see below)
- `wontfix`: not a bug, should be tagged and closed (once everyone agrees/explanation given of course!)
- `duplicate`: same issue already exists. Main issue should be linked, and the duplicate closed.
- `enhancement`: not a bug, but something that would be nice to have
Platform tags (html #800080, purple):
Things that have to deal with specific platforms, python versions. This includes `IPython`, `Python 3`, other versions such as `PyPy`, etc..., `Windows`, and `SymPy Gamma`/`SymPy Live`. I feel like the last 2 should be moved to their respective repositorys, but I don't know how to export issues (it may not even be possible). I'd like to consolidate these if possible, but current system isn't terrible.
Priority tags (html #eb6420, orangeish?):
How important this is to sympy. I don't like these, as almost everything is marked as medium. I feel they don't provide a level of information that we actually care about, and a better triaging system could be used. Mainly, priority is relative - what's important to some users may be irrelevant to others. Really, only the `critical` tag has been used to some success. But, as we were using them before, let's keep them for now.
Meta tags (html #c7def8, sky blue):
Issues that have to deal with non-code functionality. Testing and documentation tags are obvious, `Maintainability` has to do with how we organize code/code quality/dev environment issues.
Special tags (html #f7c6c7, pink):
Things that need their own issue and need to stand out. Right now this is deprecation warning removal issues, as they're important and should be easily visible, and `Needs decision` labels.
Difficulty tags (html #009800, green):
How hard is this task? Currently only "easy to fix". I'd like to get a better breakdown, such as what Pandas has. See below for more info
You may notice that leaves many tags in our current labeling system unused. That's because I'd like to get rid of them, but only once they're retagged. Too many different labels makes the whole system hard to navigate, too few and we can't find what we're looking for. I believe the above is a good proposed start.
How can you help???
If you want to help out with the effort, here's what I need:
- Brief discussion on labeling system. I will not accept a bikeshed on this, so discussion should be kept brief. Anything is better than what we had before, we don't need to decide on the *end all* labelling system. Really, all I want is to know if others think the Priority labels are useful (I don't), and also how people would feel about labels for effort and difficulty levels, such as what Pandas does
- Help labeling. I've already started at the end of our issue list, and have been making my way forward. The methodology:
- Determine if the issue is still valid in master. If not, close it.
- Tag issue with classifier tags (`enhancement`, `valid`, `duplicate`, or `wontfix`)
- If relevant, tag issue with submodule tag. Create new one if no good match exists.
- If relevant, tag issue with platform tag. Create new one if no good match exists
- If relevant, tag issue with meta tag.
- Difficulty, priority, and special (really just `Needs decision`) tags are super optional. If we can agree to tag difficulty in some tiered system, then this should be done as well, but I'm not going to enforce this. Same for priority. SymPy is big - not everyone is going to know what's important or difficult. Further, what's important to me, may be irrelevant to others.
Once all issues have been gone through, the `bug` and `wrong result` issues should be deleted, and `valid` renamed to `bug`.
To work together on this, just start at the back, and work forward. Most issues have no tags, so it should be reasonably easy to see what hasn't been touched by others yet.
- All issues are tagged
- Many of the issues are found to be already fixed/duplicates and can be closed
GSoC starts in a month - it'd be really nice to get our issue tracker cleaned up for the big push through the summer. I'm sure we can do it!
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to