K2 doesn’t begin with HTML, it begins with the way of working. In this course the Kladde becomes a web application with pages, an API, a database and a sign-in. You no longer work on it alone: every change is an issue with acceptance criteria and a pull request with tests that a second person has read. From now on that’s written in the Kladde’s house rules. So that this holds from the very first web step, this module sets up the way of working first:

Lesson What you build
2.10.1 Issues and definition of done the plan for K2: issues, milestones, a board, docs/definition-of-done.md
2.10.2 Rules in the repository a main branch that only accepts reviewed pull requests
2.10.3 Reviews that help a checklist for reviews, practiced on someone else’s pull request
2.10.4 SOLID in everyday work a core that can handle a second interface

In this lesson you plan. At the end, all of K2’s features are issues in your repository, ordered by milestone and visible on a board, and the definition of done is a file of its own in the repository.

What you bring from K1

In K1’s final project (lesson 1.10.1) you already planned with issues:

  • An issue has a title, a purpose and acceptance criteria, often with a section Not in this issue.
  • The template .github/ISSUE_TEMPLATE/feature.md gives those parts.
  • The definition of done is a checklist in the pull request template.
  • Closes #34 in a pull request’s description closes the issue when it’s merged.
  • The milestone Version 1 showed how far along the Kladde was.

All of that stays. K2 adds three things. A feature now reaches through several layers: a page, an API, a database. A second person reads every issue and every pull request, and they can only check what’s written down clearly. And the plan covers 360 hours instead of twenty; without an overview you lose the thread in it.