pierrel / capacity-planner Goto Github PK

Need to render run results bette in web

• Create spec
• Start change

Allow the config to define names for iterations.

There's a bug where effort for a project dips below 0, causing us to have to test for positive values to see if a project is exhausted. There shouldn't be a situation where effort goes below zero.

We should remove the pos? here and only test for zero:

Need to attach a test file to demonstrate this.

Use Google's CSP for better solutions: https://developers.google.com/optimization/cp

Come up with a better intermediary reporting format that can support multiple views of everything that's happening for each iteration. Should include:

• Change to each project remaining effort
• Contributors (and how much) to each project for each iteration
• Whether that iteration drew the project to completion
• Any intermediary steps like inter-iteration changes (not sure if this is possible just yet)

Allow the ability to make the start of one project dependent on the completion of another. Should be able to declare in the config with something like:

:projects ({:name "Alpha" ...}
           {:name "Beta" :depends-on "Alpha" ...})

Currently we do not summarize to completion. We report the final backlog (as complete) but do not add it to the history of backlogs and therefore it's not reported.

Should show completion and progress by iteration and project. Columns can be iterations and rows projects. Internal cells are values to represent progress, completion, and no progress.

Create an arg that allows all projects to be exhausted by re-running the final iteration on the backlog.

Create a configuration on an iteration that allows for the iteration to "expand" to multiple iterations. Should make writing configs easier.

For example, if you wanted to only write the contribution as one iteration for each year, but wanted to get understand what completes at the quarter-level then you could write the config something like this:

:contrib {:multiply 4
          :pierre 1}

This is only an example. We may need to reformat that section of the config. Should also take into account naming from #2 .

Validations that cannot run because of an exception should print some context. When running a validation on a form and an exception is thrown whether because of the finder or validator fail then it should print something saying which validation did not pass and on which form.

🌟 Bonus points 🌟
Split the running of the finder and validator so that the error message can let the user know which one failed.