Talk track filtering

[Michael Allan]

Thanks C,

> >    pinned      set       default        group
> 
> This is how it works atm.

So the behaviour you reported where it falls back to the pinned anchor
whenever a new diff is staged is correct (sort of).  We can't easily
tell whether the new diff (from clicking in the talk track, or
whatever) includes the currently staged actor (Test-1 in your case).
So we force-stage the anchor.  The anchor is guaranteed to be in any
diff on the talk track, because you're always filtering to the group.
So this is OK for now, I guess.

> > 
> >                set       non-default    pair
> 
> This does not work yet.

When you're ready to code this, please ping me.  I'll open a branch
and remove the forced anchor staging, then we can release together.

Mike


conseo said:
> Hey Mike,
> 
> > 
> > Let's document a filtering convention for the stage API.  This affects
> > both our code, and also the "actorName" problem we chatted about:
> > http://zelea.com/var/cache/irc/votorola/12-10/08
> > 
> > Here's what I propose.  This assumes a poll is staged: [1]
> > 
> > 
> >    defaultActorName [2]  actorName [3]  filter
> >    -------------------------------------------
> >    free        null      null           forest
> > 
> >                null      end            forest
> >                          candidate
> > 
> >                null      non end        branch
> >                          candidate
> 
> This has to be implemented properly next, because it needs apropriate mapping 
> to counts and the trees. We have discussed some approaches already.
> 
> >    -------------------------------------------
> >    pinned      set       default        group
> 
> This is how it works atm.
> 
> > 
> >                set       non-default    pair
> 
> This does not work yet.
> 
> > 
> > 
> > You'll probably be filtering on other properties too, but currently
> > only the actor is a mutual dependency, and only when a poll is staged
> > *and* the track is pinned.  So it's only the bottom half that we need
> > to document in the API.  But I discuss all four filters below.
> > 
> > free
> > ----
> > Here the vote track is animated and the user may explore votespace.
> > Talk lighting may be used to show the way, much as in geospace with
> > the geotrack [5].  Filtering is consistent with this.
> > 
> > (forest) Talk track shows diff messages for entire poll, i.e. entire
> > votespace forest.
> > 
> > (branch) Talk track shows messages for upstream votespace branch
> > (deep) as rooted in actor's candidate, i.e. including the candidate.
> > 
> > pinned
> > ------
> > Here the vote track is pinned to the default actor and immobile [4].
> > This happens in draft pages and the difference bridge, for instance,
> > where it allows for pair selection *instead of* exploring votespace.
> > Again, filtering is consistent with this.
> > 
> > (group) Talk track shows diff messages for default actor (pin) and
> > immediate cast relations, viz. with diffs between the pin and an
> > immediate voter, co-voter, base co-candidate, or candidate. [6]
> > 
> > (pair) Talk track shows all diff messages between the pin and actor.
> > 
> > There's probably no need to actually code any filtering for your first
> > deployment.  We only need to agree on the plan.  What do you think?
> 
> Following our structuring of the discourse in the tree form, your proposed 
> filtering shows all communication regarding the current context. Pinning 
> limits it to group level, while for browsing vote space we want to show all 
> relevant discussion on that level. So I agree. 
> 
> conseo