Linux files on demand: show status in file browser

[tbsbdr]

Description

User Stories

• As a user I want to know what status a file has, so that I can work with it

Value

• visibility of system status

Acceptance Criteria

• always show the status of the file
  • Always available (pinned)
  • Downloaded
  • Online Only
  • Error
  • Warning

@db-ot could you please modernize/create the needed icons https://github.com/opencloud-eu/desktop-shell-integration-resources/tree/main/128x128

• svg
• different sizes ( x file overlay

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
  • No sonar cloud issues
• Configuration changes
  • The next branch of the OpenCloud charts is compatible

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.