Priority queue issue
If you like Incremental Reading check out previous post a status report from a newbie in IR
Priority queue includes dismissed elements
First of all, if you think you read this before see note at the botton of the post.
Browsing trough my collection, I accidentally hit “alt+p” over a dismissed topic (folder in this case). To my surprise it had a high priority position 0.02 % (107 in a 54000 element queue).
To know some elements are never going to be postponed via autopospone is great insurance for high importance material. The only problem though that in this case this is a folder. To keep dismissed elements in the priority queue (even worst high in that queue) is not correct. This elements displace real high priority elements which also affects the autopostpone behavior that is the most effective way to deal with overload and hence with people leaving supermemo after getting to a huge acumulation of material in their queue. If the autopospone + priority have this design troubles people won’t trust its knowledge to supermemo in the long run.
The priority queue is almost the main reason for using sm2006 but this high priority for dismissed elements simply is plain wrong, and should be even better in newer versions.
Design of a priority queue should always based on pending material
You are only concern with “to do items”, in supermemo case those are memorized or pending.
Currently the priority percentage is been manage by the total items in the collection, which I feel is a design problem. You have an item with 6% priority in a total of 7000 items of which 50% are dismissed elements, Then in reality its priority is 12%, but of course no one will notice it at first hand.
Dismissed elements by default on any GTD management system goes to the bottom of priorities or even better have no priority at all.
Dismissed elements included in Piority window are useless
In the following scenario:
topic # 67: (dismissed element)
item #24: What is the most common cause of pneumonia? (memorized)
Topic #1542: (dismissed element)
Is not possible to make a decision about priority with regard to previous or folowing element in priority queue. Would you put it before or after the dismissed element, always before anything dismissed, wright?
Autopospone manages high priority material by not postponing them
Auto-postpone is great way for managing overload of material. By using a priority queue things get even better, that is unless the priority queue es flawed.
I consider the information in my collection according to an interval scale:
0-10% high priority
10-50% regular priority
50-100% low priority
Of course all information added to supermemo is always important, but priority has to do with what is most important over other important information.
Setting this interval scaling helps me decide the value of priority assigned to an element when needed, usually a mid interval is chosen inside the desired category
Autopostpone is set to never postpone elements with priorities lower then 10% in my collection.
After a while of including a lot of dissmised items more and more are going to be included with priorities in the 0-10% range leaving many items of high priority aside.
If you got many dismissed elements, and this fill up a lot of spaces in the priority queue, because if you don’t move dismissed elements to the end of the queue they will displaced really high priority elements making this item postponeable and the whole priority + autopostpone algorithm useless.
- Priority queue should only consider Memorized and Pending elements
- Priority total should only refer to this elements
- Dismissed elements should regain a new priority when added to the memorized or pending material, because of the change in its condition.
Current Work Around:
In my continue motto: “Don’t complain, fix it!”. Here is what I’ve been doing to deal with the problem.
Every once and a while (e.g. monthly or after adding a lot of new elements)
Open View: Dismissed
Undismiss all subset
Dismiss all subset back.
Dismissed elements are always put at the lowest priority possible (I previously though this was flawed) In this sense steps needed are less and simpler. Previous steps are bellow in gray.
- Open complete collection in browser
- Selected child dismissed
- Change priority
- Dismiss again the same subset.
Notes: (3) is necessary otherwise browser won’t accept changing priorities in dismissed elements. (4) Use a interval big enough to fit all dismissed items. (5) Don’t ever forget this step, else medicine will be worst then the disease.
I do this is by using autohotkey macros, but not plain keyboard will do it with ease.
This an updated post for problems on priority queue for dismissed elements