-
Notifications
You must be signed in to change notification settings - Fork 34
Dev Team Guide
There are a few conventions in play on our team. For now we are keeping things simple. Stuff is likely to change as the team grows.
We have a channel. Please use it. If you have any technical difficulties or questions ask there, there are a bunch of people who can help. http://rocketchat.umuzi.org/group/tilde-dev-team If you dont have access to the channel, PM Sheena
Please choose an issue from the team board: https://github.com/Umuzi-org/Tilde/projects/2 There is a column named "Prioritised backlog. choose from here only". The highest priority tasks are at the top of that column.
When yo ustart working on an issue:
- assign it to yourself
- make sure it is always in the correct column. Move it along as you go
For now the team is small and there are too many other meetings going on. So we would like to avoid more meetings. But we also want all the info and accountability that we would get from agile meetings.
On Rocketchat there will be a message posted that just says "Sprint Plan: 2 September" or something similar. This will happen on Tuesday morning since the Education sprint plan happens on a Monday afternoon. Please respond to the message ASAP. You can also post the "Sprint Plan" message yourself if it isn't there when you need it.
Each team member should add a response to that message saying what Tilde dev work they intend to do for the week. Please be descriptive, if you just list issue numbers it's painful for people to know what you mean. If people get into the habit of posting user-UNfriendly messages then we will need to start scheduling more meetings.
Please read each other's plans and make sure they make sense to you. Please discuss if anything seems amiss. We are a team.
On Rocketchat there will be a message that says "Standup" or something like that. Please respond with a message that describes your dev tasks ASAP. Please dont go into detail on your education tasks. Let's keep the signal to noise ratio healthy. Please answer the following questions each day:
- What did you do since last standup
- What do you plan to do before the next standup
- Do you see any problems? Do you have any problems?
eg:
1. made a PR for #123 - user profile page skeleton.
Reviewed Tshepos PR for #154 - Review response modal
Had a PP session with Mpho to help with onboarding
2. No dev. Working on education tasks
3. I think there is a dependency between 154 (review response modal) and 172 (something else). Tshepo and Greg should chat and make sure they aren't double-devving
Please make sure you are familiar with the feature branching stratergy. The overall stratergy we are using is actually a bit more complicated but you only really need to know about feature branching to get by.
Generally you'll want to do feature branching using develop as the base branch. Eg:
git checkout develop
git pull
git checkout -b "issue-123-build-profile-page"
When you make a PR then you will try to merge back into develop.
From time to time we will use a different base branch, in this case it will be specified on the issue. Eg:
git checkout something_else
git pull
git checkout -b "build-profile-page/123"
In this case your PR will attempt to merge into the something_else branch.
We haven't always been strict about naming conventions on our git branches and PRs but that needs to change because the team is increasing in size.
PRs can be named like this: #[Ticket_ID] PR description Eg: #123 improved review emojis
Branches can be named like this: short-description/issue-number eg: git checkout -b oauth-migration/244