The great issue cleanup of 2015

[James Crist]

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.

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

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.

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.

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

------------------------------------------------------------

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.

- Help labeling. I've already started at the end of our issue list, and have been making my way forward. The methodology:

1. Determine if the issue is still valid in master. If not, close it.
2. Tag issue with classifier tags (`enhancement`, `valid`, `duplicate`, or `wontfix`)
3. If relevant, tag issue with submodule tag. Create new one if no good match exists.
4. If relevant, tag issue with platform tag. Create new one if no good match exists
5. If relevant, tag issue with meta tag.
6. 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!

- Jim

[Jason Moore]

Thanks Jim! That all sounds great to me and seems like a major improvement. Rock and Roll!

Jason
moorepants.info
+01 530-601-9791

--
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+un...@googlegroups.com.
To post to this group, send email to sy...@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.

[Aaditya Nair]

Yes, this will be a great task. 

1. I agree with Jim that the Priority labels are pretty darn useless. People will always solve issues they are comfortable with, high priority or not.

2. Also, I am not too comfortable with the difficulty labels as they tend to be subjective. What is `medium` to you may not be so for me.

3. For some issues, the solution to the problem is presented in the discussion in the issue itself. I think they should be merged with the 

   `Easy to Fix` ones with a tag that says `If you read through the discussion, you will find how to solve this issue`.

Also, if I had to suggest some tags, should I just add a comment in the discussion ?

Aaditya

[Harsh Gupta]

Great initiative, I suggest adding `needs decision` to the classifier tag. It is for the issues for which we are not sure if they are valid or not. 

--

Harsh

[James Crist]

On Friday, April 17, 2015 at 8:17:56 AM UTC-5, Harsh Gupta wrote:

Great initiative, I suggest adding `needs decision` to the classifier tag. It is for the issues for which we are not sure if they are valid or not.

`Needs Decision` already exists, and is a "special" (pink) tag. The reason for this is because both bugs and enhancements may need a decision, so the tag shouldn't be a classifier, but a note to the dev team that some decision needs to be made.

Also, a clarification on `wontfix` (because I see some issues have been tagged with it wrongly). `wontfix` is for things that are not actually bugs (for example, an issue saying "simplify doesn't do my taxes" isn't a bug, because that's not what simplify is for). `wontfix` is *not* for things that are already fixed in master, but used to be bugs.

- Jim

[Aaron Meurer]

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 <cris...@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.

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.

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

[Aaron Meurer]

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

[Aaron Meurer]

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

[Aaron Meurer]

Also, did you kill the "Alternate Python" label? That was useful.

Aaron Meurer

[James Crist]

> 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.

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+un...@googlegroups.com.

To post to this group, send email to sy...@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.

[Aaron Meurer]

On Fri, Apr 17, 2015 at 11:33 AM, James Crist <cris...@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.

> https://groups.google.com/d/msgid/sympy/CAJ2L7mc3759qTuBmZ6rH0nKsKxKQTygXSseTD80YkewpK%3DDSQg%40mail.gmail.com.

[Joachim Durchholz]

Am 17.04.2015 um 07:40 schrieb James Crist:
> - Brief discussion on labeling system.

Actually I think what you're proposing is fine.
If it's found lacking, we can easily fix it.

> - Help labeling.

I haven't found a way to enable tagging for people that do not have full
write access to the repository. I suspect GitHub does not offer any.
This is also the reason why tagging does not happen very much.

BTW I'm super happy that you've picked up with the house cleaning. It
was long overdue, and really necessary IMHO.

[James Crist]

On Friday, April 17, 2015 at 1:34:55 PM UTC-5, Joachim Durchholz wrote:

> - Help labeling.

I haven't found a way to enable tagging for people that do not have full
write access to the repository. I suspect GitHub does not offer any.
This is also the reason why tagging does not happen very much.

Hmmm, you're right... It would be nice to allow the general public to tag issues, but I could also see an argument against that due to "potential vandalism". In general, I'd trust people not to mess with things, but can also see why it is the way it is. Once we get through the huge backlog, having the core team tag issues as they come in should be a lot more manageable.

I have another label question:

- `Needs better patch`: could be useful to indicate PR status to devs, but mostly I feel that it comes off as rude to the person making the PR. I'd like to remove it unless someone makes a strong argument to the contrary.

[Sudhanshu Mishra]

Hi,

​​

`Needs better patch`: could be useful to indicate PR status to devs, but mostly I feel that it comes off as rude to the person making the PR. I'd like to remove it unless someone makes a strong argument to the contrary.

​Perhaps, we can reword it.​ How about "Needs changes" or "Waiting for changes"?

Sudhanshu Mishra

--

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+un...@googlegroups.com.
To post to this group, send email to sy...@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/7ed5e065-3b3e-4210-9e1a-520b8dee133b%40googlegroups.com.

[James Crist]

That's at least a little nicer. How about the following for status tags:

- Needs Decision : community hasn't decided how to handle this
- Needs Work : PR needs work to meet standards
- Needs Review : PR needs review by someone before being merged

Seems to cover all the bases, but I'm still not certain how useful the second 2 are (needs decision *is* useful).

Mainly, all open PRs are assumed to need review, we shouldn't need to have to label them to note that. And who is `Needs Work` directed to? If it's to notify reviewers, the tag will still there once it's updated by the submitter, so reviewers would have to open the PR to know the status either way (and as Joachim pointed out, only core devs can change labels). And if it's to notify the submitter, simply commenting what changes need to be made is more informative than tagging.

Again, if people feel the tags would be useful, we can keep them. I've made my case, but could go either way on this.

- Jim

[Joachim Durchholz]

One thing I saw proposed elsewhere is to group labels, by naming them
group:label.

Am 17.04.2015 um 07:40 schrieb James Crist:

> *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.

i.e. area:evalf, area:integrals, etc.

> *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.

status:valid, status:wontfix, status: duplicate

> - `enhancement`: not a bug, but something that would be nice to have

type:bug, type:enhancement

> *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.

platform:python.3 etc.

> *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.

One policy I just saw was "we see everything as normal, and have an
'urgent' classification, so we didn't see a need for 'low'".

I do not even see a reason for priority:urgent. Different things are
urgent for different people, so maybe something like
attention:release (for release blockers)
attention:security (for security holes - just an example, it's
irrelevant for SymPy)
attention:<whatever team we might else have>

> *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.

That might be attention:release.

Or maybe trigger:release-0.7.8 for issues that should have a review
trigger. (OTOH I don't like triggers; they tend to be done twice, and
afterwards everybody things they's be the second one. It's usually
better to have a status that people automatically know when to reset,
something labelled "trigger:" won't make them reset it.)

[James Crist]

That's just a name change for each label (one-to-one correspondance with existing labels), which can be done easily later. I'm just going to keep doing what I've been doing, and if we want to change the names later we can.

- Jim

--
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+un...@googlegroups.com.

To post to this group, send email to sy...@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/5531633F.2030802%40durchholz.org.

[Jason Moore]

Don't the colors already serve to group the labels?

Jason
moorepants.info
+01 530-601-9791

--

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+un...@googlegroups.com.

To post to this group, send email to sy...@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/CAJ2L7mfPJ28L72-bLCeedyuVgt-9x_mscf%2B4YXRi4sdmrg%3DVfA%40mail.gmail.com.

[Aaron Meurer]

Do people still use this? This is leftover from Google Code when
people literally uploaded patches to issues. It and NeedsReview were
the only way to keep track of patches so they wouldn't get lost. But
now that we have the pull request queue, I feel that it's mostly
unnecessary.

Aaron Meurer

>
> --
> 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+un...@googlegroups.com.
> To post to this group, send email to sy...@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/7ed5e065-3b3e-4210-9e1a-520b8dee133b%40googlegroups.com.

[James Crist]

> Do people still use this?

Many recent beginner PRs have been tagged with it. If no one is attached, I'd like to remove it.

- Jim

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+un...@googlegroups.com.

To post to this group, send email to sy...@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%2BLxqYOTbHqKEpAS9EFomwnMn8ENAh-MjHw6sWRvyv-mg%40mail.gmail.com.

[Joachim Durchholz]

Am 18.04.2015 um 01:28 schrieb Aaron Meurer:
> On Fri, Apr 17, 2015 at 2:05 PM, James Crist <cris...@umn.edu> wrote:
>> I have another label question:
>>
>> - `Needs better patch`: could be useful to indicate PR status to devs, but
>> mostly I feel that it comes off as rude to the person making the PR. I'd
>> like to remove it unless someone makes a strong argument to the contrary.
>
> Do people still use this? This is leftover from Google Code when
> people literally uploaded patches to issues. It and NeedsReview were
> the only way to keep track of patches so they wouldn't get lost. But
> now that we have the pull request queue, I feel that it's mostly
> unnecessary.

I'd be using them if I GitHub allowed me to (I'm using square brackets
in PR titles instead, like most others).
They indicate who's next to work on the PR. "Needs better patch"
triggers the PR author, "needs review" triggers reviewers (i.e. anybody
except PR author). I find that quite useful.

How about adding a hook that inspects comments, and places or removes
tags depending on what's in square brackets? E.g. [NeedsReview] adds the
NeedsReview label, -[NeedsReview] removes it.
The hook should check whether the user group has write access for these
labels (not all labels should be settable or resettable by everybody).

[Jason Moore]

Aaron,

I've noticed lots of the old imported issues from Google code referencing patches that have never been merged. Are all of these patches going to disappear when Google code does?

Should we be worried about that?

Jason
moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BLxqYOTbHqKEpAS9EFomwnMn8ENAh-MjHw6sWRvyv-mg%40mail.gmail.com.

[Aaron Meurer]

We should probably download all Google Code issue attachments, at
least for posterity. Anyone know of a good way to do it?

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/CAP7f1AiscYPYxi6TxdmG-7ADU4utEKG4Qo3BarTdfv31V%2BJgRw%40mail.gmail.com.

[Chris Smith]

Needs Decision is good to keep, but I would drop Needs Work. If the PR is open and has comments that haven't been addressed it needs work. 

If someone has made changes and they want to indicate that it'res ready for review again they can use the Needs Review -- or perhaps because of permission settings they can't? (But then anyone with permissions can reset the flag to indicate that changes were made and someone should review it again.) 

Passed Review is good if one is not going to commit the PR but feels that all issues have been addressed.

[Joachim Durchholz]

Am 17.04.2015 um 23:11 schrieb James Crist:
> That's just a name change for each label (one-to-one correspondance with
> existing labels), which can be done easily later.

Grouping labels might make it easier to manipulate them using hooks.
But then it's probably better to change the names once it's clear what
changes should be allowed by which user group. And once it's clear that
we can do this hook stuff in the first place.