RFC: how do you think we should treat ranking in this Agora, in particular as it grows?

I don’t like that this kind of list could grow into a fixed hierarchy

^ agree

I think it should be configurable per user. Either by a config setting in each user’s garden, or on the client side.

Different sort/rank configuration options:

• random
• order of creation
• upvotes

I’m generally wary of liking/upvote mechanisms, but they are probably OK. So long as they avoid gamification/addiction.

Not sure about putting uprank data within nodes themselves - it seems like metadata? I’m not sure I would do it, as my notes exist outside of this agora, too.

RFC: how do you think we should treat ranking in this Agora, in particular as it grows?

I don’t like that this kind of list could grow into a fixed hierarchy

^ agree

I think it should be configurable per user. Either by a config setting in each user’s garden, or on the client side.

Different sort/rank configuration options:

• random
• order of creation
• upvotes

I’m generally wary of liking/upvote mechanisms, but they are probably OK. So long as they avoid gamification/addiction.

Not sure about putting uprank data within nodes themselves - it seems like metadata? I’m not sure I would do it, as my notes exist outside of this agora, too.

agora ranking

• As of [[2021-11-06]] Agora ranking is essentially non-existent except for
  • 1. a hack in [[agora.py]] which upranks users [[@agora]], [[@flancian]], [[@vera]], [[@neil]] in that order — essentially admins in order of entry. This was hotfixed in when some long content that didn’t render well (due to garden conversion issues) grabbed top position in interesting nodes. It’s not a stable setup and I don’t like that this kind of list could grow into a fixed hierarchy.
  • 2. client-side, as implemented by [[vera]] — see, in the same node handler in [[agora.py]], the /uprank/ functionality. This is called by client side code for sorting.
• I think we should start working on actual better ranking.
  • One simple alternative would be to introduce upvotes/emoji reactions in the interface, and store those either in git (as a reaction log) or in, say, sqlite. This could be treated as ‘volatile’ data — treating all data not derivable from the [[agora]] main repo transitively as volatile seems like an OK design decision to me (it would be optional, so wouldn’t add to the initial setup cost).
  • Another alternative would be to support explicit upranking within nodes. So, for example, if I write [[uprank]] [[@neil]] in [[flaneur]], the Agora would render Neil’s node above mine.

RFC: how do you think we should treat ranking in this Agora, in particular as it grows?

I don’t like that this kind of list could grow into a fixed hierarchy

^ agree

I think it should be configurable per user. Either by a config setting in each user’s garden, or on the client side.

Different sort/rank configuration options:

• random
• order of creation
• upvotes

I’m generally wary of liking/upvote mechanisms, but they are probably OK. So long as they avoid gamification/addiction.

Not sure about putting uprank data within nodes themselves - it seems like metadata? I’m not sure I would do it, as my notes exist outside of this agora, too.

RFC: how do you think we should treat ranking in this Agora, in particular as it grows?

I don’t like that this kind of list could grow into a fixed hierarchy

^ agree

I think it should be configurable per user. Either by a config setting in each user’s garden, or on the client side.

Different sort/rank configuration options:

• random
• order of creation
• upvotes

I’m generally wary of liking/upvote mechanisms, but they are probably OK. So long as they avoid gamification/addiction.

Not sure about putting uprank data within nodes themselves - it seems like metadata? I’m not sure I would do it, as my notes exist outside of this agora, too.

• [[2022-06-08 06:59:36]] [[@vera:fairydust.space]] (link):
  • thinking about using https://jqueryui.com/sortable/ for [[agora ranking]]