[Python-Dev] API refactoring tracker field for Python4

[Meador Inge]

On Fri, Jan 7, 2011 at 11:20 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> This happened, because of poor bug management, where community doesn't
> play any role in determining which issues are desired.
> This mostly because of limitation of our tracker and desire of people
> to extend it to get damn "stars", module split, sorting, digging and
> tagging options.

Adding a few new features to the issue tracker isn't going to make the
forgotten changes problems (assuming that it is, indeed, a problem)
that you mentioned magically go away.  Tools alone don't fix problems,
there are people using the tools involved too, and getting people to
use tools effectively is much more difficult.  Adding more features to
a tool that is not be used effectively, just makes it be used even
less effectively.

I speak from recent experiences of helping roll out JIRA to a 50 man
engineering team.  The one regret that I have is that we turned too
many stars, bells, and whistles on instead of helping people create
good issue reports.  Some times there is very good reason to add such
features, but significant amount of data should be there backing that
decision up.  It is better to wait until the data is there pointing to
the problem.

I grabbed the following descriptions from a reply from another part of
this thread:

> Stars:
>  go http://code.google.com/p/support/issues/list
>  find Stars column
>  guess

JIRA has voting, which I have used.  However, it boils back to the
tools vs. people problem.  Enabling voting is useless if no one honors
the votes.  I have seen this happen.  You must have community support.

> Module split:
>  try to get all issues for 'os' module
>  try to subscribe to all commits for 'CGIHTTPServer'

I have myself wanted this as well before.  However, the downside is
that having more options to select from will inevitably increase the
amount of incorrect selections that are made.  Fewer choices, better
data.  I would rather have better data.

> Sorting:
> click on column titles in bug tracker search results

You can just do sorted searches, right?

> Tagging:
>  as a tracker user, try to add tag 'easy' to some easy issue

Are you suggesting that *any* tracker user be allowed to place
arbitrary tags on an issue?  If so, then I think that would be more
confusing as there would be no uniformity to the entries.  I like the
keywords in use on the tracker today better.

-- Meador