[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improving browsing and discoverability in the Packages Menu

From: Artur Malabarba
Subject: Re: Improving browsing and discoverability in the Packages Menu
Date: Mon, 20 Apr 2015 12:30:38 +0100

On Apr 20, 2015 12:17 PM, "Alexis" <address@hidden> wrote:
>> This by itself will take a very long time, if ever, to have any effect. It would have to be coupled with something else.  For instance, there could be a compiler warning if the package has unknown keywords. This wouldn't prevent the keyword from working, but it would inform the developer to either change the keyword or ask us to add it in.  Is that too much?
> Hmm .... i'm not sure how practical that last bit is.

Me neither. :-) just throwing ideas around.

> For example: should "vcard" be added as an 'official' keyword? (i currently include it in the list of keywords for `org-vcard', the other two being "outline" and "org".)

I'd say yes.

>  Should i instead replace the "vcard" keyword with "contacts", given that people could plausibly find `org-vcard' via searching package names instead of keywords for the term 'vcard', but currently wouldn't find it were they thinking in terms of "contacts management"?

Use both.

> Who would be the person or people making the decision on whether a keyword should be added, modified or removed?

We would just accept any keyword that doesn't already have an obvious equivalent. The point is not to be restrictive, but to prevent duplication like mail/email. We could also have some restriction like accepting at most 1 (or 2? 3?) new keyword request per package.

> Might such a process result in emacs-devel being flooded with interminable ontological bikeshedding?

Possibly. New packages are created at a rate of a few per day. It's hard to say how many new keywords that entails. Somebody could estimate it based on Melpa git history.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]