idea: rename the org and adopt more projects #30

Closed
opened 2026-02-17 11:34:47 -06:00 by GiteaMirror · 16 comments
Owner

Originally created by @zeke on GitHub (Jul 25, 2018).

I don't know the origin story of the @conventional-changelog GitHub org nor am I an owner of it, but I have an idea.

It seems to me that the addition of the conventionalcommits.org repository to this org changes the org's purpose in a way: It's now the home of the Conventional Commits spec. As such, I think renaming the org to @conventional-commits would be appropriate. The changelog tools should still live here too. :)

Furthermore, there are other projects out there in userland that are drinking the conventional Kool-Aid and could be welcome additions here. Moving them here would make them more discoverable for people who want to start adopting Conventional Commits in their projects. A few repos come to mind:

cc @bcoe @kentcdodds @nexdrew @olstenlarck @stevemao @damianopetrungaro

Originally created by @zeke on GitHub (Jul 25, 2018). I don't know the origin story of the @conventional-changelog GitHub org nor am I an owner of it, but I have an idea. It seems to me that the addition of the `conventionalcommits.org` repository to this org changes the org's purpose in a way: It's now the home of the Conventional Commits spec. As such, I think renaming the org to @conventional-commits would be appropriate. The changelog tools should still live here too. :) Furthermore, there are other projects out there in userland that are drinking the conventional Kool-Aid and could be welcome additions here. Moving them here would make them more discoverable for people who want to start adopting Conventional Commits in their projects. A few repos come to mind: - https://github.com/olstenlarck/parse-commit-message - https://github.com/commitizen/conventional-commit-types - https://github.com/probot/semantic-pull-requests cc @bcoe @kentcdodds @nexdrew @olstenlarck @stevemao @damianopetrungaro
Author
Owner

@tunnckoCore commented on GitHub (Jul 25, 2018):

Thanks for pinging me :)

Yea, i was thinking for good org name last months, since i stopped using semantic-release for obvious reasons back than, but anyway (now it looks good, it was in the fall/winter). Another reason now is that it changed the purpose a bit to be "more general purpose automation" for every lang and etc. Okey, great. :)

Since then, i started creating many small utilities and helpers. parse-commit-message is just one of them. gitcommit is another, new-release another, there is even new-release Probot/Github App (should update the page! didn't have the time and because the app is Just Working). And etc, won't promote, just saying.

Saying that since then, i'm completely decoupled from @semantic-release and still always up-to-date with automation, exactly because the few tools and utils that i created. All of my repos are still automatically and semantically released, without thinking for npm publish or such.

I'm glad that Conventional Commits landed as general purpose specification and that i started using those conventions before around 2 years (started with standard-version, then migrated to semantic-release).

More bigger home for all of us would be fantastic 😸 No matter what are the differences in purposes. Today i was just thinking to use conventional-commit-types in the gitcommit v2


edit: oh and there is pretty old parse-git-log 😆

@tunnckoCore commented on GitHub (Jul 25, 2018): Thanks for pinging me :) Yea, i was thinking for good org name last months, since i stopped using `semantic-release` for obvious reasons back than, but anyway (now it looks good, it was in the fall/winter). Another reason now is that it changed the purpose a bit to be "more general purpose automation" for every lang and etc. Okey, great. :) Since then, i started creating many small utilities and helpers. `parse-commit-message` is just one of them. [gitcommit](https://github.com/tunnckoCore/gitcommit/) is another, [new-release](https://github.com/tunnckoCore/new-release) another, there is even [new-release Probot/Github App](https://github.com/apps/new-release) (should update the page! didn't have the time and because the app is Just Working). And etc, won't promote, just saying. Saying that since then, i'm completely decoupled from @semantic-release and still always up-to-date with automation, exactly because the few tools and utils that i created. All of my repos are still automatically and semantically released, without thinking for `npm publish` or such. I'm glad that Conventional Commits landed as general purpose specification and that i started using those conventions before around 2 years (started with `standard-version`, then migrated to semantic-release). More bigger home for all of us would be fantastic :smile_cat: No matter what are the differences in purposes. Today i was just thinking to use `conventional-commit-types` in the `gitcommit` [v2](https://github.com/tunnckoCore/gitcommit/issues/10) --- edit: oh and there is pretty old [parse-git-log](https://github.com/olstenlarck/parse-git-log) :laughing:
Author
Owner

@kentcdodds commented on GitHub (Aug 6, 2018):

I'm fine with whatever. I don't really do much with this project anymore myself :-/

@kentcdodds commented on GitHub (Aug 6, 2018): I'm fine with whatever. I don't really do much with this project anymore myself :-/
Author
Owner

@zeke commented on GitHub (Aug 6, 2018):

Pinging @nexdrew to get some more org owners into the conversation.

How do folks feel about renaming this org to conventional-commits as a starting point?

From there, I can create a new welcome repo with a README that gives an overview of the intent, the spec, and the modules within the org.

@zeke commented on GitHub (Aug 6, 2018): Pinging @nexdrew to get some more org owners into the conversation. How do folks feel about renaming this org to `conventional-commits` as a starting point? From there, I can create a new `welcome` repo with a README that gives an overview of the intent, the spec, and the modules within the org.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 6, 2018):

Sorry @zeke but I just realized right now you opened an issue 😄
IMHO it's a good idea once we'll get more tools and repositories related to this topic, but, as always, I am totally open to discussing it with all of you 😄


@conventional-changelog/org I just own the conventional-commits and conventionalcommits orgs on Github, so we'll be sure to do it easier in the future 😄

@damianopetrungaro commented on GitHub (Aug 6, 2018): Sorry @zeke but I just realized right now you opened an issue 😄 IMHO it's a good idea once we'll get more tools and repositories related to this topic, but, as always, I am totally open to discussing it with all of you 😄 ___ @conventional-changelog/org I just own the `conventional-commits` and `conventionalcommits` orgs on Github, so we'll be sure to do it easier in the future 😄
Author
Owner

@nexdrew commented on GitHub (Aug 6, 2018):

I try to help out when/where I can, but I'm not all that active in this org.

Some of the backstory (as I understand it) is that @stevemao had a bunch of little useful packages based around a primary conventional-changelog one (which was eventually converted to a single Lerna monorepo), and @bcoe and I wrote standard-version as a CLI tool to replace the npm version command with one that automatically bumped a package version and generated a changelog. Since we were using a handful of conventional-changelog packages, @bcoe approached @stevemao with the idea of moving them all under the same org, which was done. I think the idea of publishing a spec for "conventional commits" came later, under a more general topic of software development tooling, based on a shared principle of conventional commit messages.

FWIW, @bcoe and I also started a Slack workspace around a slightly different but similar vein of projects related to yargs, istanbul, and nyc, and the workspace was recently renamed to node-tooling.

Since @bcoe has been the primary driver behind unifying a lot of these efforts, I think it would be wise to get his vision for conventional-changelog, "conventional commits", node-tooling, and how they may or may not be related.

Also, this org represents a lot of work done by @stevemao over the years, so his opinion is also more valuable than mine.

@nexdrew commented on GitHub (Aug 6, 2018): I try to help out when/where I can, but I'm not all that active in this org. Some of the backstory (as I understand it) is that @stevemao had a bunch of little useful packages based around a primary [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog) one (which was eventually converted to a single Lerna monorepo), and @bcoe and I wrote [standard-version](https://github.com/conventional-changelog/standard-version) as a CLI tool to replace the `npm version` command with one that automatically bumped a package version and generated a changelog. Since we were using a handful of conventional-changelog packages, @bcoe approached @stevemao with the idea of moving them all under the same org, which was done. I think the idea of publishing a spec for "conventional commits" came later, under a more general topic of _software development tooling_, based on a shared principle of conventional commit messages. FWIW, @bcoe and I also started a Slack workspace around a slightly different but similar vein of projects related to yargs, istanbul, and nyc, and the workspace was recently renamed to [node-tooling](https://node-tooling.slack.com). Since @bcoe has been the primary driver behind unifying a lot of these efforts, I think it would be wise to get his vision for conventional-changelog, "conventional commits", node-tooling, and how they may or may not be related. Also, this org represents a lot of work done by @stevemao over the years, so his opinion is also more valuable than mine.
Author
Owner

@Tapppi commented on GitHub (Aug 10, 2018):

As for me, I have also been very quiet in this org for some time, due to shifting priorities. @bcoe and @stevemao should definitely weigh in.

I do however believe that trying to unify the very brittle conventional X landscape would be worthwhile and it might as well be under a conventional-commits or node-tooling org. These tools still drive a lot of value for me and my company, so I'll help where I can :)

@Tapppi commented on GitHub (Aug 10, 2018): As for me, I have also been very quiet in this org for some time, due to shifting priorities. @bcoe and @stevemao should definitely weigh in. I do however believe that trying to unify the very brittle conventional X landscape would be worthwhile and it might as well be under a `conventional-commits` or `node-tooling` org. These tools still drive a lot of value for me and my company, so I'll help where I can :)
Author
Owner

@hutson commented on GitHub (Aug 10, 2018):

As an org member, and regular user of conventional-changelog tools/libraries, I am entirely fine with aligning the organization's name with our mission as it has organically evolved over the years.

Here are a few thoughts that come to mind when considering a rename:

  • It would be nice to have a mission statement that outlines our goals as an organization, and establishes what is, or is not, in-scope to achieve those goals (@zeke mentioned doing something like that in an comment above). It's not my desire to create barriers, but I do worry if there's no definition of what makes a project valuable when we're working with so few resources within this organization. It would also help to align our efforts so that we benefit from the synergy.

  • I wonder if, given that we have focused on defining how to create commits that make it easy to automate the release process, and then built tools to leverage that standard, if we shouldn't include release or workflow in a new organization's name? (Though I also worry that including release in our organization's name, and as part of our mission, would be disrespectful to the fantastic semantic-release project that many of us have depended upon at some point or another to automate our release processes.)

@hutson commented on GitHub (Aug 10, 2018): As an org member, and regular user of `conventional-changelog` tools/libraries, I am entirely fine with aligning the organization's name with our mission as it has organically evolved over the years. Here are a few thoughts that come to mind when considering a rename: - It would be nice to have a mission statement that outlines our goals as an organization, and establishes what is, or is not, in-scope to achieve those goals (@zeke mentioned doing something like that in an comment above). It's not my desire to create barriers, but I do _worry_ if there's no definition of what makes a project valuable when we're working with so few resources within this organization. It would also help to align our efforts so that we benefit from the synergy. - I wonder if, given that we have focused on defining how to create commits that make it easy to automate the release process, and then built tools to leverage that standard, if we shouldn't include _release_ or _workflow_ in a new organization's name? (Though I also worry that including _release_ in our organization's name, and as part of our mission, would be disrespectful to the fantastic `semantic-release` project that many of us have depended upon at some point or another to automate our release processes.)
Author
Owner

@bcoe commented on GitHub (Aug 11, 2018):

I'm very much pro switching to conventional commits for the name of this organization, rather than conventional changelog -- I think it better captures the goals of the tools collected together within this organization.

As for the node-tooling rebranding in slack, this relates to an initiative being proposed by @boneskull. Basically, some conventions that have been developed across Node's developer tool focused communities (yargs, Istanbul, Lerna, npm, etc.) are seen as having become so prevalent the conventions and libraries that have been developed might be worth including in Node (or even JavaScript) itself.

An example of this in action is the work we've been doing around mkdirp -- mkdirp is used by almost everyone writing developer tools that interact with the file-system, let's just make it available in Node.js.

I'm familiar with @zeke's work in open-source, and am confident he'll be a big help in moving the conventional changelog org to a conventional commit org. I'm going to go ahead and add @zeke to this organization.

@zeke why don't you join us in our slack and we can coordinate some of the work that needs to be done.

@bcoe commented on GitHub (Aug 11, 2018): I'm very much pro switching to `conventional commits` for the name of this organization, rather than `conventional changelog` -- I think it better captures the goals of the tools collected together within this organization. As for the `node-tooling` rebranding in slack, this relates to an initiative being proposed by @boneskull. Basically, some conventions that have been developed across Node's developer tool focused communities (yargs, Istanbul, Lerna, npm, etc.) are seen as having become so prevalent the conventions and libraries that have been developed might be worth including in Node (or even JavaScript) itself. An example of this in action is the work we've been doing around [mkdirp](https://github.com/nodejs/node/commit/bdef1b1eb45e2953e1ff68f0cc9a68ec83573e57) -- `mkdirp` is used by almost _everyone_ writing developer tools that interact with the file-system, let's just make it available in Node.js. I'm familiar with @zeke's work in open-source, and am confident he'll be a big help in moving the `conventional changelog` org to a `conventional commit` org. I'm going to go ahead and add @zeke to this organization. @zeke why don't you join us in our [slack](http://devtoolscommunity.herokuapp.com/) and we can coordinate some of the work that needs to be done.
Author
Owner

@marionebl commented on GitHub (Aug 11, 2018):

I'm pro reframing this org, too. How about moving marionebl/commitlint to this new org?

@marionebl commented on GitHub (Aug 11, 2018): I'm pro reframing this org, too. How about moving marionebl/commitlint to this new org?
Author
Owner

@zeke commented on GitHub (Aug 11, 2018):

I just own the conventional-commits and conventionalcommits orgs on Github, so we'll be sure to do it easier in the future 😄

@damianopetrungaro since you're an admin of this org and the owner of the conventional-commits org, are you able to handle the rename? If it ends up being complicated we can ask support@github.com to help us. :)

@zeke commented on GitHub (Aug 11, 2018): > I just own the conventional-commits and conventionalcommits orgs on Github, so we'll be sure to do it easier in the future 😄 @damianopetrungaro since you're an admin of this org and the owner of the `conventional-commits` org, are you able to handle the rename? If it ends up being complicated we can ask support@github.com to help us. :)
Author
Owner

@zeke commented on GitHub (Aug 11, 2018):

How about moving marionebl/commitlint to this new org?

👍

join us in our slack and we can coordinate

@zeke commented on GitHub (Aug 11, 2018): > How about moving marionebl/commitlint to this new org? 👍 > join us in our slack and we can coordinate ✅
Author
Owner

@stevemao commented on GitHub (Aug 12, 2018):

Hi guys, I haven’t been working on this for a while. Feel free to contribute. Let me know if you need my help. Cheers!

Sent from my iPhone

On 12 Aug 2018, at 8:47 am, Zeke Sikelianos notifications@github.com wrote:

How about moving marionebl/commitlint to this new org?

👍

join us in our slack and we can coordinate


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@stevemao commented on GitHub (Aug 12, 2018): Hi guys, I haven’t been working on this for a while. Feel free to contribute. Let me know if you need my help. Cheers! Sent from my iPhone > On 12 Aug 2018, at 8:47 am, Zeke Sikelianos <notifications@github.com> wrote: > > How about moving marionebl/commitlint to this new org? > > 👍 > > join us in our slack and we can coordinate > > ✅ > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.
Author
Owner

@damianopetrungaro commented on GitHub (Aug 12, 2018):

Here we go!

🎉🎉🎉Project in a new org name 🎉🎉🎉

Invitation sent to be part of the organizations as members/owners to all you.
If anyone does not receive the invitation feel free to ping me ;)


We need a new logo and maybe revamp the UI of the website too, opening new issues for those two ;)

@damianopetrungaro commented on GitHub (Aug 12, 2018): Here we go! 🎉🎉🎉*Project in a new org name* 🎉🎉🎉 Invitation sent to be part of the organizations as members/owners to all you. If anyone does not receive the invitation feel free to ping me ;) ___ We need a new logo and maybe revamp the UI of the website too, opening new issues for those two ;)
Author
Owner

@damianopetrungaro commented on GitHub (Aug 12, 2018):

Thanks to @bcoe @kentcdodds @nexdrew @olstenlarck @Tapppi @marionebl @stevemao @hbetts and @zeke for the quick replies and the nice feedback.

@damianopetrungaro commented on GitHub (Aug 12, 2018): Thanks to @bcoe @kentcdodds @nexdrew @olstenlarck @Tapppi @marionebl @stevemao @hbetts and @zeke for the quick replies and the nice feedback.
Author
Owner

@tunnckoCore commented on GitHub (Aug 12, 2018):

Thanks too! :)

@tunnckoCore commented on GitHub (Aug 12, 2018): Thanks too! :)
Author
Owner

@zeke commented on GitHub (Aug 17, 2018):

Yay! Thanks for the renaming the org. I'm assuming it was you, @damianopetrungaro?

I've been traveling this week but I will follow up soon with some PRs on the website.

@zeke commented on GitHub (Aug 17, 2018): Yay! Thanks for the renaming the org. I'm assuming it was you, @damianopetrungaro? I've been traveling this week but I will follow up soon with some PRs on the website.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#30