Yeah, it does sound a bit complicated :))

Powerful functionality always comes with the cost of UI/UX. We'll try to make our app simple and easy to use, so we try to avoid any complex features.

Anyway, thanks so much for your feedback and ideas. I appreciate it.

Gantt charts can be made in MS Project, Google Sheets,: https://en.wikipedia.org/wiki/Gantt_chart

Critical path method > Basic techniques: https://en.wikipedia.org/wiki/Critical_path_method#Basic_tec... :

> Components: The essential technique for using CPM [8][9] is to construct a model of the project that includes the following:

> (1) A list of all activities required to complete the project (typically categorized within a work breakdown structure), (2) The time (duration) that each activity will take to complete, (3) The dependencies between the activities and, (4) Logical end points such as milestones or deliverable items.

> Using these values, CPM calculates the *longest path* of planned activities to logical end points or to the end of the project, and *the earliest and latest that each activity can start and finish without making the project longer.* This process determines which activities are "critical" (i.e., on the longest path) and which have "total float" (i.e., can be delayed without making the project longer). In project management, a critical path is the sequence of project network activities which add up to the longest overall duration, regardless if that longest duration has float or not. This determines the *shortest time possible to complete the project.\ "*

Re: [Hilbert curve, Pyschedule, CSP,] Scheduling of [OS, Conference Room,] and other Resources https://news.ycombinator.com/item?id=31777451 https://westurner.github.io/hnlog/#comment-31777451

Complexity and/or Time estimates can be stuffed into nonexclusive namespaced label names on GitHub/GitLab/Gitea:

  #ComplexityEstimate: 
  C:1
  C: Fibonacci[n]
  C: (A), J, Q, K, (A)

  #TimeEstimate:
  T:2d
  T:5m

  #Good First Issue

GitLab EE and Gitea have time tracking on Issues and Pull Requests.

Gitea has untyped Issue dependency edges, but there could probably easily be another column in the is-it-a through table for the many-to-many Issue edges table to support typed edges with URIs i.e. JSONLD RDF.

GitLab Free supports the "relates to" Linked Issue relation; EE also supports "blocks"/"is blocked by".

Planning poker: https://en.wikipedia.org/wiki/Planning_poker

Agile estimation: https://www.google.com/search?q=agile+estimation

"Agile Estimating and Planning" (2005) https://g.co/kgs/kDScM7

CPM sounds a lot like a PERT chart, which was invented in the 1950's to help design and build the Polaris nuclear submarines during the Cold War[0]. PERT has been part of Microsoft Project for decades, so it's readily available.

When you really need it (like in the case of tens of thousands of people trying to build and ship a single project at lighting speed) PERT is extremely powerful and effective. If, on the other hand, your "project management division" is you, it's a dangerously seductive time sink that will consume huge amounts of your time building and tuning and gathering data and information and understanding, for arbitrarily close to zero direct real benefit and huge net negative benefit. The increase in effectiveness you gain from all that modeling is, in software development projects, negligible and the cost of doing all that modeling is much higher than you think it will be if you've never done it. As with any approach to planning, PERT works best at a particular scale, and it's a very large scale.

In my personal opinion, from a software development standpoint, the valuable part of building a PERT chart is doing the work and thinking to draw a dependency map for your tasks. Drawing all those lines to show what has to be done before what is an incredibly effective tool for helping you flesh out and find the dependencies (tasks) you hadn't realized were going to be on your list. My view is use something like Project to build that dependency diagram, then force yourself to stop using Project because it's too seductive at making you feel like the data is giving you power when it's really just consuming your brainpower in effectively. Use dependency mapping to build a waterfall caliber understanding of what you need to build, then set it aside and use more appropriate agile style approaches to actually work through the project in an optimum manner (which often means not building it in exactly the way you mapped out originally).

[0]https://en.m.wikipedia.org/wiki/Program_evaluation_and_revie...

WBS: Work Breakdown Structure: https://en.wikipedia.org/wiki/Work_breakdown_structure

PERT -> see also ->

"Project network" https://en.wikipedia.org/wiki/Project_network :

> Other techniques: The condition for a valid project network is that it doesn't contain any circular references.*

> Project dependencies can also be depicted by a predecessor table. Although such a form is very inconvenient for human analysis, project management software often offers such a view for data entry.

> An alternative way of showing and analyzing the sequence of project work is the design structure matrix or dependency structure matrix.

design structure matrix or dependency structure matrix: https://en.wikipedia.org/wiki/Design_structure_matrix

READMEs, Issues, Pull Requests, and Project Board Cards may contain Nested Markdown Task Lists with Issue (and actual Pull Request) # references:

  - [ ] Objective
    - [x] Task 1 +tag
    - [ ] #237 (GitHub fills in the Title and Open/Closed/Merged state and adds a *hover card*)
    - [x] Multiline Markdown list item indentation
      
      <URL|text|>

      - ID#: 
      - Title: 
      - Labels: [ ]
      - Description: |
        - htps://URL#yaml-yamlld
    - [x] Multiline Markdown list item indentation w/ --- YAML front matter delimiters

      ---
      - id: 
      - title: 
      - labels: [ ]
      ---
      - htps://URL#yaml-yamlld

Time management > Setting priorities and goals > The Eisenhower Method: https://en.wikipedia.org/wiki/Time_management#The_Eisenhower... :

  |            | Important | Not important
  | Urgent     | 
  | Not Urgent | 

From "Ask HN: Any well funded tech companies tackling big, meaningful problems?" https://news.ycombinator.com/item?id=24412493 :

> https://en.wikipedia.org/wiki/Strategic_alignment ... "Schema.org: Mission, Project, Goal, Objective, Task" https://news.ycombinator.com/item?id=12525141

And the probabilities could be a result of an intra-team prediction market. Half-joking.

I know, I know, it sounds very complicated. The actual end goal however is to show quantitatively why estimating too far out is generally unreliable as well as the associated combinatorial explosion of paths. The idea is basically to illustrate the actual reality of planning.

Have you read "Righting Software" by Juval Lowy? You might really enjoy it based on your feedback above and here. There is a project design aspect that goes into this kind of planning (or at least reminds me of what you wrote).

You could try TreeAge for mapping out probabilities: https://www.treeage.com/

And just as a plug, I made https://www.knotend.com which is a keyboard-centric flowchart editor you can use to map dependencies. Im working in adding computation and probability like you say.

Thanks. I'll keep my eye on knotend.

Interesting thought. One could do Monte Carlo simulations to estimate the probability distribution of time-to-finish. I considered something like this [0] to explain the empirical log-normal distribution of project completion times [1], although I hadn't thought about including sequencing & bottlenecks. Probabilistic programming [2] is the discipline concerned with solving this type of problem - some tooling might exist, although probably w/o a nice UI.

[0] https://heteroskedasticblog.wordpress.com/2021/12/04/softwar...

[1] https://erikbern.com/2019/04/15/why-software-projects-take-l...

[2] https://en.wikipedia.org/wiki/Probabilistic_programming

Twiglfo.com allows for this. You can put probabilities on nodes that make up a directed graph (think flowcharts). Bottlenecks and dependencies are also extremely easy to see in this UI.

As others have said, PM tools need to become more opinionated rather than recreating what already exists.