Issue78

Title Make use of keywords more obvious
Priority feature Status chatting
Superseder Nosy List brett.cannon, techtonik
Assigned To Topics

Created on 2007-01-15.21:30:02 by brett.cannon, last changed 2010-10-29.07:33:16 by techtonik.

Messages
msg368 (view) Author: brett.cannon Date: 2007-01-15.21:30:01
Not sure best way to go about this, but I did not get how to use the keywords
field until I added a new one and noticed it became a list.  The solution might
be enough to just have more than a single keyword to begin with so that it is
obvious it is a list (probably shouldn't start with Py3K anyway but make it a
version number or something).

I figured the keywords would be used for things like branches or something;
stuff that is really transitive and not consistent in Python like bugs on the
stdlib or the interpreter core.
msg418 (view) Author: gbrandl Date: 2007-03-10.13:45:51
As long as there are only 2 keywords, I'd really prefer checkboxes instead of
the clumsy multi-select list.
msg421 (view) Author: loewis Date: 2007-03-10.14:14:01
Changing the UI is an expensive operation. So I rather add a few keywords for you 
than changing the UI :-) How many keywords would you think are the threshold?

Notice that somebody suggested to have a keyword per module, to indicate what 
modules are affected in an issue.
msg426 (view) Author: brett.cannon Date: 2007-03-10.20:55:40
I have been thinking of having keywords like "needs docs", "needs
tests", etc. to make it easy for people to query for issues that they
can possibly work on and to make it easy to tell where an issue is.

But a keyword list of every module seems tedious and long.  I would
rather have a text field where you can just type in anything you want
than try to maintain a list of every single module in the stdlib.

On 3/10/07, Martin v. Löwis <metatracker@psf.upfronthosting.co.za> wrote:
>
> Martin v. Löwis added the comment:
>
> Changing the UI is an expensive operation. So I rather add a few keywords for you
> than changing the UI :-) How many keywords would you think are the threshold?
>
> Notice that somebody suggested to have a keyword per module, to indicate what
> modules are affected in an issue.
>
> ______________________________________________________
> Meta Tracker <metatracker@psf.upfronthosting.co.za>
> <http://psf.upfronthosting.co.za/roundup/meta/issue78>
> ______________________________________________________
>
msg430 (view) Author: loewis Date: 2007-03-11.00:45:30
> I have been thinking of having keywords like "needs docs", "needs
> tests"

For demonstration purposes, I added these.

>, etc

Not sure what "etc" is. We should have a list of keywords to be present
when the tracker goes life.

> But a keyword list of every module seems tedious and long.  I would
> rather have a text field where you can just type in anything you want
> than try to maintain a list of every single module in the stdlib.

The tracker already has full-text search, so maybe this is enough.
Some people are fond of having lots of machine-procssable information
associated with tracker items, as they argue that you can search for
it. They forget that somebody has to enter that information.

OTOH, if some volunteer promises to track "affected modules", I wouldn't
mind it is in the data structure of the tracker. There is no need to 
have that available from the beginning, of course.

Regards,
Martin
msg431 (view) Author: brett.cannon Date: 2007-03-11.01:58:36
On 3/10/07, Martin v. Löwis <metatracker@psf.upfronthosting.co.za> wrote:
>
> Martin v. Löwis added the comment:
>
> > I have been thinking of having keywords like "needs docs", "needs
> > tests"
>
> For demonstration purposes, I added these.
>
> >, etc
>
> Not sure what "etc" is.

"etc" as in "so on and so forth".  In other words there are more
possible keywords but I don't want to list them all right now.  =)

>We should have a list of keywords to be present
> when the tracker goes life.
>
> > But a keyword list of every module seems tedious and long.  I would
> > rather have a text field where you can just type in anything you want
> > than try to maintain a list of every single module in the stdlib.
>
> The tracker already has full-text search, so maybe this is enough.
> Some people are fond of having lots of machine-procssable information
> associated with tracker items, as they argue that you can search for
> it. They forget that somebody has to enter that information.
>

Right.  I don't mind having it either.  But I would rather have a
free-form field since that does not require keeping a list of all the
module in the stdlib, nor having to scroll through one.

> OTOH, if some volunteer promises to track "affected modules", I wouldn't
> mind it is in the data structure of the tracker. There is no need to
> have that available from the beginning, of course.
>

Right.

-Brett
msg432 (view) Author: loewis Date: 2007-03-11.08:21:26
Brett C. schrieb:
>>> I have been thinking of having keywords like "needs docs", "needs
>>> tests"
>> For demonstration purposes, I added these.
>>
>>> , etc
>> Not sure what "etc" is.
> 
> "etc" as in "so on and so forth". 

I understood that.

> In other words there are more
> possible keywords but I don't want to list them all right now.  =)

Ah, but I wondered whether you had any further keywords in mind,
or merely think that there could be more. To repeat myself,

We should have a list of keywords to be present when the tracker goes life.

If it is just "needs docs" and "needs tests", that might be fine.
I added them to the wiki as well. I'm unsure whether the keywords
fall into the "classification" information or in the "process"
information, though.

Regards,
Martin
msg433 (view) Author: brett.cannon Date: 2007-03-11.18:55:32
On 3/11/07, "Martin v. Löwis" <martin@v.loewis.de> wrote:
> Brett C. schrieb:
> >>> I have been thinking of having keywords like "needs docs", "needs
> >>> tests"
> >> For demonstration purposes, I added these.
> >>
> >>> , etc
> >> Not sure what "etc" is.
> >
> > "etc" as in "so on and so forth".
>
> I understood that.
>
> > In other words there are more
> > possible keywords but I don't want to list them all right now.  =)
>
> Ah, but I wondered whether you had any further keywords in mind,
> or merely think that there could be more.

The only other thing I can think of that bugs or patches need to have
happen is they meet coding guidelines, and a bug has been verified.
After that everything else I can think of that is obvious (e.g., more
info from the OP, the issue has been processed by a developer) is a
process thing.

> To repeat myself,
>
> We should have a list of keywords to be present when the tracker goes life.
>
> If it is just "needs docs" and "needs tests", that might be fine.
> I added them to the wiki as well. I'm unsure whether the keywords
> fall into the "classification" information or in the "process"
> information, though.

I think the former, especially if we use "need" keywords.
msg1828 (view) Author: techtonik Date: 2010-10-29.07:33:16
+1 for free form keywords. I'd also allow everybody to change them (like adding easy tags).
Or have a premoderation of keywords edits if smb. afraid of misuse.
Or at least have list of people with privileges to edit keywords accessible from popup help.
History
Date User Action Args
2010-10-29 07:33:16techtoniksetnosy: + techtonik
messages: + msg1828
2007-03-11 18:55:32brett.cannonsetmessages: + msg433
2007-03-11 08:21:26loewissetmessages: + msg432
2007-03-11 01:58:36brett.cannonsetmessages: + msg431
2007-03-11 00:45:30loewissetmessages: + msg430
2007-03-10 20:55:40brett.cannonsetmessages: + msg426
2007-03-10 14:14:01loewissetmessages: + msg421
2007-03-10 13:45:52gbrandlsetpriority: wish -> feature
status: unread -> chatting
messages: + msg418
2007-01-15 21:30:02brett.cannoncreate