• 0 Posts
  • 14 Comments
Joined 17 days ago
cake
Cake day: January 2nd, 2025

help-circle
  • Documentation has been mentioned already, what I’d add to that is planning.

    Start with a list of high-level objectives, as in “Need a way to save notes, ideas, documents, between multiple systems, including mobile devices”.

    Then break that down to high-level requirements such as “Implement Joplin, and a sync solution”.

    Those high-level requirements then spawn system requirements, such as Joplin needs X disk space, user accounts, etc.

    Each of those branches out to technical requirements, which are single-line, single-task descriptions (you can skip this, it’s a nice-to-have):

    “Create folder Joplin on server A”

    “Set folder permissions XYZ on Joplin folder”

    Think of it all as a tree, starting from your objectives. If you document it like this first, you won’t go doing something as you build that you won’t remember why you’re doing it, or make decisions on the fly that conflict with other objectives.














  • Very good point about Agile.

    As an end-user (that is, the IT staff that will be deploying/managing things), I prefer less-frequent releases. I’d love to see 1 or 2 releases a year for all software (pipe dream, I know). Once you have a handful of packages, you end up with constant change to manage.

    I suspect what we end up with is early adopters embracing the frequent releases, and providing feedback/error reporting, while people like me benefit from them while choosing to upgrade less frequently.

    There are about 3 apps that I’m a beta tester for, so even I’m part of that early-adopter group.