assigning tasks to projects

[esquires]

Greetings!

I am trying to figure out how to best use neorg for my workflow. Oftentimes I am taking notes during meetings and have a short period of time to jot down tasks. An example might be the following

@document.meta
    title: puzzle
    description: 
    author: esquires3
    categories: 
    created: 2021-12-03
    version: 0.0.8
@end

* 2021-12-02 How To Do Puzzles
  ** Meta
    Attendees: corner piece, middle piece, box
    Agenda:
    -- choosing a theme
    -- choosing a difficulty

 ** Choosing a Theme
    - Discussed importance of finding topics that are interesting so puzzles are more fun
    - Discussed level of detail is important for intended audience (also affects difficulty)

 ** Choosing a Difficulty
    - Discussed factors affecting difficulty
    -- contrast: color, piece shapes, picture detail
    -- number of pieces
    - [ ] buy a color theory book

  

Let's say this is just one of many meetings on puzzles so I might have 10 or files like this. As I understand it, in the current workflow if I were to view the projects list :Neorg gtd views followed by p I would see an interface like this:

* 2021-12-02 How To Do Puzzles (0/1 done)
   [          ] 0% done

* 2021-12-01 Puzzle Manufacturing (0/1 done)
   [          ] 0% done

* 2021-12-02 Puzzle History (0/1 done)
   [          ] 0% done

In other words, neorg seems to organize the tasks based on meetings rather than on a project theme where in this case it is better grouped into a more coherent goal (e.g. create puzzle app). As I understand it, I could do this in neorg manually by moving the tasks I create during meetings into another file (perhaps called create_puzzle_app.norg) that looks like this:

@document.meta
    title: create_puzzle_app
    description: 
    author: esquires3
    categories: 
    created: 2021-12-03
    version: 0.0.8
@end

* Create Puzzle App
  - [ ] buy a color theory book
  - [ ] identify 5 areas of history to be in one puzzle theme
  - [ ] send an email to foobar about discussing manufacturing experience

This is certainly doable but it seems to have the following downsides:

1. It slows down workflow. Instead of basically being done with task management at the end of a meeting, I have another task to move the todos from a meeting into another file.
2. It loses context. When I jump to a task I no longer see the discussion context of why I created the task in the first place since the task is now in a new file (e.g it is now in create_puzzle_app.norg rather than puzzle.norg). Of course, I could add a link back to the original file where I made meeting notes but this adds further overhead to the task management process.

Another higher level issue is that sections and GTD projects are both designated by * in the neorg spec which seems ambiguous (see here for a related discussion).

My questions are:

1. Is there another method in neorg to organize projects for the above workflow that I am not seeing? I know we can use contexts but my understanding from GTD is that contexts are more designed for use with where we can do actions as opposed to being a manager for project lists.
2. What do you think about adding a project tag to a task as follows? This would enable the workflow above (being done with task management at the end of a meeting/removing ambiguity between headers and projects/keep context for created tasks)

For question (2) the suggestion would be to add a tag similar to the waiting_fors convention already in neorg. So it would look something like this:

In some notes file where I had in the "How To Do Puzzles" meeting:

  #project create_puzzle_app
  - [ ] buy a color theory book

and in the file where I had the other notes file where I had the "Puzzle Manufacturing" meeting:

  #project create_puzzle_app
  - [ ] send an email to foobar about discussing manufacturing experience

Then when doing :Neorg gtd views followed by p would yield

* create_puzzle_app (0/3 done)
   [          ] 0% done

Then we could expand the project with "" to see the tasks and jump to the corresponding discussion.

Let me know what you think!

[esquires]

I didn't hear anything on this so I went ahead and created an extension that implements the above here.

It involved copying a few large functions that only required a couple line changes. Mind if I send in a pull request to refactor some of the functions so it involves less copying?

[vhyrro]

Hey, sorry I completely missed this discussion 😅

I think having a #project tag would be a cool idea. You can send in a pull request, sure!
I'm currently not the king of the GTD implementation, that title goes to @danymat, so he'll probably have more insight than I do on the idea.
I'm busy doing core stuff and will only have time to truly hop in on the GTD action when I'm done with everything there.

I'm all for disambiguating though, and it seems sensible to do it this way :)

[esquires]

No problem. I appreciate your work on neorg! As an aside, it was straightforward to create the extension so nice job on the framework.

If you all want to use project tags as the default implementation for gtd project views I can send in a pull request for that and remove my extension. On my end that would be preferable. Alternatively if you all want to keep the current implementation I can limit the pull request to refactoring so that the core gtd can be more reused.

@danymat , let us know what you think.

[danymat]

Alternatively if you all want to keep the current implementation I can limit the pull request to refactoring so that the core gtd can be more reused.

I think we can start by doing some PR to refactoring stuff (feel free to open some PR's for it, explaining what where your changes) , and when we arrive on an agreement on the GTD spec, we could change GTD core.

[danymat]

Hello @esquires, sorry for the missing feedback until now (we're quite focused on wrapping up some features, that'll allow us to close unstable and only use PR's for development)

Nervertheless, these are my feedbacks about your questions and points:

Is there another method in neorg to organize projects for the above workflow that I am not seeing? I know we can use contexts but my understanding from GTD is that contexts are more designed for use with where we can do actions as opposed to being a manager for project lists.

From what I see, you want to ditch the rigidity of GTD specs from using heading1 levels from projects, to be able to use other things as projects. I'm not sure we can allow such behavior (or we only could allow this as public config, to be enabled). Why? From my point of view, this:

• Quick understanding of what is a project and what is every component of GTD (contexts, projects, tasks, ...) (see :h neorg-gtd-projects)
• Incoherent handling of information: suppose we allow heading1 and heading2 to be both projects. What happens if we have a project declared as heading1, followed by a heading2 ? Are they both separate projects? Do they depend on each other? What happens of their tasks ?

This last point is in my opinion the trickiest to bypass. For example, what do we do with this information ?:

* This is a project 
  #project
  ** This is treated as a project too
    - [ ] This is a task 

This is a task is a task, but from which project ? Both? Only heading2 project? I think if we can agree of something, it could be good indeed.

One idea to bypass this is allow the user to change projects to be heading1 from an other heading (in your case heading2).

If you all want to use project tags as the default implementation for gtd project views I can send in a pull request for that and remove my extension. On my end that would be preferable. Alternatively if you all want to keep the current implementation I can limit the pull request to refactoring so that the core gtd can be more reused.

I think if you can help me solve these considerations, we'll be good to do some PR's

[esquires]

It should be adding a configuration (https://github.com/nvim-neorg/neorg/wiki/Getting-Things-Done#configuration) to switch between heading1 or #project.

Is there a need to have both options? It seems like this would yield a fairly substantial increase in the code size, particularly since the implementations (at least for viewing) are so different.

For Tab, could we just tell users to map it to za if using the folding implementation rather than having to redraw the buffer?

[danymat]

Is there a need to have both options? It seems like this would yield a fairly substantial increase in the code size, particularly since the implementations (at least for viewing) are so different.

You're proposing to entirely substitute (remove) the projects defined as heading1 ? If so, I think we should keep this as a feature by pointing it to your extension.

For Tab, could we just tell users to map it to za if using the folding implementation rather than having to redraw the buffer?

Maybe, and I think we can do this mapping on the default_keybinds file. If so, then we can do it for them so that this change goes unnoticed.

[esquires]

You're proposing to entirely substitute (remove) the projects defined as heading1 ? If so, I think we should keep this as a feature by pointing it to your extension.

Yes. That seems like the reason for creating the extensible framework so that the neorg core doesn't get too bloated.

Keeping it as an extension works on my end. I'll just send some PRs to refactor so that the extension can have less copied code. Does that sound like a good next step?

[danymat]

I'll just send some PRs to refactor so that the extension can have less copied code. Does that sound like a good next step?

This is optimal indeed, feel free to open some PRs, and I will be sure to review them!

[esquires]

No problem. The pull request is #229