Thank you, @Harpush, for your valuable feedback.

We plan to address issues, considering closure, reopening, or checking for resolutions in newer versions. Any additional insights on this matter would be welcomed.

Regarding your last point, I agree that continuous improvement is essential. Personally, I find the "boy scout rule" a good approach for enhancing specific areas. Do you have examples or suggestions for code sections that might benefit from improvement?

1. I think the split area should become a component and not a directive. Especially with the iframe fix integrated inside.
2. I think templates should have their own file.
3. I think the split component itself should be more ordered as it is a really large component with a lot of imperative code.
4. We should also look at features like collapse which I am yet to understand their value.

Just what I had in mind...

@Harpush Nice to meet again.
The first order of business is improving the CI/CD story. To do that, we must first improve the DX. Please have a look at #370 for a first step.
We plan to do a "final" release in the current state but with all non-breaking PRs merged. (Unless there is a good reason that we are unaware of to not merge any of those).

The next step will be a breaking release, with the PR that is breaking merged but also completely moved to standalone.
If you have things that you think should be part of our first breaking release, please let us know; then, we can estimate the work and decide to include or postpone till the next breaking release. I would rather bundle as much as possible in a single-breaking release than spread it out. At the same time, we are all very busy and we need to set realistic goals. Otherwise, nothing will ever get released.

I agree. I believe squash and merge is correct.
So generally the PR title should follow the commit guidelines and so the squash merge commit.
Does that mean "on the fly" commits don't have to follow specific guidelines? Or do we want to follow those guidelines in internal commits too but without merging commits and force pushing?

I am pretty sure commitlint can run only on specific branches but I am not sure if it will work or how to do it.

Jeffery found a tool to force the squash&merge msg format to follow conventions. That means we can allow anything, but we need to fix the message before merging it. That will still allow automated changelogs and stuff, but without needing to demand strict rules on commit messages.

I would say we should see if we can integrate this tool.

BTW, if we as maintainers use proper commit messages, the job during merge is a lot simpler. So it makes sense to still keep proper commit-message hygiene.
I use the Conventinal commits plugin in vs-code, which makes it easier to format those things properly.

So let's take a scenario - I am creating a feature branch and the first commit is:
feat: add something
Later I decide to add some stuff so:
feat/refactor: add more something
Later I have a bug so I commit:
fix: fix PR comments

At the end when you merge the branch you only take the first commit name as the squashed one:
feat: add something
Am I correct here? Or the fixup way is better?

@Harpush, the person who is going to press the merge&commit button, has to make sure the message is formatted correctly. Otherwise, the button will not work. (at least, that is what I understood from the tools docs.)
We prefer proper commit messages as that makes the job a bit easier, but we require nothing