Use 🏵️ for added/updated annotations

[realpixelcode]

Emoji symbol

🏵️

Emoji code

🏵️

Emoji description

Added/Updated annotations, decorators etc.

Describe the use case of your emoji

Sometimes, all you do in a commit is updating annotations/decorators of methods or fields, especially something like @NonNull , @Nullable, @Contract, @Getter, @Setter etc. Using the 🏵️ emoji, which represents artistic rosette ornaments present on tiles, statues, building facades and the like for decorative purposes, would fit this job quite well.

The currently best-fitting Gitmoji would probably be ♻️, but “refactoring” does not accurately describe modifying annotations specifically.

Is this use case covered by an existing emoji?

No ❌

Does this emoji fall into the "how" or the "what" category?

• This proposal do not describe "how" a commit was made, but does in fact describe "what" is the contents of the commit about.

Examples

• 🏵️ Add @NonNull
• 🏵️ Update @Contracts
• 🏵️ Override @Getters

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue requesting the emoji.

[jorenham]

I use gitmoji for scipy-stubs, the official typing stubs package for SciPy. Because it's a stubs-only package, most of the commits are either additions or changes to annotations. But I don't really find it useful to annotate all of those with 🏵️.
I can imagine that there are more stubs-only packages that feel this way too.

So perhaps we could split this up into e.g. additions, changes, deletions or annotations, and perhaps also one for a refactoring/cleanup of code related to static typing?

Given the original meaning of "annotation", and considering the static and formal nature of type annotations, we could for instance use 📎 for additions, ✒️ for updates, ✂️ for deletions, and perhaps 📐 for refactoring/cleanup.

[realpixelcode]

most of the commits are either additions or changes to annotations. But I don't really find it useful to annotate all of those with 🏵️.

There are already plenty of Gitmojis that don't differentiate between adding, updating and removing:

• 📝 = Add or update documentation.
• 💄 = Add or update the UI and style files.
• ✅ = Add, update or pass tests.
• 🔐 = Add or update secrets.
• 👷 = Add or update CI build system.
• 📈 = Add or update analytics […]
• 🔧 = Add or update configuration files.
• 🔨 = Add or update development scripts.
• 📦️ = Add or update compiled files […]
• 📄 = Add or update licence.
• 🍱 = Add or update assets.
• 💡 = Add or update comments […]
• 💬 = Add or update text and literals.
• 🔊 = Add or update logs.
• 👥 = Add or update contributors.
• 🥚 = Add or update an Easter egg.
• 🙈 = Add or update .gitignore.
• 📸 = Add or update snapshots.
• 🏷️ = Add or update types.
• 🌱 = Add or update seed files.
• 🚩 = Add, update or remove feature flags.
• 💫 = Add or update animations and transitions.
• 👔 = Add or update business logic.
• 🩺 = Add or update health check.
• 🧵 = Add or update concurrency.
• 🦺 = Add or update validation.

Considering the fact that there are many test-only repos, UI-only repos, licence-only repos, documentation-only repos, assets-only repos etc. out there, I believe that adding 🏵️ as “Adding or updating annotations and decorators” would still fit the overall Gitmoji theme, even though 🏵️ wouldn't be too useful to scipy-stubs.

In other words, if your entire code is just annotations, then you should probably use ✨♻️🔥⚰️, because it would be obvious that you're referring to annotations. (Similarly, test-only repos shouldn't bother using ✅🧪 either.)

we could for instance use 📎 for additions, ✒️ for updates, ✂️ for deletions, and perhaps 📐 for refactoring/cleanup

I think there three options:

1. Using 📎✒️✂️📐 exclusively for annotations. I'm not a fan of this, because these emoji are too generic for that purpose.
2. Using 📎✒️✂️📐 not just for annotations but as generic Gitmojis for any code changes. Though, refactoring is already covered by ♻️, and removals are covered by 🔥. 📎 for additions would still be useful even though ✨ exists, because not all additions necessarily introduce new features (depending on your perception of the term).
3. Introducing 📎✒️✂️📐 as modifiers that can be added to existing Gitmojis, for example:

• ✅📎 = adding a passing test
• 🏵️✒️ = updating an annotation
• 💄🔥 = removing a UI file
• 📈♻️ = refactoring analytics

In my own repos, I already do sometimes combine two or three Gitmojis to make a more precise statement, so I would be fine with the third option. But it would be a major change to the core concept of Gitmoji and would very likely face harsh resistance from other Gitmoji users and would facilitate incompatibility bugs for Gitmoji scripts.

Therefore, I would prefer option two and propose using 📎✒️🔥♻️ instead of 📎✒️✂️📐.

Given the original meaning of "annotation", and considering the static and formal nature of type annotations

Could you perhaps elaborate on this? I proposed 🏵️ specifically with Java annotations in mind, as I'm not too familiar with annotations/decorators in other languages, especially not in Python.

Basically, in Java, @NonNull means that a class field (variable) must never be null (undefined), and if it is null at some point, the program will exit. @Getter will automatically (at compile time) create a getter method for an annotated class field. That's some use cases I had in mind when creating this proposal.

[jorenham]

Wow, thanks for the elaborate response @realpixelcode 🤯!

---

In my own repos, I already do sometimes combine two or three Gitmojis to make a more precise statement, so I would be fine with the third option. But it would be a major change to the core concept of Gitmoji and would very likely face harsh resistance from other Gitmoji users and would facilitate incompatibility bugs for Gitmoji scripts.

Therefore, I would prefer option two and propose using 📎✒️🔥♻️ instead of 📎✒️✂️📐.

I really like this idea. It kinda makes me wonder what the optimal set of "atomic" gitmoji's would be, with which all of the current ones could be expressed using a combination of such atomic gitmoji's 🤔. I suppose that they'd be more like tags then labels that way.

---

Could you perhaps elaborate on this? I proposed 🏵️ specifically with Java annotations in mind, as I'm not too familiar with annotations/decorators in other languages, especially not in Python.

Java is statically typed language, but Python is a gradually typed language, meaning that type annotations are optional, and they don't even need to be valid for the "program" (script) to run. Type-checking is done via 3rd party static type-checkers.
A consequence of this is that not all Python libraries annotate their codebase. And if you need to use such unannotated library, but still want to annotate your own code, then you're going to have to use typing stubs. An example of this is scipy, which is unannotated mainly because it predates the introduction of gradual typing into Python. Since I care about typing and frequently use scipy in several of my projects, I developed 'scipy-stubs' as a separate, stubs-only package, so that anyone can benefit from the improved IDE support and type-hinting that these type-annotations result in.

[cruzdanilo]

some previous discussion about multiple emojis: #1334 (comment)