Development Plan - GNUKhata =========================== ## Introduction This is an overview of the actionable items for GNUKhata development. ## Short-Term Plans - Finalize the features to be supported and the issues to be solved for v8.0.0 stable release (domain-specific). - Support invoice-level discounting. Currently discount is only supported for individual items. - Support `other charges` (freight charges, insurance charges, etc.) in Invoices. - Support purchases other than inventory. Currently this is done using manual journal entry which is not user-friendly. - Fix `Profit & Loss` and `Balance Sheet` statements. - Fix `Close Books` and `Roll Over`. - Temporarily remove features that aren't fully functional yet (GST, Budget, Cost Center and Not-For-Profit organisation support). removing GST for example you mean reports or everywhere like [this issue](https://gitlab.com/gnukhata/gkapp/-/issues/427) ? (for NGO, i think we have good support but i guess we have to check against old gkwebapp if something is not yet ported over) - Fix domain-agnostic issues. - Ensure data integrity. - Document the business logic in detail, regarding transactions and reports, with step-by-step actions that happen on the database level on user interaction. This is a necessary reference to test whether the application is working correctly as needed. - Add data validation. This has to be done and tested on the backend first as it helps to reduce the number of factors that can cause issues. Once the backend is stable, add frontend data validation. These are prerequisites for fixing some domain-specific issues. - Test scalability and reliability with high volume of data. - Add server-side pagination, search, filters and sort. Currently some of these are done from frontend which won't be able to handle the load as the data grow over the time. - https://gitlab.com/gnukhata/gkapp/-/issues/199 - Add keyboard shortcuts for frequently used features. - Fix installation issues across supported platforms. - Add separate installation instructions for end-users and developers. - Fix data backup and restore. (we should ignore tally integration as that is not feasible in a real sense for now) - Fix performance issues - https://pagespeed.web.dev/analysis/https-gnukhata-gitlab-io-gkapp/r6w3na1qie?form_factor=mobile - Release 8.0.0 stable version. - add opening balance, type of account to create contact [link](https://gitlab.com/gnukhata/gkapp/-/issues/208) - [multiple org bank accounts](https://gitlab.com/gnukhata/gkcore/-/issues/559) - improve accounts page which has a totally different UX than rest of application and is not helpful for new users. ## Medium-Term Plans - Introduce API versioning. - This helps to warn developers of potential breaking changes after a stable release. - Fix existing issues with `GST`, `Budget`, `Cost Center` and `Not-For-Profit` organisation support and re-release them before working on new features. - Fix issues affecting the stable version as they appear, depending on the severity. - Improve UI/UX. - Make design language consistent across the app. - Follow the `principle of least astonishment` and make the UI/UX more intuitive. - Make the app more user-friendly such that frequently needed features can be used quickly with minimal interactions. - Review the status of frontend framework (Vue) at that time. Vue.js v2 has already reached end-of-life. Decide whether to migrate to latest version of Vue or to a new framework. (if we are looking for a new framework, we should investigate one which has ootb good support for financial reports, tables, charts, dashboards) (vuejs doesn't have a lot of table filtering/sorting and searching for example) - Review the status of backend framework (Pyramid). - The development of Pyramid framework has slowed down over the time (their last major release was in March 2021 followed by two patch releases in 2023). If the slow development phase continues, without fixing any critical bugs on time, and it fails to work with the Python version that comes by default in popular distros at that time, then it's a sign that we need to check for other options. - Refactor and improve modularity and portability of gkcore. - Introduce separation of concerns by extracting framework-independent code like business logic (service layer) and utilities in to separate modules. - Remove [code smells](https://refactoring.guru/refactoring/smells) and anti-patterns if any. - These have to be done even if we're not migrating away from Pyramid framework so as to keep the code maintainable in the long run. - Migrate to new framework(s) if needed or proceed with adding desired features. All the above steps are prerequisites to start working on new features. - Refer the [Feature Enhancements](https://pad.nixnet.services/4eQ6xf0xSp2HudgXRj8zIg#Feature-Enhancements) section shared by R2 for the features to be implemented. - Package application for popular distros. - make gkapp avaialble for non-indian users [nepal for example](https://gitlab.com/gnukhata/gkapp/-/issues/275) - [multiple modes of payment](https://gitlab.com/gnukhata/gkapp/-/issues/143) - categories support ported over from old gkwebapp [old issue] (https://gitlab.com/gnukhata/gkwebapp/-/issues/1345) currently we only have skeleton migration, it should be supported on add and edit items page for example. - [port over projects from old gkwebapp](https://gitlab.com/gnukhata/gkapp/-/issues/254) this one is a migration from old code, don't think it should need a rewrite - [credit period](https://gitlab.com/gnukhata/gkcore/-/issues/471) ## Long-Term Plans - Refer the [Future Feature Enhancements](https://pad.nixnet.services/4eQ6xf0xSp2HudgXRj8zIg#Future-Feature-Enhancements) section shared by R2. - AI integration - [Need further discussions] - support cloning/duplicate invoices - allow importing invoices/vouchers/items/contacts/bank entries/ - allow quick entry mode - POS support - payment gateway/payment links --- ## General Suggestions ### Adhere to Coding Standards - Adopt a style guide for both frontend and backend. - Use git pre-commit hooks to enforce style guide with the help of linters and formatters. - Currently this is done at the IDE level, it can be autoamted on commits using git hooks so that it'll available for all developers independent of the IDE. - Follow `Clean Code` naming conventions. - https://thecoderoad.blog/2020/03/29/clean-code-naming-conventions - https://nightshade7.medium.com/efficient-naming-conventions-a-guide-to-improved-code-readability-d387dff01f12 - Follow atomic commits. - https://www.aleksandrhovhannisyan.com/blog/atomic-git-commits/ - Follow conventional commits. - https://www.conventionalcommits.org/en/v1.0.0/ ### Follow Issue-Based GitLab Workflow - A sample workflow is mentioned here: - https://pad.nixnet.services/qWeqhoWORWOgR8xGd0hSPA ### Adopt a Git Branching Strategy - A sample branching strategy is documented here: - https://pad.nixnet.services/dV8vILl9Tqmymfe8ilhlkQ ### Create contributing guidelines - Once finalized, document the above mentioned guidelines in `CONTRIBUTING.md` file in the repo. ### Host a dedicated website/wiki for documentation - Validate and improve the existing documentation. - https://pad.nixnet.services/rcbvb4wSSEiNtSPUbzUmwQ --- ## Community Revival - Rebuild an active community of users, contributors and enthusiasts of GNUKhata. - Introduce GNUKhatas to local SMBs and college students (we can conduct both online and offline events like workshops, demos, hackathons, localization sessions, etc.). - Collaborate with existing free software communities. - Participate in free software events and promote GNUKhata. - Create and maintain a public forum to provide technical support. - Create and manage accounts on social networks powered by free software (eg. mastodon, lemmy). - Announcing releases on the official website, social media, mailing lists and forums.