Is "proposal" still an apt abstraction?

[oliverbarnes]

Given people can vote on answers in some cases, or even on people, should we move towards a higher level abstraction like "votable"?

[oliverbarnes]

I see projects and people being fit into proposals: a proposal for a project, a proposal for a candidature.

But I have a hard time seeing that for answers. A proposal for an answer, in the context of multiple answers?

On the other hand, votable is very abstract, feels like something one would find in the innards of a voting system, programmer speak. Polymorphism, etc.

So there might be a cost in opacity to this change.

[jinjagit]

I think you're right. 'Proposal' makes little sense if I am asked a question and permitted to select an/some answer(s), which then are somehow weighted to contribute to some kind of result(s).

'Votable' would be a less misleading and more generalize-able name, and is fine by me. Maybe we can think of a less techy word, but I don't dislike it.

Merriam Webster says it's a thing, though it lists only adjective usage, not noun.

So, one drawback is that a dev might, at first glance, assume votable is something like a boolean variable; can_be_voted_on?

[oliverbarnes]

we'd have it as votable_url so it's unambiguous the data type we're asking for in the api

[davefrey]

Votable is super abstract, I agree.

subject could be another term, even if grammatically object would be more correct. But in the api, create_vote(voter, subject) and create_delegation(voter, delegate, subject) seem decent to me.

subject could be documented to be a url, for example, or anything that uniquely and durably identifies something being voted on. Or it could be explicitly subject_url though I think it limits unnecessarily.

proposal_url does make me wince though, I always match it to Decidim proposals, and it takes me an extra effort to separate the things. I think a new term will serve us well.

Our PB case of wanting to delegate at one level and vote at a lower level is an excellent use case, we should be able to describe the api interface with whatever new terms and feel completely comfortable fitting the PB case to it.

[oliverbarnes]

Subject is an interesting possibility. I think it should be typed, though - if a field accepts urls, it should only accept urls and nothing else, in which case it's good to be explicit about it. Else, it's really pretty vague imo.

proposal_url does make me wince though, I always match it to Decidim proposals, and it takes me an extra effort to separate the things. I think a new term will serve us well.

But decidim.barcelona literarily uses Decidim proposals for the initial priorization of projects, so that's a concrete case where proposals == projects in PB. Proposals then get imported as projects, but they're interchangeable.

I'm attached to proposals as a concept because in the end, participatory platforms are about having propositive platforms as an alternative to social networks, where free form conversation and kvetching breaks down. So having structured proposals is an important thing. it's the necessary "what do you propose, then?" step to civic participation, that's many times missing in mobilization and debates.

Of course, this is a platform concern. But I worry about the API itself not not conveying the basic concepts for participation.

One option might even be not supporting question and answers altogether. Unless this format is about a consultation where actual proposals are involved, bringing it closer to participatory budgets - with the difference that the selection of proposals is fixed.

[davefrey]

Propositions?

And it's okay if I wince ... I can get used to proposal_url, esp if Decidim (from where comes the ambiguity for me) is already overloading in this way.

I anticipate in any engagement that we'll be saying things like "proposal, as in decidim proposal" or "Liquidvoting proposal".

I trust your instincts

[oliverbarnes]

I looked into Propositions back in the beginning, and it seems like it has different meanings (including a malicious one). When I say "propositive" I mean platforms where one makes proposals, not propositions :)

It's interesting that you wince at "proposals", it could very well be that I'm using in some non-american idiom.

I'd say for now let's keep the current naming, but let this discussion percolate until the need for a change becomes clear.

[davefrey]

Your English sense of "proposal" is exactly right to my ear for most of the LV senses that come to mind, maybe it's a little weird in the case of multiple choice responses.

My wince is completely from the overloading, each time I see the word in decidim/lv context I'm wondering which sense applies. Add that some of the LV language itself is evolving, proposal = exactly proposal until just recently.

Maybe sharing the word "proposal" even supports us explicitly mapping from client domains to LV domain.

Agree, not a compelling time to change that now.

[davefrey]

Wondering about:

  create_vote(voter, subject)
  create_delegation(voter, delegate, scope)

Maybe we always vote subjects (so it's very concrete, always it's a thing like a PB project or a proposal or an answer to a poll), and always delegate for a scope (which could be equivalent or identical to one subject, that's the default situation I suppose)

Scope can correspond to or match exactly a subject, or be something higher, as high as 'global' (to the LV org/instance)

Implicit matching of subject and scope is tempting (eg via a path/url hierarchy) because it dodges a whole layer of managing associations, but feels pretty restrictive.

Otherwise we'll need api support for putting subjects into scopes. For a PB:

budget="http://my/budget/432"
project1="http://my/budget/432/project/1"
project2="http://my/budget/432/project/2"

create_delegation(voter, delegate, scope: budget)  # scope is an optional arg, though needed for PB etc
create_vote(voter, subject: project2, scope: budget)
...
create_vote(voter, subject: proposal_url)
...
create_delegation(voter2, delegate: voter, scope: proposal_url)
create_delegation(voter3, delegate: voter, scope: "global")

[oliverbarnes]

I can see how a scope could be flexible enough to be both a single item or everything, and I had already wondered about making it include global.

There's a flip side to that, though, and with Decidim this has already happened - everybody is confused about scopes there. Sometimes a concept is so flexible that it can mean anything, and people will always be asking for "what's a scope? give me an example" - and same goes for subject. And if people need to ask, chances are people will also be misusing it before even asking :/

The internal wiring for making a scope match a collection or a single votable item wouldn't be trivial either.

Given question/answers is so far the only scenario that really doesn't fit at all into the proposal abstraction, and that changing the abstraction might involve a great deal of pain, maybe it's better to leave it as is for now?

Until we get to an actual implementation scenario where absolutely we need to change it, at least.

[davefrey]

👍👍

[oliverbarnes]

Warming up to votable as after all the api interface will only be seen by api client developers.