linux files on demand - publish beta: Make current status installable as binary #781
Description
Description
User Stories
- As a user I want to install the current dev status of the Linux VFS so that I can try it.
Value
- make the current dev status available
Acceptance Criteria
- publish binary as beta-appimage
- the appimage can be installed by the user
- Greenfield: if the user creates a greenfield new sync: all files are virtual
- Existing: if the user has existing synced files, these files are hydrated and have no special pin state
- new files are virtual
implementation details
- cmake install target for openvfs
- move git to opencloud repo
- make socket comunication more robust
- mount fuse layer to sync folder automatically
- unmount when application shuts down
- app-image packaging
Definition of ready
- Everybody needs to understand the value written in the user story
- Acceptance criteria have to be defined
- All dependencies of the user story need to be identified
- Feature should be seen from an end user perspective
- Story has to be estimated
- Story points need to be less than 20
Definition of done
- Functional requirements
- Functionality described in the user story works
- Acceptance criteria are fulfilled
- Quality
- Code review happened
- CI is green (that includes new and existing automated tests)
- Critical code received unit tests by the developer
- Non-functional requirements
Writing Tips
User Story
INVEST Criteria for User Stories
-
Independent
Should be self-contained in a way that allows being released without depending on one another. -
Negotiable
Only capture the essence of the user's need, leaving room for conversation. A user story should not be written like a contract. -
Valuable
Delivers value to the end user. -
Estimable
User stories must be estimated so they can be properly prioritized and fit into sprints. -
Small
A user story is a small chunk of work that allows it to be completed in a short period of time. -
Testable
A user story has to be confirmed via pre-written acceptance criteria.
Value
Examples:
- Save time
- Reduce risk
- Make it accessible for anyone
Acceptance Criteria
What Acceptance Criteria are for
Acceptance Criteria answer one question only:
How do we know this story is done?
Not how it is implemented. Not what might be nice. Not future hypotheticals.
Tie every AC to user value
Each criterion must protect or enable the user benefit.
Bad
- API returns 200 OK
Good
- User sees a confirmation that the action succeeded
If the user would not notice a failure, question why the AC exists.
Use observable outcomes
ACs must be verifiable by anyone, not just engineers.
Bad
- System processes data efficiently
Good
- Results are shown within 2 seconds after submission
If you cannot test it without reading code, it is trash.
Write from the user’s perspective
Describe what the user can do or see, not internal behavior.
Bad
- Data is stored in the new table
Good
- User can see previously saved entries after reload
Keep ACs binary
Each AC should be clearly pass or fail.
Bad
- Works well on mobile
Good
- User can complete the flow on a mobile device without horizontal scrolling
If there is room for interpretation, it will be abused.
Cover the happy path first
Do not drown the story in edge cases.
Start with:
- Core flow
- Primary user goal
Add edge cases only if they:
- Prevent real harm
- Block release
- Create user-visible failure
Avoid solutioning
ACs define what, not how.
Bad
- Button is implemented using component X
Good
- User can submit the form using a visible primary action
If you lock implementation, you kill collaboration.
Use Given / When / Then where helpful
Optional, but useful for clarity.
Example
- Given the user is logged in
- When they submit the form
- Then they see a success message and the data is saved
If it adds noise, skip it.
Litmus test
A good set of ACs allows:
- A developer to build it
- A tester to verify it
- A product manager to accept or reject it
Without further clarification.
If not, rewrite.