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

["Emilio A. Sánchez" <[e-mail]>]

    Hi Robert,

    See comments inline.

El 18/01/12 23:36, Robert Sparks escribió:
...
>> 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

    Yes, I have the same results, and the 4 and 1 are subsets of the 8.

> draft-ietf-ecrit-. There are a slew of
> individual submissions that don't get matched.
>
> Some important ones missing include:
> draft-ietf-geopriv-policy-uri
> draft-ietf-sipcore-location-conveyance
>
> 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?

    I've done the same grep in the draft repository of the beta server 
and I've only got 10 results. I suppose that the difference is because 
the beta server doesn't have all the drafts or because you have more 
than one version of each draft.

    About the RFCs being filtered out, this was a bug and it is fixed now.

    About the draft 'draft-ietf-geopriv-policy-uri': The system doesn't 
found this draft because there is an inconsistency between the draft 
repository and the database. In the database the draft is in revision 03 
but in the draft repository the file is the one for 04 revision. The 
reason is that the database and the repository were updated in different 
dates.

    Of course this will not happen in a production server.

>> 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've run a script that updates the needed dates in the database so 
sorting will work without waiting that future changes in the drafts fill 
this info.

>> 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 management view is focused to the owner of the list and the read 
only to the other users. So in the read only view you'll find only the 
draft list and the links that an user may require: The ones for the 
mailing subscription and the rss links (they are in the meta of the page 
so your browser should detect them).

>> 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
>> http://beta.community.yaco.es/community/personal/adam%40nostrum.com/view/
> Fixed.
>>
>> 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?

    I resent you the email this morning.

    Best,