Codeberg/Community
54
325
Fork
You've already forked Community
12

New emoji for quick issue reactions #735

Open
opened 2022年09月25日 15:06:34 +02:00 by fnetX · 7 comments
Owner
Copy link

I propose to add the following useful emoji for the quick reaction menu for issues:

🤷 :shrug:

  • to indicate a response along the lines "I read the issue, but I can't answer it"
  • often issues get stale, because no one knows the answer. It looks like they don't care, but maybe they just don't know
  • an additional use in context is to indicate that you don't care

:white_check_mark:

  • indicate something was done without the need for a response
  • useful when comment contain tiny proposals or side-hints next to the main discussion

What do you think?

I propose to add the following useful emoji for the quick reaction menu for issues: 🤷 `:shrug:` - to indicate a response along the lines "I read the issue, but I can't answer it" - often issues get stale, because no one knows the answer. It looks like they don't care, but maybe they just don't know - an additional use in context is to indicate that you don't care ✅ `:white_check_mark:` - indicate something was done without the need for a response - useful when comment contain tiny proposals or side-hints next to the main discussion What do you think?

Reactions shouldn't always be replacement for comments. I don't receive a notification when a maintainer adds a reaction to my issue, so I will not be aware that a maintainer saw my issue and either is okay with it or has no clue(in which they should ask for a clarification etc.).

It can be broadly interpreted, but that's more a general issue with emoticons.

White check-mark is fine, as I mainly use 👍 for such occasions, but a checkmark could be used instead.

Not a fan of the shrug.

Reactions shouldn't *always* be replacement for comments. I don't receive a notification when a maintainer adds a reaction to my issue, so I will not be aware that a maintainer saw my issue and either is okay with it or has no clue(in which they _should_ ask for a clarification etc.). It *can* be broadly interpreted, but that's more a general issue with emoticons. White check-mark is _fine_, as I mainly use 👍 for such occasions, but a checkmark could be used instead. Not a fan of the shrug.

I think the checkmark is a good idea! I often use 👍 as an alternative but 👍 can be confused that you liked/agreed with the message not you solved the message. I don't prefer shrug because you won't be notified that the people read but they didn't know the answer.

I think the checkmark is a good idea! I often use 👍 as an alternative but 👍 can be confused that you *liked/agreed* with the message **not** you *solved* the message. I don't prefer shrug because you won't be notified that the people read but they didn't know the answer.
Author
Owner
Copy link

My motivation for shrug was not to notify people (a reaction is usually used when you don't want to send a notification), but for people looking at stale issues / comments to know that no one had an opinion.

The use case is specifically if someone does not want to add a comment because they think it's not relevant enough to get everyone informed about it, so an issue goes completely stale (although some users have read it). Instead, they can add a shrug, so looking at it again, you see that people just don't have an opinion.

My motivation for shrug was not to notify people (a reaction is usually used when you don't want to send a notification), but for people looking at stale issues / comments to know that no one had an opinion. The use case is specifically if someone does *not* want to add a comment because they think it's not relevant enough to get everyone informed about it, so an issue goes completely stale (although some users have read it). Instead, they can add a shrug, so looking at it again, you see that people just don't have an opinion.

The use case is specifically if someone does not want to add a comment because they think it's not relevant enough to get everyone informed about it, so an issue goes completely stale (although some users have read it). Instead, they can add a shrug, so looking at it again, you see that people just don't have an opinion.

Might be a good idea but people can abuse it. Maybe also add a guide to use quick reactions in the best way in the documentation?

But people also might don't read documentation.

> The use case is specifically if someone does *not* want to add a comment because they think it's not relevant enough to get everyone informed about it, so an issue goes completely stale (although some users have read it). Instead, they can add a shrug, so looking at it again, you see that people just don't have an opinion. Might be a good idea but people can abuse it. Maybe also add a guide to use quick reactions in the best way in the documentation? But people also might don't read documentation.
Member
Copy link

Just wanted to note here that gitlab (just like matrix) allows adding arbitrary Unicode emojis as reaction to issues/comments. I've always found it quite strange that gihub (and thus I guess gitea) doesn't.

That said except maybe for counting votes they serve more as a fun distraction than a useful communication tool for me.

Just wanted to note here that gitlab (just like matrix) allows adding arbitrary Unicode emojis as reaction to issues/comments. I've always found it quite strange that gihub (and thus I guess gitea) doesn't. That said except maybe for counting votes they serve more as a fun distraction than a useful communication tool for me.
Upstream: https://github.com/go-gitea/gitea/pull/22156

This will not implement the specific emojis mentioned in the OP, but would definitely help towards that direction.

This will not implement the specific emojis mentioned in the OP, but would definitely help towards that direction.
Sign in to join this conversation.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure

Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers

Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support

This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#735
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?