You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I will outline how I imagine (or would like) the weekly review to work in org-gtd to elicit opinions, suggestions etc.
For me processing of the inbox combines step 2 (clarify) and step 3 (organize) of the GTD methodology. Step 4 (reflect) of the methodology can be performed daily/weekly but David Allen emphasises the importance of the weekly reflection. In any case, a M-x org-gtd-reflect command should exist to initiate a session of reflection.
For me step 4 (reflect), involves processing of all files in one's GTD system (i.e. any files in org-gtd-directory - this approach offers flexibility to the user to use as many files as they need/want in their system. Some have all projects, single action tasks etc. in one file; others prefer to have a separate file for each project etc. I include the inbox.org file in this as quite often items can still be in the inbox when one comes to perform their weekly review.
I imagine such a review working similar to how we currently process the inbox. We take a file in org-gtd-directory, narrowing the "reflect" buffer to the first top level heading and cycle through all top-level headings (a progress counter as suggested in issue #69 would be welcome in a reflect buffer too) in the file one-by-one as we do when we process the inbox. We repeat this process for each file in the org-gtd-directory. Therefore, we would have to track what files have been reviewed already.
When we narrow on a project headline (i.e. a top-level headline with subheadings) the reflect buffer should present all subheadings. It may be best for the reflect buffer to take the whole frame when the reflection session is started. When a reflect buffer narrows on a headline the user should be able to archive it if it is truly complete or in the case of a project add further subtasks if they feel it is still not complete. In such a reflect buffer they should be able to do the usual stuff they expect to an org headline such as adding a priority, adding/removing tags etc., change the todo state, re-order subtask headlines etc. The ability to skip a headline and move to the next in a reflect buffer would be welcome.
Ideally, a project has a TODO state and only switches to DONE when all subtasks are in a done state. If a subtask switches back to an undone state then the project state should automatically switch back to the TODO state. An incomplete project without at least one subtask with a NEXT state should be considered a stuck project. Users can make use of org-agenda to group projects that are stuck so they can come to their attention even before a weekly review.
The text was updated successfully, but these errors were encountered:
I will outline how I imagine (or would like) the weekly review to work in
org-gtd
to elicit opinions, suggestions etc.For me processing of the inbox combines step 2 (clarify) and step 3 (organize) of the GTD methodology. Step 4 (reflect) of the methodology can be performed daily/weekly but David Allen emphasises the importance of the weekly reflection. In any case, a
M-x org-gtd-reflect
command should exist to initiate a session of reflection.For me step 4 (reflect), involves processing of all files in one's GTD system (i.e. any files in
org-gtd-directory
- this approach offers flexibility to the user to use as many files as they need/want in their system. Some have all projects, single action tasks etc. in one file; others prefer to have a separate file for each project etc. I include theinbox.org
file in this as quite often items can still be in the inbox when one comes to perform their weekly review.I imagine such a review working similar to how we currently process the inbox. We take a file in
org-gtd-directory
, narrowing the "reflect" buffer to the first top level heading and cycle through all top-level headings (a progress counter as suggested in issue #69 would be welcome in a reflect buffer too) in the file one-by-one as we do when we process the inbox. We repeat this process for each file in theorg-gtd-directory
. Therefore, we would have to track what files have been reviewed already.When we narrow on a project headline (i.e. a top-level headline with subheadings) the reflect buffer should present all subheadings. It may be best for the reflect buffer to take the whole frame when the reflection session is started. When a reflect buffer narrows on a headline the user should be able to archive it if it is truly complete or in the case of a project add further subtasks if they feel it is still not complete. In such a reflect buffer they should be able to do the usual stuff they expect to an org headline such as adding a priority, adding/removing tags etc., change the todo state, re-order subtask headlines etc. The ability to skip a headline and move to the next in a reflect buffer would be welcome.
Ideally, a project has a TODO state and only switches to DONE when all subtasks are in a done state. If a subtask switches back to an undone state then the project state should automatically switch back to the TODO state. An incomplete project without at least one subtask with a NEXT state should be considered a stuck project. Users can make use of
org-agenda
to group projects that are stuck so they can come to their attention even before a weekly review.The text was updated successfully, but these errors were encountered: