This page contains a list of several tasks which aim at improving HEAL's software and hardware infrastructure. Especially those tasks are managed in this list, which can hardly be done within the scope of regular research projects.
Every HEAL member is invited to add additional tasks under "New" and to contribute to these tasks.
| Task | Reporter | Description | Votes
|
|---|
| .NET Standard Migration | swagner | We should switch from .NET Framework to .NET Core to enable HL on platforms other than Windows (at least for the non-GUI parts). Therefore, we need to migrate as many HL assemblies to .NET Standard as possible. | 3
|
| HL & Chocolatey | swagner | Provide Chocolatey packages for HL and HiveDrone to enable easier deployment and installation. | 0
|
| Explore GUI Alternatives | swagner | WinForms is outdated and already quite old. We should think about a new HL GUI. Ideally, it should also support platforms other than Windows. Therefore, we should explore alternative platform-independent GUI frameworks. | 0
|
| Hive Budgets | swagner | Hive should offer the functionality to assign a compute budget to a user/project/etc. | 0
|
| Automate Deployment of Hive VMs | swagner | Maybe we can automate deployment of Hive VMs using Terraform or any other deployment automation solution. | 0
|
| Hive & Docker | swagner | Hive jobs should be executed in Docker containers in order to gain more flexibility and security. | 0
|
| Use GitLab CI instead of TeamCity | swagner | If we migrate to Git and host HL on GitLab, we should try to use GitLab CI instead of TeamCity to reduce the number of different tools we use. | 0
|
| Restructure Plugins | swagner | HL consists of too many plugins. We should merge several plugins together to reduce the number of assemblies drastically. | 3
|
| New Algorithm Model | swagner | The operator graph algorithm model has not been very successful in the end. We should rethink HL's algorithm model. | 1
|
| Pull GUI Updates instead of push | swagner | Currently GUI updates are pushed by firing events in an algorithm. However, it would be a better idea to pull new data from the GUI instead as this should reduce the overhead for GUI updates significantly. | 0
|
| Rename HiveSlave to HiveDrone | swagner | Following the analogy of a bee hive, Hive slaves should be named Hive drones instead. (gkronber: I like HiveWorker better) | 0
|
| HL Usage Survey | swagner | A usage survey could be integrated in HL (e.g., on the start page) to ask users about their application scenarios and most desired and most disliked features of HL, etc. | 0
|
| Telemetry Data | swagner | It would be very interesting to get some telemetry data from HL, so that we can get some information, which algorithms/problems/features of HL are frequently used. | 0
|
| Change Hive WCF Services to REST Services | swagner | Instead of WCF services Hive should use REST services. | 0
|
| HL Web App | swagner | Think about which functionality would be reasonable in the HL Web App and how it could be improved. | 0
|
| irace | swagner | Integrate irace into HL. | 1
|
| OKB Agents | swagner | Implement agents that identify interesting test configuration for OKB automatically. | 0
|
| Search Visualization Showcase | swagner | Think about a possible showcase to visualize the search process of a heuristic algorithm with VR technology (together with Anthes/Jetter). | 0
|
| Reports for Experiment Analysis | swagner | Automatically generated reports might help to make analysis of large experiments easier. | 0
|
| Unit Tests | swagner | Implement more unit tests and improve coverage of automated tests. | 0
|
| Projects / Workspaces | swagner | Some kind of projects or workspaces in HL would be nice to organize one's work. | 0
|
| Parameter Validation | swagner | Parameters set by users in the GUI should be validated. | 0
|
| Simplify Release Process | abeham | The release process currently takes several hours. It should take only a couple of minutes. | 1
|
| Adapt plugin dependencies | abeham | Transport plugins are cumbersome, as NuGet references have to be rebuilt as plugin dependencies. As an alternative, an additional assembly reference would be nice, that can be used to reference additional assemblies which are shipped via NuGet. | 1
|
| HL Automation/Scripting | epitzer, swinkler | Scripting from external applications, HL Language Server |
|
| HL Script Serialization | pfleck | Ability to separate script code and data and save separately. |
|
| VSCode Integration | sraggl | Integrate HL into VSCode |
|
| Roslyn for Scripting | jkarder | Use of Roslyn to perform the code generation / compilation |
|
| HL Notebooks | jzenisek | Similar to Jupyter notebooks, ability to integrate code, visualization and data into one document type |
|
| Graph Query Language | rhanghof | |
|
| Update ANN methods | swinkler | Our implementation of neural networks is not state of the art |
|
| Develop new algorithms | abeham | Many more multi-objective algorithms exist, also more flexibility and variants |
|
| Interfaces to other tools | maffenze | HL should provide more interfaces to other tools |
|
| Improve documentation | bburlacu | For instance readthedocs |
|
| ML-Pipelines | bburlacu | Similar to ML.NET |
|
| HIVE UX Improvement | bburlacu | For instance to handle large experiments that do not fit entirely into memory |
|
| Integration of native code for performance | bburlacu | Some things are faster if implemented natively |
|
| Exerpiment definition language | bburlacu | A language / code to describe experiments instead of GUI only and more abstract than a script. |
|
| Problem data server | epitzer, fbaching | Store problem data on a server and reference it instead of saving it with every file. Maintain versions of the problem data (e.g. for data analysis) |
|
| Better integration of unit tests | Currently reside in their own project, not first class citizens |
|
| Code generation and VS extensions | bwerth | |
|
| Better folder structure for release package | dpiringe | The .exe resides in a folder with hundreds of .dll and .config files |
|
