...
We generally use epics to organize other issues by their systems. When creating a story or bug, you'll see a number of fields.
| Field | Content | Purpose |
|---|---|---|
| Summary | [System] Very brief summary | The system (usually the shortname of the corresponding epic) is tagged to make it easier to distinguish issues across systems. The summary should be extremely brief, probably around 4 to 10 words at most. It should describe the issue at a high-level, focusing on the impact rather than implementation. |
| Reporter | User picker - set to you by default | It's important to know who made the issue so we can request for clarification if necessary. Do not change this field. |
| Description | Detailed description of the issue, possible causes/fixes/implementations | This should be a relatively detailed description, including the purpose, possible implementations, links to documentation, and other important information. |
| Priority | Usually medium | This should reflect the urgency of the issue. Higher priority issues are blocking or have hard deadlines. Most issues are medium-level, which is the normal priority. |
| Assignee | User picker - either you or unassigned | This is the person who should be responsible for addressing the issue. If you're creating this issue for yourself, assign it to yourself. Otherwise, unless you're an electrical lead, leave it unassigned and let the system owner know. |
| Epic Link | Corresponding epic | This should be set to the epic that corresponds to the system you're working on. |
| Sprint | Pick the currently active electrical sprint or leave it blank | This is just used to keep track of how issues are progressing. If this issue is something that should be done within the next few weeks, pick the currently active electrical sprint. Otherwise, if it's something that's more of a reminder of something that needs to be done eventually, leave it blank. |
| Original Estimate | Approximate estimate of the number of days it'll take | This should be an estimate of time it'll realistically take to complete the issue. This should account for testing and reviews. We don't expect it to be extremely accurate, but it should at least reflect the workload required. |
| Team Members | Multi-user picker - leave it blank | This is just a multi-user picker if you want to track some additional people. Note that using this field will not inform those people that they have been added to this issue and is purely cosmetic. |
If a field wasn't mentioned, leave it blank.
...