The future of gitmoji

[smolijar]

Hi @carloscuesta , I am great fan of gitmoji and I would like to contribute to the cause.

In fact I started using it few weeks ago and I think the project could move in more dynamic way. Here are several imperfections I find in gitmoji

• PRs and issues are not very well maintained (moths old PRs without reaction)
• The project could benefit from more formal specification
• Gitmoji CLI could have richer setup or integration

(I am certainly not the man that would throw in a dozen of new emojis every week, quite contrary, I think the current base has a good balance and I would like to keep it more or less the same.)

I created a PR and realized there are many issues and PRs without reaction. If you'd be interested, I would be interested in becoming a co-maintainer.

If you don't want to accept a helping hand and neither want to maintain the project anymore, I would consider creating a specification based on gimoji. Is this idea something you would support or suggest against it?

I write with the best intentions to help the project, please, if you feel any offensive gestures in trying to rule the project and cast you out, you are mistaken. But if you are unwilling to mainatin it anymore, creating a standard based on gitmoji is an option for me.

Best regards

[carloscuesta]

Hello @grissius

Thanks for your interest on the future of the project. I totally understand your point of view on that the project should move in a more dynamic way. In fact that's probably right. The reason why there are a lot of PRs and Issues without any reaction is because I think I should not be the only person deciding based on my criteria if something should be added as a gitmoji or not. I try to wait and see upvotes on the issues to decide if something is worth enough to be added.

And there's no much feedback on new proposals, so that's why the whole thing is a little bit stopped.

I have no problem on having maintainers, in fact I think that you're the first one proposing this.

I would be very interested on those two points, can you elaborate them a little bit more ?

• The project could benefit from more formal specification
• Gitmoji CLI could have richer setup or integration

I invited you to be a collaborator of the repository, I'm leaving this issue open so we can discuss about it

[smolijar]

ad. The project could benefit from more formal specification, here are some ideas:

Having defined the emojis for different tasks, a standard powerful enough to compare to conventional commits has been created. However it only defines, what emojis to use when, and even that is bit vague at some points.

The only additional info is the brief introduction in the readme:

Using emojis on commit messages provides an easy way of identifying the purpose or intention of a commit with only looking at the emojis used. As there are a lot of different emojis I found the need of creating a guide that can help to use emojis easier.

I would suggest the following

• write formal standard people can follow, similiar to https://www.conventionalcommits.org or https://semver.org
  • define length of messages (now only defined by CLI implementation)
  • define form of a message (e.g. capitalization, imperative)
  • define where to post references and how to handle multiple references (e.g. Github & Redmine)
  • define wether to use text or unicode notation
  • (just came to my mind, maybe wild idea) commit metadata to mark commit "changelog significant" and include it in changelog generation
  • add emoji "mindmap" for better orientation (eg :apple:, :penguin:, :checkered_flag: and :robot: are all special cases of :bug:)
  • add signature text/badge (see #317)
  • write set of rules for existing and future emojis (as a guide for decission making in issues, PR etc) - for example: must unambiguous, applicable to general software development, etc.
  • add extended description for emojis with examples, so users can have more specific idea when learning gitmoji

(gitmoji doesnt have to use strictly one option, but the standard should enlist possibilities and chose preferences and set defaults)

[SnO2WMaN]

For your infomation, Now I'm working on customizable gitmoji-cli rewritten typescript.

I would like to complete this in a few days.

It may not be much related ...

[smolijar]

Thanks for your input @SnO2WMaN Would you summarize what are the new features of your gitmoji-cli fork? Is it about more configuration or about adding new symbols that are not supported by gitmoji?

If its the former, would you consider creating a PR if thats ok with @carloscuesta

[SkyaTura]

ad. The project could benefit from more formal specification, here are some ideas:

Having defined the emojis for different tasks, a standard powerful enough to compare to conventional commits has been created. However it only defines, what emojis to use when, and even that is bit vague at some points.

The only additional info is the brief introduction in the readme:

Using emojis on commit messages provides an easy way of identifying the purpose or intention of a commit with only looking at the emojis used. As there are a lot of different emojis I found the need of creating a guide that can help to use emojis easier.

I would suggest the following

• write formal standard people can follow, similiar to https://www.conventionalcommits.org or https://semver.org

  • define length of messages (now only defined by CLI implementation)
  • define form of a message (e.g. capitalization, imperative)
  • define where to post references and how to handle multiple references (e.g. Github & Redmine)
  • define wether to use text or unicode notation
  • (just came to my mind, maybe wild idea) commit metadata to mark commit "changelog significant" and include it in changelog generation
  • add emoji "mindmap" for better orientation (eg 🍎, 🐧, 🏁 and 🤖 are all special cases of 🐛)
  • add signature text/badge (see #317)
• write set of rules for existing and future emojis (as a guide for decission making in issues, PR etc) - for example: must unambiguous, applicable to general software development, etc.
• add extended description for emojis with examples, so users can have more specific idea when learning gitmoji

(gitmoji doesnt have to use strictly one option, but the standard should enlist possibilities and chose preferences and set defaults)

I loved the idea of standardizing the specification using the RFC 2119, however, I'd like to add my opinion to the discussion.

The way I see, Gitmoji is more like an agnostic pattern, that allows you to use the usage of emojis on your own commit pattern.

As the project is up without any message-wise spec for a while now, adding these kind of change now could potentially cause conflicts between different implementations.

However, I do agree that discussing with the community and researching combinations of message standards that works fine with Gitmoji would be nice.

My suggestion is focusing on writing a formal standard about topics like:

• Emoji usage on git commits
• Define wether to use :text: or unicode notation
• Define wether combine (or not) emojis to improve meaning
• A criteria for adding new emojis to the specification (Popular vote, relevancy, etc)
• A criteria for using non-standard emojis (if applicable) ... and others related to emojis only

And then, as a different issue, defining suggestions of message patterns to be used with, based on what we achieve from researching with the community.

[SkyaTura]

About the "gitmoji-cli", it would be awesome if the tool had an (optional) analytics metric collector, that allows us to see which emojis are more popular and which are not.

Of course, the implementation would guarantee privacy protection, only capturing emojis used and never the whole message content.

[smolijar]

@SkyaTura I like the idea of knowing the statistics, but as a user I feel this is terrible way to implement it. I think this might be a reason why some users might stop using it.

I think a better approach would be using #317 and crawling OSS repos only -- all data is open, it can be verified, users are not afraid of enabling "spy" feature etc. It also covers users who do commits manually.

[smolijar]

@SkyaTura Interresting perspective on the specification on gitmoji being a general pattern unrelated to message style.

As the project is up without any message-wise spec for a while now, adding these kind of change now could potentially cause conflicts between different implementations.

Not sure what do you mean by conflicts between different implementations, but yes, it would introduce changes that are not BC with the current version. That's why we should introduce semver about the standard as well. However I don't see how this is different in its nature compared to deciding to use only unicode/text, the BC troubles are afoot one way or the other.

However, I do agree that discussing with the community and researching combinations of message standards that works fine with Gitmoji would be nice.

I think this is very dangerous. Let's do the statistics, let's do reasoning, but let's not ask community to "add their own flavor". We will end up with sixteen different standards, half of which would break the purpose of gtimoji.

All in all, I think that releasing the standard under different name and leaving gitmoji as it is is not very perspective for anyone (including current, future users and the released standard as well). Without guidelines it (gitmoji) will rot, it will either be left not maintained, or bloat with meaningless emojis that will eventually render it useless. Doing a major semver update seems like the best solution.

[SkyaTura]

@SkyaTura I like the idea of knowing the statistics, but as a user I feel this is terrible way to implement it. I think this might be a reason why some users might stop using it.

I think a better approach would be using #317 and crawling OSS repos only -- all data is open, it can be verified, users are not afraid of enabling "spy" feature etc. It also covers users who do commits manually.

I though more as an opt-in feature then spying on people, however, crawling repos is an acceptable (and safe) alternative as well.

[SkyaTura]

@grissius

Not sure what do you mean by conflicts between different implementations, but yes, it would introduce changes that are not BC with the current version. That's why we should introduce semver about the standard as well.

What I meant is that adding restrictive rules about message could conflict with already implemented and defined on projects and companies that adopted Gitmoji with their own message patterns.

However I don't see how this is different in its nature compared to deciding to use only unicode/text, the BC troubles are afoot one way or the other.

The difference is that rules can be open, or, at least, not so tight. We could, for example, specify as a recommended behavior using :text: notation to avoid compatibility issues, but let users to accept the tradeoff of using unicode characters if this isn't a problem on their environment.

I think this is very dangerous. Let's do the statistics, let's do reasoning, but let's not ask community to "add their own flavor". We will end up with sixteen different standards, half of which would break the purpose of gtimoji.

I think @carloscuesta is the best person to decide about this, but I really don't think that public opinion should not have its value. Of course it's impossible to create a pattern that everyone will agree, but we still can be reasonable and discuss on the subject instead of just dictating patterns. Again, formal specs doesn't require rigid immutable rules, they can, and they should, be prepared for exceptions as well.

All in all, I think that releasing the standard under different name and leaving gitmoji as it is is not very perspective for anyone (including current, future users and the released standard as well). Without guidelines it (gitmoji) will rot, it will either be left not maintained, or bloat with meaningless emojis that will eventually render it useless. Doing a major semver update seems like the best solution.

I totally agree with that, this I loved this project since the first time I saw it, and I've been recommending on my local development groups, managed to make as internal standard on the company I work with, and I wish the best for the future.

Don't get me wrong, I really support the idea of improve the specification, and I admire you for suggesting that, my only concern here is creating too many tied rules that may causes people to avoid using it.

The best argument I found to convince people on using Gitmoji is it's simplicity of adoptance, and I don't think it's impossible to improve it as simple as already is.

[carloscuesta]

I don’t think we need to make things more complicated. One thing people like about the project is the simplicity of just putting an emoji before the commit message and that’s all!

[smolijar]

Well @carloscuesta, sometimes what people like is not what they need. Giving them what they like is a short term solution. They are happy, start using it and few years later, you take a look back on the repos using gitmoji and you have created nothing, because using gitmoji without standard or recommendations, is just as bad as using no convention at all.

All commits in the image are valid. Is that all ok with you? The emoji can use unicode or text, the emoji can be practically anywhere in the message. There can be one, seven, zero emojis? Sure! They can be in the title, body, trailers even git notes. Can I put just ermoji and no text? Can I leave commit message completly empty? Can I use custom emojis that have no defined semantics? All fair game. Just add the shield refering to this repo.

Is this initiative about being likable, or being useful? I think you of all people should know, that making things other people "like" is a road to hell. Too harsh? See #244 #136 #155 #59 #196 #139 #137... the list goes on and on.

My only concern here is creating too many tied rules that may causes people to avoid using it. @SkyaTura

If thats your only concern, good. Nobody is using it. Seriously, see the list. There are like 4 repos of any signifance. Sure, some few random hipsters including us (probably) use it, but that's all individuals. How come no large projects, teams or corporations use it? Here's why: it's likable, but its not practical. Having no specification makes it unmaintanble for teams with any number of developers.

So what happens if a team tries to adopt it? They either realize it's vaguely defined rendering it useless and they go with conventional commits or they draft their own recommendations. Not only they have standard nobody ever heard of but in some time we have gitmoji-x, gitmoji-y, gitmoji-z recommendations which as good as none.

I am disappointed by your reactions, but @carloscuesta has the final call. If we keep it the way it is, I guess we do. But mark my words, if we don't draft a specification gitmoji will remain only but a hipsters guilty pleasure and if we do what people like, the project will, slowly but surely fall, become bloated and unusable.

[carloscuesta]

The “specification” for me If you want to call it like that is the following one

“[Emoji] [Title]”

[smolijar]

If it has this form, i'd rather call it comment than a specification. Are those two optional? Even if required, 😜 42 is valid? Emoji is a single smybol in either unicode or text or multiple? Is this a valid commit message?

The last thing I want to do is fight about edgecases. I justy want to point out that sooner or later depending on the popularity of this initiative these questions will become relevant and this oneline recommendation mentioned in soon historical issue will have no use.

But since I am the only one around here with this opinion I have no power here. If this is the most formal you want to get with gitmoji, I think it is pointless to discuss it. You are the author and have the final word in that matter. For me the issue is resolved. Please @carloscuesta close if there is nothing more to discuss.

[carloscuesta]

It’s interesting discussing this I consider your point of view and opinion valid as mine.

Answering your questions, yes, the emoji and commit message are required to follow this “standard”.

If you think that 😜 42 adds enough value to identify the purpose of your commit, then it’s your own responsability to decide if that is valid as a commit message or not.

The format it is still valid though. Only one symbol should be used per commit since this helps to organize and split commits better kind of “atomic commits”.

The debate unicode vs the symbol I do not have a strong opinion on this. I see great things on both sides.

What edge cases do you want to talk about?

Let’s have a starting point of:

${emoji}* ${commitMessage}*

• are required fields

[Stivaros]

@grissius I think it's really cool that you're stepping up during Hacktober and helping maintain the project. About time some of these issues and PRs were handled :)

I think you're looking at this problem the wrong way, as you've alluded to in your last message. My understanding (and I believe this was @carloscuesta's intent) is to have a simple emoji at the start of a commit to give a context as to the changes that were made.

If people can't grasp that (relatively simple) concept without a technical specification then it's their codebase that will suffer and isn't @carloscuesta's problem. He put some time and effort in a while ago to set something up, I don't think he (or anyone!) should then have to worry about providing support for this. It really is devastatingly simple to use, that's the whole point!

The reason I'm posting is to say that your input has been great in helping tidy up the PRs and issues within the repo, I'm not wholly sure this discussion is necessary or particularly helpful. The aim of hacktober is to help OSS, not burden it with unnecessary admin. :)

[smolijar]

Thank you for you feedback @Stivaros I wanted to introduce the specification for the people who are more than capable of grapsing the concept and have nothing more to hang on to, but I understand reasons why it is considered in best interest for gitmoji to keep it dead simple.