Start of your working day #

All tasks are on the github kanban board. You can also check previous sprints on plan for the coming sprints by changing sprint name in filter. You can filter your tasks by clicking on your icon at any task.

Please use progress_developers channel to update on which tasks you are planing to work on TODAY.

Working process #

1. Test your change locally
2. Create a Draft PR
3. Convert to a real PR
4. Move to kanban board/make sure PR is on kanban board
5. Add your branch to the corresponding ticket (“Development” field)
6. Make sure linter checks and tests have successfully passed for you PR
7. Address any issues with PR; if the ticket is blocked - add the blocking/responsible person to the ticket (“Assignee” field) and move the corresponding ticket to “Blocked” on the kanban board
8. Assign a reviewer to your PR (“Reviewers” field), move the corresponding ticket to “Code Review” on the kanban board
9. If the review is successful, flatten and merge (check in with your QA - Iryna (Investment team) or Volodymyr (Marketing team)
10. Check e2e tests, inform the team in case of any failures
11. Move the corresponding ticket to “QA Review in Progress” on the kanban board
12. The assigned QA will move PR to “Done” if the testing is successful

Please don’t forget:

• move your tickets on kanban board from to do to in progress column
• or from in progress to review in progress + add check label
• monitor if your tasks have been moved back to in progress (in case if you missed notification)

Take task from list you got from slack progress report channel or from kanban board. Carefully read ticket description, you do need to understand task from business perspective. If you feel you don’t have enough description or you don’t understand the task completely don’t hesitate to ask questions and let ticket owner know why you are blocked/whats you haven’t understand yet.

Update your local branch and create new branch using contribution guideline

Local testing #

When you finish your task, its crucial for you to check yourself. It will be faster and less painful for everyone if you will test your changes before doing PR. If you need help to set up whole infrastructure please let us know, we will help you.

Open PR request #

• Take a look on our release flow and no breaking changes policy
• Make sure you run tests (if they exists, usually make.sh test)
• Make sure you run lint checks (usually make.sh check)
• if all tests are passed, make final commit (or update existing commit) with commit message guideline
• squash and push your changes to your branch
• open PR at github, don’t forget to:
• • assign reviews
• • put yourself to assignees
• • add PR on development kanban board
• • add correct milestone
• • add labels if needed (optional)

Collaboration with teammates #

Repo names and responsible engineers.

Responsibilities:

• make sure you don’t have open PRs for more that couple days
• check/review PRs in a couple hours
• check and apply security PRs from security bots
• merge updates from stage to production

Mering PR #

Requirements for merging PR:

• all questions from team mates are resolved
• all conflicts are resolved
• all build check are passed

Nice to have (very nice to have)

• make sure you rebased your branch with dev before merging
• squash your history into one commit
• use squash & merge for dev branch
• use only merge for staging and production environment