Short answer:
the correction process does require a written explanation, but it is super helpful for us as a team and how we handle issues, feedback, corrections for lots of super awesome Skritter users.
Long answer:
Since this post is a question about How to best report issues? I’d like to dig deep into that question, and address that for anyone reading this, and also give a little behind-the-scenes insight into all this stuff.
First, I think it is important to establish that there needs to be a distinction between Beta feedback, and Corrections.
These should not be treated as the same thing, and it would be super helpful to us for anyone reading this if that distinction is honored.
When we get a screenshot on a beta build (via Apple) we get info about the device, build, and the associated TestFlight email. It’s a quick and easy way to quickly share info with us, and we can hopefully use those details to track down bugs and fix them before we release the app as a live production build.
That’s exactly what we’re looking for when we release beta builds. Rapid testing of new features, regressions, things of that nature, along with any details about the when and the where when things go wrong. We can then collect all the feedback in bulk, fix things up, and then release the next build or push the latest to production. Mission accomplished!
There are some issues with this submission process for Skritter, and now that I’m writing this reply it honestly might actually be best for us to disable this kind of reporting in the future 
That’s because what we don’t get from these emails are the super important things for when the issue is at the account or vocabulary level.
Skritter username and associated email are not provided with the screenshots, and it makes getting those details unnecessarily complicated. To make matters worse, we don’t actually have a way to reply directly to screenshots and establish a conversation. We can follow up manually, but it doesn’t mean that the email for TestFlight is the same as the email on Skritter.
Sometimes we can guess who the user is, but that isn’t always the case. So, we’ve gotta dig up all that info manually if we can and a new email and hope the user sees it and opens it. If we don’t know those details already, our first point of contact goes like this:
"Dear skritter user, thanks for your email. We’d love to help, but could you please let us know your username and the email address related to your account so we can take and dig into your account and assist?
No fun. Especially when the user doesn’t reply because the TestFlight email is in an inbox they never check because they made it 15 years ago or something like that. We’ve certainly seen it all at this point 
The alternate method of reporting report bugs and issues (not corrections) is to use the Contact button in the app, which we vastly prefer.
When issues come in via the Contact button in the app or the website, we get tons of helpful data right out of the gate. Username, account-associated email, build version, and a quick and easy way for us to establish a contact in the context of the issue being reported.
As an added bonus on Help Scout, users can even see previous conversations with us right in the app or on the website. Wahoo!!!
On our end, we get an alert in our Help Scout inbox, which our entire team can view, tag, add notes on, and even pass along to the appropriate team member with the tap of a button. From our end, this is smooth as butter 
and 100% the best way to report bugs or account-related issues.
Corrections and item-related issues are a different beast, and the best way to report them is slightly different.
To provide some context, our database has over one million entries and grows larger every day. There are mistakes, of course, and do our best to fix them up in batches on a regular basis. While we’ll never have 100% perfect entries, we are constantly and continually improving and expanding the character, word, and sentence-level content in Skritter. While a vocab item might have an issue with reading, audio, example sentence, etc. they’re not bugs in the software sense, and really shouldn’t be treated as such.
The app is largely working and doing its thing, and fixing the item will not require a beta or production update.
Because of that, the best way to report corrections is to use the Submit Correction button from the vocab info screen. When a correction is submitted this way it automatically gets tagged in our system by issue type, and we get tons of details about the vocabulary in question along with a direct link that opens up the item directly in our database.
No muss, no fuss, no fat finger typos, or time spent typing the entry in a search query-- we just press a button and the item in question can be fixed up during the next batch of corrections we do!
Honestly, these days we can actually do lots of cool things on our backend, which are pretty cool. Not only can we fix corrections, but we can also add sentences, update audio files, audio Skritter-made images, deck art, and in-app videos, and lots more on the fly with a single save button. Those updates then automatically go out to the website and new mobile apps and are updated the next time you sync your account or open a deck-- no local data refresh needed!
I hope those details help answer the questions about how to best report issues. This is a super long reply, but I wanted to give some additional context behind how it all works, and why we encourage everyone to use the flows we’ve built out. We know it takes a little bit more effort to send an email in the app using the Contact form or using the Submit Correction button, but it saves us an insane amount of time on our end, which is time we can then spend making more content, fixing more issues, and making more updates to the apps that all you wonderful and passionate people reading this far are using to study Chinese and Japanese 
Best,
Jake and The Skritter Team
