To your last bullet point, these seem like a good reasons to me. This does not seem to have happened with the iOS version.

>However, the sheer volume of legacy issues, combined with submissions that completely ignore the provided issue template, has created a situation where there are currently more than 1,100 open tickets. Most of these issues have been inactive for several years and they reference versions of Signal that are no longer available. Many open issues are essentially ad-hoc discussion threads or feature requests that are a better fit for the community forum. Perhaps most importantly, many of these issues lack debug logs, descriptions, and the steps that would be necessary to understand and reproduce the reported behavior.

They essentially declared "issue bankruptcy", in the Lessig/Turkle sense.

Question:

What do tests and CI have to do with the usability and usefulness of a program? I agree that the other issues could be worrying, but those first two throw me for a loop.

Tests and CI help you make sure that functionality actually works, that buttons you press have the desired effect, and that if I as a contributor ship you a pull request for a UX/feature improvement, both your and me can check that it doesn't break anything before merging.

The grandparent poster also wrote about security/privacy, for which I think tests are pretty important.

Finally, having CI would allow the developers/contributors with limited time to spend more time on usability and usefulness instead of on issues like "master doesn't build, anybody else have this problem?" (when I wanted to PR something to Signal, master did not build).

This is still looking at it from a developer's or contributor's point of view. Developer velocity has no practical impact on the user experience. In a way, the constant addition of features or tweaks to the user experience is a net negative, since the user has to re-learn how to do things in the app.

This also makes the assumption that since there are few automated tests, that there are no tests done on a build at all. I disagree that it is a valid assumption. Most security vulnerabilities are not found by unit or functional tests, but instead by linting and code reviews.

> Developer velocity has no practical impact on the user experience.

This may be true in a megacorp. I doubt it's true in a project like Signal where resources are limited and a few developers are the single bottleneck for everything, UX or otherwise.

All those issues were closed, as it is explained in your link, because they lacked debug logs/steps to reproduce the problem/etc. It's not feasible to dedicate enormous amounts of resources to try to address those issues. You're welcome to re-open them, properly this time, if you want.

That is wrong, they closed issues indiscriminately.

Oh, and they will keep doing so: "Legacy issues that are more than one month old will be closed by an automated process as part of this cleanup effort."

That is wrong. If you read the thread, you would immediately see that, as I give examples there of how issues that were in the middle of being tested by users were closed, and that were acknowledged as real issues by the developers days before.

Good points, but I think it's good to mention that Telegram is actually open source: https://telegram.org/apps#source-code

No, it's not. Telegram clients are; telegram, as a service - the server component - is not.

Further, the Android app doesn't have an issue tracker. According to [1] and links in there it was removed without explanation.

[1] https://github.com/telegramdesktop/tdesktop/issues/1137

It's actually dated-source. The source code they occasionally publish is always months beyond the recent release.