2024-04-24 Call 20 Working Group

21:00

Greetins and presentations

All

Everyone briefly introduced themselves

21:30

State of the art

@Alessandro Domanico

Exposed the current setup of the (approximate) release process: We typically have two releases per year, one in June and one in December.

The latest release (1.14.0), which includes significant updates such as Java 17, the latest MariaDB version, Telemetry, and an EXPERIMENTAL full-stack version, was released in February. Due to this recent release, it may be challenging to have the next one (1.15.0) ready by June. However, we will make an effort to do so by organizing two groups to work in parallel: one focusing on code quality and robustness, and the other on implementing new features, mainly related to Pharmacy Management.

Currently, we are working on two user interfaces: the old GUI (Java Swing) and the new UI (React). While the UI is nearly 60% complete, there is still a significant amount of work to be done on the installation process (either through an installer or a well-documented installation guide), which is crucial before an official release can be made. Consequently, the GUI will likely remain in use for at least the remainder of this year, or possibly longer, until the new UI is 100% ready. Nonetheless, UI development is progressing, with research, design, and development primarily driven by the Uni2grow and Intesys teams.

UI developers can utilize a Docker included in the UI repository to have a fully functioning backend.

21:45

Next release

All

The need for increased unit testing coverage, currently at 60%, has been acknowledged, and we have agreed to dedicate an Epic/Task to this in the next Sprint.

Additionally, there is a consensus on updating the current SecurityConfig using JWT, and an issue will be created for this purpose.

We also discussed the best approach for distributing the full-stack on an end-user server machine. As no clear solution has emerged yet, this task will be thoroughly studied.

In terms of new features, the next version will include the "Inventory" features for the pharmacy, which are currently under development, along with some other features related to lot management and data types.

Considering these developments, we agree that for June, we cannot take on many additional tasks in the next Sprint. However, contributions to any issue are always welcome.

22:30

New Feature: Pharmacy Inventory

@Alessandro Domanico @Arnaud FOFOU

During our discussion, we addressed the issue of lot management within the new Pharmacy Inventory feature and determined the best approach to handle it. Additionally, we examined the current application behavior under various setups, particularly focusing on AUTOMATICLOT management and stock movements.

23:00

Discussion Topics and Improvements Proposal

All

We discussed topics proposed from the community, concerning:

1. Visibility and management of sprint start and end dates

We recognize the importance of making sprint start and end dates visible and easily accessible to our community. While our sprints are public, it's worth noting that our volunteer-driven nature means we don't always adhere strictly to business SLAs. However, we aim to pursue limited, well-defined goals aligned with our release schedule.

2. Awareness on System Usages (maximum user and max patients per instance, user interface, admin function, ecc..)

We've noted an average of 8-10 users per installation, and patients currently do not have access to the system. Common usage patterns can be found in our User Manual.

3. Availability, accessibility, and sharing of aggregated data

Since the release of version 1.14.0, we've introduced a Telemetry module allowing users to opt-in for sharing aggregated data and usage information. While it's still early days (only 2 months since release), we're committed to collecting and utilizing this data effectively.

4. Enhancing visibility on design choices and UX research, and how this could improve productivity and motivation by strengthening the collaboration between designers and developers.

We acknowledge the need to enhance visibility on design choices and UX research, fostering collaboration between designers and developers. While decisions are currently made centrally, we aim to involve the community more in the decision-making process, sharing our reasoning and roadmap to facilitate asynchronous feedback and contributions.

5. The expected timeline for the SaaS version.

Based on our experiences as supporters and implementers, we believe that end-user contexts are not yet ready for a SaaS solution. Consequently, the timeline for a SaaS version remains undefined.

6. Formalization of feature lifecycle (e.g., research, design, development, testing, release)

While our project wiki outlines our feature lifecycle workflow, we recognize the need to streamline and improve documentation, which is currently spread across GitHub, Jira, and Confluence. Contributions and suggestions to enhance this process are warmly welcomed.