Gitmoji: Should gitmoji be platform agnostic?

Created on 8 Jun 2020  Β·  16Comments  Β·  Source: carloscuesta/gitmoji

Hello, :sunglasses:!

So I noticed there are some discussion around here around if we should or not add more technology specific emojis like shell script#432, storybook#325, or that disscussion on changing the :whale:#287.

I think we should disscus "formally" if we want to keep adding more platform/technology specific emojis, to not only come to a common decission about it, but also be an issue that we can point people when they suggest more of those, maybe event have this on the readme :D

So, should gitmoji be platform agnostic?

breaking-change discussion

Most helpful comment

So let me begin :D

I don't think we should :D platforms and technologies die, gitmoji should live forever :joy:, not only that but adding too much platform specific emojis adds complexity to newcomers to gitmoji making it harder to grasp or at least scaring people away from the emojis (#352) :rainbow:.

All 16 comments

So let me begin :D

I don't think we should :D platforms and technologies die, gitmoji should live forever :joy:, not only that but adding too much platform specific emojis adds complexity to newcomers to gitmoji making it harder to grasp or at least scaring people away from the emojis (#352) :rainbow:.

Totally agree with your point of view @vhoyer. Having platform agnostic gitmojis will end up by having hundred of new gitmojis proposition for each platforms/libraries/frameworks/plugins/modules/...

I think thats a 'good' gitmojis can be used in multiples projects environnement (web/system/server-side/design/...) wich is for example not the case of ☸️ which only refer to k8s technologie.

I agree, I think we should drop and stop adding platforms, but still keep operating systems, because they aren't much of them : Windows, Linux, Mac, Android, iOS. They can be often useful.

I don't think that 'they aren't much of them' is a valid argument to keep them @KaKi87 :thinking: Why create a 'rule' that we don't apply ?

What about 'they can be often useful' ?
In any multiplatform project there can be OS-specific issues.

Still an edge case of :bug:. In a web project should we have all gitmojis for JavaScript, css html ?

OSes, not platforms nor languages.
Independently of your platform and programming language, you can have OS-specific issues.

I would agree in leaving the ones we have due to backwards compatibility :D

EDIT: typo

@vhoyer I will recommend to make them as deprecated. If people want to use them it would be their own choice (emoji itself will still be render properly by the platforms).

yeah, but how would we pass this information? I don't like the idea of having deprecated emojis :thinking: I prefer the idea of removing. I know this is contradictory compared with my last comment, but in the last comment I was just proposing a compromise :D

EDIT: :pencil2: typo :sweat_smile:

I think that we can drop them since as you said those emojis are covered by a generic one.

For example:

:bug: -> it’s the same as Fixing something on iOS / Windows / Android

So, let’s create a list of the emojis that we are going to remove that are platform based and lets raise a PR

Ok, than this issue is set, we will not have anymore emojis added that are platform based, I will close this PR and reference it on all the other suggestions(issues) to add platform emojis. :smile:

the discussion of removing the emojis, I think can be covered by #435 :D

I think there are many others that would be removable we really intent to strictly keep only generic gitmojis.

Lets finalize the list of gitmojis that have to be removed:

  • :apple:
  • :penguin:
  • :checkered_flag:
  • :robot:
  • :green_apple:
  • :whale:
  • :wheel_of_dharma:

Please add a comment if I missed one πŸ‘

I think you listed all of them @johannchopin.

Once we merge that removal, we should make a new release of Gitmoji and publish it to npm sincey it's a breaking change πŸ‘

If we remove 🐳 I think that we have to first add a new gitmoji related to containers what do you think? There's already been a proposal in #298.

Was this page helpful?
0 / 5 - 0 ratings