Skip to content

Milestones

List view

  • Template Selection Support

    Currently, users might be overwhelmed with the PARIS templates and which one to select in what situation. Users should receive help to select the most fitting template. Firstly, possible solutions should be planned thoroughly, considering their pros and cons. Later, the "best" solution should be implemented and evaluated. Building early-stage prototypes to test approaches against each other might be beneficial to find the best solution. This milestone is not urgent, as the potential implementations might be quite complex and time-consuming.

    No due date
    0% complete0 open0 closed

  • Input Field Mapping on Variant/Template Change

    Currently, when using the EIFFEL input form the user is required to re-enter all, already entered information if they want to change the template's variant or the template itself. EIFFEL should allow some sort of input mapping between different variants and templates. Firstly, this feature should be implemented using an interactive mapping. Later, an automatic mapping should be considered as well to increase comfort.

    No due date
    0% complete0 open0 closed

  • Improve Requirement Copying

    Currently, it is only possible for the user to copy a single requirement at once. The user expects a more ergonomic way to copy multiple requirements at once for further use in other applications. This feature should be planned, developed and evaluated.

    No due date
    0% complete0 open0 closed

  • Refactor `core/web`

    `core/web` should be refactored and simplified. Currently, the implementation feels "bloated" and not very idiomatic. As of right now I don't have 100% the right words for it but there is room for improvement and evaluation. Also the current templating approach should also be carefully revised as it feels very-unidiomatic, abstracting away the std lib's templating engine. In general, a little more simplicity and idiomatic Go approaches could improve overall code and project quality.

    Overdue by 2 year(s)
    •
    Due by March 18, 2024
    0% complete0 open0 closed

  • Self-contained Binary

    HARMONY must be runnable as a single binary without dependance on any local files, they should be embedded into the binary. Embedded should be files like: translations, templates and configs. Configs should be embedded as the application will be configured on compilation and through env variables. Changeable config files on various systems will be avoided.

    Overdue by 2 year(s)
    •
    Due by March 12, 2024
    0% complete0 open0 closed

  • Module manager and general refactoring

    Great stuff has already been implemented but there is more to come. For a sustainable development and great DX the main focus of near future development will be the module manager or better to say `harmony.mod.Manager` using `harmony.mod.Event`s to communicate and interact loosely coupled between various modules. Main points of interest for this milestone: - [ ] Module Manager - [ ] Events (improved) - [ ] Lifecycle of Modules, Automatic Registration, etc. - [ ] General Refactoring (where applicable, especially due to a lot of fundamental changes) This milestone will build a very solid foundation for future development and advancements.

    Overdue by 2 year(s)
    •
    Due by March 9, 2024
    0% complete0 open0 closed