Managing lnksz's contributions

[lnksz]

Soon I will finish my work on rivus (as far as my thesis goes), and still have a lot of pending PRs, I summarized the properties of them hoping to ease the process/decision of acceptance/merging. @KSchoenleber

Fast ToDo:

• [ ] Add labels like in urbs, so that Issues and PRs can be labelled. This would ease the sorting and handling of those. [urbs-labels]
  • Adding documentation/discussion labels where needed.
  • maintenance, bug, etc...
• [ ] Define version milestones. (Now 0.1, which is the original. Alone #13 should mean a version upgrade.) (See doc)

Pull Requests

As I restructured the project at the beginning, and that was already merged, the PRs mostly consist of self-maintained contributions. However, broader developments can rely on changes now pending in earlier pull-requests.

Sub Packages

#self-contained

• [x] 3D interactive plot #17
• [x] Graph/Network analysis sub package #22
• [x] DB integration #24
• [x] Gridder #28
• [x] Unittests #33

Core Changes

#maybe-self-contained

Merge conflicts can arise, as these operate on the same file. But in different places, so should be ok, or solvable with minimal time investment.

• [x] Line length calc bugfix #13
• [ ] Save function extension #16
• [ ] Excel parsing #23
• [x] Speed-ups #27
• [x] Fix Warnings from Pandas #30
• [x] Ban hubs from vertices #37

Broad Changes

#relying-on-others

• [x] Runbunch. This is where the threads come together. #32
  • Relies on: 17, 22, 24, 28, | 13, 16, 23, 27, 30
• [x] Documentation. As changes include docstring and variable name formatting al over the codebase. #40 + main.rivus changes