Helping out and triaging

[jcrben]

Following up on my offer to help triage @jberkel -

I think I'd need project permissions, yep (dunno much about matrix permissions, some stuff at https://github.com/isaacs/github/issues/311 and https://help.github.com/articles/repository-permission-levels-for-an-organization/). I'm a developer without Android or Java skills so I can ask the right questions and maybe take a glance at a log here or there but don't expect to contribute code anytime soon.

I'd like to see more labels and close more issues. It's best if users report bugs against later versions than the 2015 one in the Play store, and if they can't provide a log, I'm inclined to close after a period of time... for example https://github.com/jberkel/sms-backup-plus/issues/380

Also, we could add a .github/ISSUE_TEMPLATE and add a code helpers badge https://www.codetriage.com/ maybe?

Anyhow, no pressure - I can't promise I'd be very active - possibly only spending an hour or two a month, especially after or while checking my backups 😆

[jberkel]

Awesome, thanks again!

I created an initial issue template, feel free to adapt it. I also added you to the project so you should be able to apply labels etc. Stale/"Hanging" issues should definitely be closed. Also let me know if something in the docs is missing, I'm planning to rewrite some of it for the next major release.

I haven't used codetriage.com, interesting idea, I'll add it.

[jcrben]

I added the help wanted and good first issue labels since Github does some work with those automatically https://help.github.com/articles/finding-open-source-projects-on-github/#searching-using-labels

Also something that confirms reproducibility would be good - do you have a name in mind? reproducible or something?

I wonder how hard I would present a repro case. When I report bugs, I like to be able to present an actual downloadable case showing the bug, often with a repo and possibly with a VM in packer (packer.io) if it's platform-dependent - dunno if you can do that with Android.

[jberkel]

maybe confirmed? repo cases are difficult in general, some of the bugs are very dependent on a specific version of Android, a particular carrier etc. Especially the backup reliability related issues are very hard to reproduce. But some are really "obvious" bugs, and it would be good if they could be labeled as such.

[jberkel]

In preparation for the upcoming release I've just done a marathon bug review session.

Besides the known problems (RCS, MMS, Auto backup) there don't seem to be any major "real" issues. Also thanks @Woi who added relevant context to some of the issues. Let me know if you want project access to help with future triaging.

[jcrben]

Nice! By the way I saw https://blog.github.com/2018-03-28-improved-organization-project-permissions/ - haven't really dug into it

We might want to have another tag for "awaiting information" or something to help us find places where we asked for more information and didn't get it. And ultimately there are automation tools out there...

[Woi]

Project access would be nice. Don't expect continues involvement from me, but at least I could close, link and label some of this old bug reports.

[jberkel]

@Woi invite sent. don't worry, there are no expectations on my part.

[Woi]

Cool. Thanks :)

[jcrben]

@jberkel just as an fyi - I'm still using this and will help out when I can (including maybe code someday), but I'm not having the issues that a lot of people are e.g. restoring thousands and not motivated to help out with that... I'm fine with the messages archive in email

restoring thousands UPDATE: glancing at https://github.com/jberkel/sms-backup-plus/issues/868 - it seems that a large restore was successful... still, maybe the app should only cap the loaded number and notify the user that no more will be loaded. It may not be realistic to load an unlimited amount.

I agree with the sentiment at https://github.com/jberkel/sms-backup-plus#faq-restore-many-messages

SMS Backup has not been designed to restore many thousands of messages.

and even https://github.com/jberkel/sms-backup-plus/pull/586 noted that "Restoring a lot of messages by default fails after at least 30 minutes with e.g. timeout of IMAP server" (altho that was in 2015, not sure if you've improved it).

moving away from SMS and supporting countless permutations Long-term, I want to move away SMS and be using an open-source platform where the messaging protocol is open-source such as Signal or Riot or what have you. I'm also pessimistic about the problem of reproducing problems on the various permutations of platforms, which is minimized if there's a more centralized app.

So I'm also planning to make open-source contributions in that area. Signal can also handle SMS so once it stabilizes a bit more I may switch - altho I'm also waiting for the Signal Desktop to support SMS since I currently use SMS from the desktop quite a bit using Pulse (I also discussed this a bit in the context of reliability at https://github.com/klinker-apps/messenger-issues/issues/101#issuecomment-373424858).

[jberkel]

I think SMS will still be around for a while, there are still many markets with low smartphone usage/bad internet. it'd be nice if Android offered a common storage protocol for all the different messaging solutions, then SMS Backup+ could just hook into that.

re: restoring, this should probably be addressed seriously in a future release. I think there's definitely a way to make it faster and more reliable (even if it fails with a temp error it could pick up where it stopped on the next run)

anyway, thanks for your help, it allows me to focus more on the development part 👍

[kurahaupo]

As I indicated in #985, I'm also helping out where I can. Lately I've been adding new labels where there's commonality between issues; let me know if this is helpful. (I figure the text of a label can be changed, so they're merely my own suggestions.)

I've also added a few technical feature requests that should help fulfil various user functionality requests.