First off, I couldn’t find an existing post here or on GitHub so I opened a new one. Let me know if we should merge the discussion in another thread.
We rolled out Metabase at work 5 months ago and we’re very happy with the product. Once you start working with Metabase you run into occasional glitches and issues which you can work around. Still, it adds up and it gets a bit annoying. I do appreciate the product you guys created and it’s an amazing piece of software, especially given it’s early stage. Even less technical users find their way around after a short intro and that’s perfect.
It makes me uneasy though to see many open issues and pull requests on GitHub and I got the impression the core developers don’t have enough capacity to work on all of these and, for pull requests for example, make sure the feature is released successfully and no regressions are introduced.
I’m wondering how I (and hopefully other volunteers) can support this process. Do you need resources to run automatic regressions tests against new builds or manual tests? I’m sure my company wouldn’t mind allocating resources to this.
I saw the project roadmap on GitHub but this is probably too high level for day-to-day work.
So I guess the TL;DR question would be: What kind of help would you need the most to accelerate Metabase development?
hmm… I just found out Metabase couple days ago and consider using it.
Your word worry me
I’d suggest you run a trial and see if it works for you. It’s not that Metabase is crashing constantly and buggy software but more smaller UI glitches that makes it a bit harder to use as a power user.
Hey @camsaul and @maz, you’re part of the Metabase core team, right? Is this a good place to discuss this?
Hey everyone, we’re a small team so we can only work on a fraction of the feature requests or open issues that people open – tons of people are using Metabase and dozens of issues get opened every day.
If you’d like to help contribute to Metabase, my recommendation is to submit PRs for bugs that you run into. Make sure they include tests to prevent regressions in the future. We would love that kind of help.
That was my impression as well; your team being small and the number of requests high.
Looking through the open pull requests, is there a way to get them merged in? Some of them probably address smaller improvements like the documentation and shouldn’t impact the releases too much. For me this would reduce the perception of being overloaded.
Before I start opening pull requests I think I’d try to get to a clean slate and get the number of open pull requests to 0. But maybe that’s just me.
I’m aware of your Contribution Guide but I wanted to check with you how you approach developing for Metabase from a broader perspective.
Probably not going to get to 0 any time soon. We have lots of PRs that are in various stages of completion, or are waiting for follow-up changes. We’ve tried not to be too aggressive closing community PRs that show potential but aren’t quite ready to merge for one reason or another.
Other things we could definitely use help with would be following up with old bug reports and seeing if they still apply. A confirmation that the issue is still present or is no longer present could really help us focus our time on fixing issues instead of GitHub triage.
I know, Inbox Zero is an ambitious goal. Thanks for clarifying, I’ll go through the issues these days and will look if I can support you. Apart from that defining a timeout for stale issues comes to mind. If the person who opened the issue doesn’t reply it means they probably don’t care anymore because either it has been fixed in a newer release or they found a different solution.
Let me see if I can help.