Issue373

Title Add 'module' field to tracker
Priority feature Status chatting
Superseder Nosy List eric.araujo, ezio.melotti, loewis, r.david.murray, stephen, techtonik
Assigned To Topics

Created on 2011-02-01.16:33:54 by techtonik, last changed 2012-04-16.23:37:24 by ezio.melotti.

Messages
msg1902 (view) Author: techtonik Date: 2011-02-01.16:33:54
Module field will help to track patches, issues and commits related to separate modules from stdlib more easily.
msg1905 (view) Author: ezio.melotti Date: 2011-02-02.18:28:11
Even if knowing the module(s) related to the issue is useful, there are a number of problems that should be considered:
* there are hundreds of modules;
* there's no easy way to display so many options;
* several modules can be related to the issue;
* there are different modules depending on the Python version;
* there are different names for the same modules depending on the Python version;
* the list of modules must be updated when modules are added/removed/renamed;
* a new field adds clutter to the UI and more work for the submitters and triagers;
* searching for a specific module won't include the issues if the field is not set correctly (i.e. old issues and issues that haven't be triaged), the normal search will;
* there's no patch ready to implement (or attempt to implement) this feature;

Another option is looking automatically at the attached patches, figure out what files they affect, and make this information available.
This won't require extra work for submitters and triagers and no new fields are needed in the issue page (only a field in the search page).
msg1983 (view) Author: eric.araujo Date: 2011-04-13.15:51:43
From the wiki page about desired features:

When I want to find all bugs related to one module or package, I have to use the plain text search, which could give false positives and leave out valid results. For some packages I can use a component, e.g. Distutils, but not for all. I suggest a new field that would allow selecting what module(s)/package(s) a bug apply to. This would provide reliable and discoverable URIs for people who want to monitor particular modules or packages. [me]

This has been suggested and rejected a number of times on python-dev. --RDM

This information is not useful. Can you list the arguments? -- techtonik

No, but it would be great if you would search the archives and post links to the threads here. --RDM

I tried with no luck. It would be useful to find the threads for future reference, but your memory is enough for me to withdraw my feature request. –merwok

Found this: http://psf.upfronthosting.co.za/roundup/meta/issue78 —merwok

Nice catch. But that's not python-dev requests RDM is referring to. -techtonik
msg2004 (view) Author: techtonik Date: 2011-04-13.23:09:49
On Wed, Feb 2, 2011 at 8:28 PM, Ezio Melotti
<metatracker@psf.upfronthosting.co.za> wrote:
>
> Even if knowing the module(s) related to the issue is useful, there are a number of problems that should be considered:
> * there are hundreds of modules;

How many exactly? I doubt there is more than hundred.
https://bugzilla.gnome.org/ handles it pretty well.

> * there's no easy way to display so many options;

If the tracker suxx - change the tracker. It should help development -
not constrain it.

> * several modules can be related to the issue;

Make them tags.

> * there are different modules depending on the Python version;
> * there are different names for the same modules depending on the Python version;

Use both until subset of Python versions is not selected. If you need
to store both names - use module description format -
http://code.google.com/p/pydotorg/issues/detail?id=8

> * the list of modules must be updated when modules are added/removed/renamed;

Store module mapping in repository and throw warning during build
stage when files added or removed.

> * a new field adds clutter to the UI and more work for the submitters and triagers;

Split reporting in two steps like in Gnome or Eclipse Bugzillas. The
first step can also force search for similar items - like in
Launchpad.

> * searching for a specific module won't include the issues if the field is not set correctly (i.e. old issues and issues that haven't be triaged), the normal search will;

All issues should undergo triaging process. Opened old issues can be
retriaged. Closed could be left RIP. If you want to find them - use
module name in normal search - it will still work.

> * there's no patch ready to implement (or attempt to implement) this feature;
>
> Another option is looking automatically at the attached patches, figure out what files they affect, and make this information available.
> This won't require extra work for submitters and triagers and no new fields are needed in the issue page (only a field in the search page).

That's included in the proposal by the link above. But mind you that
issues without patches may never get any, because module maintainers
are unaware that there are issues for them. Modules should have their
own bug Atom feed.
msg2025 (view) Author: eric.araujo Date: 2011-04-21.16:42:56
>> Even if knowing the module(s) related to the issue is useful, there are a
>> number of problems that should be considered:
>> * there are hundreds of modules;
> How many exactly? I doubt there is more than hundred.

More than two hundreds.

>> * several modules can be related to the issue;
> Make them tags.

What are tags?

>> * the list of modules must be updated when modules are added/removed/renamed;
> Store module mapping in repository and throw warning during build
> stage when files added or removed.

Or maybe use the mapping in lib2to3.fixes.fix_imports (not sure the Python used for our Roundup is recent enough.)

>> * a new field adds clutter to the UI and more work for the submitters and triagers;
> Split reporting in two steps like in Gnome or Eclipse Bugzillas.

Interesting idea.

>> * searching for a specific module won't include the issues if the field is not set
>> correctly (i.e. old issues and issues that haven't be triaged), the normal search will;
> All issues should undergo triaging process. Opened old issues can be
> retriaged. Closed could be left RIP. If you want to find them - use
> module name in normal search - it will still work.

“Should” is nice.  How do you propose to implement it concretely?  It could possible to add a special “untriaged” state used in queries, but I’m not sure this would help; given enough volunteers with enough free time, bug triaging happens quite effectively.  The weekly email also helps find unanswered reports.

>> Another option is looking automatically at the attached patches, figure out
>> what files they affect, and make this information available.

Sounds good.  I’m sure difflib can do that.

> But mind you that issues without patches may never get any, because module
> maintainers are unaware that there are issues for them.

There are triagers who use the experts list (in the devguide) to add maintainers to nosy.
msg2031 (view) Author: r.david.murray Date: 2011-04-21.18:18:25
Please no two step process.  Also, I've never encountered a bug tracker-autosearch that worked worth a darn.
msg2033 (view) Author: techtonik Date: 2011-04-21.21:05:27
On Thu, Apr 21, 2011 at 7:42 PM, Éric Araujo
<metatracker@psf.upfronthosting.co.za> wrote:
>
>>> Even if knowing the module(s) related to the issue is useful, there are a
>>> number of problems that should be considered:
>>> * there are hundreds of modules;
>> How many exactly? I doubt there is more than hundred.
> More than two hundreds.

How many exactly?

>>> * several modules can be related to the issue;
>> Make them tags.
> What are tags?

Issue labels. Like GMail labels or labels in Google Code tracker. In
Google Code you can label the same issue as documentation issue and as
module issue, for example.

>>> * the list of modules must be updated when modules are added/removed/renamed;
>> Store module mapping in repository and throw warning during build
>> stage when files added or removed.
> Or maybe use the mapping in lib2to3.fixes.fix_imports (not sure the Python used for our Roundup is recent enough.)

As a quick hack, yes. But lib2to3 is underdocumented and can break at
any moment. Ideally lib2to3 should fetch information from branches of
versions it tries to convert.

>>> * a new field adds clutter to the UI and more work for the submitters and triagers;
>> Split reporting in two steps like in Gnome or Eclipse Bugzillas.
> Interesting idea.

We may need to leave an option for RDM to go directly to the second
page as he finds that the Roundup search suxx (and I totally agree).
However, if search scope is limited by module, the results will still
be useful.

>>> * searching for a specific module won't include the issues if the field is not set
>>> correctly (i.e. old issues and issues that haven't be triaged), the normal search will;
>> All issues should undergo triaging process. Opened old issues can be
>> retriaged. Closed could be left RIP. If you want to find them - use
>> module name in normal search - it will still work.
>
> “Should” is nice.  How do you propose to implement it concretely?  It could possible to add a special “untriaged” state used in queries, but I’m not sure this would help; given enough volunteers with enough free time, bug triaging happens quite effectively.  The weekly email also helps find unanswered reports.

In Google Code all issue have 'New' status by default. Triaged are
usually 'Accepted' or 'Acknowledged'. In Bugzilla new issues are
'unconfirmed'. In SCons we use 'untriaged' flag. Of course, triaging
is about priorities and without module maintainers, roadmaps and
release plans the process can be a bit pointless. So, if somebody
answers to b.p.o report, does that mean that the report is triaged?
What is the result of triage on b.p.o?

>>> Another option is looking automatically at the attached patches, figure out
>>> what files they affect, and make this information available.
> Sounds good.  I’m sure difflib can do that.

Difflib can't parse patches - it produces diffs only, but you can
download python-patch from Google Code. SVN version has a nice
diffstat capability.

>> But mind you that issues without patches may never get any, because module
>> maintainers are unaware that there are issues for them.
>
> There are triagers who use the experts list (in the devguide) to add maintainers to nosy.

You still don't allow new people to opt-in to help with module
maintenance, testing or patching.
msg2034 (view) Author: r.david.murray Date: 2011-04-22.13:56:38
Actually I think roundup search works very well, except for the case sensitivity on username searches.  The UI could use some help, but personally I won't be satisified with it until I get around to writing a command line interface for it :)  But that is off topic.

In our tracker, an untriaged issue has stage 'no selection'.

We can already label an issue with multiple components.

Having a way for non-commiters to indicate to everyone (but especially triagers) that they are interested in helping with a given module would be a nice feature.  Someone has to figure out how to implement it though, and I think any movement on this issue is going to have to start with a concrete UI design.
msg2035 (view) Author: stephen Date: 2011-04-22.15:06:05
R David Murray writes:

 > Having a way for non-commiters to indicate to everyone

In XEmacs's Roundup we allow any user to assign themselves an
"assignable" Role (which is misnamed "Developer").  All this does is
add them to the list that pops up for "Assigned-To" (there is also an
assign-to-me option there which allows anybody to assign an issue to
themselves, whether they have the Developer Role or not).

This was trivial.  A couple lines to create the Role in schema.py, and
a couple lines in the issue template to filter in Reviewers and
Developers in the Assign-To menu.

 > (but especially triagers) that they are interested in helping with
 > a given module would be a nice feature.

Limiting a user's offer to a given module would be more effort to
implement, but shouldn't be too hard.  Probably the code would be very
similar to the auto-nosy that some maintainers have for modules they
maintain.
msg2460 (view) Author: loewis Date: 2012-04-16.15:33:03
>  > Having a way for non-commiters to indicate to everyone
> 
> In XEmacs's Roundup we allow any user to assign themselves an
> "assignable" Role (which is misnamed "Developer").  All this does is
> add them to the list that pops up for "Assigned-To" (there is also an
> assign-to-me option there which allows anybody to assign an issue to
> themselves, whether they have the Developer Role or not).

In Python, we don't do assignments. What I could imagine is an
"ask for help" feature, where people indicate components that they
are willing to work on, along with an "ask for help" button available
to developers that sends anybody interested one of the relevant
components a help request. Triagers could then send a message to
these volunteers indicating what work needs to be done.
msg2461 (view) Author: techtonik Date: 2012-04-16.21:10:25
On Mon, Apr 16, 2012 at 6:33 PM, Martin v. Löwis
<metatracker@psf.upfronthosting.co.za> wrote:
>>  > Having a way for non-commiters to indicate to everyone
>>
>> In XEmacs's Roundup we allow any user to assign themselves an
>> "assignable" Role (which is misnamed "Developer").  All this does is
>> add them to the list that pops up for "Assigned-To" (there is also an
>> assign-to-me option there which allows anybody to assign an issue to
>> themselves, whether they have the Developer Role or not).
>
> In Python, we don't do assignments. What I could imagine is an
> "ask for help" feature, where people indicate components that they
> are willing to work on, along with an "ask for help" button available
> to developers that sends anybody interested one of the relevant
> components a help request. Triagers could then send a message to
> these volunteers indicating what work needs to be done.

I believe that was not an assignment in classical management style.
The primary purpose is to be able to assign a ticket to yourself to
become a ticket owner. You're basically "taking a task", but you can
also agree with somebody who triages tickets to assign interesting
stuff to you, so that it can popup in your personal Roadmap
automatically ('module' field which is a topic of this ticket can also
be used to add all interested subscribers) . You can then rearrange
items in your personal Roadmap list and the ordinary number of the
item in this list will then be displayed next to your name in ticket.
A separate feature(creep) is to enable tickets with several owners -
people, who are actually committed to do something about this ticket.
This gives people an ability to coordinate by looking into each
other's Roadmaps. This should also answer the question 'why my bug is
opened here for 5 years already?'.

The ticket owner know the stuff better and can can be coordinator
(mentor) for the task. Ticket owner with less number near to hos name
is more likely to work on it than other. Empty "owner" means that task
is not interesting, and somebody is free to take and a candy for
developers out of it.

I am not opposing "ask for help" feature proposal, but find it strange:
1. It implies that there is a separation between developers and non-developers
2. And that developers need help
3. That developers nudge volunteers to help them
I prefer the scenario where everybody is free to participate
regardless of the status. For example, you don't need to be a
developer to draw diagrams, write tests, PEPs, user stories, improve
tracker and python web site.
msg2462 (view) Author: ezio.melotti Date: 2012-04-16.23:37:24
Something similar to the "module" field already exists: the nosy list autocomplete can search for module maintainers and developers can add themselves if they are interested to specific modules.

One possible option is to move this information from the devguide to the tracker, so that everyone (including non-developers) can list the modules they want to maintain.
If this happens, we could also move the "interest areas" to the tracker, and possibly merge them with and/or use them to replace the "components".  The result would be a few fixed set of tags (module names, interest areas) that can be used to find people interested to a specific issue and possibly to mark/tag the issue.
If we want to add another layer of complexity we might also let the user decide what kind of notification they want to have (auto-assign, auto-nosy, just some visual hint for potentially interesting issues).

Once people agree on one of these ideas, someone will have to turn it in a concrete proposal (that should include both the UI changes necessary and how the whole thing is supposed to work), and then someone will have to implement it.


>>>> * there are hundreds of modules;
>>> How many exactly? I doubt there is more than hundred.
>> More than two hundreds.
> How many exactly?

209 on the "experts" page, 265 in help('modules').  Note that help('modules') lists some C _modules (like several _codecs_*) that are not listed on the "experts" page but otoh it just lists the root of packages, without listing all the subpackages (e.g. only 'xml' instead of 'xml.dom', 'xml.sax', 'xml.etree').
History
Date User Action Args
2012-04-16 23:37:24ezio.melottisetmessages: + msg2462
2012-04-16 21:10:25techtoniksetmessages: + msg2461
2012-04-16 15:33:04loewissetnosy: + loewis
messages: + msg2460
2011-04-22 15:06:05stephensetnosy: + stephen
messages: + msg2035
2011-04-22 13:56:38r.david.murraysetmessages: + msg2034
2011-04-21 21:05:27techtoniksetmessages: + msg2033
2011-04-21 18:18:25r.david.murraysetmessages: + msg2031
2011-04-21 16:42:56eric.araujosetnosy: + r.david.murray
messages: + msg2025
2011-04-13 23:09:49techtoniksetmessages: + msg2004
2011-04-13 15:51:44eric.araujosetnosy: + eric.araujo
messages: + msg1983
2011-02-02 18:28:11ezio.melottisetstatus: unread -> chatting
nosy: + ezio.melotti
messages: + msg1905
2011-02-01 16:33:54techtonikcreate