Hello everyone,
As you are probably all aware, we're currently in our v1.2 development cycle, and have started planning for v2.0. As part of this process we hosted our usual "kick off" meeting with our core developers and team members, where we discussed plans for the next release, as well as procedural challenges that are blocking and slowing down progress.
During the past several releases, one of our biggest challenges has been managing the issue backlog on GitHub. There's quite a few reasons for this:
- Basing our milestones on this backlog makes it difficult for us to develop and implement our own vision for the future of the project; instead, we're following the plans of past community members and contributors, many of whom are no longer involved with the project. This is both demotivating for us, and bad for the project, since the issues we're solving aren't necessarily the most important ones at the moment.
- The current state of our milestones are somewhat arbitrary, more a result of "this used to be on
milestone n - 1, so we moved it to milestone n" than because those issues are actually high priority.
- A lot of issues are partially complete, or have had conversation devolve into weird tangents and rabbit holes. As a result, starting work on an issue is much more difficult than it needs to be.
- Many issues that have been open for years are no longer relevant. Triaging them to know which ones are and aren't takes up a lot of time.
- Ideally, issues would be use-case driven, such as solving a bug for users, improving some aspect of developer experience, or building a safer API for some feature. Quite a few of our current issues are about obscure technical changes, without a clear use case.
- With 350 open issues, even choosing which issues to work on takes up a lot of time and decision paralysis.
And if these issues are causing so much of a headache for our team, which is pretty familiar with Flarum, you can imagine that it's probably much more confusing for new contributors.
We've been talking about improving this situation for a while, and have spent a lot of time closing outdated issues, cleaning up open PRs, and keeping an eye on new issues. Unfortunately, the impact has been minimal, so we have decided to shut down the Flarum project. It's been a pleasure, folks.
That's a joke, of course, but we will be making some drastic changes to our current work organization setup. The main goal here is to ensure that all issues on the GitHub repo are actionable, use-case driven, relevant, and approachable.
- All existing issues will be moved to an archive repo and then closed in core.
- Archive repo will be closed/deleted in roughly a year after we've pulled issues we feel are important or otherwise needed.
- Documentation on what we consider good issues and PRs will be created and put on our new Internal Docs.
- Issues and PRs not following our new standards will be closed without further response.
- We will release a roadmap for v2.0 and beyond. Having a roadmap in the past was great for helping both team members and our community remember our long-term vision. We want to bring this back.
- We will create a new tag here on Discuss where "wishlist" / far-off / unconfirmed / unverified bugs, suggestions, and feature proposals can be discussed. The tag will support voting, so the community will be able to indicate which issues matter the most to them. Some of these will be moved to GitHub issues as we decide to work on them / confirm ideas for a technical implementation.
- Depending on some experiments in the coming weeks, we might be moving to a monorepo setup for core and bundled extensions. This would help simplify things by putting all development in one place. There's still a few issues that might block it though.
While these changes may seem drastic we ask that you please understand where we're coming from. The amount of issues and PRs in our GitHub repos results in developer fatigue, which in turn means less new features, less bug fixes and overall slower development for you. For us, the extra paperwork makes us less happy and excited to work on Flarum, which makes it difficult to keep up morale and build a better, bigger team. We've made this decision unanimously as a team because we all believe that this is in the best interest of not just ourselves, but for Flarum as a whole.
We expect these changes to take place sometime within the next few weeks. Once we move to the new system of tracking issues, authors of discussions in the support and feedback tags here on Discuss will be able to request that their discussions be moved to the new community voting tag. Please bear with us during this transition, and feel free to ask any questions below.
