No no, nothing like that. My question is about the new SRS changes related to having more than one SRS system and a different number of stages.
What I mean is, what if you introduce a new SRS system that only has 5 stages? Let’s say it goes:
Unlocking: 0
Starting: 1-2
Passing: 3
Burning: 4
If you get a review wrong, would you have it drop by one rank if it was at SRS stage 1 or 2 (starting) but drop by two ranks if it was at SRS stage 3 (passing)? That seems like it would be most consistent with the current approach, but I wasn’t sure if you’d thought about that.
Yes, given the algorithm we are using, stages starting (meaning the srs stage before the review was completed) below the passing stage will drop by a factor of 1.
Yep that would be the case.
We plan to keep it consistent like this across all spaced repetition systems. There are no plans on having unique algorithms for systems.
I never particularly liked the level names - it irked me that ‘guru’ was before ‘master’, that ‘guru’, a Sanskrit term, always struck me as a bit dodgy for a site about learning Japanese, and that the stage names seemed a little arbitrary. I hacked an extension to rename the stages to a poetically expressed length of time before they’d become due again, so ‘dawn’, ‘midday’, ‘dusk’, ‘night’, ‘rising sun’ (the ‘passing’ stage), ‘week’, ‘fortnight’, ‘month’, and ‘season’.
@viet “However, we have plans to add more spaced repetition systems”
Does this mean you’re going to add more stuff to WK or just that you’re going to tailor SRS stages to some items/lvls/whatever ?
EDIT: also I’m not sure “a full 2 months” is enough time for people maintaining scripts on their free time and I can’t use WK vanilla (no offense). I’m s c a r e d
I wouldn’t say so. The number of complaints about how slow WaniKani is was truly astronomical.
And if this is your first experience using an SRS, it’s easier to start understanding how it works if the first reviews pop back up again fairly quickly and it doesn’t take a week to reach level 2.
It might seem unnecessary in the grand scheme of the system, but from a customer experience point of view as your first point of contact with the programme I think it’s a good design.
Particularly since sitting on just radicals for 3 days would be unbearable. Plus, many users will have learned a decent amount of the N5 Kanji, making them suffer with a low amount of reviews for things they already know.
Same. The simplicity has made it easy to be consistent and honetly, I wish theyd hold off for 9 months so I could finish the way the system is currently set up. Because… it works for me. I wish they would give people a way to choose Wanikani original because I would rather stick with what im doing now thats working for me. I can see myself improving and I dont want that to stop. Im afraid this will sap my motivation and just cause me to stop. But, we will see.
Going against the grain a bit here and keep in mind, I’ve never worked with the WK API, but from a technical standpoint I do like the API changes. These changes will give the team more options to customize WK to individual users and experiment with different STS strategies easier. It’s the kind of change that would allow them to play with different settings on the test server without rolling them all out to us.
A couple ideas I thought of could be setting the early levels (beyond just 1/2) to shorter SRS stages, but slowly lengthening them to help the WK-is-too-slow complaints. Or, creating a pre-test, then cutting the SRS stages down to help those with prior knowledge catch up quicker, while still getting them adjusted to all the WK mnemonics and SRS style (this could also be used for anyone thinking about resetting). @viet’s suggestion of shortening radical SRS stages is something I’m in total support of.
Getting attached to the SRS stage names is silly, but changing them does cause problems for communicating about them. As long as the naming is consistent and progression is clear, I don’t see this being a major issue.
I’ve been pretty critical on some of the more recent changes, but this is one I can totally get behind.
@viet While the docs are being updated, can you add a section on resurrecting burned items? It seems odd that while you technically could do that via API, there is no formal documentation.
That is an internal endpoint for us to use. It isn’t an official API endpoint (it isn’t in the api subdomain namespace). Therefore no documentation since it isn’t meant to be used as a public API.
