7 ms·

One argument might be "because Signal * has (almost) no tests, * has no CI (at least I could find none), * lacks some basic features competitors have, * som

by nh2 9y ago

One argument might be "because Signal * has (almost) no tests, * has no CI (at least I could find none), * lacks some basic features competitors have, * sometimes doesn't ring when you call, and * they just closed all 1100 open issues without reading their contents [1]." Don't get me wrong, I think Signal is a great idea and have contributed some code to it, but these look like some red flags to me. Obviously hard to compare to Telegram, which is closed source so we can't know whether they have similar problems. [1]: https://github.com/signalapp/Signal-Android/issues/7598 https://github.com/signalapp/Signal-Android/issues/7598

andrepd 9y ago
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.
- Mithaldu 9y ago
  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."
- nh2 9y ago
  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.
falcolas 9y ago
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.
- nh2 9y ago
  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).
  - falcolas 9y ago
    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.
    - nh2 9y ago
      > 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.
24gttghh 9y ago
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.
- redler 9y ago
  They essentially declared "issue bankruptcy", in the Lessig/Turkle sense.
Keloo 9y ago
Good points, but I think it's good to mention that Telegram is actually open source: https://telegram.org/apps#source-code https://telegram.org/apps#source-code
- pmlnr 9y ago
  No, it's not. Telegram clients are; telegram, as a service - the server component - is not.
  - nh2 9y ago
    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 https://github.com/telegramdesktop/tdesktop/issues/1137
- schoeneskind 9y ago
  It's actually dated-source. The source code they occasionally publish is always months beyond the recent release.

by nh2 9y ago

andrepd 9y ago

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.

Mithaldu 9y ago
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."
nh2 9y ago
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.

falcolas 9y ago

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.

nh2 9y ago
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).
- falcolas 9y ago
  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.
  - nh2 9y ago
    > 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.

24gttghh 9y ago

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.

redler 9y ago
They essentially declared "issue bankruptcy", in the Lessig/Turkle sense.

Keloo 9y ago

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

pmlnr 9y ago
No, it's not. Telegram clients are; telegram, as a service - the server component - is not.
- nh2 9y ago
  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 https://github.com/telegramdesktop/tdesktop/issues/1137
schoeneskind 9y ago
It's actually dated-source. The source code they occasionally publish is always months beyond the recent release.