Skip to content

EN_workflow

Jump to bottom
Christian edited this page May 15, 2019 · 7 revisions

Definition of done and basic workflow

Definition of done (DoD)

  • Feature/Fix is tested locally by the developer.
  • Feature/Fix is tested in a dedicated server environment.
  • Feature/Fix is tested, if necessary, with common/affecting mods (e.g. ACE 3)
  • Feature/Fix passed CircleCI.
  • Feature/Fix was reviewed by at least two developers who didn't work on it.
  • All possible merge conflicts are resolved.

Basic Workflow

We orientate in general on the Scrum workflow for our project. Due to the fact that it's a hobby project in our spare time, we bend the basic conditions a little bit depending on our "normal life schedule". This includes extending sprint durations and also remove planned user stories from an ongoing sprint which would be a no-go in "normal Scrum".

Our general sprint duration is 23 days, starting on a friday and ending on a sunday. Between the sprints we take a 5 day break for recreation and setting up user stories for the next sprint, so basically a 5 day sprint planning and retrospective phase. This begins on monday and ends on friday with the next sprint start.

After each sprint we provide the usual so called "Potentially Shippable Product Increment", which we call "Sprint Result Pre-Release" in terms of Liberation, on GitHub and the Steam Workshop. We also provide a Dev Blog for the finished sprint on GitHub.

Lifetime of an Issue

  • Creation of an Issue from users or from the team as User Story
    • Pipeline: New Issue
    • ToDo:
      • Estimate the workload via Story Points. This should ideally be done by all team members and not by only one member. That way we can ensure that also every team member really knows what the user story is all about and what's exactly to do. If the workload would be too much for the current description of that issue, it should be split in more issues with smaller workloads. Basically we won't go above 11 story points.
      • Identify if it's necessary to add some sub-tasks to the user story via a checklist in the issue description.
      • As soon as the above is finished, the issue will be moved from "new issue" to "backlog" and get the appropriate label (transparency for people without ZenHub extension).
  • Issue is estimated and possibly needed sensible sub-tasks are generated
    • Pipeline: Backlog
    • ToDo:
      • The issue/user story is ready to be assigned to a sprint. During the sprint planning it'll get assigned to the sprint milestone (sprints are created in ZenHub/GitHub with the milestones feature)
  • The sprint of which the issue is part from is started
    • Pipeline: Backlog with assigned sprint/milestone
    • ToDo:
      • As soon as the sprint is started, we don't change the content of that sprint anymore. Only under rare circumstances we could add an issue from the backlog to the sprint. Of course it can happen due to the fact that this is still a hobby project, that we'll remove an issue from the sprint during the running sprint. This shouldn't happen in general, but could be possible to lack of time or other more important private circumstances.
      • A "Sprint Branch" will be created upon the start like v0.97S10.
      • You can turn on the filter of the ZenHub board to just show issues from the current milestone/sprint. If you want to start to work on an issue (each team member is free to select a task if it's not yet assigned/in progress) you move the issue to the "In Progress" pipeline, assign yourself to the issue, change the label from "backlog" to "In Progress".
  • Work on the issue has begun
    • Pipeline: In Progress with assigned team member
    • ToDo:
      • Create a new work branch from the current sprint branch named like "v0.97S10-[issue ID #]"
      • All work on the issue should happen in the new branch. You can already open a pull request as soon as you like as a "draft pull request".
      • During this phase it should be ensured that the first 4 steps for the DoD are passed successfully.
      • Now the issue can be moved to the pipeline "Review/QA", if it passed the first 4 DoD steps and all possible merge conflicts are resolved. Change the label of the pull request and issue from "In Progress" to "Review/QA".
      • Request the review of the other team members. At least 2 reviews are needed to unlock the merge button.
  • Issue is ready for review
    • Pipeline: Review/QA
    • ToDo:
      • The team members start their code review in the pull request. Things to check are if:
        • everything is following the coding conventions/guidelines
        • the comments are enough to explain the code in a good and sensible way
        • the content of the user story/issue is really fulfilled with the provided solution.
      • If everything seems fine, the reviewer can approve the changes. Otherwise state comments in the changes where is something to improve and say for the review "request changes".
  • Issue passed the review
    • Pipeline: Review/QA
    • ToDo:
      • The pull request will be merged by the team member who worked on the issue.
      • The issue and PR will get the "Done" label while the "Review/QA" label will be removed.
      • The working branch will be deleted and the issue can be closed.
  • Issue is finished and closed
    • Pipeline: Closed
    • End Note:
      • A closed issue with the label "done" is really closed and shouldn't be reopened anymore. If there are bugs or something else which is caused by the solution for the issue, a new issue needs to be opened instead of reopening the old one.

Issue isn't important or needed to be done in the next time

For this we use the "Icebox" pipeline and label.

Issues in the Icebox have a lower priority to implement (concerning the current situation). Those issues could be something, that might be a nice addition in general to the mission or something, that brings a small benefit for only certain players and is therefore not "for everyone". Maybe something from the Icebox can be moved out of it to the backlog, if we haven't enough user stories for an upcoming sprint or if we're near the completion of the next version and are motivated to do some "extra work" or have a "all important things are finished, let's put something small in it, too".

In general: Issues which are in the Icebox won't be implemented in the mission. Only in really rare circumstances an issue will be moved out of it. So there is no need to really keep track of the Icebox issues.

Clone this wiki locally