Re: Adding Org Files to org-agenda-files

[pietru]

> Sent: Sunday, December 13, 2020 at 9:59 PM
> From: "Tim Cross" <theophilusx@gmail.com>
> To: "Ihor Radchenko" <yantar92@gmail.com>
> Cc: "Jean Louis" <bugs@gnu.support>, daniela-spit@gmx.it, 
> emacs-orgmode@gnu.org
> Subject: Re: Adding Org Files to org-agenda-files
>
>
> Ihor Radchenko <yantar92@gmail.com> 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.
>
> 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 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. 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.
> You have limited ability to identify all the stages, all the tasks or
> make terribly accurate estimates on completion time. 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.
>
> 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.
>
> 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. The great
> power of org mode is in the ease to which it can be bent to fit with the
> individual's preferred workflow. This is significantly different from
> many other solutions which require you to adjust your workflow to fit
> with the tool. 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.

I know people are trying to help.  Still, I fully agree with Tim here.
I want to give more flexibility to people in the ditches.  They should
decide  their approach and be able to adjust their workflow as they see
fit.  Currently capture works ok for some, but if we get the buffer to have
flexibility as emacs, it would make a big difference, and they will use it.

Particularly for extensive excavations where different regions are under
separate direction.

> --
> Tim Cross
>