Page tree
Skip to end of metadata
Go to start of metadata

Definition of Done (preversion) to be used in A+ development


https://www.leadingagile.com/wp-content/uploads/2017/02/definition-done_720.jpg

Writing the Github issue

The issue should include

  • the user story/ description
    • gives reason for why the feature needs to be implemented (can be short, if the new feature is e.g. an additional check box)
    • to be written with such precision (unambiguously - yksikäsitteisesti) that the developer (e.g. a summer intern) understands what the need is
  • teacher requesting for the feature, and the course(s) in need for the issue
  • acceptance criteria
    • written by / agreed on with the teacher requesting for the feature
  • reviewer of code 

Before the issue can be scheduled and allocated

  • Product Owner accepts the User Story
  • Product Owner or lead developer accepts the acceptance criteria
  • Reviewer of code is agreed on at issue allocation

Before the issue can be closed, i.e. it is Done

  • Unit tests passed
  • Code reviewed
    • by reviewer (agreed on at issue allocation)
    • discussion possible in the GitHub pull request
    • data security, usability, ethical issues (etc general?) will be assessed as part of the code review
    • coding style guide: needs to be added in the summer intern onboarding material : Link to the basics + our add-ons. Editor recommendations → Jaakko will do, ready at the end of May.
  • Acceptance criteria met
    • according to what is written in the issue
    • acceptance testing and feedback by the teacher requesting the feature
  • Functional tests passed
    • A+ has only a few old basic Selenium tests. We could create more, but until then we rely more on manual testing. The technical instructor must support the developer in understanding how widely the new code changes affect the system so that the developer knows what needs to be tested, even outside the boundaries of the new feature. The instructor/reviewer should also test the key features manually.
  • Non-functional requirements met
    • included in code review
    • should we focus more on these in the design?
    • to be included in the coding style guide
  • No labels

5 Comments

  1. Should the git pull request guidelines be given on this page or the summer intern orientation/onboarding page? People might be looking at this page every time they are submitting a new pull request.

    1. I think this information could be added to this project you created https://github.com/apluslms/.github

      1. I don't think we should copy long instructions to the pull request template since developers would have to delete the text manually when they open a new pull request. Now that I think of it, does github.com have some separate template for instructions that are not copied to the pull request description? If yes, we could use that.

        1. I was thinking more about the supported files in general.  Maybe having a DoD.md file could fit the purpose of this repository.

          1. I don't see DoD.md in the Github docs you linked, so I guess Github does not recognize that file in any special way. CONTRIBUTING.md should have some special Github support and maybe that is suitable for pull request guidelines.