I’ve noticed a small issue with my email client for quite some time now where composing a new email will have several blank lines by default.
It’s not too much of an issue to simply delete them but hey, maybe no one had pointed this out before! So I filed a bug report only to get this response… basically it’s not a bug, its a feature!
Seems like a weird hill for Proton to not want to climb down, considering their position within the email client marketplace. I would absolutely make UX a high priority.
Well, the humour behind “it’s a feature, not a bug!” has to come from somewhere and it seems your company/the company you work for is one of the players contributing to it :P
IMO call a bug a bug. Even if they were to say “yes this is a known issue, we’re aware of it but don’t know when we will be able to work on it” would be 100x better. The client is open source and I wouldn’t mind taking a look at it myself and potentially submitting a pull request.
However, saying “yes this is the expected behaviour” coupled with one closed pull request where someone implemented a “mark all as read” button (clearly a non-trivial amount of work) but closed the request months later with this comment doesn’t make me too eager:
There’s another where someone literally took the vector image that they use for their icon and created a PR to support Android 13 themed icons. After half a year someone rejected it due to only the design team being allowed to make design changes.
Is the source code released under a license that allows you to use, change and distribute it? Then yes, it’s open source.
Open collaboration is a separate thing.
“Expected behavior” doesn’t mean “intended behavior.” It just means that it’s a bug they know how to fix but don’t have the bandwidth to fix yet. So it’s not a feature, it’s just a defect that isn’t important enough to remove yet.
Most likely, next time they have cause to open the file that’s causing the bug, they’ll fix this too. Fixing bugs by attrition is one of many ways to keep dev costs low. Well, lower.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
IMO, that’s a clear acknowledgment that this is a specification bug.
And that it has a low priority.
Seems to readily impact 50% of the entire function of an email app (to write emails).
Seems like a weird hill for Proton to not want to climb down, considering their position within the email client marketplace. I would absolutely make UX a high priority.
This is how our company would word it. I see no problem with their response. Limited resources means focusing on top priority issues first.
Well, the humour behind “it’s a feature, not a bug!” has to come from somewhere and it seems your company/the company you work for is one of the players contributing to it :P
Ha ha. And when we test, we do it in production baby. It’s a wild ride
Of course you wouldn’t see a problem with it.
IMO call a bug a bug. Even if they were to say “yes this is a known issue, we’re aware of it but don’t know when we will be able to work on it” would be 100x better. The client is open source and I wouldn’t mind taking a look at it myself and potentially submitting a pull request.
However, saying “yes this is the expected behaviour” coupled with one closed pull request where someone implemented a “mark all as read” button (clearly a non-trivial amount of work) but closed the request months later with this comment doesn’t make me too eager:
There’s another where someone literally took the vector image that they use for their icon and created a PR to support Android 13 themed icons. After half a year someone rejected it due to only the design team being allowed to make design changes.
Is it something actually open source if
It requires a proprietary backend, kept secret
Not a single pull request is approved, all contributions are ignored for years, then finally rejected
The issue tracker is kept secret
?
Is the source code released under a license that allows you to use, change and distribute it? Then yes, it’s open source. Open collaboration is a separate thing.
[This comment has been deleted by an automated system]
As long as they can put on their website “We support open source!” who cares right?
“Expected behavior” doesn’t mean “intended behavior.” It just means that it’s a bug they know how to fix but don’t have the bandwidth to fix yet. So it’s not a feature, it’s just a defect that isn’t important enough to remove yet.
Most likely, next time they have cause to open the file that’s causing the bug, they’ll fix this too. Fixing bugs by attrition is one of many ways to keep dev costs low. Well, lower.