NB: This is just a collection of ideas about our definition of done, and other general workflows, that are also part of the definition, because the should be checked as well... Please update as you prefer!

Path of a Workload

1. The product owner (PO) or developer (DV) creates a User Story (US) and puts it into the Geobank Backlog
   • PO: Short description in the form As a ___ I want to ___ because ___
   • PO: US with high priority must be more detailed and split into workloads doable in one sprint
     • if the split is not clear, ask developers and define splits before the team meeting
     • Details: Acceptance tests written by the product owner
2. Backlog must be sorted according to priorities (highest on top)
3. Developers (DV) put US into the "Sprint To Do" column
   • DV Optional: create additional Tasks associated to USs
   • DV Move tasks along the Kanban and the US at last
4. "In progress" means that DV (one or more) work on a single US or Task
   • Meeting with PO to clarify tasks (add tasks or details to tasks created in point 3)
   • Additional work (optional or minimal, if acceptable):
     • write tests
     • continuous delivery
     • documentation (see below)
5. Transition from "In Progress" to "Testing"
   • Create or check Acceptance Tests as a bullet list (written by PO and DV)
   • Inform wanted testers on the user story's comments
   • Describe how to test (if more stakeholder involved, describe which acceptance test is for whom?)
   • If documentation, unit tests, or other things have been skipped by contract, write that down
   • DV deploys the product on the test-server
6. Testing
   • DV tests code, comments, technical documentation
   • PO tests documentation, black-box, accepts product (normally not, but we are too few DV)
7. Done 4 Sprint
   • if tests OK, PO accepts, product running on test-servers
   • move to Done 4 Production
8. Done 4 Production
   • DV deploys it to production server

Documentation

Documentation means...

• a README.md in markdown for each repository as short as possible, but with enough information to be useful for new developers. We should keep in mind, that the repository could be made public in near future.
• if necessary a doc folder with additional material, such as PDF documents, drawings, etc.
• if tutorials and other more complex documents with hypertext links are necessary, we should use the WIKI functionality of Github

Sections to be added to the README.md

• Title
• Short description what this repository contains (Why does it exist?)
• define how to get started (from zero to a running instance)
• how to build things
• how to setup a simple test (locally if possible)
• some links to existing documentation within our Github repository, or external resources.

When do we write documentation?

• if simple enough, just write a title and a short sentence to communicate what this repository is about
• if complex + existent, update it, check links (if you have time), add missing sections (see above)
• if complex + non-existent, write a new one with all relevant sections (see above)

We should create a template to be filled for each new project.

For developers

Transition from In Progress to Testing

• inform wanted testers on the user story's comments

• describe how to test (if more stakeholder involved, describe what acceptance test is for whom?)

• check acceptance tests (bullet-list in your comments defined by the developer and the product owner, or other involved people)

• Check Acceptance Tests of the User Story itself (Should be defined already, put by the developer or product owner during the sprint)

Example of Acceptance Tests:

• Unit tests updated, must run with the new code <-- for developers
• The webpage should show a red button if you click on the blue one <-- for other testers
• ...

Code comments

• Write them for complex parts only
• Write what + why, not how

Github

• .gitignore should be updated
• issue template
• how to contribute
• license
• CI
• Security
• development and master branch

For Testers

• try to test as early as possible if you see something in Testing, not later than Thursday, re-test on Friday
• try to reproduce and test without the help of the original author
• if possible, the product is well documented or at-best self-explanatory
• if not, we should improve documentation

Deployment

Where do we put the final documentation on how to access the final product?