spacekookie
commented
6 years ago Are you actually gonna listen to user feedback on the forums for features or is this just a fancy way of saying "Go away"?
Closed jlund-signal closed 6 years ago
spacekookie
commented
6 years ago Are you actually gonna listen to user feedback on the forums for features or is this just a fancy way of saying "Go away"?
ghost
commented
6 years ago This misguided action is a problem on several fronts. In the case of bug reports that were not resolved but that have now suddenly, unilaterally been closed and locked by @jlund-signal as part of #7598:
This is not an appreciative way to treat the members of your community who are public-spirited enough to actually engage with you on the bug tracker; it's more like flipping us the bird.*
I mentioned, above, a list of examples illustrating the duplication of effort that #7598 is already causing. Here is that list, which contains some of the duplicate reports that have been filed in the last few hours where duplicates would otherwise likely not have been filed:
... and counting.
@jlund-signal, what do you suggest should be done regarding the people who were subscribed to the original bug reports that you have arbitrarily closed and locked in #7598 and that are now being duplicated? Are you going to migrate their subscriptions to the new issues, or are you going to require the community to pick up that slack by pinging them from the new bug reports so that they know which ones to subscribe to for continuity? (Or are you, as @spacekookie perceptively asked, just hoping that the community disappears?)
This is such a completely unnecessary headache :(
*This, in turn, creates another problem: it puts some of your most engaged users in the quandary of having to wonder whether or not it still makes sense to recommend Signal. I'll explain. For many users, Signal could be among the first FOSS apps they have ever used. (The very fact that it is FOSS is one of the reasons, after all, to use it instead of proprietary apps like WhatsApp or BBM or whatever.) This should be a positive experience, or else it might well put them off not just Signal, but FOSS altogether. I know a number of people for whom this is true - Signal is their first FOSS app - and who have experienced usability frustrations or technical issues with Signal. I have encouraged them to use the bug tracker and to file reports if they couldn't find a matching one that has already been filed. That would already be a stretch for them outside their comfort zone, but if they are sympathetically received, then that would help them to become long-term FOSS users and contributors, and it might help the Signal devs to better understand the difficulties that their users are experiencing with the app. If, however, they were to climb that mountain only to get slapped down by @moxie0 or close-locked by @jlund-signal , then that might realistically be the last time they ever bother to contribute to a FOSS project, and the last time they decide to pick a FOSS app over a proprietary one. Looked at like this, #7598 isn't really about bug tracking methodologies, it's about whether or not you, the Signal devs, are going to continue to be the change you (and many of your users) want to see in the world - a change towards being able to see what our software is doing with our data, and being able to work collaboratively to improve on that in order to facilitate the human rights to privacy and free assembly, etc - or not. And at the moment, it seems not.
Put differently: seasoned FOSS contributors might, sadly, be used to moody "benevolent dictator"-type project leaders or maintainers shutting people down for the hell of it, and be willing to push past that for a better outcome. New users aren't. No-one should be expected to be.
ghost
commented
6 years ago @jlund-signal better yet, please just revert your massive close-and-lock "spring clean", so that the original bug reports can just continue to be tracked and worked through as normal, avoiding any need for duplicate issues and subscription continuity workarounds.
mueller-ma
commented
6 years ago Do I need to add a debug log for UI-only bugs like #6870 ?
hotpocket
commented
6 years ago https://github.com/signalapp/Signal-Android/issues/6234
Has multiple debug logs from multiple people. The most recent "me too" comment also provided a debug log and was using a version released end of Feb 2018 (1 month old)
https://github.com/signalapp/Signal-Android/releases (4.16.9)
I applaud efforts to clean house and organize issues so they are better handled. I do not applaud attempts to sweep things under the rug.
I get the feeling this bug report and others mentioned here fall under the 2nd category. Please don't just close issues to improve bug tracking statistics.
If the signal team is buckling under the load let us know how we can help. I believe the people commenting on issues here want to make things better and to ignore their efforts is a slippery slope to another deprecated messaging app.
eligrey
commented
6 years ago https://github.com/signalapp/Signal-Android/issues/1085 is technically a feature request but it is also a bug regarding the lack of alternative identifier mechanisms. I feel that it would best be collaborated on via GitHub issues rather than the community form.
michel-zimmer
commented
6 years ago I definitely welcome housekeeping, because it keeps open source projects maintainable in the long run. I'm also OK with closing issues that don't follow the template.
What I don't get is why feature requests are banned. (Btw. multiple issue templates are possible.) The GitHub search functionality works exactly as it should in my opinion. And it is better than simple full text search. One can filter by labels - for example by appending -label:feature to hide feature requests.
But what I even more don't get is why this move has not been taken out with more precaution. This way a lot of active, helpful and overall worthwhile community members are probably put off. And an active and helpful community is more important than housekeeping as far as i can tell. You could have only closed issues not active in the last 2 months for example. And you could have transferred feature request issues with a +10 rating or so to the forum automatically and not leave that task to the community.
Just as an example for how powerful the search feature actually is: involves:automated-signal is:closed updated:>=2018-03-03 sort:reactions-+1-desc. These are the closed issues with activity in the last two months, closed by the bot and sorted by the number of up votes descending, so that we as the community don't loose track of them.
ghost
commented
6 years ago @jlund-signal, based on the number of downvotes and constructive but critical comments that you have received about this, it seems clear that it was a mistake.
The sooner you go about undoing #7598, the less overall disruption it will cause to the community.
Will you take responsibility and do that swiftly? Or are you just going to hope that this new problem, too, goes away, like all of the unresolved issues that you have effectively closed as WONTFIX, and that will now have to be re-reported as duplicates (at least, if any of the people affected by them can even be bothered to use Signal anymore, let alone to engage with the developers)?
@moxie0, it would behoove you to address these concerns, if @jlund-signal will not do so.
ghost
commented
6 years ago I'm here after posting my "me too" to "Import from plaintext backup fails. #7430" that was just closed. Has anyone re-opened that bug report?
Dyras
commented
6 years ago 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. No one benefits from having 2k+ open issues, it makes it difficult to find duplicates and it means issues quickly get lost as newer issues come in.
With fewer issues the developers will have an easier time managing the issues, which means more will get fixed in the long run.
For the next time, I would suggest spreading out the cleaning a bit more. I woke up to 92 new emails, half being "This issue was closed" and the other half was the cleanup message.
Also I think the downvotes have more to do with this being really sudden than anything else. Communication has sadly been really lacking over the years as far as Signal goes, which gives at least me the impression that you really don't want Signal to be a community project. I get that's not the intention, but it certainly feels that way sometimes. There's very little in the way of a public roadmap for this project and the only reason I know what's coming next is because I sit here on GitHub and look at the pull requests. Perhaps you should post about stuff like this on Twitter, on Reddit and on the signal.org blog a week or so before you go through with it?
A good start would be a blog post that explains why you picked Electron, since there seems to be a fair amount of critique against it at the moment. What are its obvious advantages over the alternatives as far as Signal-Desktop is concerned, what are the disadvantages and what are you doing to counter those disadvantages. Etc.
Anyway, I wish this project the best of luck. I've been using Signal since it was called TextSecure and it used GCM for message delivery and it's so much better today that the improvement is almost unreal. No doubt in my mind that Signal will grow over the years, you just have to make yourself more visible in the social media. That's all.
(This will probably not be responded to but I figured I should write it anyway just to show that not everyone hates you for this cleanup)
ghost
commented
6 years ago @Dyras , it's interesting to hear your perspective - different to mine as it is - but it doesn't seem to bear scrutiny:
having 2k+ open issues [...] makes it difficult to find duplicates
Do you really think that having more duplicates to have to search through, as #7598 has caused, will make it easier to identify whether some particular report has duplicates?
If so, I'd ... like to see your reasoning.
having 2k+ open issues [...] means issues quickly get lost as newer issues come in.
This doesn't make sense. Whether the number of open issues is 2 or 2k, reports are not lost. They are in the bug tracker, which is highly searchable and sortable.
Moreover, if the semantics of the bug tracker were followed (i.e. unresolved issues are left open; resolved issues are closed; discussions are not fragmented), then it would be easier to find reports relevant to whatever your concerns are, because then you could use the searching and sorting tools properly to query on properties like open vs closed, or number of comments, etc. #7598 has broken this functionality to an extent already, and the longer it goes unreverted, the greater that extent will become.
With fewer issues the developers will have an easier time managing the issues, which means more will get fixed in the long run.
cornfeedhobo
commented
6 years ago This is tough. Even recognizing all the downsides @sampablokuper has listed, I think I still side with the spring cleaning that was done, but fear that @spacekookie is spot on: This is also a cover for telling feature requests to go away, which would seem to align with the company's most recent strategies, e.g. partnering with Skype, despite the move furthering the siloed messaging ecosystem we are all suffering through.
Update: reading @Dyras's comments above, it's concerning that even more people get the sense that Signal is not interested in user feedback. Serious question for Signal developers: would your attitude change if we were paying for the app? I noticed the BitHub experiment never took off. I would gladly pay for your hard work, especially if it meant preventing choices that don't benefit me (I hope skype paid for a whole year of a developer or better). I already donate to the EFF, but would gladly fund feature requests.
ghost
commented
6 years ago @cornfeedhobo wait, Signal partnered with Skype? Well, that empties the toilet into the bathwater.
Do you have a link? Ah, https://signal.org/blog/skype-partnership/ . This might explain why the Signal devs are increasingly acting as though they were part of old-school Microsoft or some other "to hell with your feedback!"-style proprietary software company. I guess they are.
I suppose I had better start looking for genuinely free (as in freedom) software messaging systems to recommend in place of Signal. Sigh :(
pgerber
commented
6 years ago I believe helping Microsoft to improve the security of their platform was the right decision. The goal should be to bring more private and secure communication to as many people as possible. I'd like if telling the world to use Signal would just work, it doesn't. Thus, helping others to provide more secure and private communication, even if it is for a proprietary service, seem completely reasonable to me. Partnering with Microsoft (Skype), Google (Allo) and most importantly WhatsApp was the right decision if you ask me. Even if these messengers are far less privacy-preserving and security-conscious than Signal, how is improving security and privacy for billions a bad thing.
@sampablokuper How did you conclude that this cleanup has anything to do with Microsoft? Signal has partnered with Google and WhatsApp before and I never noticed any change.
ghost
commented
6 years ago @pgerber I didn't specify that the cleanup making-more-of-a-mess was directly related to Microsoft. Rather, I was noting that the way it was carried out was not reminiscent of a well-run FOSS project, but was instead reminiscent of the way that Microsoft and other proprietary software companies have tended to handle user feedback. I.e. from the users' perspective, it felt unilateral, dismissive, and inconveniencing.
This raises the question: why is a free software project being run like a proprietary software project? Well, if the developers are engaging extensively in proprietary software development, this could help to explain it. It's a matter of cultural approach, and unfortunately these things can rub off on people, which seems to be what has happened here. (For a subtler cultural perspective, one might say that even though Signal uses the GPLv3, a licence more strongly associated with the free software movement then with the open source movement, it is taking something like an open source approach - in the pejorative sense.)
As for whether partnering with Microsoft (Skype) was the right decision, clearly it wasn't. Partnering with WhatsApp was a terrible idea; partnering with Skype is even worse. I'll explain why, in reverse order. Based on past history, Microsoft is likely to be using its embrace, extend, and extinguish strategy against Signal. Frankly, anything that reduces people's incentive to use Signal (or other FOSS) in place of Skype (or other proprietary apps) is effectively extinguishing Signal's potential growth in usage, and let's be clear here that Microsoft's aim is much more likely to be preserving or increasing Skype's market share than protecting Microsoft customers' privacy. This tension between proprietary messaging market share vs FOSS market share isn't theoretical: I've spoken to many people who have said to me, "Why should I bother using Signal, when I can use WhatsApp which uses the Signal protocol too and must be fine because @moxie0 worked with them?" Answering this requires explaining to them about WhatsApp's retransmission vulnerability and unlawful data collection; about the network effect (i.e. if they don't start using Signal then it will be even harder to convince anyone else they know to start using Signal); and about the inherent security risks of proprietary software due to the lack of transparency around the code and the clear conflicts of interest around the economics. This is a much more involved conversation than would be necessary if Signal had not partnered with WhatsApp in the first place, and with a correspondingly lower likelihood of success.
So, ultimately, Signal's partnerships with WhatsApp and Skype are bad for privacy. They give a huge number of proprietary software users a false sense of security ("My proprietary app says it uses the Signal protocol, so it must protect my privacy." - wrong!) which increases their vulnerability and reduces the likelihood that they will take effective steps towards improving their privacy, such as switching to well-implemented, securely-designed FOSS. Those partnerships also, by reducing the incentive to switch, reduce the ability of Signal and other FOSS to benefit from the network effect, an impact that should not be underestimated.
childnode
commented
6 years ago @sampablokuper nothing to swear about any partnership - leaving aside any ethical or utopia worries -, just let's be fair to say: They are catched into market economy, they have to make money to live and Signal is just (going to be) the TechDemo.
why is a free software project being run like a proprietary software project
point ... but: if there is no real "OS community" that drives the development but only "user community" yelling to only ~ 4-6 real contributing guys whereof 2 are the main committers what is missing ... dear ... that won't work and that's not the first time OpenSource Projects died in unrealistic expectations and little contribution...
(Just to say: that's a pity, I love Signal) ... perhaps this "mass spring clean rant" will motivate some guys and girls to get hands on code ,)
colans
commented
6 years ago Can the old threads at least be unlocked so we can post links to the new feature requests in the community forum? Thanks.
ghost
commented
6 years ago @childnode wrote:
just let's be fair to say: They are catched into market economy, they have to make money to live and Signal is just (going to be) the TechDemo.
I totally sympathise with the need to keep a roof over one's head (or a boat under one's feet, as Moxie's case may be). But that doesn't seem to be the stated reason for Signal's partnerships with Microsoft (Skype), Facebook (WhatsApp; Facebook Messenger) or Google (Allo). AFAICT, neither Moxie nor any other Signal dev has said, "We didn't much like the idea of helping Microsoft/Facebook/Google to steal market share away from us and from other FOSS messaging systems and to give users a false sense of privacy, but it was the only way we could find to keep the Signal project alive." (Correct me if I'm wrong.)
Instead they said - without irony? - things like "WhatsApp deserves enormous praise ... Their devotion to the project as well as their thoroughness in getting this done are inspiring in a world where so many other companies are focused on surveillance instead of privacy." (Yes, this was after Facebook had already acquired WhatsApp, and after the Snowden revelations, and after Max Schrems had exposed the breaches of European data protection law by Facebook that were soon to bring down the Safe Harbor agreement.)
And they silently pass over offers to pay for the app; appear to have taken their Bitcoin donation page offline; and seem to be perpetually hiring.
So, either the partnerships weren't really about the money, they were about increasing the ease with which multinational proprietary software companies could retain market share (while finding new ways to undermine users' privacy and security, which is their business model); or else the Signal devs have been putting a very heavy spin on their own public communications.
I'm really quite sad about this :(
if there is no real "OS community" that drives the development but only "user community" yelling to only ~ 4-6 real contributing guys whereof 2 are the main committers what is missing ... dear ... that won't work
I understand your concern, but I'm not sure that it's warranted. Numerous long-standing FOSS projects have small developer/maintainer teams.
More of an issue, I suspect, is that instead of following, say, Rust's example of welcoming new contributors, there has been quite a bit of demeaning them, completely rejecting their concerns, and otherwise shutting them down (which is what #7598 seems to be all about; see above). I don't expect this is a great way to gain contributors. At best, it is a motivation to ask, "What is going on here? Why is this person acting like that?"
(In case you raise Linus Torvalds as a historical counterexample to that expectation, I'll note that the tide may be starting to turn.)
(Just to say: that's a pity, I love Signal) ... perhaps this "mass spring clean rant" will motivate some guys and girls to get hands on code ,)
Now here, I hope you're right :)
Natanji
commented
6 years ago I disagree that the spring cleaning was a mistake. As a person who can get super outraged at open source developers not doing as I want them to, I can understand the emotions running high. Of course there are downsides to this decision, but I honestly believe there are many upsides too. And if this is something that the developers decided that it helps them, I think it's wonderful. Hundreds of open issues do absolutely detract developers from getting a quick overview. Ever made a bug report for Firefox? You will literally go under in their thousands upon thousands of open reports that were never followed up on by anyone.
The cleanup doesn't mean the previous reports are not valued, and I get that it might feel that way, but that really isn't the point. The point is losing energy on a disorganized heap of issues, and wanting to start anew. Most people who come here don't know the more advanced sorting mechanisms of GitHub, at least I certainly don't. I find it way easier to see what's currently an issue and what is being worked on after the cleanup than before.
Any person who is subscribed to the old reports and still cares about the problem can file the report anew under the new bug template if it is still relevant and active - this helps out the developers tremendously to have a much better overview. Maybe understand yourself less as customers that get to dictate what the devs do - and more like helplings for them to find out about and fix issues you have found. I find it amazing that despite never having contributed a single line of code to the project, me and countless others were able to improve this project for everyone by doing so.
And for heaven's sake, keep this on-topic and productive instead of just venting here about your frustrations. Being mad at the devs for partnering with Microsoft really shouldn't be done here. If you must, have that discussion over at the community forums.
fbruetting
commented
6 years ago Why do you close feature requests? For bug logs not being available…?!
Trolldemorted
commented
6 years ago Because they have enough to do with fixing bugs at the moment, and most feature requests are duplicate issues?
wchristian
commented
6 years ago 
haplo
commented
6 years ago Issue #2159 was closed with an open pull request, could it be reopen and the pull request reviewed and merged?
nh2
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago 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
commented
6 years ago @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
commented
6 years ago @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
commented
6 years ago @jlund Could you please reopen all issues in which people where waiting for user feedback (an example being https://github.com/signalapp/Signal-Android/issues/6279#issuecomment-376284198)?
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
commented
6 years ago @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
commented
6 years ago 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
commented
6 years ago 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 https://github.com/signalapp/Signal-Android/issues/7585#issuecomment-378197322
Please reopen if you can provide a debug log that covers the relevant action.
@osrambilux did as asked, but in https://github.com/signalapp/Signal-Android/issues/7657#issuecomment-379523255 @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
commented
6 years ago @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:
colans
commented
6 years ago @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
commented
6 years ago 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
commented
5 years ago 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
commented
5 years ago @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!
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:
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.