From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2NM5AXfVw19FNQAA0tVLHw (envelope-from ) for ; Sun, 29 Nov 2020 17:08:07 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id aL65OHbVw18yRgAAbx9fmQ (envelope-from ) for ; Sun, 29 Nov 2020 17:08:06 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E9742940667 for ; Sun, 29 Nov 2020 17:08:05 +0000 (UTC) Received: from localhost ([::1]:40378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjQBA-0004sd-Us for larch@yhetil.org; Sun, 29 Nov 2020 12:08:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjQAJ-0004r1-Tf for emacs-orgmode@gnu.org; Sun, 29 Nov 2020 12:07:13 -0500 Received: from static.rcdrun.com ([95.85.24.50]:36275) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjQAG-0004Bt-Fr for emacs-orgmode@gnu.org; Sun, 29 Nov 2020 12:07:11 -0500 Received: from localhost ([::ffff:197.157.0.29]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C000B.000000005FC3D539.00001A19; Sun, 29 Nov 2020 17:07:04 +0000 Date: Sun, 29 Nov 2020 20:05:08 +0300 From: Jean Louis To: Ihor Radchenko Subject: Re: Adding Org Files to org-agenda-files Message-ID: References: <87r1od181i.fsf@gmail.com> <87h7p9135u.fsf@gmail.com> <87sg8tymeb.fsf@gmail.com> <87k0u4zupw.fsf@gmail.com> <87ft4s5oug.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87ft4s5oug.fsf@localhost> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: 29 X-Spam_score: 2.9 X-Spam_bar: ++ X-Spam_report: (2.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: daniela-spit@gmx.it, Tim Cross , emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.78 X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-TUID: /aq5ov2eV49L * Ihor Radchenko [2020-11-29 15:25]: > Jean Louis writes: > > > Currently I am researching "NEXT" and how people are thinking and > > trying to see if I miss some concepts. My approach seem to be > > simpler. There is project and there are tasks in their most logical > > chronological or executable order just as a program. One has to do > > first one, then next. Which one is next is clear from the order of > > tasks. Marking it "NEXT" to me seem redundant as it would mean I have > > not made good order. > > NEXT is relevant to complex projects where multiple tasks can be active > at the same time. Or when some urgent tasks are added to the project as > it goes. Then, instead of constant reshuffling of the task order and > re-evaluating the order of tasks, one can simply mark the new urgent > tasks NEXT and later use sparse trees to only look at the tasks that > should be done at the current stage of the project. The key point is > minimising exposure to irrelevant information - the number of tasks in > large project can be demoralising, especially if one gets reminded about > it frequently. > > You might also check > https://old.reddit.com/r/orgmode/comments/i4hx1z/gtd_problem_with_todo_workflowconstantly/g0ihg2d/ ,---- | So anything that is actionable is NEXT and anything that is depends on | something else should be a TODO? That seems like most tasks are NEXT | as opposed to TODO--intuitively, I would think most tasks should be | TODO and moved to NEXT when they are to be worked on now. Or do you | pluck from a large list of NEXT items and schedule them when you want | to work on them? | | The concept of NEXT tasks is most relevant to big projects. If, say, | you have a project with 10 big tasks you need to do in order to | complete the project, it is not very good idea to work on them at the | same time. Instead, you only mark 1-2 tasks as NEXT to finish them | first. Once you mark them DONE, the project will become stuck (no NEXT | tasks), which will be seen during GTD review process. So, you will | mark another 1-2 tasks as NEXT and continue working. `---- >From there I can understand that. We are doing that for projects but we never assign NEXT. Because TODO group of tags and DONE group of tags designate basically something TO DO and something that is DONE and completed, then NEXT in itself is basically TODO-NEXT. But some people are designated several tasks as NEXT so that is contradictory to logic as only one should be next according to me. We write tasks in their most logical chronological order and every staff member is instructed to follow the order. One simply cannot drive a car without putting petrol first, so that system is followed. Some tasks on the ground can be done without chronological order and our staff members are left to decide on that. When they arrive to town and need to buy timber, maybe carpenter is discovered right there while the task says that once they arrive to village that they should look for carpenter. What is NEXT is mostly practically decided while doing things at my side. > > If the type of heading is "task" then I do not need to use "TODO" as > > it implies it is task. But Org headings do not have fixed types so it > > is visually and practically better to use TODO. Here would the > > inheritance be useful more than to tags. As if user marks one heading > > as TODO, then all subtrees could automatically get its TODO. > > That can be done. Should be trivial using org-edna > (http://www.nongnu.org/org-edna-el/), for example. Or you can use > org-trigger-hook and mark all the children with TODO keyword if the > parent heading is marked TODO. Interesting complication (Edna) that is supposed to be useful. Before constructing the series of those tasks user would need to construct series of tasks to construct series of tasks. Concept is great: This task can be completed only when tasks 1, 4 and 7 are completed. But practical life is different. When conducting projects staff members may discover on ground that dependable task can be completed without 1, 4 and 7 being completed as one could not predict future randomity. It may be also discovered that those 1, 4 and 7 are not true dependencies but some other tasks. This would imply that planner must know very well future incidents which is rarely the case as it would be so easy to predict future one would not be writing tasks. It is useful in trees and it should be an org built-in to mark all children nodes with the tag. It becomes very trivial when using database with nodes having a parent: ,---- | UPDATE hlinks SET hlinks_tags = 'TODO' WHERE hlinks_parent = THIS ONE; `---- But rather a function would be used or type assigned. The above is only example that shows how complex hard coded Elisp functions can be replaced with 3-4 lines single function when database is a backend. No wonder this guy has put Org mode in a sandwich on the logo of SMOS. It eats the Org. SMOS - A Comprehensive Self-Management System https://smos.cs-syd.eu/features > > The DELEGATED type, I have seen people using this and myself also. But > > if something is fully delegated and not any more mine, then I would > > not have it in my file. So it is something usually that I have to > > think of. Many of the tasks I think of are already assigned, I could > > call it delegated. And I keep property :ASSIGNED: under the Org > > heading. When I wish to send this task, I press one key and it is > > automatically sent to the person assigned. But I am one supervising it. > > I guess the key reason to have DELEGATED is just to be reminded to > followup on the progress. Yes. And users may assign in their minds any kinds of meaning. They are not clear. Example is with NEXT, I would not use it as it becomes clear from good plan what is next. It is DESCRIBED in our tasks what is next by several words or sentences. Just like when purchasing metal roof must come first before sleeping in a cabin. They are though free to decide if they wish to sleep first in the cabin and purchase the roof tomorrow, but I am not going to pay a lodge if it is raining. > I would do it in an opposite manner - mark the task DELEGATED, which > triggers {C-c C-x p} and prompts me for the ASSIGNED value. The > advantage of my method is simply that it is easier to see later - > DELEGATED keyword is visible on the headline, which the PROPERTY drawer > is folded by default. Of course, it would not matter if you configure > org to not fold the PROPERTY drawers. For me personally it does not matter as I am easily transitioning to meta level assignments. Assignments or delegations I use very often, always. Every day. I like to press key `a', choose person, write assignment task and close it. Finished there. Computer sends the task, SMS, and maybe even follow up and reminders at specified intervals. With Org definitely same can be done, it is just less relational, more error prone. Of course I could designate a key to choose a person, then write assignment task and press key to send it to person assigned. I have that already. Relational database approach gives me speedier access or better overview without hassles. Additionally I can access tasks in the database by any programming language not necessarily Emacs Lisp. It can be just `psql' the command line tool to database. It could extract the task by using email address of a person and attach the pending list of tasks and date when they have been sent in the email (by pressing key). For the `fzf' command line tool that I discovered only recently I would like to cry as I missed something like that for years. It is like helm-mode on console.