Add support for semantic/conventional codes.

[jamarr81]

Hello @carloscuesta :sunglasses:!

This project, like the many before it, is a good start and provides a solid base of emoji's to integrate into development workflows. However, the code used for most emoji's seem to lose the original intention of that emoji. The issue is very similar to css class naming conventions/standards; or for that matter, even general OO conventions. In many contexts, it is considered bad practice to name concepts/interfaces after their "implementation" and conversely considered good practice to name them after their "purpose".

For example, using a name like .redButton or interface RedButton is unnecessarily coupling the style of button to the underlying purpose of that button. If the purpose of the button was to represent a behavior like "stop" or "exit", we should use a name that conveys that purpose: .stopButton or interface StopButton respectively; and then each implementation can use it's own style, or not, but is not inherently tied to one specific style.

This same issue has blossomed within the context of naming emojis (codes). We have a few options for addressing the issue here:

1. Add the ability for different "coded" sets of emojis to be selected or used together. (most flexible)
2. Deprecate existing codes; introduce new, semantic codes in a new version. (gets the job done)
3. Add semantic aliases to the existing configuration. (convoluted)

Examples:

• : zap: -> :perf:
• : fire: -> :chore:
• : bug: -> :fix:
• : sparkles: -> :feature:
• : memo: -> :docs:
• : white_check_mark: -> :tests:
• : penguin: -> :linux:
• : boom: -> :breaking:
• : construction: -> :wip:
• etc. etc.

The issue exhibits itself quite well in the descriptions you give for each of these emojis; in many cases, the semantic name already exists within the description itself. We should use codes that are most intuitive from a development context. An additional benefit, this project could then also be seamlessly updated as newer/better icons are designed or selected for.

This all ties into what many other projects/tools are also trying push for: standard, semantic, commit conventions. With very few changes here and there, this project could very easily integrate with those other tools. We should try to keep this project on board with the trajectory of the rest of the open source community:

1. http://conventionalcommits.org/
2. https://github.com/conventional-changelog/standard-version
3. https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits
4. https://github.com/commitizen/cz-cli

[jamarr81]

For additional reference, there have been other tickets/comments that touched on similar idea(s) but may not have been an explicit ticket concerning the underlying need/desire for more semantic/conventional emoji codes:

1. https://github.com/carloscuesta/gitmoji/issues/143#issuecomment-327198499
2. https://github.com/carloscuesta/gitmoji/issues/138
3. https://github.com/carloscuesta/gitmoji/issues/58

[techieshark]

Might be cool to have a little helper, similar to https://github.com/fteem/git-semantic-commits which then sticks the appropriate gitmoji in the commit message.

E.g.

git feat "commit message here" -> git commit -m '✨feat: commit message here'

[smolijar]

Hi @jamarr81, thanks for your input.

For example, using a name like .redButton or interface RedButton is unnecessarily coupling the style of button to the underlying purpose of that button. If the purpose of the button was to represent a behavior like "stop" or "exit", we should use a name that conveys that purpose: .stopButton or interface StopButton respectively; and then each implementation can use it's own style, or not, but is not inherently tied to one specific style.

That which you explained (correct me if I am wrong), is an issue for two reasons

• you add another red button and get lost in naming
• you don't know the purpose of red button and must look it up

This eventully happens and thus it is considered a bad practice, because you can avoid it with using proper naming and it costs nothing.

The situation with gitmoji is different IMO.

1. I don't think we would get to the (at least I think we shouldn't) point where we would have hundreds of red buttons, or any buttons for that matter (or emojis)
2. We cannot be so liberate about naming conventions. If unicode emojis are used it does not make sense, becase there is very few emojis to express a bug. When using text notation and renaming, we would lose the convinience of having emojis rendered on GitHub witohud additional steps that would render gitmoji useless.
3. And for that part when it is difficult from looking at the RedButton and telling what it does intuitively, I think the best we can do is provide a clean documentation and keep the emoji base relatively small.

Gitmoji is far more expressive than the referenced standards and chose a very specific representation, images. Yes I understand the issue, but it is inherent feature of the project.

I think the best think we could do is start taking semver seriously, so it would be possible to interpret if some symbols are deprecated or changed. I don't think that is a vital issue at this point.

I would suggest closing for now.

[johannchopin]

Close this issue due to inactivity of the author. Feel free to add a comment so I can reopen it 👍