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 yEz0Iw2cw19IYQAA0tVLHw (envelope-from ) for ; Sun, 29 Nov 2020 13:03:09 +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 YKLJHw2cw1/YGwAAbx9fmQ (envelope-from ) for ; Sun, 29 Nov 2020 13:03:09 +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 C416D940437 for ; Sun, 29 Nov 2020 13:03:08 +0000 (UTC) Received: from localhost ([::1]:60510 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjMM7-0005dH-P7 for larch@yhetil.org; Sun, 29 Nov 2020 08:03:07 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjMJo-0005cJ-Uc for emacs-orgmode@gnu.org; Sun, 29 Nov 2020 08:00:46 -0500 Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:41682) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjMJh-0001FR-VF for emacs-orgmode@gnu.org; Sun, 29 Nov 2020 08:00:44 -0500 Received: by mail-pg1-x52b.google.com with SMTP id s63so8171784pgc.8 for ; Sun, 29 Nov 2020 05:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:message-id :date:mime-version; bh=C61DCuiDaBvUiWd2ZPS3HMZXmfUR9BZakvMDKrSfAhA=; b=U0X+owcrwpf/69b8jpdUQxB78zkB0x3pSoQ54fVYdDFAxB0tBl2rr02D4rrrHBeeU+ o5aqfTfzXzSgrWdrfhe8DKH56svfnGBvJ/oQ+0XYULxJYtlH4/31k+AU/VQCyzQIqeHZ McuCgPeBBzf973+X8i5GOuK8KNhY8ni7Odr37qotUQAfdbXkyG+ELEHbc7Thz/fCzait 6lVrzo2sPiQCWQleFAiNSpYtonAEl8YDJI4Vomk2I0FGTDMlo4LIKOZmiL7dmRWxvrjQ N+DCjdnXyzIA7mIGIxZT8dv/OgSl/z3NpP052kb+FCjzzfjurLkjGMea2exalV24ANFc z16Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version; bh=C61DCuiDaBvUiWd2ZPS3HMZXmfUR9BZakvMDKrSfAhA=; b=Z8VnPBwXL5TrIqtiS/3FeJlbYS3Qc+A6FSQhyoYNOJD3FO5Up3LR0Q8LKDBXj3RbqE TbRO310jh88Sk6cV48mutU8wX6vcSzFa21VBQLNXp4y6ctDmPCaDKign/dzddnDC5a/A fZPVpOgo9YNiZZf5wETj/fsjc5XL3irWaItoD9H44v+AX23byOpA01heSX/hgARYHQiH rgtzut/iDQLVxeBgaU7JRJeg/TlM4lT/+8PztEmcE8gePa3ztMniZ6pvyY5zgvvfeyrB 2eBNGGUJmY7P9I/5xZ/En/xRfsl25BbE7ZTj226sbJfyNLF8dex6vfCFRqrnk2RXkYne i/nw== X-Gm-Message-State: AOAM531v/36bAYMgXN/PCBfr93jStYKpk5x5a106I0XJKVtJ5GIlaRM9 3aworr7klVdieD0T728KKpnpyEBj4JKZ/Q== X-Google-Smtp-Source: ABdhPJwgnIRvMFx6LS/o2UKJcpwCHO9gFuiSXkCIki8wQKPelxfUh7zIWD1ts0GKoNkQqVeAmCAyIA== X-Received: by 2002:aa7:9435:0:b029:195:f6a2:b610 with SMTP id y21-20020aa794350000b0290195f6a2b610mr14575799pfo.32.1606654835003; Sun, 29 Nov 2020 05:00:35 -0800 (PST) Received: from tim-desktop (106-69-142-109.dyn.iinet.net.au. [106.69.142.109]) by smtp.gmail.com with ESMTPSA id r66sm13402650pfc.114.2020.11.29.05.00.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 29 Nov 2020 05:00:34 -0800 (PST) References: <87wny5dy6j.fsf@gmail.com> <87r1od181i.fsf@gmail.com> <87h7p9135u.fsf@gmail.com> <87sg8tymeb.fsf@gmail.com> <87k0u4zupw.fsf@gmail.com> <87ft4s5oug.fsf@localhost> User-agent: mu4e 1.5.7; emacs 27.1.50 From: Tim Cross To: Ihor Radchenko Subject: Re: Adding Org Files to org-agenda-files In-reply-to: <87ft4s5oug.fsf@localhost> Message-ID: <87360sz5ap.fsf@gmail.com> Date: Mon, 30 Nov 2020 00:00:30 +1100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::52b; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x52b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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, emacs-orgmode@gnu.org, Jean Louis Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.18 X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=U0X+owcr; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: n6t3EYK58+c4 Ihor Radchenko writes: > 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/ > Exactly. Not all the tasks in my task list are related or have dependencies between them. I use NEXT as part of my planning process. >> 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. > This assumes the only things you have under a TODO heading is other TODO headings. That isn't how I structure my work. I might have many other headings under a TODO heading which are not tasks, but are perhaps related to the task. Sometimes I might have many tasks which are not dependent on each other and so are all at the same level. > 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. > >> 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. > Exactly. I don't just assign a task to someone and then forget about it. I want to be reminded about which tasks have been delegated so that I can follow up on them. Sometimes a delegated task is a dependency in tasks which I have to do. I need to know when it is done in order to do my task etc. >> By using this approach one can assign tasks: >> >> #+TITLE: My Org File >> #+AUTHOR: Me >> #+PROPERTY: ASSIGNED_ALL James Jane John Juda Mehdi >> >> ** TODO Negotiate with land owner >> >> Now when one does {C-c C-x p} the minibuffer prompt asks for >> "Property: " and there is ASSIGNED available as one of choices. >> >> In the next step it asks user for ASSIGNED value, and there are >> choices such as James Jane John Juda and Mehdi. Then it becomes like >> this. >> >> ** TODO Negotiate with land owner >> :PROPERTIES: >> :ASSIGNED: Mehdi >> :END: >> >> This way the major type TODO does not change, but one knows that it is >> assigned or delegated to Mehdi. > > 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. > nd this highlights the main benefit of org mode. There is no 'one right way'. It is up to the user to decide how to best use it to meet their requirements. For me, I want a text only, relatively simple system which has minimal dependencies on anything else (such as a database). I want to be able to copy all my org files onto a thumb drive or put them into the cloud and know I can access/use them from anywhere where I can run Emacs or if Emacs is unavailable, just a basic editor where I can edit/update them as text. -- Tim Cross