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!

  • marcos@lemmy.world
    70·
    10 months ago

    IMO, that’s a clear acknowledgment that this is a specification bug.

    And that it has a low priority.

    • stifle867@programming.devOP
      395·
      10 months ago

      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: https://github.com/ProtonMail/proton-mail-android/pull/144#issuecomment-1166377867

      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.

      • Moonrise2473@lemmy.ml
        131·
        10 months ago

        Is it something actually open source if

        1. It requires a proprietary backend, kept secret

        2. Not a single pull request is approved, all contributions are ignored for years, then finally rejected

        3. The issue tracker is kept secret

        ?

        • JohnEdwa@sopuli.xyz
          101·
          10 months ago

          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.

        • Skull giver@popplesburger.hilciferous.nl
          61·
          10 months ago

          As for point two and three: have you ever seen what happens when someone new tries to get a patch intl the Linux kernel, the world’s most famous open source project? There is no single issue tracker, the only way to submit patches is by email, the patches themselves get through several chains of developers responsible for specific parts of the kernel, getting code reviewed can take a while, and most people give up before they’ve refactored their code to the Linux kernel specifications.

          The status of the server doesn’t make any difference when it comes to open sourcesness. It wasn’t that long ago that every open source browser was exactly that: an open source client to proprietary servers.

      • ilinamorato@lemmy.world
        71·
        10 months ago

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

    • makingStuffForFun@lemmy.ml
      142·
      10 months ago

      This is how our company would word it. I see no problem with their response. Limited resources means focusing on top priority issues first.