Glad to see you taking this on. Quite a few issues are either duplicate or already fixed, so there is definitely some cleanup possible.
On Fri, Apr 17, 2015 at 12:40 AM, James Crist <[email protected]> wrote: > 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. These are the most important to me. Tags like "Integration" or "Solvers" really help to find an issue, especially when there are so many. It also helps new people who are interested in contributing to a given submodule to take a look at all the open issues for that submodule. > > 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 wontfix and duplicate aren't super important because they by definition only go on closed issues (and tagging closed issues is not as important as tagging open issues). > > 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. Something like https://github-issue-mover.appspot.com/ (I haven't tested this yet). > > 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. These were more useful when we used Google code, and it sorted by the priority. For now, I would only worry about critical, i.e., something that has to be fixed before a release happens (even then, the milestones are more useful for that). > > 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 "Easy to fix" is the most important one, because we send new contributors to it. Just keep in mind that we are specifically pointing new contributors to those issues, so don't use that label if there are potential issues with the issue that could trip them up (for instance, never use "Easy to fix" with "Needs Decision"). What value would other difficulties have. "Hard" might just scare people away, though maybe there are a handful of issues that look easy but really aren't that need this (I don't really see this as a problem, though). > > ------------------------------------------------------------ > > 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. People aren't labeling new issues anyway, so we should get rid of them. Labels serve two purposes: 1. Signaling things to people who come across the issue (like "Needs Decision" or "Easy to fix"). These labels typically deserve bright colors, because we want people to notice them. 2. Making the issue tracker easier to search/navigate (like "Integration" or "Solvers"). These are mainly for searching, so dimmer colors are better. If a label doesn't add value to either of those categories, we should just not use it, especially since a new issue is labelled by default, unless someone triages it. I agree that priorities are useless, except for release milestone tracking issues, which we can just use the milestones feature for anyway, so let's get rid of them. Other uses of priorities would probably be better served by milestones as well. > > - 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. > > 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! It's also a great thing for the GSoC candidates to help out with. It's a good way to learn more about SymPy and to help out. Aaron Meurer > > - 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. -- 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/CAKgW%3D6%2Benz%3DPx5CGdT7uicKhpSF3W2CfdC%3DicDHm1QNDR1WwmQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
