Andrew Ducker <[email protected]> suggested:
> Some (maybe even a lot) of people have custom posting lists where they 
> ask people if they want to be on their "cat photo" filter.  They then 
> have to follow comments/poll entries, add/remove people by hand, etc. to 
> allow them access.

Yes, and I've wanted a reader-controlled solution instead ever
since tags were announced.  Like Mark Smith and Azalais Aranxta,
I've always seen this as a feature most reasonably implemented
by allowing people to subscribe to subsets of someone's journal
based on tags, very similar to what Joshua Kronengold described
tangentially while clarifying a different aspect of WTF-lists
(message-ID <[email protected]>, timestamped
Tue, 13 Jan 2009 15:51:00 -0600, if you want to find the message).
I hadn't worked out an exact syntax to use, but Joshua's is not
inconsistent with what I had in mind:

< What I'd -love- to see here is either whole-journal or
< filter-level constraints that let you limit to or exclude specific
< tags -- so you can watch at loudfriend-meme-quiz rather than the
< entire journal, or gamingfriend+theory to view only posts tagged
< theory (in your journal or in a specific filter).  This would, among
< other things, remove one of the big uses of trust lists, but that's
< cool; it's better to use it this way anyway.  I also think it would be
< useful to be able to express a filter in terms of other filters --
< this filter contains everyone -not- in my comics or close filters, etc.

As Joshua described, this could be applied to sub-filters of your
watchlist, so your default filter might include, say, 

        dglenn-long-politics-dream

while your "I'm busy and just skimming" filter could include

        dglenn+qotd+status

and your "I'm reading everything I'm interested in at all" filter
may include

        dglenn-meme


This does put onto authors the responsibility of using tags 
consistently, but your solution similarly requires them to
assign filters for their posts the same way.  Furthermore,
not only does this seem more logically a tags-feature (the
custom filters workaround is just that:  a workaround for the
lack of this capability using tags), it also gets around the
problem of folks who are using these filters _only_ to allow
their friends to opt out of seeing certain classes of entry,
rather than for their own privacy!  If a journalholder has a
"knitting" filter specifically to avoid boring hir non-knitting
friends, with a tag-based solution a reader no longer has to
be on hir trust- (currently friends-) list to see posts that
sie has no other reason to screen than that, about knitting.

Posts that _should_ remain friends-locked can be handled by 
putting them under general friends-lock and tagging them so
that the people permitted to see them can choose whether to
filter them out or not; and any filters that are for the
privacy and/or convenience of the poster rather than opt-in
filters for the convenience of their readers, would still be
handled as custom trust-filters as they are now.  AFAICT,
there's all win and no lose here, doing this with tags, as
long as this doesn't put unexpected strain on the database.

This, really, is exactly what I expected tags to be when they
were first announced, and have been waiting to see ever since.



As long as I'm nattering on about tags, a question:  the 
last time I crawled through the API docs (long after tags
were added, but several months ago by now), I was unable to
find any way for a client to set tags at posting time.
The main reason I _stopped_ using tags was that it was too
much of a PITA to go back in my browser and add tags by
hand after posting using Clive (a nuisance compounded by
my crossposting to multiple sites).  I _think_ I understand
how to add a tag option to Clive if I know the property to
set and its syntax.  Has that been added to the docs yet, 
or does someone who's had their fingers in the code recently
happen to remember seeing what I'm looking for?

                                        -- Glenn (dgl...@ij/CJ/etc.)
_______________________________________________
dw-discuss mailing list
[email protected]
http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss

Reply via email to