On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik <techto...@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. So that the process is open, straightforward, transparent 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. There are many ways for improvement, but if people won't try alternative approaches, they won't see them. I am not sure if I can manage to get to PyCon, so I didn't do any talk preparation, but if by chance I get there and there will be an Open Space, we can definitely find a lot of ways to improve Python development process for general public. As well as discuss ways to get around stdlib graveyard and dealing with really complicated problems that won't budge over the years - like out of the box UTC support. 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, 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. 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. 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. 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. -- anatoly t. _______________________________________________ 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
