I don't know why a task saying that the point of tokens on Phabricator is unclear would get so many tokens.
recursion

I think it would help if we only had a subset that had at least a loosely documented meaning at mw:Phabricator/Tokens , where I have added links and meanings for some of them.

Some of the tokens have a mostly well established meaning, such as Like and Dislike. The currency tokens also borrow from symbols that are commonly understood.

However the majority of them have no clear meaning, even in English, so if some groups are currently using them for specific meanings they are effectively having a private conversation in public, and we should be rejecting exclusionary communication methods.

And of course the situation is much worse for ESL. e.g. even with the currency tokens, the first three would be more inclusive if the hover-overs for the first three mentioned "bronze", "silver" and "gold", as those 'value' meaning are mostly universal understood. "Haypence" is especially confusing, as Heypence is plural, while the icon only has a single coin. The most common actual haypence was the three-halfpeny, a single silver coin. I've created redirects on English Wikipedia to try to guide people to the most suitable article about the bronze coin, whereas previously it was directing readers to the silver three-haypenny.

Since a few months I explain the meaning of my tokens at https://phabricator.wikimedia.org/p/Ricordisamoa/

When @QuimGil awarded a token to one of my tickets on phab: T166981, I started trying to figure out what particular tokens meant. @Qgil awarded me a "Yellow Medal" and I am now in search for the meaning of medals I can't figure looking at the icon. :)

they are arbitrary, essentially just a way of showing appreciation.

As tokens are per task and not per a specific comment, I'm unsure whether a token added at a certain point in time refers to a recently added previous comment, or really to the task itself.

Given that there is no shared interpretation of what a specific token means, I consider tokens pretty often noise (or "fun", depending on your point of view).
(Furthermore, I would not interpret an added thumbs-down token as "appreciation". ;) )

Tokens *could* be useful to avoid noisy "me too"/"+1"/"meh" comments which would not add technical value - if tokens were per comment and not per task, plus had a clearer/shared meaning. IMHO, GitLab manages slightly better by having two default tokens (thumbs-up/thumbs-down), a questionable "way more random emoji tokens" dropdown button, and tokens per comment/task description but not per task:

Has the right energy but it's too verbose and lacks battle tested emojis.

🤔😅😂 🎉 🚀

In T899#792191, @Qgil wrote:

[…]

So yes, Tokens is an application and it can be technically disabled. However, I don't see a reason to remove it. Tokens are not doing any harm, and they seem to be doing some good.

Then one day code review will arrive here, and chances are that people involved will use them as equivalents of +1, 0, -1, this time as part of a process.

The problem as that with tokens as currently implemented, there is no per-token count, just a global count. The existence of negative reactions in particular makes the Token Leader Board less valuable than it might seem to be.

I agree that tokens do some good, and am not convinced that they should be disabled at this time given that an alternative is badly needed. But they are far from being as practical as GitLab reactions, and they are a lot less clear. As @MZMcBride and @Aklapper explained, they actually do some "harm", when we consider the cost their complexity brings. I have been using ITSs for decades, through way too many engines (Jira, Bugzilla, Mantis, Redmine, SourceForge, debbugs, Trac, Forgejo, YouTrack, GitLab, Azure, Launchpad and more) and it took me a while to figure out tokens. The terminology is unclear (and misleading, in "award a token").

@Aklapper: Nobody asked about "your"(?) plans. What are you declining?

@Chealer: What did you reopen?
We don't plan to disable the tokens feature. We don't plan to clarify what tokens are good for.

If you have specific requests regarding the "Token Leader Board" or such, then please feel free to file specific requests by using the Feature template - thanks for your understanding.

In T899#10981188, @Aklapper wrote:

@Chealer: What did you reopen?

Uh… this report? 🤨

We don't plan to disable the tokens feature. We don't plan to clarify what tokens are good for.

That is fine. And since that is not what I asked you, I hope you also don’t plan to share any more non-plans (in particular if you're not decent enough to explain who you mean by "we").

If you have specific requests regarding the "Token Leader Board" or such, then please feel free to file specific requests by using the Feature template - thanks for your understanding.

It is unclear who you are addressing, but that is only appropriate for some types of problems. Thanks for letting the system advise on the course appropriate to their situation.

Sure. As the maintainer of Wikimedia Phabricator, I do not plan to address this issue and won't accept changes. Thus this issue shall remain in "declined" state. Thanks for your understanding.

In T899#10984481, @Aklapper wrote:

Sure. As the maintainer of Wikimedia Phabricator, I do not plan to address this issue.

Nobody asked you to do that. Once again, I hope you also don’t plan to share any more of your non-plans.

Thus this issue shall remain in "declined" state.

Issues can be ignored, but not "declined".

Thanks for finding constructive ways to contribute to this ticket and ITS

@Chealer What are you trying to fix please?

I am asking because you said above "I agree that tokens do some good, and am not convinced that they should be disabled at this time given that an alternative is badly needed. ".

So seems like we agree it should not be disabled.

We also know what we use them for. So that is no longer unclear.

What is there left to do besides discussing if "declined" or "resolved" is the right way to close it out?

Greetings Daniel,

In T899#10984913, @Dzahn wrote:

@Chealer What are you trying to fix please?

First, I do not consider this as a bug report. I did mention one minor defect, but this should generally rather be understood as a request for improvement.
I stumbled on this ticket while searching the most important issues in this ITS. Since Wikimedia Phabricator does not track issue importance, I resorted to the Token Leader Board, which sorts tickets based on their number of tokens.
Oddly enough, the first ticket I saw going over the list was this one! Yet, it had been incorrectly marked as declined. This shows that contributors do not use tokens much. The fact that they were used on a low-priority ticket which so few people care about and that it stayed miscategorized for a decade is the result of 2 phenomena:

1. A large share of contributors do not generally use tokens, most likely because they do not know their purpose.
2. As a result of #1, a large share of those who read this report "awarded" it very different tokens, presumably to experiment with them.

Both of these show that a large share of contributors do not master tokens, even if Phabricator’s interface gives them considerable prominence. This supports @MZMcBride’s claim that tokens are unclear.

My own experience with Wikimedia Phabricator is also telling. My activity shows I did quite a few contributions over years before I first "awarded" a token, in December 2024. Although I am too old to treat my memory as a reliable source, I like to think that I can still remember having indeed recently understood what tokens were about, even though I noticed their presence in the interface long before that. I seem to remember that I initially confused them with bounties, and probably did not realize that I could "award" them.

I am asking because you said above "I agree that tokens do some good, and am not convinced that they should be disabled at this time given that an alternative is badly needed. ".

So seems like we agree it should not be disabled.

I agree that they should not be disabled at this point, in particular since at this point, just disabling would itself constitute a change which could confuse (and perhaps anger) those users who understand/use them.

Ideally, we would have fields to track issue importance, projected task costs, ticket quality, and perhaps direct ways to reward report authors (with kudos/reputation). Since we only have priority and tokens to do all of that, and since the priority field supports a single value, tokens have important suppletive value.

We also know what we use them for. So that is no longer unclear.

"We"―as in Phabricator administrators, I and the handful of us still following this ticket―do know their use. But their purpose remains just as unclear to the average contributor who has probably never used Phabricator elsewhere, like myself (even though I contributed to hundreds of other ITSs).

What is there left to do besides discussing if "declined" or "resolved" is the right way to close it out?

There are several ways to approach this. Ideally, tokens should be replaced with a number of features. In particular:

1. Importance tracking (in its most basic form, a dropdown field)
2. Task complexity/cost estimation (also a potentially complex topic, but a dropdown field in its most basic form)
3. Reactions to reports (and comments), akin to GitLab’s
4. Ticket ratings (in its most basic form, a "moreinfo" field)

Realistically, these are considerable investments which must happen upstream.

Shorter term, we can also just "cleanup" tokens:

1. finding an activity description more accurate than "awarding a token"
2. finding a clearer name
3. in general, implement a proper UI for the current concept.

Pragmatically, the first thing to do would be to forward this upstream. If the result is not promising, we can keep tracking this and at some point evaluate the set of Phorge issues and whether we should switch to a more successful engine (none of which is particularly great, unfortunately) or invest upstream.

In T899#10986042, @Chealer wrote:

Greetings Daniel,

Greetings, Chealer.

First, I do not consider this as a bug report.

Well, it was reported by another user over 10 years ago.

I did mention one minor defect, but this should generally rather be understood as a request for improvement.

Alright, but that changes what the ticket was originally made for. It asked to clarify what this feature is for and to disable it. Recycling a ticket for something else can be fair under some circumstances but I don't think this is one.

Mostly because requests to add _new_ features is something to report against upstream. So it would likely be the wrong bug tracker. But also because the original ticket author did not ask about new features.

Wikimedia Phabricator does not track issue importance

This is probably an old discussion but you mean that "priority" only indicates how likely is something to happen soon and not how important it is?

Yet, it had been incorrectly marked as declined.

The ticket says "may make sense to disable". You agree to NOT disable, I agree to NOT disable, the maintainers of the service agree to NOT disable.. nobody actually supported disabling. So "declined" is correct for that.

For the "clarify what it is used for" it should be "resolved". But since both are in the same ticket.. either is ok.

This shows that contributors do not use tokens much.

Apparently they DO use them as you say in your next sentence. I also don't see how one logically followed from the other.

The fact that they were used on a low-priority ticket which so few people care about and that it stayed miscategorized for a decade

People have different definitions of what "priority" really means. Earlier when you claimed that Wikimedia Phabricator does not track "importance" I assumed you mean that priority is not equal to importance to you. Now it seems like it is though.

1. A large share of contributors do not generally use tokens, most likely because they do not know their purpose.
2. As a result of #1, a large share of those who read this report "awarded" it very different tokens, presumably to experiment with them.

I don't see how "awarding many different tokens" could be a result of "contributors do not generally use tokens". I also don't think we have actual numbers how many use them. I also don't see how it's a problem one way or another. The reason that they use different tokens probably just means they have different opinions or don't want it to be boring. I am generally missing a problem statement here.

Both of these show that a large share of contributors do not master tokens

I think that's still unknown. But also see above.

even if Phabricator’s interface gives them considerable prominence.

That's an upstream issue. It's extremely unlikely that WMF will fork Phorge to add a new system that replaces tokens. (if that is what you are asking for? is it?)

I agree that they should not be disabled at this point, in particular since at this point, just disabling would itself constitute a change which could confuse (and perhaps anger) those users who understand/use them.

This part I fully agree on. Which means it's correct to call this declined.

Ideally, we would have fields to track issue importance, projected task costs, ticket quality, and perhaps direct ways to reward report authors (with kudos/reputation).

Fair enough, but we can't do this with our current resources and it certainly would be a completely different ticket or rather a large project involving buy-in from management and many stakeholders.

Since we only have priority and tokens to do all of that, and since the priority field supports a single value, tokens have important suppletive value.

If they have value that's just another reason to keep them around. Hence "declined" to disable them.

"We"―as in Phabricator administrators, I and the handful of us still following this ticket―do know their use. But their purpose remains just as unclear to the average contributor who has probably never used Phabricator elsewhere, like myself (even though I contributed to hundreds of other ITSs).

I don't think there is a relation to being administrator. For the most basic example a token with a thumbs up and thumbs down seems pretty self explaining to me. I personally use them mostly just to thank people who resolved a ticket to show my appreciation without creating yet another comment and notification.

There are several ways to approach this. Ideally, tokens should be replaced with a number of features. In particular:

1. Importance tracking (in its most basic form, a dropdown field)
2. Task complexity/cost estimation (also a potentially complex topic, but a dropdown field in its most basic form)
3. Reactions to reports (and comments), akin to GitLab’s
4. Ticket ratings (in its most basic form, a "moreinfo" field)

If you would like to request new features that's fair but please do so as a new request.

Keep in mind though that it's likely that they should be created in https://we.phorge.it/ and not here. Unless it is only about configuration of existing features.

Whether WMF wants to do things like "cost estimation" is more a question for management though.

Furthermore your request would have to start with a discussion what "importance" even means because I know people have different opinions on that. Such discussion would be appropriate for a mailing list or talk page, most likely. Same for what "ticket ratings" are since I am not immediately sure I understand that part.

Realistically, these are considerable investments which must happen upstream.

Agreed, which just means this ticket should be closed.

Shorter term, we can also just "cleanup" tokens:

1. finding an activity description more accurate than "awarding a token"
2. finding a clearer name
3. in general, implement a proper UI for the current concept.

Will it really clear up things for anyone to divert from upstream and any other Phorge installation? I have doubts. Just means we are a special case.

Pragmatically, the first thing to do would be to forward this upstream.

Yes, please do that.

whether we should switch to a more successful engine (none of which is particularly great, unfortunately)

Would be a huge multi-year project not going to happen ..unless there are much more important reasons than this. Donors would be rightfully upset and users annoyed if we did this just because of such a detail.