Emoji reactions for GitLab projects

Project interest is not the same as project sentiment

A Star is a simple way to mark a public GitLab project as interesting. That is useful, but it compresses too much into one action. A project might be production-ready, experimental, abandoned-but-important, impressive, hard to trust, surprisingly good, or simply relevant to a team evaluating tools.

Emojery adds a separate public signal for that nuance. Visitors can leave a quick emoji reaction without turning the project page into a comment thread or forcing every response through one Star button.

Reactions belong to the public project page

The GitLab adapter targets public project pages on gitlab.com. The reaction is attached to the project itself rather than to a random branch view, search result, pipeline page, or issue thread. When another Emojery user opens the same public project, they see the same aggregate reaction layer near the project actions.

An emoji picker where project actions already live

On supported GitLab project pages, Emojery places the picker in the project action row near controls like Star, Fork, and More actions. That keeps the signal in the part of the page where users already decide whether a project deserves attention, and the trigger opens the same searchable palette used across every supported site.

Public totals, one per verified person

Anyone can read a project's totals without a GitLab or an Emojery login. Leaving one asks for a provider sign-in once, so what you read is a count of provider-backed accounts instead of disposable browser profiles.

When the action row gets crowded

A GitLab project page already carries Star, Fork, and a More actions menu, and the picker joins them rather than replacing anything. If that row is busier than you want it, Hide original buttons clears the native control out of your browser and leaves the picker in its place. Flip it back whenever; the project page everyone else loads never changed.

Useful for tools, templates, and infrastructure projects

GitLab is often where teams evaluate operational code: CI templates, deployment examples, libraries, internal-tool foundations, and public infrastructure projects. A richer reaction layer gives quick context before someone spends time reading pipelines, issues, or merge request history.

A heart, warning sign, thinking face, fire emoji, thumbs up, or thumbs down will never replace a proper technical review. It can, however, tell a visitor that other people had a strong enough impression to leave a signal on the project. Maintaining projects yourself? See what the layer gives maintainers, on GitLab and on GitHub.

Separate from GitLab's own ranking and workflows

Out of the box, an Emojery click does not Star the project, subscribe you to notifications, open an issue, or change anything in GitLab's own project state. It is a separate reaction, counted under the model documented on the counts page and built for fast sentiment rather than platform workflow. The opt-in Auto-press setting below is the one deliberate exception.

A live reaction badge for your project

The browser reaction is just one side of it. A maintainer can also drop a reaction badge into the project README: one line, like a CI or coverage badge, showing the top 3 emoji and the running total. Every visitor sees it, extension installed or not.

Sitting at the top of the README, it reaches the people who never open the project's browser page at all: readers of the docs, of a mirror, of a package listing that renders the same file.

How Auto-press works on GitLab

Evaluating a lot of projects in one sitting, you may want the Star to follow the reaction. That is what the off-by-default Auto-press original buttons setting does: an emoji you filed as positive also presses Star, exactly as your own click would. GitLab has no native dislike here, so a negative or neutral pick presses nothing, and dropping your reaction releases a Star only if the extension is the one that set it.