On Fri, Apr 17, 2015 at 11:33 AM, James Crist <crist...@umn.edu> wrote: >> Also maybe a small gripe about organizing by submodule. > > I did this because this seemed to be the easiest way to ensure that like > issues were grouped together, in a way with consistent naming. There were > `integration` and `Integration` labels before, as well as many tags for > things that were almost, but not exactly how they were named in sympy. > However, you're right that not all issues fit into a submodule category. I'd > really prefer to do it this way, but could be convinced otherwise. Perhaps > most things are named by submodule, but some tags can just be a general > label? Same color, same casing (lowercase), just not referencing an exact > submodule? > >> Also, did you kill the "Alternate Python" label? That was useful. > > Renamed it to `Python Versions`, as that's what the issue really was (not > everything worked on all versions of python).
It was more about IronPython, Jython, and PyPy. Python3 is usually the label used for Python version issues. > >> In case this wasn't clear, I think you should revise your color scheme. > > Colors were haphazard - I just wanted something brighter than the light grey > we had before for topics. I think topics are fairly important, and should > stand out against githubs background at least. But changing them is fine. > > > From your comments, I'll remove the priority labels. Did you want to keep > critical or just use milestones? Having only one difficulty label ("Easy to > Fix") also seems like a better method in retrospect, so that can stay as is. Let's keep critical. It's bright red and stands out, and sometimes there are issues that deserve that label. Aaron Meurer > > On Fri, Apr 17, 2015 at 11:20 AM, Aaron Meurer <asmeu...@gmail.com> wrote: >> >> Also, did you kill the "Alternate Python" label? That was useful. >> >> Aaron Meurer >> >> On Fri, Apr 17, 2015 at 11:19 AM, Aaron Meurer <asmeu...@gmail.com> 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 <asmeu...@gmail.com> >> > wrote: >> >> On Fri, Apr 17, 2015 at 11:13 AM, Aaron Meurer <asmeu...@gmail.com> >> >> 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 <crist...@umn.edu> >> >>> 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 sympy+unsubscr...@googlegroups.com. >> >>>> To post to this group, send email to sympy@googlegroups.com. >> >>>> 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 a topic in the >> Google Groups "sympy" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/sympy/LN6xcS1aMNk/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> sympy+unsubscr...@googlegroups.com. >> To post to this group, send email to sympy@googlegroups.com. >> 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. > > > -- > 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 sympy+unsubscr...@googlegroups.com. > To post to this group, send email to sympy@googlegroups.com. > 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/CAJ2L7mc3759qTuBmZ6rH0nKsKxKQTygXSseTD80YkewpK%3DDSQg%40mail.gmail.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 sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. 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%3D6K-7cWrbgr1rVxPSgOxMeyO45xGYEu_FR8gqTDCFLZumA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.