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.
