Been looking at some of the issues in Github for Status React and it’s approaching 500 even with all the various issues going stale and getting auto-closed daily. That’s a scary amount of tech debt.
I’m wondering if there’s any concept of bug jail right now, i.e. at which point are things no longer added and instead there is a feature freeze until a % of bugs is resolved / closed? If there is nothing, I would recommend adopting such a workflow even at the expense of some of the swarm progress (only in a minor and very temporary way), because otherwise we’re building on some broken foundations and compounding the issue for the future.
For example, Status flat out still doesn’t work after sleep on Android 9+ and I’ve never managed to sync devices. And yet, we’re getting a sticker market. This is not to disparage a feature that’s going to add utility to SNT, or the hard work of the team. It just seems strange in terms of priorities, especially given that, among some other things, we have:
Has there been discussion prioritizing bug resolutions? If not in the form of bug jail then maybe in the form of dedicated bug-days or bug-weeks? For example, bughuntThursday, or one week every 2 months everyone competes in resolving as many bugs as possible for some Kudos, something like that? Make it public, too, so we have bug bounty weeks? Better yet, people can do writeups of how they squashed a bug and not only increase community engagement but also inadvertently train people for the next bughunt by providing awesome detailed resources and hunting procedures.
I couldn’t find any discussions about this so just putting it out here, maybe worth brainstorming?
You’d be surprised. I’ve worked on a few projects in this decade which “versioned” via email and each team member worked on a specific monolithic file dedicated to them and them only.
This post makes my sense of justice hurt. I disagree on a couple of levels there and it shows our teams from a murky perspective.
(1) The Android bug
That isn’t true to all devices, you got the unlucky one. I’ve been using Status with Android 9 since it was released and never had this particular issue and can’t reproduce it at all.
(2) We always prioritise bugfixes before releasing anything, so a week before the public release is always a bugfix week. Right now we don’t release that often, so they are more rare obviously.
(3) Not only we fix bugs in our codebase, but we also give back to the community making the libs we are using better.
For example:
OK but then you should have put feedback into the issue?
2 and 3 I didn’t know, and imo should be communicated better. This is precisely why I posted this - to find out if any initiatives exist, because I wasn’t aware of any. Where can I learn more about concentrated bugfix efforts?
These were not any special “initiatives”, that’s common sense. We need to make a public release, we make a deeper dive into our app, we fix bugs. If a bug is in an external library, we try to fix it upstream because we don’t want to support/update a separate fork of a library.
Sure, I see you have your pet peeves in the app, but try installing a version from the beginning of 2018 and compare it to what we have now
So, my logic behind all this is that if the app is getting better, it means that what we do works, somehow. Sure it is a very subjective feeling, but the last thing I want is to make everyone to try to optimize some metric as a KPI. In general, treating code quality by then number of open bugs is hardly better then measuring programmer’s productivity by lines of code written.
A huge amount of issues in the repo is also explained by the fact that we used to use them for project management and coordination and now we mostly not. So it is good that the bot is closing them.
On the other hand, you are doing a nice job of keeping some of the bugs alive, thanks!
I hope you don’t take this personally, I’m just a concerned citizen. I’m commenting on what I see, and what I see right now is that both implementations I’m using - Windows and Android 9+ - are currently broken or semi-functional for me and there’s been surprisingly little feedback on it. I find it hard to believe there’s so few people with Android 9+ phones that can just say “can’t reproduce” or “here too”. So I’m just trying to find out why I’m getting this impression, if it’s my fault, and how I can help and/or learn more.
IMO this is not a good argument. Sacrifices have been made to get to this state (centralized elements were introduced), so I wouldn’t call it an all out win, but I would agree that, in broad strokes, we have a better app now than we used to, of course. My peeves are not pet, though - they’re blockers and why I don’t use Status nearly as much as I’d want to.
100% agree - not something I was recommending. The kudos would have as much significance to one’s job as the Slack kudos did, it’s just flair for the gamification lovers out there.
Yes but none of those are tagged as bugs I think?
Anyway, what I’m saying is I’m seeing the Chrome effect forming. The Google Chrome repo has open issues from 2009, but those were all neglected because they had to add bells and whistles to compete with Firefox’s bells and whistles.
I think discussions like these contribute to transparency and clear things up, far from murkying up. We have extremely silly blockers in Nimbus too but we’re aware of them and have plans for dedicated “tech debt removal” periods. That’s all I’m trying to bring up here to see if there’s any interest in crowdsourcing or Statussourcing it.
Again, you make it sound (to me) like everyone with Android 9 has this issue, but that is just not true. Some phones with Android 9 have it, some don’t. It’s not reproducible with Android 9 on my Pixel 2, so it is not even everyone with it.
As for centralized elements (as of mailservers and Infura): they were introduced before beginning of 2018, so they aren’t the reason the app has become better last year. And we also expanded from 2 to 5 platforms that are used by the core contributors.
I have nothing against the initiatives to focus on bugfixing. If anything, I did them as a standard practice at Opera.
I read into your initial post the attitude I really disliked and it really hurt my feelings. I really felt that the team wasn’t judged appropriately. I hope I’m the most sensitive one there
After it wiped out my local configuration, I subscribed to #status and it did not sync. I waited a few hours, then subscribed to 3-4 more channels - that’s when it started syncing.
More than the bug itself, this is about user experience - the only feelings that matter
(1) Priorities. We have 6 developers on Core Improvements that actually fixes issues and improves different aspects of the app vs 2 developers on the Sticker Market.
(2) High-severity issues. Sure, we have 16 open as of now, and the oldest one is very old, but to put it in perspective:
- 2 were fixed since this post was opened;
- 11 were fixes since December 1st
- 129 were closed since July when we actually introduced the severity field.
I don’t know… We have a QA team that tests (mobile) nightlies, and we have automation so it looks unlikely to me.
On the other hand, I agree that that bug reporting experience was very bad. Obviously, the issue was fixed somewhere, but no one actually answered.
Probably, right now to get your issue properly noticed, you also want to ping people in #status-desktop channel. And that should be improved, yes.
Not sure if that is bad or good. But anyway, feel free to ping me or Anna on Status (or #status-core) or via email if you bump into something.
…
So, maybe we can just make a poll for people to specify top 3 blockers for them and a version that they use? Maybe after the next release (beginning of February)? What do you think?
If a bug is in an external library, we try to fix it upstream because we don’t want to support/update a separate fork of a library.
