4 ms·

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 an

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.

dbdjfjrjvebd 8y ago
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.
- vortico 8y ago
  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.
rwmj 8y ago
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.
- vortico 8y ago
  Sounds about right. For me it's probably closer to 20-30 users.
tonyedgecombe 8y ago
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.
- vortico 8y ago
  I wish I was on that side of the spectrum. Mine is on the other extreme. :)
  - hcs 8y ago
    No known features?
    - jonathonf 8y ago
      Include every possible bug?
      - arbie 8y ago
        Every bug is secretly a feature?
- dbdjfjrjvebd 8y ago
  And this is how to retain users. Although you might struggle to sell support contracts with preferential access to bug fixes...
- rwmj 8y ago
  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?
  - 8_hours_ago 8y ago
DoreenMichele 8y ago
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.
phobosdeimos 8y ago
No just realistic. MS can afford patch Tuesday.
mikhailt 8y ago
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.
julian-klode 8y ago
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 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.

dbdjfjrjvebd 8y ago

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.

vortico 8y ago
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.

rwmj 8y ago

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.

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

tonyedgecombe 8y ago

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.

vortico 8y ago
I wish I was on that side of the spectrum. Mine is on the other extreme. :)
- hcs 8y ago
  No known features?
  - jonathonf 8y ago
    Include every possible bug?
    - arbie 8y ago
      Every bug is secretly a feature?
dbdjfjrjvebd 8y ago
And this is how to retain users. Although you might struggle to sell support contracts with preferential access to bug fixes...
rwmj 8y ago
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?
- 8_hours_ago 8y ago

DoreenMichele 8y ago

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.

phobosdeimos 8y ago

No just realistic. MS can afford patch Tuesday.

mikhailt 8y ago

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.

julian-klode 8y ago

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 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.