[ledgersmb-devel] LedgerSMB community overview 2019

Hi, As the year-end approaches, it's time to provide an overview of what our community has achieved over the past year. At the beginning of the year, in last year's overview, the hope was expressed that the MC branch would be merged this year and that the 1.7 release cycle would turn out shorter again than the previous ones. == Community interest == The hits on our web site show a stable line month-on-month, although lower than last year. Consensus has it that traditional websites get lower numbers of hits than several years ago because of mobile and other (social) media. Hits seem to be pretty stable now. During the year, we've seen the number of Watchers, Stars and Forks on GitHub slowly but steadily increase. Traffic seems to be slightly up on our mailing lists, the users mailing list especially, with questions from new users installing and configuring LedgerSMB. The number of active developers is a bit lower, than last year; some hang around in our chat channel to help evaluate changes submitted by active members, though. All in all, the community seems to be on-boarding potential and new users and experiencing its regular in- and outflux of developers. == Releases == Last year we hoped to release 1.7 in the first half of the year. With the release of 1.6.0 on June 10 2018, we hoped to be able to start doing yearly releases. We also expressed the hope to land the MC branch on master. We ended up releasing 1.7 on October 4 2019, a little less than 16 months after 1.6.0. We did reduce the release cycle, but not by as much as we'd hoped. In part, the longer-than-hoped-for release cycle was caused by the fact that the MC branch did land on master, which warranted additional test effort, especially of the database migration scripts against real-world data. All in all we released around the same number of times as we did in 2018: * 10 stable releases: 1.7.0 - 1.7.6 & 1.6.10 - 1.6.12 * 11 old-stable releases: 1.6.13 - 1.6.17 & 1.5.25 -1.5.30 == Packaging and installation == In preparation for the 1.7 release, some work was done on the Docker images to run on Debian Buster. However, we found that Buster deprecated the ssmtp package which we depended on and it was too late in our own release cycle to do any fundamental changes to our e-mail functionality. We ended up going back to Stretch to run 1.7 on. Further work will be required to make sure 1.8 offers similar functionality without depending on ssmtp. The Debian ledgersmb package for 1.6 transitioned to Buster. Which is great as Debian Stable now has a non-deprecated version in its package repository. Last week we found that the package unfortunately misses a few files. We hope to fix that really soon. == Development progress == Over the course of 2019, 40 issues were created, 19 of which remain open at this point. All 19 issues were created by the development team, many in the process of doing code reviews or development work. A total of 73 issues were closed in 2019, including issues created in prior years. From these numbers, we can see that now that the MC branch has been merged, there's time or room to work on issues not directly related to MC or the creation of infrastructure to support MC development. The development work spun off 304 pull requests on the LedgerSMB repository. The number of pull requests is a lot lower than in 2018 when the number was around 480. The 304 PRs triggered nearly 1000 builds on Travis CI. During the first half of the year, we developed large numbers of new tests, push coverage up from 34% in last year's report to 41% now. Although 41% still is by far not enough, we started to run into the limits of what Travis CI was able to provide us (which is: maximum of 50 minutes of run-time on each test job). We evaluated a number of other CI providers, including the option to run our own. We ended up going for CircleCI; to their service we moved our longest running test job (we left the others at TravisCI), because they account the total time to be spent by a project differently. Areas that we're currently spending time on, include: * Selection of a new translation engine which supports more than 2 plural forms * Building on last year's separation between printed-document templates and UI templates, moving more printed documents into the framework * Gradual polishing of 1.7 through regular fixes of issues left to be polished after 1.7.0 release * Polishing of the technical implementation and user experience of payments and receipts The 334 issues that are open today summarize into these statistics: * 71 are marked bite-sized; this means they should be good places to start for new-comers * 188 are marked as desirable enhancements * 43 are marked as being in our queue of design work (Note that an issue may fall into more than one category.) == New functionality and improvements == A long-standing desire was to remove code duplication in templates to generate output tables. This year, we managed to move all code using the old report table infrastructure to the new code base. While doing so, we also cleaned up fixed assets code. Another topic that we spent time on, is research on how other PostgreSQL based projects structure their authentication. One project that drew our attention was Graphile (https://www.graphile.org/). From their approach, we've come up with an approach that may help us simplify setting up the database connections and managing / reporting password expiry on login. == Looking forward to 2020 == In 2020, we'll likely release 1.8 in the second half of the year. I personally hope that we can shorten the release cycle to get to yearly releases around the middle of the year. With that schedule it'll leave a number of patch releases until the end of the year, allowing users to migrate to a stable release after closing their books at the end of the year (if they didn't migrate earlier already). For 2020, I'm also hoping that the idea to work concentrate on specific topics, moving from topic to topic to improve the software, leads to an attractive 1.8 release. The various topics have been grouped into GitHub "projects" (https://github.com/ledgersmb/LedgerSMB/projects). Topics that have my personal priority are "Payment/payment_link support for all parts of the code base" and "Polish cash and payments". The first is rather technical in nature and a prerequisite to address the issues collected into the second. For 2020, I'm hoping to complete at least one, but hopefully both projects. For 2020, I'm hoping for 1 or 2 new contributors (not necessarily developers; translators, testers, documenters or UI artists are all greatly appreciated!). If you want to contribute, but don't know where to start, please contact me. Leaves me only to wish everybody in our community - and their loved ones - a very good, healthy and prosperous 2020! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.