Also maybe a small gripe about organizing by submodule. Evalf labeled issues don't have to be something that is happening in the core (you renamed it to "core.evalf"). I also like to encourage creating issues for things that come up a lot, even if they aren't submodules (the "Noncommutative" label is a great example of this).
Aaron Meurer On Fri, Apr 17, 2015 at 11:16 AM, Aaron Meurer <[email protected]> wrote: > On Fri, Apr 17, 2015 at 11:13 AM, Aaron Meurer <[email protected]> wrote: >> 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. > > In case this wasn't clear, I think you should revise your color > scheme. Bright blue is too bright for these labels. There's also value > for signalling labels to have distinct colors from one another (I > would keep the already established ones for the ones that are already > there, like needs decision, easy to fix, and critical. > > Aaron Meurer > >> >> 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%2BjBtY6Lc71Mvan6gFYt2rUNWJNTxgDZhmF_oOt_wakWA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
