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 a
Thanks Jim! That all sounds great to me and seems like a major improvement.
Rock and Roll!
Jason
moorepants.info
+01 530-601-9791
On Thu, Apr 16, 2015 at 10:40 PM, James Crist wrote:
> As of this writing, SymPy has 1648 issues open. That's more than numpy,
> scipy, or pandas (more than numpy a
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 wrote:
> As of this writing, SymPy has 1648 issues open. That's more than numpy,
> scipy, or pandas (more than nump
On Fri, Apr 17, 2015 at 11:13 AM, Aaron Meurer 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 wrote:
>> As of this writing, SymPy has 1648 issues
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
Also, did you kill the "Alternate Python" label? That was useful.
Aaron Meurer
On Fri, Apr 17, 2015 at 11:19 AM, Aaron Meurer 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 "cor
> 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 almo
On Fri, Apr 17, 2015 at 11:33 AM, James Crist 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`
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 repo
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
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 "Wait
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 ce
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 #FF, blue):*
Everything after `sympy.` for the specific submodule. Keep the naming and
casing consistent with the sympy namespace. If the rele
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
On Fri, Apr 17, 2015 at 2:47 PM, Joachim Durchholz wrote:
> One th
Don't the colors already serve to group the labels?
Jason
moorepants.info
+01 530-601-9791
On Fri, Apr 17, 2015 at 2:11 PM, James Crist wrote:
> 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
>
On Fri, Apr 17, 2015 at 2:05 PM, James Crist wrote:
> 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 a
> 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
On Fri, Apr 17, 2015 at 6:28 PM, Aaron Meurer wrote:
> On Fri, Apr 17, 2015 at 2:05 PM, James Crist wrote:
> > On Friday, April 17, 2015 at 1:34:55 PM UTC-5, Joac
Am 18.04.2015 um 01:28 schrieb Aaron Meurer:
On Fri, Apr 17, 2015 at 2:05 PM, James Crist 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
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
On Fri, Apr 17, 2015 at 4:28 PM, Aaro
We should probably download all Google Code issue attachments, at
least for posterity. Anyone know of a good way to do it?
Aaron Meurer
On Sat, Apr 18, 2015 at 12:04 PM, Jason Moore wrote:
> Aaron,
>
> I've noticed lots of the old imported issues from Google code referencing
> patches that have
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
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
22 matches
Mail list logo
