New Post / Content Gitmoji

[wolfspyre]

Emoji symbol

📰

Emoji code

📰

Emoji description

New user-facing content

Describe the use case of your emoji

blog post / informational content... I don't feel like any of the existing gitmoji really cover this case.

Is this use case covered by an existing emoji?

No ❌

Does this emoji fall into the "how" or the "what" category?

• This proposal do not describe "how" a commit was made, but does in fact describe "what" is the contents of the commit about.

Examples

• 📰 new post about my left nostril kazoo company

• 📰 dissemination of information about the perils of SKWIRRELZ

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue requesting the emoji.

[vhoyer]

donno about this one, I usually just use the 💬

[wolfspyre]

IMO the definition of the speech balloon gitmoji:

Add or update text and literals.

Is a bit ambiguous. Feels more appropriate for non website content/context..

IOW I read that as 'back-of-house' content... hence the explicit distinction of 'user facing content'

[vhoyer]

Yeah I also thing the description leans towards this meaning, but I'm more in favor to rewording the speech balloon emoji than adding a new one. opnions? (personally I've always used the speech balloon to do commit those user facing contents)

[cruzdanilo]

apart from 💬, there's also 🍱 for other kinds of content.

[wolfspyre]

🍱 is for ‘assets’ which I’d felt aligns with static non-textual content, yes?

[realpixelcode]

I believe blog posts belong in their own repository, separate from the main project's source code. However, source code repositories often do contain informational content shown to the end-user in the GUI, such as release notes, terms-of-use or privacy policies. Though I'm not sure whether 📰 would fit this purpose. Maybe ℹ️ (:information_source:) would represent informational content better?

[wolfspyre]

ahoy!
I appreciate your participation and perspective!!

i agree that some segregation is useful…
I also feel that the best place for a piece of software’s documentation to reside is within the code repo itself.
if nothing else, then from the perspective of automatic quantification, having the ability to easily relate code changes and documentation changes helps
one craft a coarse metric around documentation trustworthyness / gauge likely accuracy… but i concur that not all ‘public facing’ content belongs in the same repo(s) as the ‘back of house code’

and .. think about repos which are primarily staticsites…
where the content and posts are kinda the main focus of the project …
there’s also a benefit to being able to differentiate ‘front of house’ and ‘back of house’ yknow?

as to your suggestion … :) it could work too.. hell, i could see value in both of them :)