Setting for repeating times

[alexanderadam]

trafficstars

Reproduction Steps

1. Go to settings or settings documention
2. Search for repeating times

Expected Result

Having a possibility to configure the "repeating times" (1 min, 10 min, 4 d).

Actual Result

Nothing to find

Debug info

AnkiDroid Version: 2.9.1 Android Version: 9 ACRA UUID: 79b69820-6975-4051-abdd-e6f15900be29

Research

• [x] I have read the support page and am reporting a bug or enhancement request specific to AnkiDroid
• [x] I have checked the manual and the FAQ and could not find a solution to my issue
• [x] I have searched for similar existing issues here and on the user forum

PS: I have the feeling that this thing is so obvious that there probably is some possibility to configure them but I can't find it. So in that case it would be good to improve documentation regarding this.

PPS: I know that I can set a maximum but this is obviously not the same and leads to buggy behaviour. For example setting the maximum to 4 days will lead to having something like this:

[mikehardy]

Hi there! I think what you're looking for is covered in the "upstream" manual (that is, the manual for Anki Desktop, which AnkiDroid is based on, and which covers more than just the AnkiDroid manual) https://apps.ankiweb.net/docs/manual.html#reviews

[alexanderadam]

Wow, thank you for this unbelievable fast answer. :pray:

So is the Interval modifier what I'm looking for? If I try to set it to 70 it shows 69 in the overview, which is nice, but still "wrong". :wink:

Also setting the maximum still leads to situations where buttons have the same value and I'm not sure whether there is any situation where this would be useful. I rather would think that having a maximum would mean that buttons on the left side of the maximum buttons will have less than the maximum in any case).

And would it make sense to keep this issue also open regarding the missing documentation in the AnkiDroid doc? Because now there are kind of 'two truths'. Or did I misunderstand the documentation situation?

[mikehardy]

I would close it personally, it's like 2 manuals that work together because AnkiDroid is just an Android-specific implementation of Anki. That means AnkiDroid documentation may have some specific information but in general unless AnkiDroid docs say something different, the Anki manual is the rule. It's inefficient to make both complete when we can just refer upstream

As for the specifics of the math making 70 look like 69, it could have to do with current day settings etc - referring again to efficiency, it is likely not efficient to focus on such a small thing vs getting to the truly hard work of reviewing and recall on material to memorize ;-). That said, occasionally there are errors - if you detect one and you can reproduce it upstream on Anki Desktop it could be a bug

[alexanderadam]

the Anki manual is the rule

So AnkiDroid is referring to the 'incomplete' one right now, right? Meaning the help system is somehow broken if someone expects the AnkiDroid documention to be as helpful as the 'correct' one?

the specifics of the math making 70 look like 69, it could have to do with current day settings

what? Day settings? :eyes: Why? I would have expected a regular rounding error instead (like when calculating 1.2 - 1.0).

it is likely not efficient to focus on such a small thing

I agree with that. However focusing on things don't have anything to do with issue lists and backlogs. Issue lists and backlogs should be complete but you should focus on one thing at a time. Issue tags (i.e. priorities, versions, causes etc.), filters and assignments usually help focusing.

if you detect one and you can reproduce it upstream on Anki Desktop it could be a bug

But a bug can still be a bug if it's just appearing on AnkiDroid, right? :thinking:

[mikehardy]

PRs are welcome

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[alexanderadam]

still searching for solutions

[david-allison]

Bad bot!

[github-actions[bot]]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

[alexanderadam]

Isn't there a label that can be applied to avoid the bot spamming? :thinking:

[mikehardy]

There is, but you know what's even better? Someone caring enough to actually implement it. If no one cares and it goes stale then it's not spam, it's a valid indicator that nothing is going to happen

[alexanderadam]

If no one cares […]

We wouldn't comment here, if no one would care. I might not be a Java developer, but I am a user of the application who cares about its behaviour because I'm using it and I'm believing in improvements anyway. So its obviously not the case that no one is caring about it. AnkiDroids userbase might be smaller than others, but even then a wording like 'no one' might be wrong / misleading.

[…] it goes stale then it's not spam, it's a valid indicator that nothing is going to happen

But an issue that's not fixed or declined isn't in any finished state either.

Usually one of two things happen with unfixed issues in the combination with a stale bot:

1. Ticket is getting closed and people create duplicates
2. People are writing 'bump' or similar comments to avoid the closing of the issue.

Therefore both variants will generate notification noise without helping to fix any issues. And it turns out that SPAM is pretty much the same: notification noise without any sign of productivity.

An open issue that doesn't show any progress is at least very clear that there's no further progress. Which is obviously also worthy communication in a way, isn't it? This way other users might stumble over this issue and can clearly see that it is still an open issue. Which is also semantically the correct state in my opinion.

[mikehardy]

There is a lot of collective experience in open source project management that disagrees with you, @alexanderadam

It's also not a debate.

[david-allison]

@mikehardy This seems like a docs issue. May I transfer it to ankidroiddocs?

[mikehardy]

Sure