-
Notifications
You must be signed in to change notification settings - Fork 157
How We Work
Sung-Jae Lee edited this page Apr 20, 2020
·
1 revision
Revision 1 (2019 June)
- This document describes how people in ONE project work.
- Our only one rule is everybody doing one's best to collaborate efficiently and effectively.
- In this sense, the purpose of this document is to share our development culture. Hopefully this document helps readers to understand our work style and cooperate with us.
- We NEVER try to argue that our work style is right one. We just found that this work style has been fairly fit to us, and we want others to understand our culture.
- Expected audiences may include
- New developers in ONE project.
- Existing member of ONE project.
- Monthly milestone is posted as an issue, about every end of the month. [(example: milestone)](to be linked)
- Sometimes, pre-discussion is posted. [(example: pre-discussion)](to be linked)
- We encourage anyone to leave comments for milestone.
- Please keep an eye on milestone to see what we, as a team, set our direction to go.
- (Don't confuse this with 'milestone' feature of github, which we use for sprint)
- We make our backlog(todo lists) together on issue board.
- Everyone can make tasks on issue board. At this time, they have not been assigned to anyone yet.
- We choose our own tasks by ourselves.
- Everyone can decide his/her own tasks by self-assigning. It can be the creation of a new issue or a selection from an already stacked backlog. By this action, he/she is now the owner of the issue.
- You don't need to assign an issue to yourself just because you create it.
- You should avoid assigning an issue to yourself an issue that you can not afford. It makes the whole process delayed.
- Choosing a task, you should consider following:
- It is highly recommended that task subject is related to and a small partition of monthly milestone.
- If you think you need some discussion before opening an issue, create an issue with
type/discussionlabel. - Else if you wants to create a task not very related to monthly milestone, you might open a new issue with reasonable intention.
- If you are not sure about how to choose what to do, have a look on issues with
help wantedlabel, or ask your peers.
- When you create an issue, it is highly recommended to add link to related issues, when it has. [(example)](to be linked)
- When you create an issue, it is highly recommended to add related labels. All labels are well and simply documented in each description.
- One sprint is normally one week long.
- We use github 'milestone' feature to collect all task issues in sprint. [(example: sprint)](to be linked), (list of sprints)
- You should post a task issue stating what you will do in following sprint before the end of the first day of each sprint, normally Monday.
- Mark appropriate sprint in each task issue.
- If you want to work on the task yourself, assign it to you. Otherwise, mark it
help wantedlabel, so that others can work on the task if they want so. (should be revised) - Until the last day of sprint, normally Friday, all tasks would be closed.
- For unplanned or partially done task, please check out each section below.
- When unplanned work happens during sprint, there are two cases:
- If the unplanned work is not that urgent and can be postponed to future sprint, accumulate this issue board as a backlog.
- Else, i.e. when the unplanned work should be done in current sprint, for example the work is a prerequisite for the task in current sprint, create task issue and label it as
sprint/extraand add it to the current sprint immediately. [(example)](to be linked)
- If
sprint/extratask is finished within a sprint, close it as a normal task.
- If a task is not finished within a sprint,
- Edit or comment on task issue what partial job you have done in the whole task.
- Create remaining task as new task issue for the next sprint
- Close existing issue leaving a comment saying like 'Closed as rest of task moved to #0000'.
- [How to create a Pull Request](to be linked)
- It is recommended to assign reviewers who have interest in reviewing your PR, for example someone who knows about the PR very well.
- In case that you have no idea who would be the right guys, you may leave it blank.
- PR should be small enough.
- It is not a good idea to run a very large unit of work in a private repository. If you want to change large portion of the repository, in most cases you can and should divide it into several smaller PRs.
- This is mainly to reduce reviewers' workload and build a development log as specific as possible.
- We follow CI/CD workflow. At the same time, we try to share our works in one main repo, not on each private repo. So if you plan to make a large modification of repo, following method would be a good practice.
- Create and PR the entire structure without body part. So each function can have only a name, a
/* TODO */, and a dummy return value. That means, a build break does not occur, and an error does not occur due to unnecessarily calling this code at execution time. - Implement each function and PR to the minimum unit required. It is better to include a unit test for the function and a descriptive document, if needed.
- Once all the implementation of the entire structure is complete, you can then PR the code which call it from the main module.
- Create and PR the entire structure without body part. So each function can have only a name, a
- Merger can merge PR only if there are 1 or more approvals without any pending reviews or rejections. Just commented ones are ignored.
- When making PR, it is highly recommended to add related issue link, if it is the case.
- Reviewers can approve, reject or just leave comments
- Approval means always +1, there is nothing like +0.5, +0.2, ...
- It is highly recommended to regularly check out issues with
type/announcementlabel, and monthly milestone issue. - It is very good idea to leave a related issue link or outer link to the issue, comments, PRs, basically everywhere.
- Once you have a question, search for issue and PR board first. Sometimes you are not the first one who had a bug or question.
- When you cannot find out solution in issue and PR board, you are welcomed to ask on issue board or on chat.
- It is highly recommended to add a appropriate reason after you close an issue.
Anyone who participates on ONE projects are welcomed to edit this content, once it has been discussed and agreed enough throughout all team members.
Original [reviewed here](to be linked)