Gitmoji: Verbose Gitmoji Descriptions

[kevtan]

I've been thinking a long time about perhaps adding a more verbose description for all the gitmojis? Taken directly from the README, "Gitmoji is an initiative to standardize and explain the use of emojis on GitHub commit messages." I think the one-sentence descriptions are useful for beginners but I think one-paragraph descriptions with examples would prove to be a standard for power users. This gives us the liberty to write somewhat abstract one-sentence descriptions like "Add or update development scripts" while still preserving uniform usage across projects.

For instance, I still don't know what 🔊 and 🔇 are for. Are they for print statements in the code? Or actual log files to the project from a specific run? Also 🌱. What's a seed file anyway? I've never worked with these before and the last time I Googled the first result was "[a] SEED file is a data file saved in the Standard for the Exchange of Earthquake Data (SEED) format" which confused me.

I understand there is an extra level of maintenance but I actually don't see the paragraph descriptions changing as much as the sentence ones!

[KaKi87]

I've been thinking a long time about perhaps adding a more verbose description for all the gitmojis?

I actually prefer the exact opposite, to find faster.

I still don't know what 🔊 and 🔇 are for.

Just ask.

For me, in JS, adding, updating or removing logs means adding, updating or removing console.log or similar instructions.

In general, that means adding, updating or removing events to be or not to be logged.

Also 🌱. What's a seed file anyway?

I did asked too, at #144, and got the answer.

[kevtan]

@KaKi87 You're misunderstanding my proposal. I'm not suggesting to use paragraph descriptions to replace the sentence ones. I'm suggesting to include paragraph descriptions on the website for further clarification and examples.

Of course anyone can just ask. This is the baseline and bare minimum. If we claim to be a "standard" we should enable users to have as much information available from the canonical source as possible and not force them to dig through archaic forums and closed issues...

[johannchopin]

Hey @kevtan 👋 It's not a bad idea but would you have an example of what this paragraph contain? Should it provide an commit message example?

[kevtan]

@johannchopin Sorry for the late response! Here are two really rough and dirty examples I took a minute to come up with. There is a _lot_ of potential to improve.

• Gitmoji: 🔨
• Sentence description: Add or update development scripts.

• Paragraph description: Examples of development scripts include launch.json files for debugging in Visual Studio Code, npm command hooks (idk if this is what they're called), and various other scripts used during development but not production.

• Gitmoji: 🔊

• Sentence description: Add or update logs.
• Paragraph description: Add new print statements to your code, change the severity level of logging statements, redirect logs to a file, etc.

[carloscuesta]

Hey @kevtan I've got an idea to integrate this 👍🏼

I think we can implement a page for each Gitmoji, something like /gitmoji/:code:

This page would be accessed by clicking on a Gitmoji card, inside of that page, we would find a more detailed description and use case of the emoji

What do you think?

[kevtan]

That sounds like a good idea! I'd prefer we open a modal instead of a page so there is less context switching. What do you think about that?

[carloscuesta]

I think that navigating to another page is a better solution since you can share that single page with anyone based on the URL, a modal is not so accessible to share

One thing that bothers me is how we're going to maintain the descriptions of the Gitmojis, I don't really think the .json file is ideal, since putting it a lot of information inside such as description, examples and use cases could made the file really big 🤔

[vhoyer]

Maybe we could have a folder with markdown with the name of each emoji as the nema of the file (e.g.: fire.md), then we would just have to configure next to render those appropriately with the routes and stuff, what you think?

[carloscuesta]

That’s an option, however I’m a little bit concerned about having different points for storing the information about gitmojis,

Currently we have;

• gitmojis.json
• emojiColorsMap.js

Introducing another one woule be another thing we should require and ask on PRs, at the contributing guidelines.

Let’s see if we can find a different approach that solves us that problem!

I will think about it and try to explain what comes to my head on this thread 😊