You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/github/project-management.md
+25-25Lines changed: 25 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,71 +22,71 @@ These guidelines are meant to ensure that issues are created in a standardized f
22
22
6. Milestone: Most DIF projects have Milestones which map to our project timelines. There is a search function which can help identify the correct milestone for the work being done. The Project Manager can help if you are not sure of the correct milestone.
23
23
1. Note: If a project repo does not have milestones created (for example the ODI data-infrastructure repo) then this can be left blank.
24
24
7. Due Date: Assign a due date when the work needs to be completed by, if applicable. If there is no set due date this can be left blank.
25
-
8. Status:
26
-
1. New: Default for new issues. If discussion is needed to clarify details about the issue leave it as New until that discussion happens (so it appears in the “New Status” Project Board view).
27
-
2. Backlog: If work is not planned on this within the next 2-3 sprints, set the Status to Backlog (or Blocked if the work is blocked for any reason) and do not assign it to a sprint.
28
-
3. TODO: If the issue is assigned to a sprint but work has not started yet, set the status as TODO.
29
-
4. In Progress: Choose this status once work has started on the issue.
30
-
5. Needs Review: Indicates that review is needed from other team members.
31
-
6. Blocked: Choose this if work on the issue cannot move forward due to something outside of your team’s control, for example if waiting on another team to respond to a question.
32
-
7. Paused:
33
-
8. Done: Indicates the issue is completed. This status is set automatically when the issue is closed, you do not need to select it.
34
-
1. Note: The correct way to close an issue is to scroll to the bottom of the issue page and choose “Close Issue”.
25
+
8. Status: Assign a status on the current state of the issue. See below for Status defintions.
35
26
4. Pull Requests: Add phrase “[Fixes/Closes/Resolves] #xx” to ensure the referenced issue gets closed when PR is merged
36
27
1. Review “Open PRs” tab during stand up
37
28
5. Make sure to fully close an issue when completed.
38
29
39
30
31
+
## Size Definitions
40
32
41
-
42
-
#Appendix: Github Issue Sizing and Priority Definitions
43
-
44
-
##Sizing
45
-
46
-
Tiny
33
+
**Tiny**
47
34
48
35
- Easy task, something that can be completed in about an hour May not require issue creation but could use as a reminder to complete the task later in the sprint (if something takes less than 30 minutes, no need for an issue).
49
36
- Example: Sending a follow-up email
50
37
51
-
Small
38
+
**Small**
52
39
53
40
- A task that can be completed in one day
54
41
55
-
Medium
42
+
**Medium**
56
43
57
44
- A task that can be completed in about a week
58
45
- More complex but still straightforward to complete
59
46
60
-
Large
47
+
**Large**
61
48
62
49
- A task that can be completed in 2 or more weeks
63
50
- Increased complexity, may require slower manual work or unknowns that require research and discovery
64
51
65
-
X-Large
52
+
**X-Large**
66
53
67
54
- Tasks that may take a month or longer to complete
68
55
- Consider breaking up into sub-tasks if appropriate, or create a meta-issue when there are dependencies
69
56
- Example: Building a data model
70
57
71
-
##Priority
72
-
Urgent
58
+
## Priority Definitions
59
+
60
+
**Urgent**
73
61
74
62
- Top priority / emergency
75
63
- Putting everything else on backburner
76
64
- Aiming for completion ASAP
77
65
- Due Date assigned must be kept
78
66
79
-
High
67
+
**High**
80
68
81
69
- Important, goal is to complete this sprint
82
70
- Due Date should be kept as much as possible
83
71
84
-
Medium
72
+
**Medium**
85
73
86
74
- Less important than High, aim to complete within 2-4 sprints
87
75
- Due Date is a target but OK to push back
88
76
89
-
Low
77
+
**Low**
90
78
91
79
- Work on as time allows, may leave in backlog
92
80
- Due Date not required or kept as a reminder to check back and move out of backlog by a certain point in time
81
+
82
+
## Status Definitions
83
+
84
+
1.**New**: Default for new issues. If discussion is needed to clarify details about the issue leave it as New until that discussion happens (so it appears in the “New Status” Project Board view).
85
+
2.**Backlog**: If work is not planned on this within the next 2-3 sprints, set the Status to Backlog (or Blocked if the work is blocked for any reason) and do not assign it to a sprint.
86
+
3.**TODO**: If the issue is assigned to a sprint but work has not started yet, set the status as TODO.
87
+
4.**In Progress**: Choose this status once work has started on the issue.
88
+
5.**Needs Review**: Indicates that review is needed from other team members.
89
+
6.**Blocked**: Choose this if work on the issue cannot move forward due to something outside of your team’s control, for example if waiting on another team to respond to a question.
90
+
7.**Paused**:
91
+
8.**Done**: Indicates the issue is completed. This status is set automatically when the issue is closed, you do not need to select it.
92
+
1. Note: The correct way to close an issue is to scroll to the bottom of the issue page and choose “Close Issue”.
0 commit comments