On Tue, Aug 16, 2011 at 8:15 AM, Vladimir Perić <[email protected]> wrote: > On Mon, Aug 15, 2011 at 10:57 PM, Aaron Meurer <[email protected]> wrote: >> On Mon, Aug 15, 2011 at 1:59 PM, Vladimir Perić <[email protected]> >> wrote: >>> Actually, I was trying to clean up our issue list a few times already >>> (generally closing a few way, way outdated issues and such) and I was >>> thinking about it in general. I was actually going to suggest we >>> organize a "Bug Day" (or rather a bug weekend perhaps) to organize and >>> close our issues. It would be cool to do this after all (or most) GSoC >>> work is merged in, as I assume that will make further issues obsolete. >>> Something like this might also motivate students to stay on SymPy by >>> having them fix random issues and "branch out" from their little bit >>> of code. Currently there are some 900 issues on the tracker and this >>> basically means you need a direct link to an issue to find it and for >>> it to be useful. >> >> Doc day sounds fun. Two years ago, we had a "Doc day", where a bunch >> of people improved documentation (this is, e.g., the origin of the >> Gotchas and Pitfalls document). Would you like to organize it? > > "Bug day", you mean? And yes, I'd like to organize something like > that. I think though that we should wait to get the current GSoC work > in, as people are busy working on that (reviewing, updating), and the > new stuff might fix even more old issues (the integration work for > example). I think doing it in two or three weeks is fine, though.
Sorry, typo :) > >> >>> >>> If we decide to do something like this (but also if we don't) we might >>> also want to give some thought to our general organization in the >>> issue tracker; it's a bit haphazard at the moment. Tagging works fine, >>> but I'd like to see some more care given to the assignment of >>> milestones - we don't really have any rules for it (unless I'm missing >>> something). The problem here is that issues with milestones get pushed >>> to the top of the list and get much more exposure as such; on the >>> other hand, a lot of these aren't being worked on and so they clutter >>> the list. Of course, this problem might simply disappear if we trim >>> down our 900 issues to 200 or something (not that I expect it, >>> though). >> >> The problem with milestones is that probably 80% of issues with >> milestones get postponed at the release. Because this is a volunteer >> project, the milestones really have no meaning other than "this would >> be great." If no one works on an issue, it doesn't get fixed, >> regardless of how important it is. >> >> I do agree that milestones are abused a little. The thing is, once >> someone attaches a milestone to an issue, it never gets removed, just >> postponed. >> >>> >>> As part of a move to a more rapid release schedule, I'd like to see >>> milestones used just for regressions (and perhaps some very obvious >>> bugs) and have all issues without a milestone. We could introduce >>> additional priority levels to further differentiate issues if >>> required. This is just a thought, though, I'd much rather just have us >>> be consistent. There's no point in adding a milestone to some random >>> issue unless someone is working on it. >> >> I agree. Fewer issues should have milestones. > > Ok, so lets remove them and decide how we are going to use them in the > future. You have bulk editing privileges, so just remove it as you see > fit. I think "milestoned" issues shouldn't take up more than one, two > screens (they take ~4 for me ATM), so that's perhaps 15-20 issues at > the most. Bulk editing out the milestones is a bad idea, I think. You need to read each issue to see why the milestone was attached and judge on an individual basis if it's important. The next time I do a release, when I go through the milestoned issues, I'll consider deleting the milestone instead of postponing it for each issue. I'll add a note about this to the release guide. > >> >> I've been using the label Priority-Critical for issues that absolutely >> *must* be fixed before the next release. The main purpose that the >> milestones hold is that they are generally all gone through before a >> release, and either fixed or (more usually) postponed. > > Ok, I feel if we cut down on the amount of issues with milestones we > can then actually use milestones and not a special label, but an extra > label is ok too. Perhaps it would be a good idea to write a wiki page > detailing our current practices (basically, how you feel is best/how > you do it, because there aren't any rules anywhere) and we can work > from that. > >> >> By the way, I think we should have more labels. There are a bunch of >> topics that have a ton of associated issues, but are not grouped >> together with any label. If you want to tag a bunch of issues with a >> new label, just let me know, and I will create a new label in the >> system (otherwise it will bug you about not having an official label). >> I also have the ability to bulk edit issues, so if you want, you can >> just give me a list of issues and I will mark them all with a given >> label. > > Yeah, more labels are probably a good idea. I think the automating > cc-ing of people for certain labels might be a big help (like you have > me set for Python 3 and Testing) and if we had finer-tuned labels more > people would be willing to put up with the extra traffic that entails > (I know my two are almost unused). As for the actual labels to add, I > don't know, I'm not really that familiar with most parts of SymPy. At > the very least, each of our modules (directories under sympy/) should > have their own tag. If there are a bunch of issues relating to the same thing, then they should be grouped with a label. If it's not specific enough, though, it won't be very useful. For example, just having a "functions" label wouldn't be very helpful, I think. And you'd need to be careful with a "core" label or else just about everything would fall under it. > >> >> I can also do other things like change the default ordering of issues >> (right now it is lexicographic with respect to Milestone, then >> Priority, then reverse Stars, then ID), add new labels, make only one >> in a group of labels allowed (like is done with type, priority, and >> milestone), create issues templates, and apply certain rules to issues >> based on what labels it has. > > I think the current order is fine (if we trim down the milestones, of > course). I also don't know if creating templates or the other stuff is > needed really, but I'll give it some thought. Just letting you know the sort of things that can be done. Let me know if you have an ideas. Aaron Meurer > >> >> Aaron Meurer >> >>> >>> Thoughts? >>> >>> On Mon, Aug 15, 2011 at 9:30 PM, Aaron Meurer <[email protected]> wrote: >>>> Hi everyone. >>>> >>>> I was bored today, so I wrote up a little script that opens a random >>>> open issue in the issue tracker in your default webbrowser. It's at >>>> https://github.com/asmeurer/Issue-Tools. I put it inside a large >>>> GitHub project in hopes that I or some of you will write some other >>>> cool or useful tools for working with the issues. >>>> >>>> But hopefully this little script will be useful to those of you who >>>> get bored and want to contribute to SymPy, but don't really have >>>> anything specific that you want to do. Just open a random issue and >>>> work on that (or, as seems to be common, decide that the issue is >>>> outdated and close it). >>>> >>>> Aaron Meurer >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "sympy" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/sympy?hl=en. >>>> >>>> >>> >>> >>> >>> -- >>> Vladimir Perić >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/sympy?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> >> > > > > -- > Vladimir Perić > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
