Hacker News Reader

Comment by vortico | Hacker News Reader

Probably an unpopular opinion, but when a project is starving financially, responding to bug reports should be the first thing to go. Hugely popular features and large subprojects that change the direction of the project are more important than the average bug fix. One of my projects has 1000 new open issues in the last year, and I'm the only paid contributer, so the chance your issue will even be responded to is about 25%. Only the highest quality bug reports are addressed. If not enough information is provided, you can pretty much guarantee it will be ignored because there are hundreds of other issues that are written better and deserve better attention.

Without knowing anything about the blogger's bug reports, I'm going to guess this is what's happening at Canonical that is causing bug reports to not be addressed.

View on HN

This is a good way to increase your churn. If your product has known bugs affecting my workflow that I have reported and you have not even responded to (a valid response could include instructions for preparing a patch/PR or even a message saying needs more info) I will always be looking for alternatives. If you are adding pointless features (to me as a user I started using the product with the existing feature set so new features are most likely pointless to me) at the same time I'm really starting to wonder about just forking.

For Ubuntu, you're probably right. For a year-old immature project like mine, it's definitely better to work on steering the cruise ship itself rather than work on tiny problems on it. Every project has its own rules, so make judgements on a case-by-case basis. But I'm not here to discuss my project, simply a guess as to the reason Canonical has disappointed the blogger.

My usual rule of thumb (with no particular evidence) is that for every bug that's reported, another 9 users are having the same problem.

That said, what you prioritize depends on what you want out of the project, be that features at all costs, or building a small but sustainable community of users for the long term. It's a perfectly valid thing to throw code over the wall and tell people to fix their own bugs, but don't expect to build a solid community around it.

Sounds about right. For me it's probably closer to 20-30 users.

With my commercial projects I've always had a policy of no known bugs. If I wasn't able to handle this then I'd consider it a warning that the scope of the project was too large.

I wish I was on that side of the spectrum. Mine is on the other extreme. :)

No known features?

Include every possible bug?

Every bug is secretly a feature?

And this is how to retain users. Although you might struggle to sell support contracts with preferential access to bug fixes...

I'm interested in how this works. Obviously there are bugs which can and should be fixed - but how about bugs which are really feature requests, or bugs which are extremely complex to fix and only affect 1 person? Do you mean that you close out these bugs very quickly without fixing them, or do you take superhuman efforts to implement everything?

Bugs can be triaged into deficiencies and new feature requests. Usually new feature requests are handled differently than actual bugs. For hard-to-fix bugs that don’t affect many people, sometimes documenting it as a known issue along with a workaround is good enough.

I don't worry if it only affects one person, I assume there are more that haven't told me or haven't found it yet.

I also don't worry if it's complex, I have had seemingly simple requests take several weeks although that is quite rare. I have never closed a bug as won't fix.

Then close the bug tracker, don’t waste everyone’s time. The serious bugs will pop up in some ways.

I’ve filed proper bug reports that went nowhere and guess what, I’ve lost interest in doing so since it was pointless. I’ve moved on to other projects that took them more seriously.

The blogger's bug report he linked to was about a package in universe. Universe is essentially the community playing ground - packages there are not supported, and most of them are synced unmodified from Debian and not there because anybody cares about them.

The best course of action with universe packages thus is to fix them yourselves. Ubuntu development is open to everyone. All you need to do is submit a debdiff and subscribe the ubuntu-sponsors team. You can even submit stable release updates with sponsoring, https://wiki.ubuntu.com/StableReleaseUpdates tells you more.

If you can't do the development yourself, and there's no community member who cares about the package, your bug might not get fixed. But that's the way things work in free software communities.

Probably an unpopular opinion, but when a project is starving financially, responding to bug reports should be the first thing to go.

Or effort could go into trying to improve the funding situation.

No just realistic. MS can afford patch Tuesday.

Reply on news.ycombinator.com