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

Robert Sparks <> Wed, 18 January 2012 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 371A011E80A2 for <>; Wed, 18 Jan 2012 14:37:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.443
X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4NQuLCwjhhIy for <>; Wed, 18 Jan 2012 14:37:03 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id ECB0811E807F for <>; Wed, 18 Jan 2012 14:37:02 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q0IMau0K057151 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 18 Jan 2012 16:36:57 -0600 (CST) (envelope-from
Message-ID: <>
Date: Wed, 18 Jan 2012 16:36:56 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To:, Henrik Levkowetz <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass ( is authenticated by a trusted mechanism)
Subject: Re: [yaco-community-tool] Observations from my second attempt at using the community tool
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the Yaco / Community ID Tracking and Notification Project <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Jan 2012 22:37:04 -0000

I revisited these with the updated test instance. Comments inline.

On 12/9/11 3:39 PM, Robert Sparks wrote:
> (The first attempt stopped abruptly with a crash).
> I spent some time trying to exercise this tool and ran into several 
> problems.
> 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 documents
> containing the text "location conveyance". It only found seven. There 
> are many, many
> more.
So it looks like rules of the form "All I-Ds that contain a particular 
text string" are
case-sensitive. I added three rules
"location conveyance" found 4 docs
"Location conveyance" found  1 doc
"Location Conveyance" found 8 docs

Now to sanity check that with my copy of the draft repository:
unexplicable:draft rjsparks$ grep -irl "location conveyance" . | perl 
-pe 's/-[0-9]{2}.(txt|xml)//' | sort -u | wc
       77      77    2884

So there are many drafts the search isn't finding.

Now the Documents tab shows only 8 drafts. I hope that's because the 4 
and 1 above are subsets
of the 8. All the docs returned are draft-ietf-geopriv- or 
draft-ietf-ecrit-. There are a slew of
individual submissions that don't get matched.

Some important ones missing include:

Now I can see the second not being in the set if you are filtering out 
drafts that have become RFCs
(its not obvious that you should do that though), but the first is still 
in IESG evaluation - very much
in the middle of process, so why isn't it being found?

> 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.
Sorting by Publication date still doesn't work, and the sort by change 
of status still doesn't make sense.
(It might help it make sense if it showed the date of the change of 
status somehow).
> I could only subscribe to lists or feeds from the read-only view of 
> the list.
> It is very unintuitive to look there for those options - why aren't 
> they available to me on my regular view?
I see you added links to the export tab. I still find the disparity 
between the read only view page and the modifiable page disconcerting.
> 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.
This is fixed.
> 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.
I confirmed that this works, at least to the level of making updates in 
the RSS feed.
I supposedly successfully subscribed to the email list for any change, 
but I haven't seen any
email after making changes to one of the matched documents as 
stream_user. There's a chance
that it's caught in grey-listing, but that would be odd given that I 
completed the subscription
email-confirmation dance just a few minutes before. Can you see any 
evidence that it _tried_
to send me email related to the change in a state of one of the 
documents on the list? If so,
please send me the message-id?

You responded to the rest below already - there's nothing there for me 
to retest
> 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.
> RjS