[pydotorg-www] Process improvement to reduce bug triaging errors

Georg Brandl georg at python.org
Sat Apr 24 15:35:37 CEST 2010

Hash: SHA1

Am 24.04.2010 14:53, schrieb anatoly techtonik:
> Hello again, I haven't caught up with the latest threads, but here is
> one more thing for ecosystem consideration,
> I have an issue reported two years ago [1]. It was rejected and now I
> see commit that does what I proposed then.

Not exactly; see the issue comment.

> The status is still rejected.

OK, I've changed the status.

> How do I feel about it? Positive, because it is finally done
> (even partially). Negative, because I've waited for 2 years and didn't
> receive any feedback finally.

I don't understand the "finally".  Do you mean, right now when I made the
commit?  I hope you don't expect me to remember every issue I closed in the
last few years; there are hundreds of them.

> I don't blame Martin or Georg, because they do much work for the Python
> and have more chances to realize the human right for an error here.
> Thing to consider for process improvement is how to reduce such errors?

I object to the decision being called an error.  Are those arguing against
adding a feature in Python "in error", when it is finally decided to be
included?  At the time, we didn't see its use and decided not to add it.
Now, by some of the comments on Jesse's blog, I was convinced that having
these links is a good thing, even if we don't have the system for a direct
submission of change suggestions.  What really convinced me that one
commenter listed his complete experience while trying to get an issue fixed,
so I could learn what we can do better and what a first step that can
be implemented quickly can be.

Version: GnuPG v2.0.14 (GNU/Linux)


More information about the pydotorg-www mailing list