> 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).
> 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.
On Fri, Apr 17, 2015 at 11:20 AM, Aaron Meurer <[email protected]> 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 <[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 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
> [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.
>
--
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/CAJ2L7mc3759qTuBmZ6rH0nKsKxKQTygXSseTD80YkewpK%3DDSQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
