Am 01.02.2011 16:51, schrieb anatoly techtonik:
On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <techtonik@gmail.com> wrote:
To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome.
Anatoly, your constant efforts to try to force python-dev to adapt to *your* way of doing things, instead of being willing to work with the documented processes are *seriously* annoying. Which is a shame, since it obscures the fact that your underlying suggestions are often quite reasonable.
I'll abandon my efforts when you prove me that current "documented process" is a top-notch way for all interested parties to do a quality contributions to make Python better.
And who or what decides what this "top-notch way" is?
So that the process is open, straightforward, transparent
Ah. Well, that's definitely very a concise spec.
and doesn't waste people's time more than necessary to communicate a change, make it visible for all interested parties, get feedback, polish and finally integrate.
[...]
The most valuable contributions are coming from professionals, and these people often don't have enough time to follow "documented process". In the era of information abundance you often have only 140 symbols to communicate the idea,
That's a great idea for a change: report bugs by twitter. We need to set up a twitter search for #PythonBug, and then you simply enter #PythonBug the process is slow and it is converted to an issue on b.p.o. Very open, very transparent, and of course very straightforward. Let's not care about how to reach the submitter when clarification is needed, or what to do about patches. If it doesn't fit into 140 characters, it doesn't exist!
and instead of blaming people of annoying behavior, it might be more useful to make process intuitive and easy to follow. If that's not possible, there should always be an exact link to a reasonable explanation about why you need the process to be so complicated.
The new devguide (docs.python.org/devguide) should provide exactly that, and in a central location.
So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker.
As I explained, it is an *issue tracker*. And since in 99% of cases there is an actual issue underlying a patch, it is more than justified to use it to track issues that have patches.
It doesn't allow to monitor incoming patches by module, its search is very poor. Of course mailing lists are even worse in this regard, but there is nothing Python community can't deal with.
Exactly, so let us continue the ongoing work in improving the tracker.
The problem is to keep non-core people outside motivated, and the biggest problem with current "documented process" is that nobody even thinks about it.
I think others already wrote enough about that. Georg