Also, did you kill the "Alternate Python" label? That was useful.
Aaron Meurer On Fri, Apr 17, 2015 at 11:19 AM, Aaron Meurer <[email protected]> wrote: > 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%2BQc6VkC%3DcyZF7mnS%3D0Jw0VCSRrO_rh78LzVwjY0dfNHg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
