Brett Cannon wrote: > One thing to keep an eye on for old issues, Daniel, is the Stage > field. Setting that is nice for Bug Days as people can see what > issues still need a test written or could use a review, etc.
OK, I'll try to set a useful Stage for bugs I edit. I'll reread your blog post on stages and study the discussion. > I have a doc I am writing up at > http://docs.google.com/Doc?id=dg7fctr4_51cbt2vktw which outlines > what the various Stage values should mean. Feedback from you and > anybody else is welcome, although realize it is rough as I was not > planning to make this public quite yet. Looking good, I'll collect doc feedback as I learn Stages better. Here's some feedback on Stages themselves (still learning, probably misguided). Many old issues have patches without tests, or have patches and tests that are outdated. Others have patches (and sometimes tests), but aren't confirmed as bugs. So the Stage field would be easier to use if it included: 'not reproduced in current releases', 'reproduced, needs updating', 'is this really a bug?' (i.e., should I be writing a test/confirming or discussing the issue?), 'on hold/blocked' (has a blocking dependency). I'm not sure those would be useful for new issues, I think handling the important cases efficiently is more desirable than tuning the workflow for old issues. It's telling that the Stage that caught my attention was [triage] :D Thank you for the support and feedback (and Stages guide!), it helps a lot :) Daniel _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com