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