Open japhir opened 3 years ago
Heya, thanks for the interest!
great, thanks for the reply!
- I create three files right now: the inbox, an "actions" file, and an "incubate" file. org-mode's archiving feature generates the corresponding archive files
ah ok. I guess that means I could just set those variables to link to my existing files in that case, right? I have an inbox.org file and a todo.org file (for personal stuff) and a work.org file right now.
- TODO, NEXT, WAIT, DONE, and CANCELED are being used
what are they used for? specifically, what does the "TODO" state mean? is it a deferred action until some specified time? I've been using TICK for that (from the tickler file) but I've found that I don't use it that often. Also, I use CANC in stead of CANCELED so that they're all 4 characters long and they line up nicely ;-).
- no tags - up to the user. Properties -- only a custom one, "DELEGATED_TO"
Ah ok, I've ~stolen~ used that idea now already, seems nice!
How do you define projects? I've now started defining them as: any headline with the :prj:
tag. I then define "stuck projects" as anything with the non-inherited prj tag and without the DONE/CANC/SOME todo state. This is nice because you can also easily set up an orgzly search query to list all your projects (.it.done tn.prj
).
- Hmm, I've forgotten what trigger lists are -- it's a tool I haven't yet had to reach for. What are they?
Trigger lists are simple lists that help trigger open loops in your brain: during the weekly review you go through them at some point and they help you think of all the things you need to do. Often they consist of your horizon 2: areas of responsibility (with 0 being NEXT actions, 1 being projects etc.).
I've been listening to the book again lately and am trying out some new stuff to help me create habits for the weekly review etc., so that I can get my GTD game up to a good level again :).
I just saw your talk, I'd include it in the README :)
There are quite a few decisions that you made that I would not like in my GTD workflow. For example:
I love that you facilitate processing the inbox one-by-one, but the hotkeys for processing it seem not so intuitive yet (rename whenever->next? where can I find the Someday/Maybe action? what does "later" do?)
It's really useful to listen to these podcast episodes to help understand how complex building a good GTD app is:
I hope you find this helpful :)
Heya!
Thanks for the recommendation, I'll add the talk to the README, while I ponder making something easier to digest (it's still ~12 minutes).
it seems like you've set up org-edna to make projects always linear. Sometimes you can do multiple things in any order, right?
Sure, you can do things in any order sometimes. What's the value-add ? To note, as you say you do not like it, then equally someone else told me they do. The only valid argument I have heard to date against linear projects is projects that block each other... The great argument for linear projects is how simple the implementation currently is.
Tell me more about what you don't like in linear projects; I have found that the rigor of linearity forces me to clarify things early, which means I can then focus solely on execution.
how do you get a quick overview of all the projects that are currently active?
Open the actionable.org
file in the GTD directory and look at the projects there; completed projects can be archived with org-gtd-archive-completed-projects
.
I love that you facilitate processing the inbox one-by-one, but the hotkeys for processing it seem not so intuitive yet (rename whenever->next? where can I find the Someday/Maybe action? what does "later" do?)
I've tried to find words with distinct first letters for the collection of choices provided by GTD when processing an item, and this is the best I could come up with at the time; if you can think of any other collection of words for the choices which allows people to choose the first letter of the word unambiguously, I'm ready to change the list.
Hi again,
Tell me more about what you don't like in linear projects; I have found that the rigor of linearity forces me to clarify things early, which means I can then focus solely on execution.
hmm perhaps I haven't thought about this enough, let's see if my todo file has an example to help illustrate it and make things more concrete. If we can rework this into a linear sequence and the result is clearer, perhaps this constraint may be beneficial as you say:
** create rolling window estimates of temperature data with age :prj:
*** NEXT create synth dataset with non-equal age gaps :@programming:
*** NEXT read Martin rolling window code and take notes :@read:
*** NEXT write a rolling window function that includes 95% ci uncertainty :@programming:
mess around with rolling window for d18O
try to get 95% confidence interval from the zoo::rollapply function
From the above, I think it's valuable to keep track of the desired outcome (project name) as a single project, but I can take next actions on all three steps simultaneously: creating a synthetic dataset is useful for writing a minimal reproducible example and ultimately for writing tests, but reading up on the approach/theory from other sources is independent and can be started right away, and the synthetic dataset is not required to make the function; I can also work on my real dataset. What do you think, would splitting this up in some way be more useful?
if you can think of any other collection of words for the choices which allows people to choose the first letter of the word unambiguously, I'm ready to change the list.
maybe something like:
but this was just what I came up with after typing it out, it's quite hard to keep it consistent: are we using short-hands for the verbs or for the place where it ends up?
@japhir With your permission, Github just introduced a "Discussions" feature and I'd like to move this thread over to that feature. Let me know if you're OK with it.
creating a synthetic dataset is useful for writing a minimal reproducible example and ultimately for writing tests, but reading up on the approach/theory from other sources is independent and can be started right away, and the synthetic dataset is not required to make the function; I can also work on my real dataset. What do you think, would splitting this up in some way be more useful?
In the current system, I would consider each of these to be separate actions, because they don't depend on one another. I would probably want to tie them in together with some kind of tag or property, but I wouldn't make them an org-gtd project.
If they must be in a project, then if they can be done in any order, then just pick the order you prefer.
If they must be in a project, and you can start all three of them at the same time without jumping from one task to the next (e.g. a process takes a day to finish, you can read the book), then there may be a missing feature, where a project item gets moved to WAIT and the following TODO item could become NEXT -- but this is already reaching a level of complexity at which I need to seriously rework the internals of this project.
Re: the list of things, you see that you also had to make some odd choices with your letters. You asked a good question; do we use short-hands for verbs or where it goes? And the answer is ... What can we make work? I would prefer the action, since as a user I think that's what's most meaningful to me, but I'm open to other reasonings here too :)
yeah sure, feel free to move it to "discussion"! I'm a little lost on the detailed description, but I'll get back to you soon(ish) :).
Hey I was just processing a massive inbox file again and wanted to streamline the process. Then ended up looking at how you did it here and decided to write it up shortly and start a discussion in #33
Hi! Great repo, this looks very interesting to me!
I couldn't work out from the README how everything fits together in this package, what the philosophy is. I also tried browsing the source code but that got me even more confused.
I'm hoping to understand these issues better before I want to load the package and possibly migrate my current set-up (see my emacs config).
These comments are intended to be helpful, even if they may come off a bit whiney! I'm potentially interested in using the package and likely contributing many bug reports/feature requests if I do.