* Rust Conversion (got a proof of concept, need to productionise it) - Anki Desktop has moved to Rust. We can unify all of the platform, and remove most of our backend code and maintenance burden.
* Android 11 has made significant changes to how applications store files on the device (Scoped Storage). I expect this will be a nightmare to deal with: https://developer.android.com/preview/privacy/storage
* Visual HTML Editor (probably 2.13) - currently editing and adding formatting could do with a ton of love. Typing HTML by hand isn't a great experience for non-technical users.
* User onboarding & UX - We get tons of bad reviews: "All my cards have been deleted" - this is because we fail to explain how Anki/Spaced Repetition works and that we take control of scheduling. People download AnkiDroid expecting flashcards, and we can do much better in this area.
* Performance improvements with larger collections - we're fast, but there's still lots of low-hanging fruit regarding multithreading.
* Background media sync - Medical Students have multi-gigabyte collections (just fixed a bug where some Android systems wouldn't open zips >= 2^31-1 bytes). We're tied to the AnkiWeb protocol for syncing, but it'd be a much better UX if we moved this to the background.
Personal Goals (some point in the future)
* CI/CD improvements - both speeding up build times, adding more styles of testing to the pipeline and adding more auto-linting.
* Accessibility - our TTS doesn't play well with Android talkback; this hurts me to type.
* Better gamepad support
Thanks!!
No official roadmap (such is Open Source), but:
* Rust Conversion (got a proof of concept, need to productionise it) - Anki Desktop has moved to Rust. We can unify all of the platform, and remove most of our backend code and maintenance burden.
* Visual HTML Editor (probably 2.13) - currently editing and adding formatting could do with a ton of love. Typing HTML by hand isn't a great experience for non-technical users.
* User onboarding & UX - We get tons of bad reviews: "All my cards have been deleted" - this is because we fail to explain how Anki/Spaced Repetition works and that we take control of scheduling. People download AnkiDroid expecting flashcards, and we can do much better in this area.
* Performance improvements with larger collections - we're fast, but there's still lots of low-hanging fruit regarding multithreading.
* Background media sync - Medical Students have multi-gigabyte collections (just fixed a bug where some Android systems wouldn't open zips >= 2^31-1 bytes). We're tied to the AnkiWeb protocol for syncing, but it'd be a much better UX if we moved this to the background.
Personal Goals (some point in the future)
* CI/CD improvements - both speeding up build times, adding more styles of testing to the pipeline and adding more auto-linting.
* Accessibility - our TTS doesn't play well with Android talkback; this hurts me to type.
I would love to contribute to Anki, especially learning that it's Rust. I know Anki's time-based space repetition is highly effective for long-term learning, but I've found it frustrating when I or my friends really just needed to cram the night before an exam.
When I am strongly constrained in the time-domain, I've found the older Leitner method to be the most efficient. I also have a lot of difficulty performing this in Anki except by resorting to absurd time controls and manual resets that are difficult to explain to friends.
I'd love to provide Anki with a strict Leitner mode for last-minute cramming. I'm just not sure the Anki project would support this, as I've seen them be fairly dismissive of it in the past.
Awesome, thank you for the info. Anki is a tool I use and love but I know very little about the behind the scenes work.
>* User onboarding & UX - We get tons of bad reviews: "All my cards have been deleted" - this is because we fail to explain how Anki/Spaced Repetition works and that we take control of scheduling. People download AnkiDroid expecting flashcards, and we can do much better in this area.
Somewhat related, but I would like a way to "cram" cards (ie. temporarily review all cards in a deck, in random order, without affecting anything about their spaced repetition timing). I feel like this must exist but I haven't found it. Do you know how to do this?
Also, how does Anki support the costs of Ankiweb? Is there a way I can contribute? It's not immediately obvious to me from clicking around on Ankiweb.
> Somewhat related, but I would like a way to "cram" cards (ie. temporarily review all cards in a deck, in random order, without affecting anything about their spaced repetition timing). I feel like this must exist but I haven't found it. Do you know how to do this?
That's a strange one... it exists, (Create Filtered Deck - Long Press - Options - Untick Reschedule) but only works well in the V2 Scheduler. The V1 scheduler doesn't handle cards in the red (learn/relearn) well.
Personally, I'm taking donations (caveat: AnkiDroid is a port, I'm one of a few contributors, and the money would go to me, rather than Damien, who runs the rest of the ecosystem (AnkiWeb/AnkiDesktop/AnkiMobile)): https://github.com/sponsors/david-allison-1/
No good reason. It's A combination of time allocation, the fact that it's a collaborative process and I'm still learning the ropes, and the fact that nobody's asked for one until now.
(new account, hit the HN anti-procrastination timer)
I hadn't contributed to Open Source before, had never wrote Java professionally, and my Android knowledge was pretty much non-existent, but I was aware of the project and how it operated. The catalyst was encountering a frustrating bug, and downloading the source to fix it.
The best thing about working on an application rather than a library is that you're dogfooding your own changes, and you have a good intuition for what the end result will be. You can always tell yourself: "Even if this isn't accepted, I find it useful and can use it".
I started out with small issues that I wanted improving, gradually moved on to getting access to crash reports, and fixing most of them (I think we're down from around 12 to 0.05 crashes per 1000 users). Confidence with larger issues comes from experience: documentation helps to some extent, but sitting down and reading the source code is always useful, as is looking to the source of the port as a source of truth.
Most projects would benefit from more volunteers (I just helped put out an ad for contributors on Stack Overflow). For confidence: accept that you're going to make mistakes as you start out, but the value that you bring to a project will overwhelmingly be net-positive as long as you stick with it.
> PS: Completely unrelated issue, just for fun search for "Logan's run" on Youtube, filter by "length > 20 minutes", and check out a few of the many results. ... Doesn't that waste huge amounts of Youtube storage? Why does Google not do anything about it, ML algorithms should have an easy time finding most of those uploads?
It's been prevalent for many years now. The files are typically a single image for the majority of the video, so compression should alleviate the storage issue.
These videos are likely very profitable for YouTube if ad-supported, given that they'll take very little data to store and serve.
I doubt the movie studios significantly care about removing them; the videos significantly frustrate pirates, likely causing a slight conversion to actual sales. To note: these results often appear on the ContentID dashboards (causing frustration for the studios), so this may be subject to change in future.
Since it's buried at the bottom of the stackexchange: #region/endregion is useful for visually grouping Unit Tests per method under test. They're also occasionally useful to group interface implementations.
I'm pretty sure that #1 is against Facebook's page guidelines:
> Personal Timelines and friend connections must not be used to administer promotions (e.g. "share on your Timeline to enter" or "share on your friend's Timeline to get additional entries" and "tag your friends in this post to enter" are not permitted).
> Exact lookup in the trie is O(string_length), like a hash table
It's worth noting that some standard libraries (Java's JDK for one [1]) will cache the value of String.GetHashCode(), meaning string lookup in a HashTable is constant time average (but O(n) worst-case due to collisions).
