I've always seen conventional commits as an anti-pattern as it seems to discourage developers from writing small, atomic commits.
I think that a commit should always be as small as possible and have a descriptive, meaningful message. It is therefore pretty common that I end up with tens of commits when working on a simple feature. Which of these commits should be labelled as "feat" when the feature is added by a group of commits rather than a specific one, and that none of them really adds any feature? Also, a bug can be fixed by many commits. Which of these commits should be labeled as "fix"? We can't label all of them as fixes as cherry-picking only one of them wouldn't fix anything, which means the commit message would be misleading. The only solution left is to create one commit per bug fix or per feature.
Moreover, this information can (and should) be carried by the branch name already, as you'd usually branch off from your main branch to either fix a bug or develop a new feature. All you have to do is to follow a naming convention for your branch like "feature/my-awesome-feature" or "bugfix/fix-this-annoying-bug".
The only benefit I see with using conventional commits is generating changelogs automatically from your git history.
I agree with you that such a commit has nothing to do in the main branch. But it has nothing it do in any branch that is shared with anyone either. Git has enough ways to keep your own history clean at all times to not require a hack like squash PRs to compensate the lack of discipline of a team. With squash PRs you lose so much valuable information that it gets impossible to use commands like bisect or to have a proper context on a blame.
You can combine together theses classes in another class name for reusability. I've been doing CSS for 15 years and I love tailwind. It's just a bunch of handful predefined classes but they encourage you to write everything in small, single-purposed classes that you combine together.
You can absolutely do that with CSS (and some people probably did for years), but having theses classes already available kind of shows you the way.
How does a technology become mature if no one wants to test it? I get your point, but we need both type of people in the real world: cutting-edge tech enthusiasts and stable products users. The problem is not that some people try out some fancy new tool, it's that they try it at work and waste lots of money without even being worried about it because it's not theirs. But in few cases it also pays off.
Exactly. It would be amazing to have some of the many incredible UX/UI designers out there help with open source projects like these. So many potential adopters are lost just because of the interface, no matter how awesome the software is.
I feel tempted to buy kleptosphere.com just to imagine someone's confusion the day they would want to buy it but get greeted with a "Sorry, this domain name is taken" instead.
What kind of ideas does sponsoring give you access to that you wouldn't get otherwise?