task

creates a plain-text task file in the current directory
git clone git://brookjeynes.dev/bjeynes/task.git
Log | Files | Refs | README | LICENSE

manifesto.txt (6487B)


      1 Manifesto
      2 =========
      3 
      4 Plain text is software and operating system agnostic. It's searchable,
      5 portable, lightweight, and easily manipulated. It's unstructured. It works when
      6 someone else's web server is down or your Outlook.PST file is corrupt. There's
      7 no exporting and importing, no databases or tags or flags or stars or
      8 prioritizing or _insert company name here_-induced rules on what you can and
      9 can't do with it.
     10 
     11 There are three key axes to an effective todo list
     12 
     13 1. Priority
     14 	Your todo list should be able to tell you what's the next most important
     15 	thing for you to get done - either by project or by context or overall. You
     16 	can optionally assign tasks a priority that'll bubble them up to the top of
     17 	the list.
     18 
     19 2. Project
     20 	The only way to move a big project forward is to tackle a small subtask
     21 	associated with it. Your system should be able to list out all the tasks
     22 	specific to a project.
     23 
     24 	In order to move along a project like "Cleaning out the garage", my task
     25 	list should give me the next logical action to take in order to move that
     26 	project along. "Clean out the garage" isn't a good todo item; but "Call
     27 	Goodwill to schedule pickup" in the "Clean out garage" project is.
     28 
     29 3. Context
     30 	Getting Things Done[1] author David Allen suggests splitting up your task
     31 	lists by context - ie, the place and situation where you'll work on the
     32 	job. Messages that you need to send go in the '@email' context; calls to be
     33 	made '@phone', household projects '@home'. That way, when you've got a few
     34 	minutes in the car with your cell phone, you can easily check your '@phone'
     35 	tasks and make a call or two while you have the opportunity.
     36 
     37 [1] URL:https://en.wikipedia.org/wiki/Getting_Things_Done
     38 
     39 
     40 Formatting
     41 ----------
     42 
     43 Each task is a plain text file. To take advantage of structured task metadata
     44 like priority, projects, context, there are a few simple but flexible file
     45 format rules.
     46 
     47 Philosophically, this format has two goals:
     48 - The file contents should be human-readable without requiring any tools other
     49   than a plain text viewer or editor.
     50 - A user can manipulate the file contents in a plain text editor in sensible,
     51   expected ways. For example, a text editor that can sort lines alphabetically
     52   should be able to sort your task list in a meaningful way.
     53 
     54 
     55 Incomplete Tasks: 4 Format Rules
     56 --------------------------------
     57 
     58 The beauty of this format is that it's completely unstructured; the fields you
     59 can attach to each task are only limited by your imagination. To get started,
     60 use special notation to indicate task context (e.g. '@phone' ), project (e.g.
     61 '+GarageSale' ) and an optional priority (e.g. '(A)' ).
     62 
     63 A task file might look like the following:
     64 
     65 $ tree tasks                                  
     66 tasks
     67 ├── checkout-race-condition.txt
     68 └── done
     69     └── checkout-ui-design.txt
     70 
     71 $ cat 0001-checkout-race-condition.txt
     72 (A) checkout race condition @bug +checkout
     73 
     74 Add a reservation hold on the orders table
     75 
     76 # Query all not-done items tagged with '+checkout'
     77 $ grep --exclude-dir=done -r '+checkout' tasks
     78 tasks/checkout-race-condition.txt:(A) Checkout race condition @bug +checkout
     79 
     80 # Query all not-done items tagged as '@bug' with a priority of '(A)'
     81 $ grep --exclude-dir=done -r '(A).*@bug' tasks    
     82 tasks/checkout-race-condition.txt:(A) Checkout race condition @bug +checkout
     83 
     84 # Query all items tagged as '@bug' or '@ui'
     85 $ grep -r '@ui\|@bug' tasks 
     86 tasks/checkout-race-condition.txt:(A) Checkout race condition @bug +checkout
     87 tasks/done/checkout-ui-design.txt:update ui to match new styleguide @ui +checkout
     88 
     89 # Query for a task with the id "mxkpzqvnwolsrktu"
     90 $ grep -r '^id: mxkpzqvnwolsrktu' tasks
     91 tasks/add_release_types.txt:id: mxkpzqvnwolsrktu
     92 
     93 # Usually the first 2-4 characters are sufficient.
     94 # Query for a task with an id starting with "mx"
     95 $ grep -r '^id: mx' tasks
     96 tasks/add_release_types.txt:id: mxkpzqvnwolsrktu
     97 
     98 
     99 There are four formatting rules for current todo's.
    100 
    101 Rule 1: If priority exists, it ALWAYS appears first.
    102 	The priority is an uppercase character from A-Z enclosed in parentheses and
    103 	followed by a space.
    104 
    105 	This task has a priority: 
    106 		(A) Call Mom
    107 
    108 	These tasks do not have any priorities:
    109 		Really gotta call Mom (A) @phone @someday
    110 		(b) Get back to the boss
    111 		(B)->Submit TPS report
    112 
    113 
    114 Rule 2: Project and context may appear AFTER the title.
    115 	This task has a context and/or project: 
    116 		(A) Checkout race condition @bug +checkout
    117 		(B) UI rework +checkout
    118 
    119 	These tasks do not have contexts/tasks: 
    120 		(A) @bug Checkout race condition
    121 		+checkout UI rework
    122 
    123 
    124 Rule 3: Additional context may appear after the metadata block.
    125 	A task does not have to have additional context. If it does, it should be
    126 	separated form the task title and metadata by a blank line.
    127 
    128 	This task has additional context
    129 		(A) checkout race condition @bug +checkout
    130 
    131 		Add a reservation hold on the orders table
    132 
    133 Rule 4: If an ID exists, it appears on the 2nd line of the file.
    134 	The ID is written as 'id:' followed by a space and a 16-character lowercase
    135 	identifier made up of the letters k-z. This represents 8 bytes encoded in
    136 	reverse-hex notation.
    137 
    138 	The ID is intended to be stable for the life of the task. Editing the task
    139 	title, priority, project, context, or filename should not change the ID.
    140 	When a task is completed and moved into the `tasks/done` folder, its ID
    141 	should be preserved.
    142 
    143 	Tools that create new tasks should generate a random 8-byte ID, encode it
    144 	using the letters k-z, and check existing task files for a collision before
    145 	writing the new task.
    146 
    147 	This task has an ID:
    148 		(A) checkout race condition @bug +checkout
    149 		id: mxkpzqvnwolsrktu
    150 
    151 	This task does not have an ID:
    152 		(A) checkout race condition @bug +checkout
    153 
    154 	These tasks do not have valid IDs:
    155 		(A) checkout race condition @bug +checkout
    156 		ID: mxkpzqvnwolsrktu
    157 
    158 		(A) checkout race condition @bug +checkout
    159 		id: mxkpzqvnwol
    160 
    161 		(A) checkout race condition @bug +checkout
    162 		id: abcdef1234567890
    163 
    164 
    165 Complete Tasks
    166 ---------------
    167 
    168 Once a task has been completed, it is moved into the tasks/done folder. Tasks
    169 that have not been finished sit flat-file in the tasks/ folder. There is no
    170 concept of "in-progress", a task is either done or not-done.
    171 
    172 
    173 Attribution
    174 -----------
    175 
    176 This document is adapted from todo.txt: https://github.com/todotxt/todo.txt
    177 
    178 The original todo.txt format documentation is licensed under the GNU General
    179 Public License v3.0. This modified version is distributed under the same
    180 license: https://www.gnu.org/licenses/gpl-3.0.html