2 #+author: Richard Westhaver
3 #+email: ellis@rwest.io
4 #+description: High-level description of CC workflows
5 #+setupfile: ../clean.theme
8 :ID: ad4a24f8-7de4-479b-bc5a-7065e4b43087 12 :ID: 51b210fd-0ba1-41c1-a4ec-85c3d9295c02 16 :ID: 249ae0a5-0ef8-4d8a-be61-f408fb2b2cff 20 :ID: b7f9c275-90fd-407f-aa39-615fa6ab64d6 22 When an item has no task-related state associated with it, it is
23 considered a
/non-task/ or
/simple item/.
25 Simple items imply that there's no action directly associated with
26 this item, but it may contain child items which are tasks with action.
29 :ID: a7c60105-171a-4960-b2fc-3a8611ce210b 34 :ID: daf2c376-1969-48f9-bdbd-1a5f066e8109 38 :ID: 81da5e76-2619-42c3-8a2a-dea2b815b261 40 There is a dedicated
=CODE= keyword available for headings
41 dedicated to a specific piece of code.
43 All CC code is kept under version control and intended to be linked
44 directly using the
=vc= link type. Code can be linked anywhere -
45 including org documents, other code, or online. In org documents,
=vc= 46 links are often used as the value of the
=LOCATION= property.
49 :ID: 66333c80-aa6f-43d7-a305-44e218dde045 51 Tasks are most often found as headings with some additional metadata
52 such as scheduling info, priority, clock info, and special properties.
54 Tasks are always
*stateful* and exist somewhere in one of the
55 following abstract
/todo states/:
57 - TODO :: Incomplete task
58 - WIP :: Work In Progress task
59 - DONE :: Completed task
61 Tasks are easily identified by a
[[id:2cadda9a-22a3-4b42-ad4e-d7a774f74cba][keyword]] which represents the current
62 state. Tasks always follow a sequence with at least one 'TODO' state
63 and one 'DONE' state. There is always an implied 'WIP' state in the
64 sequence which come after the TODO keywords and before the DONE
69 :ID: 560f4094-e077-4389-9e09-dba1e0d4004e 71 Projects are denoted by the special keyword
=PROJECT= and act as
72 containers of related work to be done. They may contain the same
73 metadata as tasks, and may be 'downgraded' to or 'upgrade' from tasks.
75 Projects often contain additional metadata, such as
=CATEGORY= and
79 :ID: 1b426ef7-b88b-4b66-8413-df37d8312dcd 80 :LOCATION: [[vc:comp/core/-/blob/branch/default/emacs/lib/inbox.el][inbox.el]] 82 The inbox is a flat list of
[[id:249ae0a5-0ef8-4d8a-be61-f408fb2b2cff][items]] usually found in the
83 =org-inbox-file= (default is ~
/org/inbox.org). Items are [[https://orgmode.org/manual/Capture.html][captured]] by 84 various means and then [[https://orgmode.org/manual/Refile-and-Copy.html][refiled]] to another location.
86 As of [2024-08-24 Sat] we capture items manually and in a local-only
87 fashion. In the future this may change to support automatic capturing
88 via org-protocol and email as well as peer-aware/group inboxing.
91 :ID: 44e6ff33-ad62-4ef0-a188-506f837648d8 92 :LOCATION: [[vc:comp/core/-/blob/branch/default/emacs/lib/scrum.el][scrum.el]] 94 We apply a
[[https://www.scrum.org/resources/what-scrum-module][scrum]]-like framework to plan our projects and tasks.
96 We borrow the same terminology where possible but do not align with
97 any specific implementation. Here are some noteworthy implementation
99 - We utilize the
=EFFORT= property with time values as the basis of
100 estimation such as
=1d=,
=24:00= or
=24h= as opposed to
[[https://www.scrum.org/forum/scrum-forum/33290/age-old-question-story-points-vs-hours][story 101 points]]. We measure progress in time too, but we don't
/represent it/ 102 as such. We effectively represent it as some form of 'story point'
103 like a percentage. This is because the estimates don't reflect
104 realtime and shouldn't be intertwined with measures of performance.
105 - Realtime values can be found in the scheduling and clock metadata as
106 well as some timestamps like the
=CREATED= property.
107 - Performance-related metrics may be derived from the clock
108 metadata, but I have always found it tedious to
[[https://orgmode.org/manual/Clocking-Work-Time.html][clock work time]] in
109 Org mode. As of [2024-08-24 Sat] this is still unresolved, but we
110 have some ideas to improve the workflow and implement some
112 - Products and Projects are separate entities. As a rule, any task
113 belonging to a product is unable to block a project.
116 :ID: be90c808-6c3b-4381-a032-af07d54f5907 118 The
[[https://compiler.company/plan/roadmap.html][roadmap]] is a high-level document which describes the strategic
119 plan associated with pre-determined period of time called program
120 increments or PIs. The current length of a PI is 1 year.
123 :ID: b94e643b-479c-400b-9679-0eb843a782fa 125 For every major project in our portfolio there is a dedicated list of
126 tasks. This list can contain any type of heading at any level but will
127 usually consist of top-level project items containing sets of
128 tasks to be completed.
131 :ID: 5576df8c-7cc3-4d7b-a5df-9201c278a08a 133 Products are an implementation of the value our projects provide. They
134 represent a tangible end-goal, an anchor point for connecting with
135 potential users and supporters, and collecting feedback.
138 :ID: 6ebed997-12c0-4a20-88ef-df8cf424b198 140 Notes should be collected frequently and referenced often. They can be
141 as simple as a link to a Wikipedia page, or contain a complex tree of
142 inter-connected nodes.
146 :ID: 33ac913a-1697-49d6-8d80-542b5a1f83ec 148 How you store your own notes is a very personal decision, and so I
149 think it's important to leave a space for users to store their own
150 notes and make their own decisions on how to use them.
152 As of [2024-08-24 Sat] there is no API for this at all - in the future
153 we will likely provide an API and default implementation specifically
157 :ID: 92d71908-dba3-41b7-a126-0c6415b54579 159 Graphs are a set of inter-connected nodes inspired by Roam and
160 Zettelkasten (see
[[https://github.com/org-roam/org-roam][org-roam]]).
162 As of [2024-08-24 Sat] this has not been implemented, but we intend to
163 implement a fully connected knowledge graph. See
[[vc:comp/core/-/blob/branch/default/emacs/lib/graph.el][graph.el]].
166 :ID: 03e13d7e-6cda-46d4-830f-5671518bd32f 170 :ID: 111db7b0-61e0-4be3-8ec7-1a68913997ff 172 For every project under version control there is a
=readme.org= file
173 in the root directory. This file contains some dynamic blocks of basic
174 information followed by additional content introducing the project.
177 :ID: 26532798-89ca-4d15-aabe-e57122dea07d 179 API References are generated for some of our projects based on the
180 source code. In general these documents are generated automatically
181 and highly structured.
184 :ID: 4a299f6e-b176-43bd-88fc-3cbdde1cc2d6 186 User Manuals serve as the subject of the phrase 'RTFM'. These are
187 always written manually and revised regularly to stay accurate.
190 :ID: 307ba3e8-ef19-48da-a3c9-f5a46d6819e9 194 :ID: ca0dcc07-0517-4d04-86f0-905537cb7801 196 When an item is archived, it is moved to a file under version-control
197 in the
[[vc:comp/archive][archive]] project.