On Thu, Oct 30, 2008 at 17:27, Victor Stinner <victor.stinner@haypocalc.com> wrote:
Le Friday 31 October 2008 00:34:32 Paul Moore, vous avez écrit :
Agreed. I was thinking vaguely in terms of a type of voting - rather than a status or resolution, it might be more like the nosy list - a list of people who have said they think the patch is OK. The more people on the list, the stronger the assurance that it's acceptable. It is still a matter of trust, of course - nothing can avoid that.
I like this idea. But there are different things to review. Examples: - the bug report: is the bug reproductible? is the bug isolated? - a patch: the patch works? the patch looks correct? or invalid coding style, introduce a regression, or anything else
I was thinking in terms of summary reports (...)
I think that you need an new information: the issue progress, eg. - initial state: 0% => need more information - bug isolated: 25% => need a patch - patch present: 50% => patch needs reviewers - patch reviewed: 75% => patch just have to be applied - issue closed: 100% (done)
Beginners can search for progress < 25%. They can try to reproduce a problem to check the Python version, the OS, etc. Or just help to give more informations about the issue.
Core developers just have to check for progress >= 75%.
I have a similar list that I have been thinking about proposing. I did a blog post about it at http://sayspy.blogspot.com/2008/08/what-are-typical-steps-issue-goes.html and received positive feedback: * triage * verify bug * test needed * needs patch * patch review * commit review * committed/rejected That way all the steps needed are obvious. I was going to start working on proposing this after doing the first draft of the DVCS PEP. -Brett