Improve contributing workflow: transition to simplified git flow with automatic release of beta versions

[thomvaill]

See https://github.com/thomvaill/log4brains/discussions/108 and the ADR created in this merge request to understand the context and the rationale behind this change. But the key idea is to streamline contributions and release more often.

The goal is to make contributing easier, streamline the release process, and allow more automation. This will make it simpler to delegate tasks to new maintainers and make it easier for contributors to follow the process. It also provides early feedback on beta features from the community, which will help us catch issues before stable releases.

WORK IN PROGRESS

Changes to the contributing workflow

• We’re transitioning to a Simplified Git Flow with the following changes:
  • The main branch for ongoing work is now develop: all the feature branches should be merged into this branch
  • Any change on develop triggers the automatic release of a beta version (testable immediately by running npm install log4brains@beta)
  • When we are satisfied with the current version of develop, we merge it into the stable branch and release the stable version manually to npm
• We introduce 2 maintainer roles in the CONTRIBUTING.md:
  • Canary Maintainers can merge PRs to the develop branch, triggering beta releases for testing.
  • Core Maintainers can merge develop into stable for stable releases (for now, I’ll handle this).

How to review?

The best is probably to read first:

1. The new ADR "Transition to Simplified Git Flow"
2. CONTRIBUTING.md
3. Then the other files

Your Feedback Matters

I’d love to hear your thoughts on this new workflow. Do you think this will make contributing easier? Are there any concerns or suggestions you have about this approach? Your feedback is invaluable to make sure this change benefits the community.

[Potherca]

After reading through the code, I think that the proposed flow (a.k.a. "the process") strikes a good balance between making things easier for contributors without compromising quality or introducing too many hurdles.

The only thing I am wondering about is whether the project would only want developer contributors or if more high-level individuals might also be needed, as developers quite often prefer clear work task over fuzzy issue triage and back-and-forth support requests.

I mention this specially, as I've seen this in other open-source project where contributors (and maintainers) spend time on non-code work. People started to feel like they were burning a lot of fuel just spinning their wheels without actually getting anywhere, which eventually led to loss of interest and people leaving or burning out.

[thomvaill]

After reading through the code, I think that the proposed flow (a.k.a. "the process") strikes a good balance between making things easier for contributors without compromising quality or introducing too many hurdles.

The only thing I am wondering about is whether the project would only want developer contributors or if more high-level individuals might also be needed, as developers quite often prefer clear work task over fuzzy issue triage and back-and-forth support requests.

I mention this specially, as I've seen this in other open-source project where contributors (and maintainers) spend time on non-code work. People started to feel like they were burning a lot of fuel just spinning their wheels without actually getting anywhere, which eventually led to loss of interest and people leaving or burning out.

Thank you for your feedback! 👍 I agree with you that we cannot rely only on "developer contributors", but I guess there will be two phases in this new organization: Phase 1: this is what I call "make a fresh start": fix the Node and dependency issues, merge the pending pull requests, fix the bugs and implement the long lasting most wanted features Phase 2: make the project evolve, think and implement new impacting features... For phase 1, I think it's OK if I remain the only "core maintainer", because this is mainly "basic development". No strong vision is required. However I hope that during phase 1 some key contributors got engaged and motivated to become core maintainers with me, as we will need in fact to discuss the vision we want for the project, which is required for phase 2 to begin.