GitHub Issue Cleanup

[jlund-signal]

It's time for some spring cleaning

As more people join the Signal team and our Android development efforts continue to accelerate, it is increasingly important to organize incoming issues. We rely on high-quality bug reports in order to triage, prioritize, diagnose, and fix the problems that users discover. We're excited about the enhancements that have been added to Signal recently and we want that momentum to continue.

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.

A new beginning

We need to get to a point where we can effectively track actual issues in the GitHub repository. We're aware of the features that users want, and we're working hard on them every day. Community involvement plays a large role in our development and planning process, and we closely follow the forums and other feedback channels.

We are taking the following steps in order to turn this repository into a functional issue tracker for bug reports:

1. The issue template has been updated to indicate that GitHub issues should only be used to track existing bugs in Signal.
   • If you feel like you are unable to make an idea fit within the confines of the template, that might be a sign that you are about to submit something that isn't a bug.
   • If you disagree with the way that a feature is working (but it's working!) that's not a bug.
   • If you have a suggestion for a new feature, that's also not a bug.
   • The community forum is available for all non-bug submissions and discussions. This feedback is highly valuable, but our GitHub issue tracker is not the right venue for questions, comments, or feature requests.
2. We will routinely close issues that ignore or delete the issue template.
3. Legacy issues that are more than one month old will be closed by an automated process as part of this cleanup effort.

Out with the old, in with the new and improved

Users are welcome to re-submit bug reports that follow the updated issue template and that still affect the current release of Signal. By re-submitting valid issues with up-to-date reproduction steps (and debug logs that were produced by a recent version of Signal) the developers will be better equipped to solve any underlying problems. Please include the legacy issue ID in your new submission if there is important context available in the old thread.

We need the community to help us with this step, and we sincerely appreciate your participation in this cleanup effort.

Many of you have been asking for this for a long time. We believe that these actions will improve the development cycle and make the process easier to follow for everyone involved. We apologize in advance for the flood of email notifications, but the pain is temporary and a brighter future awaits.

[nh2]

You are losing your contributors and creating a lot of extra work for yourself with this action.

Consider #6279, the effort to be able to use the back camera, a highly requested long-standing issue.

I put in many hours of my time to implement this feature, and now your bot has closed the issue so that I can no longer get feedback on whether it works or makes problems for other users. You have locked the issue down to collaborators, and even though I participated in the issue before, not even I can comment.

You are throwing road blocks into the way of your contributors, wasting their time and limiting their abilities to get work done.

Closing thousands of issues automatically has never helped anybody and will not make your issues go away. It is one of the big software-engineering antipatterns.

It appears Signal has a broken project management process, and this action will not fix it.

[haplo]

Replying to @Dyras above.

I ordinarily never post anything discussion related on here, but I just want to say I support the decision of cleaning out the really old/subpar issue reports.

I can understand cleaning up duplicate issues, or even completely-out-of-scope issues, but there are issues with open ready-to-be-merged pull requests that have been closed. Look at #2159, a long-standing issue with an open bounty that the contributor was trying to claim. Who believes that closing that issue is not a mistake? I would consider Signal an open-source failure if it drove contributors away like that.

[jlund-signal]

Since the beginning of March, over 14 new features have been added to Signal for Android including Registration Lock, enhanced authentication (with fingerprint support), UI enhancements, and comprehensive encrypted backup functionality.

The community forum has proven to be incredibly valuable as we work on new features. For example, several intrepid users volunteered to test the large-scale database migration that paved the way for encrypted backups. The smooth roll-out of this feature wouldn't have been possible without their early help.

The forum provides an ideal discussion format for feature requests because these conversations tend to be open-ended. Users can talk about the initial idea, and once something is in the app the conversation can seamlessly transition into suggestions for additional improvements to the feature or thoughts about the latest release.

We pay close attention to this feedback and we're active on the community forum. The shift to discussing Android feature requests on the forum isn't an attempt to distance ourselves from users. Rather, it's us fully embracing something that has worked really well -- in contrast with the former approach that wasn't working.

The problem with having an enormous number of open issues is that the repo can start to become a black hole that is difficult to navigate and that potential contributors are less likely to follow closely. Everything begins to blend together as the void grows. We needed to establish some clear guidelines that would be actively enforced in order to move towards a usable issue tracker.

To some users, this cleanup effort has felt like we are trying to sweep things under the rug, but our intent is just the opposite. We want to make bugs more visible and we want to fix them quickly.

Although there have definitely been some growing pains, this process is off to a promising start. The upcoming 4.19 release branch has already fixed 12 bugs (and counting) in less than a week. Several high-quality bug reports have been re-submitted by the community as part of the cleanup process. Freed from the legacy of long-dormant threads that were difficult to follow and often full of mostly stale information, issues are being addressed that were previously buried by a signal-to-noise ratio that was simply too high to be sustainable.

Although a blank slate was necessary, we knew that this process wasn't going to be easy and that we were asking a lot from our community. We understand the frustration that some of you are feeling and we appreciate your patience and support. Thank you for being such an important part of the project.

We know that there is more to do. We're as invested as anyone in the success of Signal and we'll continue to work hard every day to make it your favorite messaging application.

[jlund-signal]

I can understand cleaning up duplicate issues, or even completely-out-of-scope issues, but there are issues with open ready-to-be-merged pull requests that have been closed.

Pull Requests were deliberately excluded from the automated cleanup process (but not the linked issues). We'll be reviewing those separately.

[strugee]

@jlund-signal thanks for the response - it's very much appreciated.

What you've written makes a lot of sense, and as the maintainer of several projects I certainly sympathize with the desire to have a clean issue tracker. But there were a couple things that frustrated me about this experience. I wanted to voice some of those concerns, and some hopefully-productive suggestions for what could have been done instead.

First off, there wasn't enough (any?) communication in advance - I just woke up one to find that suddenly I had 20 GitHub notifications about issue closures, with no warning beforehand. In the future it would help a lot if the Signal folks engaged with the community and tried to work with them before making unilateral decisions like this, and it would probably prevent you from having to do what you've done here - responding to a crisis after it's occurred, instead of before, when it would be much easier to manage. See this section in the book Producing OSS for some stuff related to this. This is also related to the other problems since if you had solicited feedback before taking this action, we would've been able to suggest less invasive alternatives that might still have worked.

Second, it feels like the first instinct was to take the nuclear option. If I were doing the cleanup in this repository, I first would have tried using the bot to leave a comment that said something along the lines of, "we're trying to clean up the issue tracker; please leave a comment that says @signal-bot leave open if you have checked that this issue is still present in modern Signal versions. If not, it will be auto-closed in 30 days." That seems much more reasonable and hopefully would have had the same effect of making the issue tracker usable. If it didn't - that's okay! It still would have given you the option of doing the type of mass-close that actually happened. But at least you would have tried, and that type of effort will go pretty far towards inspiring goodwill.

Finally, it was pretty galling that all the issues were locked, since that just adds insult to injury. Mass closures already raise (to borrow a term from Freenode) the temperature, and locking the issues just feels insulting on top of that (see the bit about using channel op privileges sparingly). I cannot stress enough how damaging that is to the goodwill of the community. To have all my issues locked makes me feel like I'm being treated like a child who can't listen when other people ask me to follow instructions. Plus, as others in this thread have pointed out, it makes it impossible to cross-reference issues so you can find the new ones from the old ones.

All issues being locked makes those of us in the community feel unvalued. I personally am still here in this issue tracker because I think Signal is a really good product, and I really believe in it, but this behavior left me with an extremely bitter taste in my mouth. If something like that happens again I will probably consider leaving simply because I don't want to participate in a project where I have no real autonomy and where my contributions are continually disrespected.

Again, I appreciate your response, and your motivations. I really do hope you take what I've written into consideration - I want this project to succeed as much as you.

[jlund-signal]

@strugee Thank you for the thoughtful feedback. I don't anticipate that we'll need to do anything like this again in the Android repo, but we hear you.

[nh2]

@jlund Could you please reopen all issues in which people where waiting for user feedback (an example being #6279 (comment))?

Right now the communication channel between users who wanted to give feedback, like

I will try out your debug build in a couple days and let you know if it works as expected on my phone.

and developers is cut off:

This conversation has been locked and limited to collaborators.

And neither side can even comment on where to move the discussion instead.

[Trolldemorted]

@nh2 can't you open a new issue, and link to the old? Iirc it will still receive a notification that a reference was created.

[nh2]

Iirc it will still receive a notification that a reference was created.

@Trolldemorted I this is not the case, I have just tried it with #7664. For closed issues, a reference is created, but for issues where This conversation has been locked and limited to collaborators. it doesn't work.

Also, it wouldn't help much, because references are only created on Github, and people do not get any form of notifications (email, github notifications) from them, so they don't know that it happened unless they actively re-visit that issues without having been notified (which people almost never do).

[nh2]

Further, I'm not sure opening new issues is sanctioned in any way either:

Consider #7657, where somebody asked for their issue #7585 to be reopened, as was requested by @moxie0 in #7585 (comment)

Please reopen if you can provide a debug log that covers the relevant action.

@osrambilux did as asked, but in #7657 (comment) @moxie0 then replied

Hey @osrambilux, please do us a favor and fill in the issue template when opening issues here. thanks!

This suggests that "automation" (or else, just not reading the issue at all and just clicking the close button) has progressed so far that even the simplest interactions are no longer possible.

I think it's easy to agree on the fact that being asked to fill out issue template to ask for another issue to be re-opened, that you have been asked to reopen by the same person, is nonsensical and pure bureaucracy without benefit.

(I say this as somebody who regularly works on projects with thousands of open run by small teams issues regularly that still manage to handle their issue triage process well.)

[ghost]

@jlund-signal wrote:

The forum provides an ideal discussion format for feature requests because these conversations tend to be open-ended. Users can talk about the initial idea, and once something is in the app the conversation can seamlessly transition into suggestions for additional improvements to the feature

These statements don't bear scrutiny. There is no reason why feature request discussions could not happen on the issue tracker instead - avoiding the fragmentation of bug and feature request discussions, which are often strongly related, across different websites - except that you have arbitrarily insisted that feature request discussions not happen here.

We pay close attention to this feedback and we're active on the community forum. The shift to discussing Android feature requests on the forum isn't an attempt to distance ourselves from users. Rather, it's us fully embracing something that has worked really well -- in contrast with the former approach that wasn't working.

This doesn't bear scrutiny either. The issue tracker has threads; the forum has threads. There is no reason why the thread that happened on the forum could not have happened on the issue tracker.

The problem with having an enormous number of open issues is that the repo can start to become a black hole that is difficult to navigate

It wasn't hard to navigate until you forced linkless discontinuity between issues.

and that potential contributors are less likely to follow closely.

Where is your evidence for this?

Everything begins to blend together as the void grows.

No, it doesn't. Most issues are each in their own threads, and those threads are searchable and filterable.

For the occasions when somebody inadvertently creates a duplicate thread (i.e. a new thread about a topic that already has an existing thread), the duplicate can be linked to the existing thread and closed as a duplicate. (At least, it can be linked unless someone locks a thread as you have done.)

Thus, prior to #7598, the issue tracker permitted continuity in the discussion of each separate issue or feature request, while keeping them distinct and distinguishable from each other.

We needed to establish some clear guidelines that would be actively enforced in order to move towards a usable issue tracker.

You already had a usable issue tracker.

To some users, this cleanup effort has felt like we are trying to sweep things under the rug, but our intent is just the opposite. We want to make bugs more visible and we want to fix them quickly.

This, again, fails to bear scrutiny. Bugs don't become more visible by having their reports closed and locked. In other words, your intentions may have been good, but your actions, in this case, were at odds with them.

Although there have definitely been some growing pains, this process is off to a promising start. The upcoming 4.19 release branch has already fixed 12 bugs (and counting) in less than a week. Several high-quality bug reports have been re-submitted by the community as part of the cleanup process. Freed from the legacy of long-dormant threads that were difficult to follow and often full of mostly stale information, issues are being addressed that were previously buried by a signal-to-noise ratio that was simply too high to be sustainable.

In numerous cases the information in the existing threads was not stale and the threads were not long-dormant. Yet you closed them anyway. So, those "high-quality bug reports" represented a drain on the community's time that would have been completely avoided but for your unilateral suppression of arbitrary threads.

Although a blank slate was necessary,

You don't have a blank slate. What you now have is an even messier slate than you had prior to #7598, because:

• it is now much less clear whether a thread was closed for a good reason or just arbitrarily; and because
• the lack of linkability with the locked threads means that there is no clear path from them to any follow-up reports that may have subsequently been created; and because
• the number of duplicate reports is now necessarily larger, cluttering the search results and requiring people to read more threads before they can tell which ones are viable for tracking the issue that concerns them.

[colans]

@jlund-signal : As I received neither a fix nor any sort of response to my comment here 8 days ago, I opened Unlock Github feature-request issues to allow for links to Community feature requests in the community forum.

Please action as soon as possible. Folks need to know how to get from the old issues to the new ones.

[hyiltiz]

I wish it was possible for other contributors to re-open those autoclosed issues, so only the ones that no one bothers (those that needed cleaning) remain closed.

[jhpratt]

Since it appears there is zero progress on this issue, I'd like to throw out that I would absolutely love support for tablets/wifi-only devices. There are plenty of issues, all of which are appropriately closed as duplicates of #641. #641 is also one of the issues closed by this.

So I'll ask this question: What am I supposed to do? I can't comment on the original, since it's closed and locked. If I open a new issue, it'll likely be closed. And not just closed, but quite rudely as has happened in the past.

I could certainly help out and try to put together a PR enabling support for tablets, but I need confirmation that my effort will not be in vain, rudely and without merit rejected, or entirely ignored.

Pinging @sampablokuper

[greyson-signal]

@jhpratt You can discuss feature requests on the forum, and I wouldn't work on any major changes without first discussing it in the forum and getting feedback from a Signal employee. Thanks!