起点——GTD框架
- 经历了捕捉之后，或者确认将采用新的GTD规则后，将依据规则对捕捉到的新条目，以及没有应用新规则的旧条目进行处理，组织整理，回顾，执行等。
- 实践GTD之时，将GTD的处理分为：处理、组织整理、回顾、执行四个阶段（其实处理前面还有一个捕捉，执行之后有一个归档）。
实现-GTD流程
说明
- 始于:2019-10-15 二 16:15 目前(2019-10-11 五 17:04)而言，为使GTD流程可靠，将遵循后面的流程
- 针对GTD流程的大致管理思路，参考 GTD实践流程-思考
- 表述整体流程框架的配置: 以不同的视图，表述GTD处理流程的各个阶段，大致如下：
Orgmode Agenda配置
使用Agenda做为过滤条件，标题TODO标记做为状态，使用属性 CATEGORY 标记六个高度视野中的类型（原子/非原子）。
其中，原子属性行动用四象限方式标记成4种： Q1, Q2, Q3, Q4 ，非原子属性即对应六个高度视野项目以上层次。
自定义的Agenda视图如下：
;;custom view
(defun my-custom-view
(searchstr)
;;(org-tags-view nil "PRIORITY=\"B\"")
(org-tags-view nil searchstr))
(setq org-agenda-custom-commands nil)
;;Setup Gtd views
(setq gtd-views '("G" . ">GTD process(p-process, o-organize, r-review, a-active, x-others)"))
(setq gtd-views-process '("Gp" "GTD process view." (my-custom-view "")))
(setq gtd-views-organize '("Go" "GTD organize view." (my-custom-view "")))
(setq gtd-views-review '("Gr" "GTD review view." (my-custom-view "")))
(setq gtd-views-action '("Ga" "GTD active view." (my-custom-view "")))
(setq gtd-views-others '("Gx" "GTD others." (my-custom-view "")))
(add-to-list 'org-agenda-custom-commands gtd-views t)
(add-to-list 'org-agenda-custom-commands gtd-views-process t)
(add-to-list 'org-agenda-custom-commands gtd-views-organize t)
(add-to-list 'org-agenda-custom-commands gtd-views-review t)
(add-to-list 'org-agenda-custom-commands gtd-views-active t)
(add-to-list 'org-agenda-custom-commands gtd-views-others t)
MLO配置思路
使用Flag做为状态，使用视图做为过滤条件，使用 TextTag 属性标记六个高度视野中的类型（清单/上层视野）。
其中，确定的原子属性不标记 TextTag, 可能将被分解或者包含子条目的做为清单（任务），上层视野对应六个高度项目以上层次。
自定义与流程相关的视图，在概览视图部分，包括：
- 收集箱
- 组织整理
- 回顾列表
- 活动列表
处理阶段
主要分辨条目。
符合如下流程：
- 输入——待处理条目：捕捉的 INBOX , 以及 不符合新规则的条目 。
- 输出——处理后条目：重点确认 状态 、 类别 、 优先级 ，可能会分配其它更多属性。
注意：
- INBOX，来自各类捕捉途径最终信息的汇集之处（参考：收集)，处理的时候尽量由新到旧进行处理保证公平不遗漏。
- 不符合规则的条目，是指如果更新GTD的规则，GTD系统中哪些没有应用新规则的，还在遵循旧规则的条目（便于将来扩展）。
- 状态，这方面注意的是，日程/提醒：是具有执行时间的原子类别；下一步及其它无执行时间的原子类别；参考:待归档。（具体参考：状态 ）。
- 类别，主要是原子（六个高度底层）/非原子(六个高度上层）；原子项无子项，非原子项有子项（参考：第1层：原子行动 元素之间的关联 )。
- 优先级，主要有高优先级、低优先级，前者近期关注后者推迟关注（参考：优先级与星标)，一般处理阶段大致估计一个优先级(默认C)，后续阶段仔细处理。
Orgmode配置
(setq gtd-views-process '("Gp" "GTD处理阶段：两分钟任务（执行），分配 *状态*、*类别*、*优先级*，其它。 "
(;;条件：INBOX内容
(todo "INBOX"
;;((org-agenda-sorting-strategy '(priority-down scheduled-up)))
)
;;条件：不符合规则内容(随GTD规则更新，有待添加）
;;Global options
(;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
))))
- 通过
todo "INBOX"...命令保证过滤出INBOX, 通过捕捉只向inbox.org追加，保证条目的次序由旧到新。 - 通过默认设置的
org-agenda-files, 保证若更新GTD规则，可以方便的添加新命令进行过滤。
MLO配置
目前待处理的收集条目均集中在默认的 工作蓝 中。
日后视情况可能会为不符规则的内容添加相关过滤视图。
组织整理
主要让体系合理。
应符合如下流程：
- 输入——处理后条目：主要是 无回顾条目 、 孤立条目 、 待调整条目
- 输出——组织整理后：重点确认 非日程的 回顾周期 、行动的 项目/范围 、*合理属性* （如 类别 、 优先级 、 情景/提醒) , 可能有其它属性。
注意：
- 无回顾条目，无时间属性的条目。所有条目都应有回顾机会，低优先级条目以定期回顾习惯模拟提醒，易添加，若每次整理时先添加回顾再添加范围，则只需关注孤立条目即可。
- 孤立条目，没有领域的就是孤立条目。所有条目要么是非原子的项目/任务，要么是原子行动，保证必属某一领域（参见：(45min/2) 第3层：职责、领域）。
- 待调整条目， 可能由于对活动列表的处理，或者一些其它处理的遗漏、模糊导致分类不明确、属性不合理、同步/更新不完整的现象，对这样的条目称作待调整条目。
- 回顾周期，尤其适于无回顾条目，日程/提醒（有时间属性、可能重复）无需回顾，无时间低优先级原子行动有回顾周期，项目/参考等非行动视情况添加回顾防止遗忘。
- 项目/范围，尤其适于孤立条目，任务分解和归并、理顺思路使条目间更具有条理性（类别进行调整)，一下不用太细可将回顾周期设置频繁些多次调整合适。
- 合理属性，尤其适于待调整条目，模糊、不合理条目如原子/非原子类别不对应应有的状态、无日期日程、有情景提醒、高优先级回顾等，更新后类别相应也应调整。
- 情景/提醒，提醒以时间为提示所以无需情景；日程一般也无需情景但若对时间不是特严格视情况可能有情景；无时间的原子行动才有情景；参考等非行动不用情景。
- 其它， 比如待调整到活动列表中的条目的高优先级，以及有待日后回顾的低优先级，可能顺便会确认每日计划的青蛙。
Orgmode配置
(setq gtd-views-organize '("Go" "GTD组织整理：确认行动的 *回顾周期*、*情景/提醒*、*项目/范围*、合理的 *优先级*，其它."
(;;条件：所有没有时间信息、具有状态的条目-将加入时间信息
(tags-todo "SCHEDULED=\"\"/!-INBOX"
((org-agenda-sorting-strategy
'(todo-state-up priority-down))))
;;条件：所有孤立文件中、具有状态的条目-将移至非孤立文件中
(tags-todo "FILE={[1-4]_.*Important_.*_Urgent.org}|FILE={0_inbox.org}/!-INBOX"
((org-agenda-files
(list
(concat org-directory "gtd/0_inbox.org")
(concat org-directory "gtd/1_Important_and_Urgent.org")
(concat org-directory "gtd/2_Important_but_not_Urgent.org")
(concat org-directory "gtd/3_Not_Important_but_Urgent.org")
(concat org-directory "gtd/4_Not_Important_and_not_Urgent.org")))
(org-agenda-sorting-strategy
'(todo-state-up priority-down))))
;;条件：所有具有非孤立、具有状态的、类型不合适的行动-将被调整成原子类型
(tags-todo "CATEGORY<>{Q[1-4]}/!+AGENDA|+NEXT|+LATER|+{WAIT.*}|+{MAYBE.*}|+REFERENCE|+CANCEL|+DONE"
((org-agenda-files
(list
(concat org-directory "gtd/_life.org")
(concat org-directory "gtd/_study.org")
(concat org-directory "gtd/_work.org")
(concat org-directory "gtd/_others.org")))
(org-agenda-sorting-strategy
'(todo-state-up priority-down))))
;;条件：所有具有非孤立、具有状态的、类型不合适的非原子条目-将被调整成非原子类型
(tags-todo "CATEGORY={Q[1-4]}/!+PROJECT|+TODO|+STOP|+FINISHED"
((org-agenda-sorting-strategy
'(todo-state-up priority-down))))
;;条件：所有不在2级以上的行动、项目等待办标题-将被移至合适的标题
(tags-todo "LEVEL<=2"
(;;(org-use-property-inheritance nil)
(org-agenda-files
(list
(concat org-directory "gtd/_life.org")
(concat org-directory "gtd/_study.org")
(concat org-directory "gtd/_work.org")
(concat org-directory "gtd/_others.org")))
(org-agenda-sorting-strategy
'(todo-state-up priority-down))))
;;Global options
(;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
))))
这里，
- 通过 'tags-todo "SCHEDULED=\"\"/!-INBOX"' 保证所有条目具备时间信息有机会被回顾到。
- 通过 'tags-todo "FILE={[1-4]_.*Important_.*_Urgent.org}|FILE={0_inbox.org}/!-INBOX"' 将条目从孤立文件转移，保证合理的领域文件归属，其中包含
inbox.org是为减少refile操作次数。 - 通过 'tags-todo "CATEGORY<>{Q[1-4]}/!+AGENDA|+NEXT|+LATER|+{WAIT.*}|+{MAYBE.*}|+REFERENCE|+CANCEL|+DONE"' 将所有具有非孤立、具有状态的、类型不合适的行动调整成原子类型
- 通过 'tags-todo "CATEGORY={Q[1-4]}/!+PROJECT|+TODO|+STOP|+FINISHED"' 将所有具有非孤立、具有状态的、类型不合适的非原子条目调整成非原子类型。
- 通过 'tags-todo "LEVEL<=2"' 过滤出所有不在2级以上的待办条目, 将这些遗漏的孤立任务(LEVEL<=2)也包含进来
几点注意：
- 项目范围、回顾、层级的调整可能会将其从子视图上刷新掉
- 优先级、情景的调整，不会影响过滤性。
- 为便于处理，尽量使下面子视图更新不会影响上面的。通常是下面视图处理时，上面的视图已经被处理，不会由于下面的处理导致上面的又增添项目。
- 非孤立文件是指
_life.org,_work.org,_study.org,others.org;孤立文件是指非孤立文件之外的；孤立条目是指孤立文件中的以及层级小于等于2的待办;非孤立条目是孤立条目以外的。
缺陷：有待思考是否有所疏忽，暂未详细考虑非原子项（高层视野的组织策略）。
MLO配置
集中在 组织整理 视图中，基本过滤出无回顾、孤立、待调整条目。
过滤条件为：
IsProject="假“
和 IsFolder="假"
和 ParentName 不是 ""
和 {
NextReview=”不存在“
和 StartDataTime="不存在”
和 截止=“不存在”
}
和 {
Flag 不等于 ”(无）“
或 TextTag 是 "清单“
}
和 {
或 {
Flag="非日程”
和 {
StartDateTime=“存在”
或 截止=“存在”
}
}
或 {
Flag="日程”
和 NextReview="存在"
}
}
和 Complete=“假”
以标旗（即状态）分组，按照紧急程度、重要程度排序。
这里，
- 前四个是基本条件，保证所有非项目、不在
- 为减少过多的条目，只过滤出其中具有
Flag值的（被处理过的），以及清单。
注意，这里额外说一下清单，其实这里的清单，更象是 Orgmode 中状态为 TODO 的任务。
- 清单与行动: 清单是任务分解的中间产物，确认为原子的行动都有
Flag标记状态； - 清单的产生: 若已标记了
Flag的行动后续发现还可能会继续分解，则将其转为清单，其内的清单项在收集箱处理时直接转移至这里(可能无状态也可能有状态）。 - 清单变项目: 当清单被确立了是项目级别之后，就将该清单转为项目、去掉清单的
Texttag以及Flag， 其内的清单项转化为全部分配了Flag的原子行动。
缺陷：清单概念模糊。
即两种情况：清单项如果无状态，则清单应有状态；没有状态的清单则其清单项会有状态。只要回顾 “清单”、或者具有 "Flag" 则所有清单、清单项皆能兼顾到了所有，并且保证处理阶段对清单项的处理简化（可能仅转移至清单）。
一般不会产生没有状态的清单，因为在处理阶段，一般都会分配状态，无状态的清单，一般是不允许的。
回顾阶段
主要防止遗忘。
回顾这个过程比较特殊，因为它包含了两个部分的内容：活动列表、和非活动列表的回顾。至于活动列表部分的内容，参考 执行阶段 (参见第2.5节) ，里不再重复。
符合如下流程：
- 输入——组织整理后条目：主要是组织整理之后的 日程表 、 待回顾列表 。
- 输出——回顾后：主要是调整优先级、安排日程和回顾、提醒与情景、含少量的组织整理工作。包含 活动前期 、 活动后期 、 回顾阶段 三个方面。
注意：
- 日程表，是指具有时间、提醒这些时间信息日程行动的集合，主要是当日及过期时间的条目。
- 待回顾列表，一般而言就是除去日程表之外在当日及过期回顾的列表，借助定期浏览的习惯以备遗忘那些没确定时间属性的条目（一般关注低优先级，高优先级处理时顺带回顾了）。
- 活动列表，是指当日日程、提醒、高优先级行动(无回顾和今日以前的）、备忘，其中包括日计划的青蛙事项(即活动列表中今日打算必须做的事情），是本日执行行动的参照。
- 活动前期，主要安排活动列表，如每日计划，调高今日待办优先级、并导致活动列表更新（一次性活动条目其回顾属性可被去掉，因为自然执行时回顾了）。
- 活动后期，是指一天活动之后将活动列表中的条目按照实际完成的情况更新同步相关属性为最新。
- 回顾阶段，主要是至活动前期、活动后期、以及日间空闲之时整理已有的内容补充、优化处理/组织整理/行动期间 遗漏的事项确保体系不断完善。
Orgmode配置（待回顾条目）
(setq gtd-views-review '("Gr" "GTD回顾：确认日计划、更新活动列表、以及非活动列表（低优先级）"
(;;条件：所有非日程，今天及之前的待回顾行动
(agenda ""
((org-agenda-span 1)
(org-agenda-skip-function
'(org-agenda-skip-entry-if 'nottodo
'("NEXT" "WAIT/FORWARD" "LATER" "MAYBE/FUTURE" "CANCEL")))
(org-agenda-sorting-strategy
'(habit-down time-up todo-state-up priority-down))))
;;条件：所有今天及之前的待回顾非原子条目
(agenda ""
((org-agenda-span 1)
(org-agenda-skip-function
'(org-agenda-skip-entry-if 'nottodo
'("PROJECT" "TODO" "STOP")))
(org-agenda-sorting-strategy
'(habit-down time-up todo-state-up priority-down))))
;;条件：待回顾的归档条目（一般是完成的，归档以便提升orgmode的运行效率）
(agenda ""
((org-agenda-files
(list
(concat org-directory "gtd/_life.org")
(concat org-directory "gtd/_study.org")
(concat org-directory "gtd/_work.org")
(concat org-directory "gtd/_others.org")))
(org-agenda-skip-function
'(org-agenda-skip-entry-if 'nottodo
'("REFERENCE" "DONE" "FINISHED")))))
;;Global options
(;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
))))
- 第一个
agenda ""...命令过滤出Agenda外的原子行动，（这里并未过滤掉高优先级回顾，因为组织整理阶段自动会将其处理，这里出现的话也会弥补组织整理的遗漏)。 - 第二个
agenda ""...命令过滤出非原子条目，并以高优先级在前排列（因为非原子是不具体的处理，不会出现在活动列表中所以高低优先级一并回顾） - 第三个
agenda ""...命令过滤出非行动内容，可能会定期了解、参考、甚至之后的归档确认。 - 最后，活动前期的日计划、活动后期的活动更新，结合后面的活动列表一并回顾。
注：回顾阶段跨越了：回顾（回顾非活动列表）、执行（活动列表）两个阶段的过滤视图。活动列表其实是总回顾输入的子集(当日高优先级行动+日程)。
MLO配置
集中在 回顾 视图中，基本过滤出待回顾的非日程条目。
NextReview="不晚于Today"
和 StartDateTime="不存在“
和 截止=”不存在“
和 Starred="假“
和 {
{
Urgency<="150"
}
或{
Urgency>"150"
和 Flag="稍后"
和 Flag="将来也许"
和 Flag="取消"
}
}
和 Complete="假”
根据文件夹分组，按照下次回顾日期排序，会显示分级信息,包含所有匹配项目的子级
这里，
- 前面三个保证非日程、回顾周期在今天及以前的行动能被回顾到
- 后面的条件保证回顾视图中不列出高优先级的、除了
稍后,将来也许,取消状态的行动（在活动列表中集中展示这样倾向被执行的条目）
缺点：没有仔细考虑原子层次以上的回顾。
执行阶段
主要实现任务。
对于执行阶段，其中的2分钟任务在处理阶段进行了，具体参考 处理阶段 (参见第2.2节) 。
符合如下流程：
- 输入——组织整理、回顾之后的活动列表，INBOX处理阶段的 2分钟任务
- 输出——尽量执行完青蛙行动，相应的行动尽可能完成，没有完成的重新分配时间至将来，或不愿处理的降至低优先级并添加日后回顾属性。
注意：
- 2分钟任务 一般是临时发生的紧急处理的、或者处理阶段顺便处理掉的小事件，如果堆积于GTD体系中，管理其消耗的时间精力反而大于本身能够完成所需时间。
Orgmode配置
(setq gtd-views-action '("Ga" "GTD活动列表：待安排任务（回顾前期）、待执行任务(执行)、待更新任务（回顾后期）"
(;;条件：所有两日内日程
(agenda ""
((org-agenda-span 2)
(org-agenda-skip-function
'(org-agenda-skip-entry-if 'nottodo
'("AGENDA")))
;;(org-agenda-sorting-strategy '(priority-down))
(org-agenda-log-mode-items '(closed clock state))
))
;;条件：所有今日及以前的高优先级非日程行动、无回顾周期的高优先级非日程行动
(tags-todo "CATEGORY={Q[1-4]}&PRIORITY<\"C\"-SCHEDULED>\"\"/!+NEXT|+{WAIT.*}|+REFERENCE"
((org-agenda-sorting-strategy
'(todo-state-up priority-down))))
;;Global options
(;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
;;(org-agenda-regexp-filter-preset '("-PROJECT" "-TODO"))
))))
- 通过
agenda "" ...过滤出所有的AGENDA日程。 - 通过
tags-todo "CATEGORY={Q[1-4]}&PRIORITY<\"C\"-SCHEDULED...过滤出所有非日程高优先级行动(去掉SCHEDULED是今天以后的)。
注意：执行阶段跨越了处理（2分钟原则）、执行（活动列表） 两个阶段的视图。
MLO配置
集中在 活动列表 视图中，基本过滤出待办原子条目。
过滤条件为：
IsProject="假“
和{
Starred="真”
或 NextAlertTime="早于Now+0.05"
或 {
Flag="日程“
和 {
StartDateTime="早于Today+1"
或 截止=”早于Today+1“
}
}
或 {
Flag="下一步"
和 Ugency>="150"
和 {
NextReview<"Today+1"
或 NextReview="不存在"
}
}
或 {
Flag="等待委派"
和 Ugency>="150"
和 {
NextReview<"Today+1"
或 NextReview="不存在"
}
}
或 {
Flag="参考"
和 Importance>="150"
和 {
NextReview<"Today+1"
或 NextReview="不存在"
}
}
}
和 Complete=”假“
排序依次根据标星、开始日期、紧急程度、重要程度，不分级
这里，过滤的内容分为三组：
- 所有的今日及以前的待办日程，直接过滤出来
- 所有星标高优先级（一般用于临时高优先级及青蛙）、临近提醒
- 所有今日、今日以前、不存在回顾周期的高优先级待办行动（状态为
下一步,等待委派,参考）
注：
高优先级行动如果没有回顾属性则一定都显示(保证可以一直关注的高优先级)，如果有回顾属性则只显示今天以前的（谨慎设置高优先级的回顾属性因为可能导致没有及时回顾到）。
其它
进一步的完善，参见：GTD实践相关
Orgmode操作技巧
如何不用更改状态和优先级标记今日处理过的高优先级
如果优先级今日处理之后，日后还要处理，这样优先级和状态就不需要更改，可是在活动列表视图上，如何将其标记从活动列表中去掉呢？
这里的技巧是：
- 在orgmode的对应Agenda视图中，为高优先级加入Schedule，而Schedule的日期是今日以后（不包括今日），同时也计划了将来何时再次处理这个高优先级。
- 在显示活动列表时，去掉具有今日以后schedule的高优先级待办。
- 回顾的时候，对于高优先级的待办，如果想要处理的时候，自然会处理
这样，到了指定日因为其Schedule不再是今日以后，所以自动会显示；而处理之后因为变成了将来，会消失，也减少了对今日任务的干扰。
这种非法的高优先级条目有Schedule内容，也会在活动后回顾处理的时候，将其处理成合法的：因为明天还要处理，所以优先级保留，Schedule会被处理掉。
日计划的时候，也会有这样的一种情况：今天回顾的条目，安排为高优先级，但是却忘记了去掉其SCHEDULED，导致活动列表不显示了，但是这样的事情，是自己的失误，无关软件，自己的失误应当承担一定的风险，反正倒了明天也会再次出现的。
周期回顾不用设置成重复的任务，只需要每次都修改SCHEDULE为下次即可
周期性的回顾，不用设置成重复的任务，只需每次回顾后，设置好下次回顾的时间就行，这样也免得设置状态了
（实在不行可以在标题上标记期望的回顾间隔，防止思考过于片面?其实在 LOGBOOK 中已经有了相关的回顾日志，可以了解细节）
在更改SCHEDULE的时候，可加入LOG信息，修改SCHEDULE的时候，增加日志信息的配置：
(setq org-log-reschedule 'time)