How to handle "delegate and forget"

[oliverbarnes]

Thinking about the scenario where participants sign up just to delegate to somebody who's active in a platform, and the problem where they never sign in again, have notifications off etc.

In this case, it could lead to a delegate having a de-facto long-term mandate, ultimately defeating the purpose of "liquid", where delegations are more fluid and ephemeral, being an alternative to actual mandated representation.

One possibility is having reminders, nudges and notifications of delegate activity sent to the delegator. But what if they have notifications off, or simply don't even look at notifs at all?

Another option is having delegations expire after a certain amount of time, which could be configurable. The flip side of this is that if they expire too soon and a delegator really just wanted to keep delegating to that person, it'll be annoying to them. Unnecessary friction/noise. Perhaps delegation confirmation reminders could help here as well.

[davefrey]

I like configurable policies to let orgs choose. I can imagine a bunch of point-configurations like whether global/space/issue/other scope delegation is allowed, whether delegations are until further notice or derived from another end date, or set to a separate end date or TTL. Whether to just remove, or notify/facilitate renewal.

But I think some prepackaged liquid policies would help us communicate tradeoffs, esp if we can leverage something from the language of the liquid voting domain, I assume that exists. "Delegate and forget" is a perfect example of a policy; behind the friendly name we initialize all the supporting configuration.

A wizard can be a good support too, like when LV enabled for an install or org or space or votable thing, we walk them through questions and propose a policy at the end.

This is quickly a lot of complexity; a few canned policies could simplify while still giving first-class attention to delegation approaches, which I think we really want to step up to, it's a differentiator.

[davefrey]

Then there's a question of what we can implement in the service, so this isn't just a bunch of code specific to Decidim or another LV client.