Faster pull request workflow.

[amano-kenji]

It's good to give code reviews. However, I think code review should not block merging pull requests.

As long as there is no obvious problem or no deal breaker with a pull request, it should be merged despite imperfections.

Acceptable imperfections should be communicated on pull requests, but pull requests without deal breakers should be merged quickly.

After acceptable imperfections are communicated and pull requests are merged, imperfections could be fixed later by either maintainers or pull request authors. If maintainers fix imperfecitons, they can just push commits. Contributors can summit subsequent pull requests. This leads to progress.

If new features don't introduce breaking changes, it's okay for them to not be perfect initially. It's better to have new experimental features that may break and be fixed later quickly than to stagnate and slowly die or be taken over by faster projects.

If developers who don't have time to review code pursue perfection, then a project is going to stagnate. Haskell's type system makes it largely safe to merge pull requests that introduce new features without breaking changes.

Perfection is the enemy of good. Perfection is a mental construct that doesn't actually exist in the physical universe. As long as we are in the physical universe, don't expect perfection. Prioritize progress over perfection.

[tathougies]

I understand your desire to see the maturation of the Haskell ecosystem, but this is an open-source project, not currently backed by any large company. My general advice if you want timely updates and progress is to pay one/many of the contributors (we have several now with good enough knowledge).

However, I would like to address this point:

Haskell's type system makes it largely safe to merge pull requests that introduce new features without breaking changes.

This is incorrect. Obviously, all the beam devs love Haskell. Types prevent entire classes of bugs. Types at Haskell's level do not in any way guarantee correctness... only that values are used in the way they ought to. It does not guarantee you haven't switched your boolean conditions around or that you're not off by one. Haskell code is not bug free.

It is especially important to understand this when developing foundational libraries like database mappers.

As an open-source project, you are free (in fact encouraged) to maintain your own fork.

[amano-kenji]

this is an open-source project, not currently backed by any large company. My general advice if you want timely updates and progress is to pay one/many of the contributors (we have several now with good enough knowledge).

I think some pull requests do not require much thinking. They just export existing constructs. A different mindset would accelerate merging pull requests for free.

I argue that perfectionism is slowing it down. A project doesn't have to be perfect after each commit or each pull request. Faster learning through faster pull request workflow leads to more progress.

There is no guarantee that developers are going to respond to small one-off payments, either.

On the other hand, some haskell projects either merge or close pull requests within a day or two.

[amano-kenji]

At least, merging pull requests that don't break backward compatibility should not require much thought.

I would merge small pull requests that don't break backward compatibility without thinking.

In general, most things do not require any thinking or much thinking most of the time.

[amano-kenji]

Generally, I just merge pull requests that don't look crazy and don't break backward compatibility within minutes.

Intellectual mind is often paralyzed through analysis. Intellect is not great for making decisions.

I use intuition, gut feelings, and instincts to make quick decisions after thinking for a while with my intellect.

One of my new life strategies is to make decisions by trusting my instincts and shutting down my intellect after using it for a while. It is counterintuitive because my intellectual mind wants to straighten out every little detail without any consideration of speed whatsoever. My instincts know when enough is enough.

[amano-kenji]

Long story short, if you think beam is lacking enough attention, then you can add someone like me who emphasizes speed as a maintainer although I am still not familiar with beam internals.