From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cGinFqak1l/DMwAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 23:32:54 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id eEFrEqak1l9qIgAA1q6Kng (envelope-from ) for ; Sun, 13 Dec 2020 23:32:54 +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 67CD294011A for ; Sun, 13 Dec 2020 23:32:53 +0000 (UTC) Received: from localhost ([::1]:45084 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koarD-0003G3-Tw for larch@yhetil.org; Sun, 13 Dec 2020 18:32:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49364) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koaqE-0003Es-MR for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 18:31:54 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]:53179) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koaqA-0007mS-SI for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 18:31:50 -0500 Received: from localhost ([::ffff:197.157.34.185]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000308F9.000000005FD6A45F.000072A7; Sun, 13 Dec 2020 16:31:43 -0700 Date: Mon, 14 Dec 2020 02:28:11 +0300 From: Jean Louis To: Tim Cross Subject: Re: Adding Org Files to org-agenda-files Message-ID: References: <87sg8tymeb.fsf@gmail.com> <87k0u4zupw.fsf@gmail.com> <87ft4s5oug.fsf@localhost> <87wny2uuuk.fsf@localhost> <87v9d54t19.fsf@localhost> <87tuspidsz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87tuspidsz.fsf@gmail.com> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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, Ihor Radchenko Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.80 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-Migadu-Queue-Id: 67CD294011A X-Spam-Score: -1.80 X-Migadu-Scanner: scn1.migadu.com X-TUID: lUEUK9iJ3rjq * Tim Cross [2020-12-14 00:42]: > > Ihor Radchenko writes: > > > Dear Jean Louis, > > > > Thank you for the detailed insight into your extensive experience of > > project management and practical planning. I do not have that much > > experience, but can provide a significantly different point of view > > related to my research work. > > > > Some good observations. I have cut most of it out to stop the thread > from becoming too long. > > I think it is very important to recognise there is no one way to do > project management or organise a project. Different industries have > different requirements. For example, project management requirements to > build a bridge are very different from those to build the software that > will be the next evolution of social networking sites. I do recognize, but the Org manual does not: (info "(org) TODO Items") > 5 TODO Items > ************ > Org mode does not maintain TODO lists as separate documents(1). > Instead, TODO items are an integral part of the notes file, because TODO > items usually come up while taking notes! With Org mode, simply mark > any entry in a tree as being a TODO item. In this way, information is > not duplicated, and the entire context from which the TODO item emerged > is always present. > Of course, this technique for managing TODO items scatters them > throughout your notes file. Org mode compensates for this by providing > methods to give you an overview of all the things that you have to do. Thus the Org manual is already giving a technique for managing TODO items and admitting it is scattering things. Why not then straight give to users one page with at least 3-5 other paradigms that users can follow. This way users follow only the scattering paradigm. > The way Jean Louis describes project management sounds very similar to > the waterfall methodology which was popular in software development up > until the late 90s. It is a methodology that can work well when you have > a well defined and understood project, like building a bridge where we > have a couple of thousand years of experience and engineering > knowledge. It sounds right. > It doesn't work particularly well with software projects and has been > largely replaced by various 'Agile' methodologies which are similar to > what you outline as your experiences and approach with research. Even > within the software development space, you find considerable variation > because different stages within the software life-cycle have different > requirements. You may be right, I never used Org mode to plan software. I know those workflows and it should be planned and so on, but I don't. Instead of planning I just make what I personally need. > For example, during the R&D stage, there are far more 'unknowns' > than 'knowns'. Often, many things will need to be tried and then > accepted or rejected (suck and see). At this stage, you need to be > fast and flexible with maybe 80% of ideas ending up on the scrap > heap. I like to see some concept. All our projects also have R&D stage. Preliminary Site Assessment and Inspection project is such. That is why it is part of the project. After that project has been done the next project is devised. But there is overall plan that says: - do the R&D - devise project for result from R&D > You have limited ability to identify all the stages, all the tasks > or make terribly accurate estimates on completion time. That stage is defined on my side as part of the plan. We know that we will have limited ability, but that is why projects can branch, expand dynamically. > Later, the software will move into production status. Things change > considerably at this point. Here you need stability, reliability and > performance. Changes often need to be justified from a return on > investment perspective. There are fewer unknowns, more accurate > estimates and better defined tasks. Even this is qualification stage where it is obviously and your description shows it, part of the overall plan. > Is org mode suitable in all these scenarios? Possibly not or perhaps > there are dedicated project management tools which are better suited. > Org is not a project management tool, but it is a tool that is flexible > enough for many people to use it for either project management or for > part of the project management process. As a document preparation system it is possibly suitable, more than suitable for planning of what you described. And nothing you described does not seem to fall out of planning capability. Any scenario may be described by documents. General text is enough. So Org mode is more than enough to describe such planning. Unless you refer to something else than what I think. As a planning system with TODO stuff, or actionable items, I am arguing how useful it is in that scenario or any scenario. What you described has its logic, chronology, it has its plan. You described overall plan. Nothing different than my scenario. Paradigm is same, maybe you do not see it. We have all time R&D and dynamical branching of projects. But all that is part of larger plan. Often we will not know where is the water source, how much water we could get from specific water source, if water is polluted or used by people that we should not use it and find other ways, if it is on 2 kilometers or 100 meters. That requires a project or branch to be devised when the time comes. This is first done by people on ground who propose the project then by collaboration it becomes well defined and engaged. It can be that person need to go to other city to purchase pipes for 2 kilometers and couplings and that person need to talk to chairman and neighbors where the pipe passes and that collaboration of many people is necessary until water may be brought to the place. Many things may be involved only to bring water to the site. But the plan says: - conduct Preliminary Site Assessment and Inspection (project in itself) - solve water supply (make project yourself) > To argue for a specific workflow using org mode in a specific manner > with only the task types you believe are relevant fails to recognise the > vast differences in requirements everyone has or personal preferences in > how individuals like to manage their projects or information. Everybody has personal preferences. What I do not fail to see is that many people popularize Org mode by using the scattered technique just as advertised on the website, on videos, and Org manual, and just as compensated by the org-agenda. Those others who handle their things are not in the scattering group. > The great power of org mode is in the ease to which it can be bent > to fit with the individual's preferred workflow. Org mode is too much high level. There is no inherent power in itself. Put a person behind computer and observe how that person "plans" or do anything with Org mode and inspect. Today we discussed on different mailing list about the menu item Tools -> Search files (grep) and Tools -> Recursive grep and main developer finds the option user friendly, I don't find the option user friendly. Then I ask staff member, geologist in Tanzania, who anyway used computers for many users and finished doing Emacs tutorial if she can understand what is "Recursive grep", so there is no way. She would not be able to find files by using Emacs. For full understanding one has to know GNU/Linux or BSD/Unix command line and to know what "grep" means in the first place, and then one has to have experience of using it and then one can understand "Recursive grep". And I compare that real life inspection of Emacs usability to your statement of great power of org mode and easy it can be bent to fit whatever workflows. That is what you think, I do think the same, but I do not agree it is user friendly. Among all various free software note taking applications it is probably unfriendliest. I also love it, but I look at its face without closing my eyes (or one eye). TiddlyWiki note taking in a browser https://tiddlywiki.com/ That note taking application can be also used for planning. If information is stored on remote WebDav server maybe it could be used even for collaboration. But it is intuitive and more accessible than Org and way better usable than Org. Or: Cherrytree - hierarchical note taking application with rich text and syntax highlighting https://www.giuspen.com/cherrytree/ Everybody can make a test: - open up Org mode in Emacs, and call somebody who used computer, but never Org mode and tell him to make a note, or task - open up TiddlyWiki, Cherrytree, Joplin, Turtleapp, Leo editor and then tell him to make a note or a task - let them create project of 3 items in each of those. - write down your findings and bring it here that we may make conclusions what Org mode needs to catch up with those maybe friendlier tools. Using family or friends is fine. I would like to see how it will look in Org mode, probable scrabble that does not look like anything that experienced people do with Org mode. Love is a strong bias or prejudice. We love it, we have prejudices. But where is comparison? > This is significantly different from many other solutions which > require you to adjust your workflow to fit with the tool. When you say it I find it funny. Yes, Cherrytree and TwiddleWiki and others will ask you to adjust to fit to the tool. There are subtrees, headlines, rigidness, etc. But how much is Org asking us as users to fit with the tool? Tremendously, uncompared to anything else! - try opening Org menu item and if you have more than one agenda file, you will not be able to use the mouse to come to the documentation section. Usability? From 1 to 10 I rank that to 1. User would need to learn from somebody that mouse pointer has to be moved away from the drop down menu to go around, to skip the agenda list of files, so that it may reach down to Org documentation (maybe this is why there are not many bugs reported) - did we already say that Export menu does not fit well on the screen? Terrible usability. We can customize what to export but we cannot practically use it on screen. We talked about Org capture screen being too small. Not only that user has to adapt to the tool, user is asked to learn Emacs Lisp. I find that positive in one way, rather negative in practical as such learning requirement is too steep! - this list of our adaptations to Org may be followed indefinitely. User cannot find some feature useful, the answer is more or less that user can make it. If not user maybe somebody makes it simply. Ah, something does not work. We are Wizards of Oz, we just use Emacs Lisp and look hey, it does work now. Ah, again something does not work, ah there is solution, just learn Emacs Lisp and it works. I don't mind, I enjoy that, but adaptation never ends, software never completes, and usability does not raise. I have three people in this house and each of them would be able to use Gnumeric spreadsheet for planning but not Org mode. Taking notes is not intuitive in Org mode. Even making a headline is not as intuitive compared to all those other tools. I did listen to the advise: if something does not work, you can DIY, so I did myself what I need myself. I skipped the great Org and placed it as a possible node between all other nodes which can have any other mode: markdown, asciidoc, rst, txt2tags, you name it. Implementing babel-like functions is also possible and user extensible in much simpler way than hard coding it with Org babel. Cherrytree also leaves code blocks user extensible, just decide how to run it yourself. No need to hard code. > The great weakness with org mode is that this tends to make everyone > think they have found and defined the ultimate approach, which can > easily reach religious heights and inspire a missionary zeal to > evangelise their perception of the world. -- Tim Cross I do not see that as weakness, I do understand you and where you wish to go, but no. Great weakness is its foundation as how it was designed only for advanced users using Emacs who cannot understand they are advanced users and so everything becomes little bit or much hackish and that does not really help great number of people who hear about Org mode as "powerful" tool. Jean