From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Improving browsing and discoverability in the Packages Menu Date: Mon, 20 Apr 2015 12:30:38 +0100 Message-ID: References: <871tjgj010.fsf@ericabrahamsen.net> <7b3b0d19-01d4-4f97-b85e-19383bee5605@default> <87twwbdwjd.fsf@ericabrahamsen.net> <87d22zcde3.fsf@gmail.com> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c364a65c27b00514264240 X-Trace: ger.gmane.org 1429529449 4658 80.91.229.3 (20 Apr 2015 11:30:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 11:30:49 +0000 (UTC) Cc: emacs-devel To: Alexis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 13:30:49 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yk9ua-0005mT-Rz for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 13:30:49 +0200 Original-Received: from localhost ([::1]:52787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yk9ua-000781-1b for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 07:30:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yk9uS-000770-Rk for emacs-devel@gnu.org; Mon, 20 Apr 2015 07:30:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yk9uR-0005No-LC for emacs-devel@gnu.org; Mon, 20 Apr 2015 07:30:40 -0400 Original-Received: from mail-la0-x233.google.com ([2a00:1450:4010:c03::233]:32852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yk9uR-0005NV-31 for emacs-devel@gnu.org; Mon, 20 Apr 2015 07:30:39 -0400 Original-Received: by layy10 with SMTP id y10so124266264lay.0 for ; Mon, 20 Apr 2015 04:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HiQ6cvbOWZ/0l21lINW/woHHJT6H5lXUbBtqN6cyeII=; b=xjhQvIRVpsQPYhZkPaamwjEJLNOd5MmdRkt2nQ5S2wGpMAYx6+EJhHr/R5m8Wfc6o8 8/xad9eM4qCEZ25yJXgELJkkcKFOd+Cdsj/v0O3kLlT7oT01R+sUHIAfzk0wM8eLWB9L RpGodBZ4VvlmPrsuC4wtgA4TpscWQaUzCi6X2P3WzG3dHN+hjGoX8XvUwzBNTNQBqqM2 SxMU5okDVOW15wyi6Ijr4CIyOeFVAiZg6oUFCVdkRLSHXb/6e7JM+WUpbaoNXY5w9QVo 67/Q08fCZrxqi3jbN2TXVD34YFbcwU5b/kZFAY+xCf+tYfPAa7x9OB2qy6qxj9uXBxpz Woow== X-Received: by 10.152.87.204 with SMTP id ba12mr15518602lab.35.1429529438200; Mon, 20 Apr 2015 04:30:38 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Mon, 20 Apr 2015 04:30:38 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Mon, 20 Apr 2015 04:30:38 -0700 (PDT) In-Reply-To: <87d22zcde3.fsf@gmail.com> X-Google-Sender-Auth: mMj8TPBdo0p4OpWw6tjzF_jwquM X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185695 Archived-At: --001a11c364a65c27b00514264240 Content-Type: text/plain; charset=UTF-8 On Apr 20, 2015 12:17 PM, "Alexis" 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. --001a11c364a65c27b00514264240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 20, 2015 12:17 PM, "Alexis" <flexibeast@gmail.com> wrote:
>
>
>> This by itself will take a very long time, if ever, to have any ef= fect. It would have to be coupled with something else.=C2=A0 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 dev= eloper to either change the keyword or ask us to add it in.=C2=A0 Is that t= oo 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 &#= 39;official' keyword? (i currently include it in the list of keywords f= or `org-vcard', the other two being "outline" and "org&q= uot;.)

I'd say yes.

>=C2=A0 Should i instead replace the "vcard" ke= yword with "contacts", given that people could plausibly find `or= g-vcard' via searching package names instead of keywords for the term &= #39;vcard', but currently wouldn't find it were they thinking in te= rms of "contacts management"?

Use both.

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

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

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

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

--001a11c364a65c27b00514264240--