carloscuesta / gitmoji

An emoji guide for your commit messages. 😜
https://gitmoji.dev
MIT License
15.67k stars 800 forks source link

Verbose Gitmoji Descriptions #573

Open kevtan opened 4 years ago

kevtan commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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.

carloscuesta commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Currently we have;

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 😊

poznas commented 6 months ago

I would also strongly propose adding a new includes property, examples: