[yaco-community-tool] Observations from my second attempt at using the community tool

Robert Sparks <rjsparks@nostrum.com> Fri, 09 December 2011 21:39 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: yaco-community-tool@ietfa.amsl.com
Delivered-To: yaco-community-tool@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C667621F86F6 for <yaco-community-tool@ietfa.amsl.com>; Fri, 9 Dec 2011 13:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Y7hTkTx31bmw for <yaco-community-tool@ietfa.amsl.com>; Fri, 9 Dec 2011 13:39:57 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2376121F86EC for <yaco-community-tool@ietf.org>; Fri, 9 Dec 2011 13:39:56 -0800 (PST)
Received: from dn3-177.estacado.net (vicuna-alt.estacado.net []) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pB9LdnQW029395 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 9 Dec 2011 15:39:50 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <4EE28025.5030307@nostrum.com>
Date: Fri, 09 Dec 2011 15:39:49 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: yaco-community-tool@ietf.org, Henrik Levkowetz <henrik@levkowetz.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: is authenticated by a trusted mechanism)
Subject: [yaco-community-tool] Observations from my second attempt at using the community tool
X-BeenThere: yaco-community-tool@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the Yaco / Community ID Tracking and Notification Project <yaco-community-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yaco-community-tool>, <mailto:yaco-community-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yaco-community-tool>
List-Post: <mailto:yaco-community-tool@ietf.org>
List-Help: <mailto:yaco-community-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yaco-community-tool>, <mailto:yaco-community-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2011 21:39:58 -0000

(The first attempt stopped abruptly with a crash).

I spent some time trying to exercise this tool and ran into several 

I want to ask about what the expectations of the current implementation 
and test instance were
before asserting that these are bugs.

Should the search results be accurate? I set up a rule to search for all 
containing the text "location conveyance". It only found seven. There 
are many, many

Should sorting work? - I tried the various sort options in the display 
customization section.
Alphabetical by title or by filename worked. Publication date didn't. 
Sorting by change or
significant change produced results that didn't make sense.

I could only subscribe to lists or feeds from the read-only view of the 
It is very unintuitive to look there for those options - why aren't they 
available to me on my regular view?

The view URL itself is coding the username into the URL - why? I 
_assume_ you have coded policy
that doesn't let me look at Adam's list just because I know his login. 
If that's the case, stopping at
community/personal or using something like community/personal/mainlist 
and figuring out which
list to look at by seeing who was logged in seems a lot safer.

Similarly, the way this currently constructs the "read only" view 
necessarily makes all of the lists
public. The intent of 6293 was that these be private by default and only 
exposed if the person
wants to expose them. As it is now, I know I can see Adam's list by 
looking at

I logged in as stream_user. It does not let me change any state on any 
documents, so I couldn't
test the notification features.

The option to list "changed within 1,2,7 days" as separate columns would 
be better met with
just listing a column with the number of days since the last change 
actually in the column.

I forgot (and am subsequently surprised) that 6293 restricts users to 
only one list.
I don't expect that restriction to survive actual use - I hope the code 
will be easy to adapt to the notion of
multiple lists later.