From 3cd6e45bd72d3ab6d39d3c7df9effc49ca33d09b Mon Sep 17 00:00:00 2001 From: Stefan Paletta Date: Sat, 14 Apr 2018 00:28:16 +0200 Subject: [PATCH 1/8] Handle *.png as binary in .gitattributes --- .gitattributes | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.gitattributes b/.gitattributes index 6cd5ff10c..307643006 100644 --- a/.gitattributes +++ b/.gitattributes @@ -1,3 +1,4 @@ # Enforce LF endings on Windows. This is necessary # in order for the Linux docker container on Windows to work. -* text eol=lf \ No newline at end of file +* text eol=lf +*.png binary From 3f670fd0822ba9ad0f6b3c459b946a4c8cd8bf02 Mon Sep 17 00:00:00 2001 From: v-jigen <37125824+v-jigen@users.noreply.github.com> Date: Thu, 3 May 2018 11:34:53 -0700 Subject: [PATCH 2/8] Adding GitHub Migration Process --- github_migration_process.md | 222 ++++++++++++++++++++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 github_migration_process.md diff --git a/github_migration_process.md b/github_migration_process.md new file mode 100644 index 000000000..59c5864e6 --- /dev/null +++ b/github_migration_process.md @@ -0,0 +1,222 @@ +Proposed labels by section on GitHub +==================================== +> +Assignees +--------------------------------------------------------------- + +> No labels for this section - just use the alias of the individuals owning the issue. MS alias showing is preferred. + +Labels +------------------------------------------------------------ + +> It is understood that some teams will have their OWN GItHub page. Focus is on the SF page and we can build on/modify for other Team GitHub pages later once the initial model is completed. +> +>   +### Label Rules for GitHub + +- All tags and labels are lower-case and dash separated + +- All hierarchy is whack separated and no caps. +>   + +| ***State/Status*** | ***Area*** | ***Issue Type*** | ***Pri*** | +|--------------------|--------------------------|------------------|-----------------| +| investigating | area-common | question | Pri-0,(regular) | +| needs-more-info | areas-communication | enhancement | | +| understood | area-data-structures | code-defect | | +| in-design | area-developer | test-defect | | +| in-progress | area-diagnostics | doc-only | | +| external | area-documentation | | | +| release-note-na | area-engineering | | | +| release-note-req | area-federation | | | +| duplicate | area-hosting | | | +| | area-ktl | | | +| | area-linux | | | +| | area-management | | | +| | area-operations | | | +| | area-reliability | | | +| | area-security | | | +| | area-setup | | | +| | area-sfrp | | | +| | area-standaloneinstaller | | | +| | area-store | | | +| | area-test | | | +| | area-testability | | | +| | area-transport | | | +| | area-needs-triage | | | +| | area-try-service-fabric | | | +| | varea-windows-server | | | +| | | | | + +Project - NA for now +-------------------------------------------------------------------------- + +| ***xxxx*** | ***xxx*** | +|------------|-----------| +| xxx | xxx | + + +> **No labels for this area at this time.** + +Milestones +---------------------------------------------------------------- + +| ***Release (Iteration path)*** | +|-------------------------------------------------------------------------------------------| +| 6.3, 6.4, etc. (define specifically once we get a build number at end of release) + + 6.3 CU1, 6.4 CU1, etc. (define specifically once we a get build number at end of release) + + > Example 6.3.xxx.xx + > + > All work items update automatically once the milestone is updated. (= minimal effort) + + There is not a vNext or backlog release. + + > No Milestone = backlog | + +Happy Path By issue +=================== + +Path below based on current State/Phase Labels + +****Question Happy Path**** + +*Open -> triaged -> needs-more-info (optional) -> in-progress -> Closed. * + +****Bug or Documentation Happy Path**** + +*Open -> triaged -> investigating (optional) -> need-more-info (optional) -> understood (optional) -> in -progress -> Closed. * + +****Enhancement Happy Path**** + +*Open -> triaged -> investigating (optional) -> design -> in -progress -> review -> Closed. * + +> ****Questions, Defects and Doc issues**** +> +> ***'Optional' Phases will apply to issues that are immediately understood allowing them to bypass many of the phases, moving the bug right to 'in-progress'.*** + +****Enhancement Issues**** + +> ***Where at 'review' the feature is reviewed for release and obtains any special sign-off needed from feature teams (if applicable). If not done (completed or has issues), go back to investigate (if needed) or move to design or in-progress for additional work. Repeat as needed. Once the feature can pass the review process (Whatever that may be for the given feature) it moves to closed*** + +Issue Lifecycle +=============== + +Issues are reported with no labels, and no assignees. Issues then typically follow this cycle: + +1. When an issue is reported it is sent to an appropriate area using the area label + +2. If the type of issue is obvious, a type label is set + +3. If the issue is not obvious, an investigating status label is set, and assignee is set + +4. The individual assigned works on the issue, updating the issue, status and type labels + +If the assignee has found the issue does not belong to their area, they initiate a transfer by + +1. Removing the area label + +2. Removing themselves from assignee + +3. Transferring issue to new area label + +Assigning issues +================ + +> Issues should only be assigned to individuals if they are actively being worked on by that individual. Otherwise, issues remain unassigned. This way it is obvious who is responsible for the work. It is valid for no one to be responsible. + +Work Flow Process Details +========================= + +Who are all those involved with the project? +-------------------------------------------- + +Inputs will come from both **Internal** and **External** service-fabric repo contributors and community members. Here are some of the roles we'll see. + +| **Area Leads**: | Responsible for setting direction in specific areas of the project and triaging issues within their respective areas.| +|-|- +| **Committers**: | Dedicated to working on the project, may have write access.| +| **Contributors**: | Community members that make any contribution to the project, whether it’s submitting code, fixing or reporting bugs, writing docs, etc.| +| **Users:** | General users who have a need for the project.| + +> **As a measurement** we want to try and touch all new items within 48 hours. This is not exposed to the customer but is a metric for us to determine how quickly we are touching new issues. We need to ensure that feature area owners are actively triaging their issues and keeping them up to date. +> +> A defined group of individuals consisting of Area Leads or Developers will be responsible for reviewing all new items. +> +> Once a new item has arrived the defined resource for 'touching' these issues for the first time will set the label 'triage' to the issue so that it can be reviewed. +> +> Once the item is being reviewed, they will be assigned an 'Issue type' unless it requires additional investigation, then the 'investigation' label would be added to show there needs to be some additional work before routing the issue. + +Question Issues +--------------- + +> Once marked as a 'Question' the resource will assist with the issue by pointing to self-service options or provide customized help to resolve the issue. We like to have questions actively pushed out to SO and slack (once we build up the community). +>   +> ****Questions**** +> +> ***'Optional' Phases will apply to issues that are immediately understood allowing them to bypass many of the phases, moving the bug right to 'in-progress'.*** +> +> If the issue is not clear, the resource changes the label to 'needs-more-info' so the person who created the issue understands there needs to be additional engagement by them in order to get help. +> +> **Best Practice!** +> +> If the question can be handled in a quick exchange, then there is no need to add the 'in progress label. If there is some research or it will take some time to resolve the issue the use the 'in progress label. +> +> At this point the resource just needs to complete the request and close out the question once completed. There is not a label for this state since 'closed' is its own unique state. +> +> If it is determined the 'Question' is actually a 'Bug' or 'Enhancement' the 'Question' label will be removed and updated accordingly and assigned (if necessary) to the appropriate resource. + +Defects, Enhancement, Doc issues +-------------------------------- + +> After being 'triaged' and defined as either a ‘Code-Defect’, ‘Test-Defect’, or 'Enhancement' the item will need to be reviewed and have the following labels applied based on the review of the issue.   + +- The State Label will be changed to 'investigating or understood' + +- The Area Label will be added + +- The Milestone label will be added (As needed.) + +- The Priority Label will be supplied (As needed.) + +> ****Defects and Doc issues**** +> +> ***'Optional' Phases will apply to issues that are immediately understood allowing them to bypass many of the phases, moving the bug right to 'in-progress'.*** + +****Enhancement Issues**** + +> ***Where at 'review' the feature is reviewed for release and obtains any special sign-off needed from feature teams (if applicable). If not done (completed or has issues), go back to investigate (if needed) or move to design or in-progress for additional work. Repeat as needed. Once the feature can pass the review process (Whatever that may be for the given feature) it moves to closed*** +> +> **Important! The Bug or Enhancement will remain un-assigned until someone is ready to pick up the work!** We do not want to just assign items to people who have work already since it is possible others may want to contribute to the fix/feature. +> +> At the very least the issue can be assigned a future Milestone if it is understood that is where the work needs to be done **OR** if there is not a clear path for the bug, leaving the Milestone blank functions as a backlog for issues without a release assigned. Once it reaches the current Milestone, the additional labels may be added. +> +> **Responsibility of the Area Owner** +> +> At this time, the Bug or Enhancement is **NOT** assigned to a specific individual, just the Area. Area owners need to be aware of the items in their queue and need to be aware of the Milestone so that they can review the active, unassigned items and be prepared to assign them once a resource is ready for work. +> +> Once the issue is ready to be worked on (either by resource of by Milestone deliverable) an individual will be assigned to do the work. The 'in-progress' label is applied now removing the 'understood' label'). +> +> Work on the issue will continue until completed. i.e. the fix/feature is validated and approved by the Dev Lead and no regressions are associated with the issue. Once work is done and all necessary related tasks are completed, the item is closed. +> +> Specific build numbers will be used to update the Milestone label so we know specifically what build number shipped and what fixes are associated with it. Changing the label changes ALL the tagged issues at one time. +> +> Documentation can be taken from GitHub based on build number in the Milestone and consolidated for Release Notes. +> +> Once all work is completed and signed off on, we can RTW and close-down the Milestone and move any remaining items into the appropriate/next Milestone. + +Work Flow Process Table (Same as above - fewer words) +===================================================== + +| **State/Phase label** | **Issue Type** | **State description** | **Action** | +|-------------------------|----------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **New/Open (no label)** | Question, Bug, Enhancement | No label when new issue type is created. |- A new issue is opened under the appropriate GitHub page.
-New item **must** be triaged in less than 48 hours!| +| **No label** | Question, Bug, Enhancement | New issues should be triaged within 48 hours of being opened. Add the 'needs-triage' label at this time if not clear what area issue impacts |- Area PM/Dev Lead will triage the issue.
- Define whether it is a bug, Enhancement or Question. +| **investigating** | Bug, Enhancement | Potentially optional if the issue is not fully understood. Remove 'triage' and add 'investigation'. Issue which are understood can move right ahead to 'Understood'. |- Define the Area (Team).
- Define the Milestone (Iteration).
- Define Priority +| **needs-more-info** | Question, Bug | If an item needs more information before it can be assigned use this label. This is also optional. |- It an issue needs more info then it is up to the current owners to reach out to get that info so that the item can be understood and ready to be picked up for work.
- Any sections not previous defined (Area, Owner, etc.) those should be added at this time. +| **understood** | Bug | This label is assigned once the bug issue understood and ready to be assigned.|- This is a parked phase where the bug contents are understood and ready to be worked on once the defined resource is ready to engage.
- The necessary resources will be added to the 'Assignees' section of the issue. | +| **design** | Enhancement | Use this label to define the enhancement is being worked on and due to its nature requires more than just coding to address.|- Related design work, meetings and other activities rewalted to coding a new feature will occur during this phase.
- A new Enhancement might be reviewed more than once and move back to a prior state before work resumes on the new enhancement. | +| **In-progress** | Question, Bug, Enhancement | When the work is understood and actively being worked on.|- For a Bug, once the Dev resource engages the label will be changed to 'In-Progress'.
- For Enhancements, the label of 'in-progress' is only added once the current design aspects have been defined fully.| +| **review** | Enhancement | Use this label when an enhancement is under review. This work item may need to go back to 'investigation' or 'design' based on the outcome of the review. |- This phase is unique to Enhancements. Once an enhancement has been completed, it needs to be reviewed prior to release to ensure all aspects of the new enhancement (feature) work as expected. | +| **closed** | Question, Bug, Enhancement | No label is required here. Once all work on a given issue is completed the issue is closed.|- Completed issues will be closed and remain as such unless Recall mode requires it to be reverted.
- No label change is required so long as the item is marked 'Closed'.
- Items can be chosen by 'Milestone' and 'Closed' to get documentation for given release.
- Do we still need to make notifications about the release?
- No further action required for issue.| From 31c5679f530fdf3fe6ce92468909d52747d1b044 Mon Sep 17 00:00:00 2001 From: Denis Trailin Date: Tue, 15 May 2018 06:02:01 +0800 Subject: [PATCH 3/8] Fix typo in ThirdPartyNotices.txt and migrate to UTF-8 (#117) --- ThirdPartyNotices.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ThirdPartyNotices.txt b/ThirdPartyNotices.txt index 20e750f1d..b94d4b06d 100644 --- a/ThirdPartyNotices.txt +++ b/ThirdPartyNotices.txt @@ -48,7 +48,7 @@ The above copyright notice and this permission notice shall be included in all c THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Contact GitHub API Training Shop Blog About -© 2017 GitHub, Inc. Terms Privacy Security Status Help +© 2017 GitHub, Inc. Terms Privacy Security Status Help File with code "taken...from" Bond The MIT License (MIT) @@ -58,7 +58,7 @@ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -Files with cod "[i]nspired by" tipsy +Files with code "[i]nspired by" tipsy The MIT License Copyright (c) 2008 Jason Frame (jason@onehackoranother.com) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights From 76443b3906b9aa92e4b4701eb9a41a738d500502 Mon Sep 17 00:00:00 2001 From: samedder Date: Tue, 22 May 2018 13:08:53 -0700 Subject: [PATCH 4/8] Moving file to new location --- github_migration_process.md => docs/github_migration_process.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename github_migration_process.md => docs/github_migration_process.md (100%) diff --git a/github_migration_process.md b/docs/github_migration_process.md similarity index 100% rename from github_migration_process.md rename to docs/github_migration_process.md From 6bc88f0b29d5ad66966c0deda745d50208e98136 Mon Sep 17 00:00:00 2001 From: samedder Date: Tue, 22 May 2018 13:10:07 -0700 Subject: [PATCH 5/8] Adding in-person changes --- docs/github_migration_process.md | 29 ++++++++++------------------- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/docs/github_migration_process.md b/docs/github_migration_process.md index 59c5864e6..9d240e0c1 100644 --- a/docs/github_migration_process.md +++ b/docs/github_migration_process.md @@ -1,27 +1,25 @@ -Proposed labels by section on GitHub +Best Practices Guide for GitHub usage ==================================== > Assignees --------------------------------------------------------------- -> No labels for this section - just use the alias of the individuals owning the issue. MS alias showing is preferred. +> No labels for this section - just use the alias of the individuals owning the issue. Labels ------------------------------------------------------------ -> It is understood that some teams will have their OWN GItHub page. Focus is on the SF page and we can build on/modify for other Team GitHub pages later once the initial model is completed. +> It is understood that some teams will have their own GitHub page. Focus is on the SF page and we can build on/modify for other Team GitHub pages later once the initial model is completed. > >   ### Label Rules for GitHub - All tags and labels are lower-case and dash separated - -- All hierarchy is whack separated and no caps. >   -| ***State/Status*** | ***Area*** | ***Issue Type*** | ***Pri*** | +| ***Status*** | ***Area*** | ***Issue Type*** | ***Pri*** | |--------------------|--------------------------|------------------|-----------------| -| investigating | area-common | question | Pri-0,(regular) | +| investigating | area-common | question | pri-0, | | needs-more-info | areas-communication | enhancement | | | understood | area-data-structures | code-defect | | | in-design | area-developer | test-defect | | @@ -40,28 +38,21 @@ Labels | | area-sfrp | | | | | area-standaloneinstaller | | | | | area-store | | | -| | area-test | | | +| | area-testinfra | | | | | area-testability | | | | | area-transport | | | | | area-needs-triage | | | | | area-try-service-fabric | | | -| | varea-windows-server | | | +| | area-windows-server | | | | | | | | -Project - NA for now --------------------------------------------------------------------------- - -| ***xxxx*** | ***xxx*** | -|------------|-----------| -| xxx | xxx | +-------------------------------------------------------------------------- -> **No labels for this area at this time.** -Milestones ---------------------------------------------------------------- -| ***Release (Iteration path)*** | +| ***Release*** | |-------------------------------------------------------------------------------------------| | 6.3, 6.4, etc. (define specifically once we get a build number at end of release) @@ -71,7 +62,7 @@ Milestones > > All work items update automatically once the milestone is updated. (= minimal effort) - There is not a vNext or backlog release. + There is not a vNext or backlog release. > No Milestone = backlog | From 6c926053d1ce1b929e4d90bb9ffc3172fafa288b Mon Sep 17 00:00:00 2001 From: samedder Date: Tue, 22 May 2018 14:15:11 -0700 Subject: [PATCH 6/8] Revert "Merge branch 'master' of https://github.com/v-jigen/service-fabric into v-jigen-master" This reverts commit c141772d090ee4178653ee3be9b5ddb3c7782728, reversing changes made to 3f670fd0822ba9ad0f6b3c459b946a4c8cd8bf02. --- .gitattributes | 3 +-- ThirdPartyNotices.txt | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/.gitattributes b/.gitattributes index 307643006..6cd5ff10c 100644 --- a/.gitattributes +++ b/.gitattributes @@ -1,4 +1,3 @@ # Enforce LF endings on Windows. This is necessary # in order for the Linux docker container on Windows to work. -* text eol=lf -*.png binary +* text eol=lf \ No newline at end of file diff --git a/ThirdPartyNotices.txt b/ThirdPartyNotices.txt index b94d4b06d..20e750f1d 100644 --- a/ThirdPartyNotices.txt +++ b/ThirdPartyNotices.txt @@ -48,7 +48,7 @@ The above copyright notice and this permission notice shall be included in all c THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Contact GitHub API Training Shop Blog About -© 2017 GitHub, Inc. Terms Privacy Security Status Help +© 2017 GitHub, Inc. Terms Privacy Security Status Help File with code "taken...from" Bond The MIT License (MIT) @@ -58,7 +58,7 @@ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -Files with code "[i]nspired by" tipsy +Files with cod "[i]nspired by" tipsy The MIT License Copyright (c) 2008 Jason Frame (jason@onehackoranother.com) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights From 2370fcbeeda86d89a8040582ce3d4c9f387abaff Mon Sep 17 00:00:00 2001 From: samedder Date: Tue, 22 May 2018 14:55:45 -0700 Subject: [PATCH 7/8] Adding edits --- .../{github_migration_process.md => issue_tracking_and_labels.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename docs/{github_migration_process.md => issue_tracking_and_labels.md} (100%) diff --git a/docs/github_migration_process.md b/docs/issue_tracking_and_labels.md similarity index 100% rename from docs/github_migration_process.md rename to docs/issue_tracking_and_labels.md From cbc7ad524095223718f33c2256b793489def0fb8 Mon Sep 17 00:00:00 2001 From: samedder Date: Tue, 22 May 2018 14:57:19 -0700 Subject: [PATCH 8/8] Rewriting --- docs/issue_tracking_and_labels.md | 264 ++++++++++-------------------- 1 file changed, 86 insertions(+), 178 deletions(-) diff --git a/docs/issue_tracking_and_labels.md b/docs/issue_tracking_and_labels.md index 9d240e0c1..4c4d60bfa 100644 --- a/docs/issue_tracking_and_labels.md +++ b/docs/issue_tracking_and_labels.md @@ -1,213 +1,121 @@ -Best Practices Guide for GitHub usage -==================================== -> -Assignees ---------------------------------------------------------------- +# GitHub issue tracking and labels -> No labels for this section - just use the alias of the individuals owning the issue. +Describes how to use labels and modifiers when tracking work items in the GitHub page. -Labels ------------------------------------------------------------- +## Assignees -> It is understood that some teams will have their own GitHub page. Focus is on the SF page and we can build on/modify for other Team GitHub pages later once the initial model is completed. -> ->   -### Label Rules for GitHub +No labels for this section - just use the alias of the individuals owning the issue. -- All tags and labels are lower-case and dash separated ->   +## Labels -| ***Status*** | ***Area*** | ***Issue Type*** | ***Pri*** | -|--------------------|--------------------------|------------------|-----------------| -| investigating | area-common | question | pri-0, | -| needs-more-info | areas-communication | enhancement | | -| understood | area-data-structures | code-defect | | -| in-design | area-developer | test-defect | | -| in-progress | area-diagnostics | doc-only | | -| external | area-documentation | | | -| release-note-na | area-engineering | | | -| release-note-req | area-federation | | | -| duplicate | area-hosting | | | -| | area-ktl | | | -| | area-linux | | | -| | area-management | | | -| | area-operations | | | -| | area-reliability | | | -| | area-security | | | -| | area-setup | | | -| | area-sfrp | | | -| | area-standaloneinstaller | | | -| | area-store | | | -| | area-testinfra | | | -| | area-testability | | | -| | area-transport | | | -| | area-needs-triage | | | -| | area-try-service-fabric | | | -| | area-windows-server | | | -| | | | | +All tags and labels are lower-case and dash separated. +| Status | Area | Issue Type | Priority | +| ---------------- | ------------------------ | ----------- | -------- | +| investigating | area-common | question | pri-0 | +| needs-more-info | areas-communication | enhancement | | +| understood | area-data-structures | code-defect | | +| in-design | area-developer | test-defect | | +| in-progress | area-diagnostics | doc-only | | +| external | area-documentation | | | +| release-note-na | area-engineering | | | +| release-note-req | area-federation | | | +| duplicate | area-hosting | | | +| | area-ktl | | | +| | area-linux | | | +| | area-management | | | +| | area-operations | | | +| | area-reliability | | | +| | area-security | | | +| | area-setup | | | +| | area-sfrp | | | +| | area-standaloneinstaller | | | +| | area-store | | | +| | area-testinfra | | | +| | area-testability | | | +| | area-transport | | | +| | area-needs-triage | | | +| | area-try-service-fabric | | | +| | area-windows-server | | | +| | | | | --------------------------------------------------------------------------- +For more information about the definition of each label, take a look at the +[labels page](https://github.com/Microsoft/service-fabric/labels) on GitHub. +There are no strict rules about using labels, apply labels when appropriate +according to each label's definition. Generally labels fall into one of 4 +categories ----------------------------------------------------------------- +**Status**: Indicates the work status or issue status, including if the issue +has been seen by a developer, been investigated, or needs more attention. It +can also be used to indicate an outcome of an issue -| ***Release*** | -|-------------------------------------------------------------------------------------------| -| 6.3, 6.4, etc. (define specifically once we get a build number at end of release) - - 6.3 CU1, 6.4 CU1, etc. (define specifically once we a get build number at end of release) - - > Example 6.3.xxx.xx - > - > All work items update automatically once the milestone is updated. (= minimal effort) - - There is not a vNext or backlog release. - - > No Milestone = backlog | +**Area**: Indicates the impacted component. These are modules and feature +areas of Service Fabric. -Happy Path By issue -=================== +**Issue Type**: Indicates what type of work is required to resolve the issue. +Defects require code changes, questions or doc changes can be resolved without +changing production code. -Path below based on current State/Phase Labels +**Priority**: Indicates how soon an issue will get attention. Avoid adding +any priory labels unless there is a strong justification. -****Question Happy Path**** +## Milestones -*Open -> triaged -> needs-more-info (optional) -> in-progress -> Closed. * +Releases are defined by milestones, these are usually denoted by a sequence of +two digits and a possible post-release fix identifier. Examples of this are: -****Bug or Documentation Happy Path**** +- 6.3 +- 6.4 CU1 -*Open -> triaged -> investigating (optional) -> need-more-info (optional) -> understood (optional) -> in -progress -> Closed. * +In this case 6.4 CU1 refers to the 6.4 cumulative update 1. This would +succeed the 6.4 release in the case there were fixes to that released version. -****Enhancement Happy Path**** +If no milestone is added, the item is considered to be on the backlog -*Open -> triaged -> investigating (optional) -> design -> in -progress -> review -> Closed. * +## Example label transitions -> ****Questions, Defects and Doc issues**** -> -> ***'Optional' Phases will apply to issues that are immediately understood allowing them to bypass many of the phases, moving the bug right to 'in-progress'.*** +Issues are reported with no labels, and no assignees. Issues then typically +follow this cycle: -****Enhancement Issues**** +### When an issue arrives -> ***Where at 'review' the feature is reviewed for release and obtains any special sign-off needed from feature teams (if applicable). If not done (completed or has issues), go back to investigate (if needed) or move to design or in-progress for additional work. Repeat as needed. Once the feature can pass the review process (Whatever that may be for the given feature) it moves to closed*** +- Add an area, if not certain, add `needs-triage` +- Add an issue type, if not certain, ignore -Issue Lifecycle -=============== +### When starting working on an issue -Issues are reported with no labels, and no assignees. Issues then typically follow this cycle: +- Add an assignee, whoever is actively working on the issue +- Update issue status according how far along the investigation is +- Adjust area if it needs adjusting +- If the issue needs to be transferred to a new area, be sure to remove the current assignee first -1. When an issue is reported it is sent to an appropriate area using the area label +### When closing issues -2. If the type of issue is obvious, a type label is set +- Make sure the area and type are set correctly -3. If the issue is not obvious, an investigating status label is set, and assignee is set +### Assigning issues -4. The individual assigned works on the issue, updating the issue, status and type labels +Issues should only be assigned to individuals if they are actively being +worked on by that individual. Otherwise, issues remain unassigned. This way it +is obvious who is responsible for the work. -If the assignee has found the issue does not belong to their area, they initiate a transfer by +## Goals and Responsibilities -1. Removing the area label - -2. Removing themselves from assignee - -3. Transferring issue to new area label - -Assigning issues -================ - -> Issues should only be assigned to individuals if they are actively being worked on by that individual. Otherwise, issues remain unassigned. This way it is obvious who is responsible for the work. It is valid for no one to be responsible. - -Work Flow Process Details -========================= - -Who are all those involved with the project? --------------------------------------------- - -Inputs will come from both **Internal** and **External** service-fabric repo contributors and community members. Here are some of the roles we'll see. +In general, GitHub is not meant to replace live support. If you have an issue +that requires immediate attention please use [Azure Support](https://azure.microsoft.com/en-us/support/options/). -| **Area Leads**: | Responsible for setting direction in specific areas of the project and triaging issues within their respective areas.| -|-|- -| **Committers**: | Dedicated to working on the project, may have write access.| -| **Contributors**: | Community members that make any contribution to the project, whether it’s submitting code, fixing or reporting bugs, writing docs, etc.| -| **Users:** | General users who have a need for the project.| +### Contributors -> **As a measurement** we want to try and touch all new items within 48 hours. This is not exposed to the customer but is a metric for us to determine how quickly we are touching new issues. We need to ensure that feature area owners are actively triaging their issues and keeping them up to date. -> -> A defined group of individuals consisting of Area Leads or Developers will be responsible for reviewing all new items. -> -> Once a new item has arrived the defined resource for 'touching' these issues for the first time will set the label 'triage' to the issue so that it can be reviewed. -> -> Once the item is being reviewed, they will be assigned an 'Issue type' unless it requires additional investigation, then the 'investigation' label would be added to show there needs to be some additional work before routing the issue. +If you are an active contributor and own a section of the code, it is expected +that issues assigned to you are actively being worked on. -Question Issues ---------------- +Responses should take less than 48 hours. -> Once marked as a 'Question' the resource will assist with the issue by pointing to self-service options or provide customized help to resolve the issue. We like to have questions actively pushed out to SO and slack (once we build up the community). ->   -> ****Questions**** -> -> ***'Optional' Phases will apply to issues that are immediately understood allowing them to bypass many of the phases, moving the bug right to 'in-progress'.*** -> -> If the issue is not clear, the resource changes the label to 'needs-more-info' so the person who created the issue understands there needs to be additional engagement by them in order to get help. -> -> **Best Practice!** -> -> If the question can be handled in a quick exchange, then there is no need to add the 'in progress label. If there is some research or it will take some time to resolve the issue the use the 'in progress label. -> -> At this point the resource just needs to complete the request and close out the question once completed. There is not a label for this state since 'closed' is its own unique state. -> -> If it is determined the 'Question' is actually a 'Bug' or 'Enhancement' the 'Question' label will be removed and updated accordingly and assigned (if necessary) to the appropriate resource. +### Area lead -Defects, Enhancement, Doc issues --------------------------------- +If you are responsible for an area, it is expected you triage all issues assigned +to that area, and validate they are closed correctly. -> After being 'triaged' and defined as either a ‘Code-Defect’, ‘Test-Defect’, or 'Enhancement' the item will need to be reviewed and have the following labels applied based on the review of the issue.   - -- The State Label will be changed to 'investigating or understood' - -- The Area Label will be added - -- The Milestone label will be added (As needed.) - -- The Priority Label will be supplied (As needed.) - -> ****Defects and Doc issues**** -> -> ***'Optional' Phases will apply to issues that are immediately understood allowing them to bypass many of the phases, moving the bug right to 'in-progress'.*** - -****Enhancement Issues**** - -> ***Where at 'review' the feature is reviewed for release and obtains any special sign-off needed from feature teams (if applicable). If not done (completed or has issues), go back to investigate (if needed) or move to design or in-progress for additional work. Repeat as needed. Once the feature can pass the review process (Whatever that may be for the given feature) it moves to closed*** -> -> **Important! The Bug or Enhancement will remain un-assigned until someone is ready to pick up the work!** We do not want to just assign items to people who have work already since it is possible others may want to contribute to the fix/feature. -> -> At the very least the issue can be assigned a future Milestone if it is understood that is where the work needs to be done **OR** if there is not a clear path for the bug, leaving the Milestone blank functions as a backlog for issues without a release assigned. Once it reaches the current Milestone, the additional labels may be added. -> -> **Responsibility of the Area Owner** -> -> At this time, the Bug or Enhancement is **NOT** assigned to a specific individual, just the Area. Area owners need to be aware of the items in their queue and need to be aware of the Milestone so that they can review the active, unassigned items and be prepared to assign them once a resource is ready for work. -> -> Once the issue is ready to be worked on (either by resource of by Milestone deliverable) an individual will be assigned to do the work. The 'in-progress' label is applied now removing the 'understood' label'). -> -> Work on the issue will continue until completed. i.e. the fix/feature is validated and approved by the Dev Lead and no regressions are associated with the issue. Once work is done and all necessary related tasks are completed, the item is closed. -> -> Specific build numbers will be used to update the Milestone label so we know specifically what build number shipped and what fixes are associated with it. Changing the label changes ALL the tagged issues at one time. -> -> Documentation can be taken from GitHub based on build number in the Milestone and consolidated for Release Notes. -> -> Once all work is completed and signed off on, we can RTW and close-down the Milestone and move any remaining items into the appropriate/next Milestone. - -Work Flow Process Table (Same as above - fewer words) -===================================================== - -| **State/Phase label** | **Issue Type** | **State description** | **Action** | -|-------------------------|----------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **New/Open (no label)** | Question, Bug, Enhancement | No label when new issue type is created. |- A new issue is opened under the appropriate GitHub page.
-New item **must** be triaged in less than 48 hours!| -| **No label** | Question, Bug, Enhancement | New issues should be triaged within 48 hours of being opened. Add the 'needs-triage' label at this time if not clear what area issue impacts |- Area PM/Dev Lead will triage the issue.
- Define whether it is a bug, Enhancement or Question. -| **investigating** | Bug, Enhancement | Potentially optional if the issue is not fully understood. Remove 'triage' and add 'investigation'. Issue which are understood can move right ahead to 'Understood'. |- Define the Area (Team).
- Define the Milestone (Iteration).
- Define Priority -| **needs-more-info** | Question, Bug | If an item needs more information before it can be assigned use this label. This is also optional. |- It an issue needs more info then it is up to the current owners to reach out to get that info so that the item can be understood and ready to be picked up for work.
- Any sections not previous defined (Area, Owner, etc.) those should be added at this time. -| **understood** | Bug | This label is assigned once the bug issue understood and ready to be assigned.|- This is a parked phase where the bug contents are understood and ready to be worked on once the defined resource is ready to engage.
- The necessary resources will be added to the 'Assignees' section of the issue. | -| **design** | Enhancement | Use this label to define the enhancement is being worked on and due to its nature requires more than just coding to address.|- Related design work, meetings and other activities rewalted to coding a new feature will occur during this phase.
- A new Enhancement might be reviewed more than once and move back to a prior state before work resumes on the new enhancement. | -| **In-progress** | Question, Bug, Enhancement | When the work is understood and actively being worked on.|- For a Bug, once the Dev resource engages the label will be changed to 'In-Progress'.
- For Enhancements, the label of 'in-progress' is only added once the current design aspects have been defined fully.| -| **review** | Enhancement | Use this label when an enhancement is under review. This work item may need to go back to 'investigation' or 'design' based on the outcome of the review. |- This phase is unique to Enhancements. Once an enhancement has been completed, it needs to be reviewed prior to release to ensure all aspects of the new enhancement (feature) work as expected. | -| **closed** | Question, Bug, Enhancement | No label is required here. Once all work on a given issue is completed the issue is closed.|- Completed issues will be closed and remain as such unless Recall mode requires it to be reverted.
- No label change is required so long as the item is marked 'Closed'.
- Items can be chosen by 'Milestone' and 'Closed' to get documentation for given release.
- Do we still need to make notifications about the release?
- No further action required for issue.| +Triaging issues involves setting correct labels and milestones, as well as driving +to closure.