Allow for the display of course-level custom data. This could be done by one of the following:

Allow course names to break to a new line to display the data
Show custom metrics in the tooltip
Show the full course name in the tooltip

The tag name "0.2.2" is not of the appropriate SemVer form (vX.Y.Z).
cc: @haydenfree

If an error is encountered while working with a CSV file a _temp version of the file is sometimes left over.

A degree plan can be exported into JSON but the functionality to import still needs to be added

A suggestion from Rick Miranda, Provost CSU.

For example, all core courses as one color. This might be a datatype on the course or at the graph level on a vertex.

The DataHandler.jl file should have a function to convert JSON to CSV. If someone loads their curriculum as a CSV, makes changes, and then wants to export it as a CSV this function would be neccessary.

A redundant requisite may be printed out multiple times. An easy fix would be to store all the strings before they're printed, and ensure there are no duplicates.

The Cbc package will not build on Windows and thus prevents the toolbox from working correctly.

Potentially look for an alternative or work to make it compatible.

The following DataHandler.jl test fails no matter what. The failure occurs at read_csv("./UBW-curric.csv"). It is unable to find the COURSE_ID header in the file. The test has been commented out for now but needs to be resolved.

curric1 = Curriculum("Underwater Basket Weaving", [A,B,C,D,E,F], institution="ACME State University", CIP="445786")
# write curriculum to secondary storage
@test write_csv(curric1, "./UBW-curric.csv") == true
# read from same location
curric2 = read_csv("./UBW-curric.csv") # FAILURE OCCURS HERE
@test string(curric1) == string(curric2)  # read/write invariance test
rm("./UBW-curric.csv")

There is currently no way to capture the notion of Engineering Standing within the toolbox. This might be accomplished by creating a dummy course labeled "Engineering Standing" that has all of the prerequisite courses to reach Engineering Standing.

There is likely a better way to capture this.

We are not currently evaluating code coverage.

Coverage.jl appears to be the go-to solution for Julia.

There are two folders for the purpose of "Introduction to CurricularAnalytics"

Notebook files should be moved to https://github.com/CurricularAnalytics/CA-Notebooks

There are a lot of files in the Notebooks directory that are not notebooks, as well as a large number of temporary files that shouldn't be included at all.

PDF files likely shouldn't be included in the examples directory but rather in the documentation.

CSV files should be separated from Julia files.

Redundant curricula/plans should be eliminated.

here are the vue curricula analytics docs. I would probably make separate embed_client_plan and embed_client_curriculum vue applications that use the plugin with different configurations. Take a look at embed_client/src/views/Graph.vue to see where most of the plugin abstraction code is.

vue-curricula-docs.pdf

Visualize a curricula such that there are no terms. It does not matter the order that it is filled.

Some courses are actually a set of possible courses, such as an engineering elective. The elective may be filled by one of a set of courses.

We may want to optimize the degreeplan by choosing the electives that result in the lowest complexity, lowest number of credit hours for the term, or lowest number of credit hours over the entire curriculum.

The delay path should be displayed but re-named to longest path

If a course name should be stored, as well as the prefix and number, then the export_degree_plan function must be updated to explicitly export both of these.

This means exporting the name, prefix, and number as separate fields. This will also depend on how the vue-curricula plugin takes in the name and prefix+number.

The tag name "0.4.0" is not of the appropriate SemVer form (vX.Y.Z).
cc: @haydenfree

The tag name "0.2.0" is not of the appropriate SemVer form (vX.Y.Z).
cc: @heileman

Remove the code that extracts the dict from the file, and make that its own function.

Update the objective function to expect the final dict, and update the optimize_plan function to have an arg with that dict.

I believe renaming the repository to "CurricularAnalytics.jl" would be more appropriate since that will be the package name.

This also seems to be convention, as many other packages do it.

The DataHandler.jl to incorporate the code for CSV import/transformation

Rather than creating a recent-visualization file, create a JSON object and keep it in memory. We should only write a file if they opt to save or have made changes.

Create a development branch that we can all push to so our changes don't result in a ton of conflicts that have to be merged. Then periodically merge this branch to the master.

When making changes to a curriculum through the visualization interface users should have the option to save to JSON or CSV file

Example:

julia> visualize(dp)
┌ Warning: Accessing `scope.id` is deprecated, use `scopeid(scope)` instead.
│   caller = ip:0x0
└ @ Core :-1
Blink.AtomShell.Window(1, Blink.AtomShell.Electron(Process(`/Users/hayden/.julia/packages/Blink/AO8uN/deps/Julia.app/Contents/MacOS/Julia /Users/hayden/.julia/packages/Blink/AO8uN/src/AtomShell/main.js port 7393`, ProcessRunning), Sockets.TCPSocket(RawFD(0x00000017) active, 0 bytes waiting), Dict{String,Any}("callback"=>##1#2())), Blink.Page(1, WebSocket(server, CONNECTED), Dict{String,Any}("webio"=>##28#29{WebIOBlinkComm}(WebIOBlinkComm(Window(#= circular reference @-5 =#))),"callback"=>##1#2()), Distributed.Future(1, 1, 1, Some(true))), Task (done) @0x0000000116066ad0)```

The blocking path should not be displayed and it should not be in the legend.

The tag name "v0.1" is not of the appropriate SemVer form (vX.Y.Z).
cc: @heileman

The tag name "0.3.2" is not of the appropriate SemVer form (vX.Y.Z).
cc: @orhanabar

The visualization currently generates the longest path itself. It should instead accept the longest path from the toolbox and visualize it that way.

Create a function generate_id(s::String) that creates a unique ID for the course. This is used when storing requisites.

For now just increment a global variable and assign the course a number starting at 1 for the first course.

When calculating the complexity of a curriculum that is a quarter system, the complexity should be multiplied by 2/3

The visualization was developed a couple versions behind and needs to be merged before being push to the development branch

Write validity tests for degree plans

The visualization function currently only takes degree plans, but there should be an overloaded version that takes curriculums.

The regular function, for degree plans, should not have the arguments to hide terms and grid. These two things should be hidden by default in the curriculum visualization.

The compare_curricula function currently just compares to curricula metric by metric and tells you the difference between the two.

Brainstorm ideas for interesting comparisons to do. For example, comparing a set of courses across multiple curricula, or comparing sets of curricula. Examples of a set of curricula might be the engineering department of a school.

Some institutions such as Carnegie Mellon list their courses in units. These units do not always requite to an whole number (integer) of credit hours. The toolbox should change the credit_hours type to something like Float64.

A course has a one to many relationship with curricula, therefor it may be associated with more than one curriculum graph. Refactor the vertex_id field to be a dictionary so that the course can have a unique vertex ID in more than curriculum graph.

ex: vertex_id::Dict{Int, Int} where the first Int is the ID of a curriculum graph, and the second int is the vertex_id of the course within that particular graph.

https://curricularanalytics.github.io/CurricularAnalytics.jl/latest/degreeplans.html#Optimized-Degree-Plans-1

Add the documentation to the degreeplans.md file rather than having it in the source code.

Academic year(s) (may be a range of years) associated with a given curriculum. Should it be a data member on a curriculum? Should it support future years? This may need to be an optional input when creating a curriculum, rather than a requirement.

If you read a degree plan as a CSV then read_csv will return a Tuple rather than a DegreePlan.

The visualize function should have an argument to toggle blink off. This allows the visualization to be displayed within a Jupyter notebook.