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 
<https://github.com/pydata/pandas/issues>.

- Help labeling. I've already started at the end of our issue list, and 
have been making my way forward. The methodology:


   1. Determine if the issue is still valid in master. If not, close it.
   2. Tag issue with classifier tags (`enhancement`, `valid`, `duplicate`, 
   or `wontfix`)
   3. If relevant, tag issue with submodule tag. Create new one if no good 
   match exists.
   4. If relevant, tag issue with platform tag. Create new one if no good 
   match exists
   5. If relevant, tag issue with meta tag.
   6. 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.

*The goal:*
- 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!

- Jim

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/6b60659e-15ff-47ee-8e0c-a2cb53810340%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to