Merge remote-tracking branch 'upstream/master' into ce-to-ee-2018-08-12

# Conflicts:
#	app/views/projects/blob/_editor.html.haml
#	changelogs/unreleased/50126-blocked-user-card.yml

[ci skip]

.rubocop.yml

@@ -31,6 +31,10 @@ Style/MutableConstant:
     - 'ee/db/post_migrate/**/*'
     - 'ee/db/geo/migrate/**/*'
 
+# TODO: Move this to gitlab-styles
+Style/SafeNavigation:
+  Enabled: false
+
 Naming/FileName:
   ExpectMatchingDefinition: true
   Exclude:

.rubocop_todo.yml

@@ -706,12 +706,6 @@ Style/RescueModifier:
 Style/RescueStandardError:
   Enabled: false
 
-# Offense count: 92
-# Cop supports --auto-correct.
-# Configuration parameters: ConvertCodeThatCanStartToReturnNil.
-Style/SafeNavigation:
-  Enabled: false
-
 # Offense count: 8
 # Cop supports --auto-correct.
 Style/SelfAssignment:

PROCESS.md

@@ -15,8 +15,9 @@
   - [Between the 1st and the 7th](#between-the-1st-and-the-7th)
   - [On the 7th](#on-the-7th)
   - [After the 7th](#after-the-7th)
-- [Regressions](#regressions)
-  - [How to manage a regression](#how-to-manage-a-regression)
+- [Bugs](#bugs)
+  - [Regressions](#regressions)
+  - [Managing bugs](#managing-bugs)
 - [Release retrospective and kickoff](#release-retrospective-and-kickoff)
   - [Retrospective](#retrospective)
   - [Kickoff](#kickoff)
@@ -176,7 +177,7 @@ information, see
 Once the stable branch is frozen, the only MRs that can be cherry-picked into
 the stable branch are:
 
-* Fixes for [regressions](#regressions)
+* Fixes for [regressions](#regressions) where the affected version `xx.x` in `regression:xx.x` is the current release. See [Managing bugs](#managing-bugs) section.
 * Fixes for security issues
 * Fixes or improvements to automated QA scenarios
 * Documentation updates for changes in the same release
@@ -209,48 +210,59 @@ you can ask for an exception to be made.
 
 Check [this guide](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md) about how to open an exception request before opening one.
 
-## Regressions
+## Bugs
 
-A regression for a particular monthly release is a bug that exists in that
-release, but wasn't present in the release before. This includes bugs in
-features that were only added in that monthly release. Every regression **must**
-have the milestone of the release it was introduced in - if a regression doesn't
-have a milestone, it might be 'just' a bug!
+A ~bug is a defect, error, failure which causes the system to behave incorrectly or prevents it from fulfilling the product requirements.
 
-For instance, if 10.5.0 adds a feature, and that feature doesn't work correctly,
-then this is a regression in 10.5. If 10.5.1 then fixes that, but 10.5.3 somehow
-reintroduces the bug, then this bug is still a regression in 10.5.
+The level of impact of a ~bug can vary from blocking a whole functionality 
+or a feature usability bug. A bug should always be linked to a severity level. 
+Refer to our [severity levels](../CONTRIBUTING.md#severity-labels)
 
-Because GitLab.com runs release candidates of new releases, a regression can be
-reported in a release before its 'official' release date on the 22nd of the
-month. When we say 'the most recent monthly release', this can refer to either
-the version currently running on GitLab.com, or the most recent version
-available in the package repositories.
+Whether the bug is also a regression or not, the triage process should start as soon as possible. 
+Ensure that the Engineering Manager and/or the Product Manager for the relative area is involved to prioritize the work as needed.
 
-### How to manage a regression
+### Regressions
 
-Regressions are very important, and they should be considered high priority 
-issues that should be solved as soon as possible, especially if they affect
-users. Despite that, ~regression label itself does not imply when the issue
-will be scheduled.
+A ~regression implies that a previously **verified working functionality** no longer works.
+Regressions are a subset of bugs. We use the ~regression label to imply that the defect caused the functionality to regress.
+The label tells us that something worked before and it needs extra attention from Engineering and Product Managers to schedule/reschedule. 
 
-When a regression is found:
-1. Create an issue describing the problem in the most detailed way possible
-1. If possible, provide links to real examples and how to reproduce the problem
+The regression label does not apply to ~bugs for new features for which functionality was **never verified as working**. 
+These, by definition, are not regressions. 
+
+A regression should always have the `regression:xx.x` label on it to designate when it was introduced.
+
+Regressions should be considered high priority issues that should be solved as soon as possible, especially if they have severe impact on users. 
+
+### Managing bugs
+
+**Prioritization:** We give higher priority to regressions on features that worked in the last recent monthly release and the current release candidates. 
+The two scenarios below can [bypass the exception request in the release process](https://gitlab.com/gitlab-org/release/docs/blob/master/general/exception-request/process.md#after-the-7th), where the affected regression version matches the current monthly release version. 
+* A regression which worked in the **Last monthly release**
+   * **Example:** In 11.0 we released a new `feature X` that is verified as working. Then in release 11.1 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
+   * *Note:* When we say `the last recent monthly release`, this can refer to either the version currently running on GitLab.com, or the most recent version available in the package repositories.
+* A regression which worked in the **Current release candidates**
+   * **Example:** In 11.1-RC3 we shipped a new feature which has been verified as working. Then in 11.1-RC5 the feature no longer works, this is regression for 11.1. The issue should have the `regression:11.1` label.
+   * *Note:* Because GitLab.com runs release candidates of new releases, a regression can be reported in a release before its 'official' release date on the 22nd of the month. 
+
+When a bug is found:
+1. Create an issue describing the problem in the most detailed way possible.
+1. If possible, provide links to real examples and how to reproduce the problem.
 1. Label the issue properly, using the [team label](../CONTRIBUTING.md#team-labels),
    the [subject label](../CONTRIBUTING.md#subject-labels)
    and any other label that may apply in the specific case
-1. Add the ~bug and ~regression labels
-1. Notify the respective Engineering Manager to evaluate the Severity of the regression and add a [Severity label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-severity-labels). The counterpart Product Manager is included to weigh-in on prioritization as needed to set the [Priority label](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#bug-priority-labels).
-1. If the regression is either an ~S1, ~S2 or ~S3 severity, label the regression with the current milestone as it should be fixed in the current milestone.
-  1. If the regression was introduced in an RC of the current release, label with ~Deliverable
-  1. If the regression was introduced in the previous release, label with ~"Next Patch Release"
-1. If the regression is an ~S4 severity, the regression may be scheduled for later milestones at the discretion of Engineering Manager and Product Manager.
-
-When a new issue is found, the fix should start as soon as possible. You can
-ping the Engineering Manager or the Product Manager for the relative area to
-make them aware of the issue earlier. They will analyze the priority and change
-it if needed.
+1. Notify the respective Engineering Manager to evaluate and apply the [Severity label](../CONTRIBUTING.md#bug-severity-labels) and [Priority label](../CONTRIBUTING.md#bug-priority-labels).
+The counterpart Product Manager is included to weigh-in on prioritization as needed.
+1. If the ~bug is **NOT** a regression:
+   1. The Engineering Manager decides which milestone the bug will be fixed. The appropriate milestone is applied.
+1. If the bug is a ~regression: 
+   1. Determine the release that the regression affects and add the corresponding `regression:xx.x` label.
+      1. If the affected release version can't be determined, add the generic ~regression label for the time being.
+   1. If the affected version `xx.x` in `regression:xx.x` is the **current release**, it's recommended to schedule the fix for the current milestone. 
+      1. This falls under regressions which worked in the last release and the current RCs. More detailed explanations in the **Prioritization** section above. 
+   1. If the affected version `xx.x` in `regression:xx.x` is older than the **current release**
+      1. If the regression is an ~S1 severity, it's recommended to schedule the fix for the current milestone. We would like to fix the highest severity regression as soon as we can.
+      1. If the regression is an ~S2, ~S3 or ~S4 severity, the regression may be scheduled for later milestones at the discretion of the Engineering Manager and Product Manager.
 
 ## Release retrospective and kickoff
 

app/assets/javascripts/boards/components/board_sidebar.js

@@ -4,7 +4,7 @@ import $ from 'jquery';
 import Vue from 'vue';
 import Weight from 'ee/sidebar/components/weight/weight.vue';
 import Flash from '../../flash';
-import { __ } from '../../locale';
+import { sprintf, __ } from '../../locale';
 import Sidebar from '../../right_sidebar';
 import eventHub from '../../sidebar/event_hub';
 import AssigneeTitle from '../../sidebar/components/assignees/assignee_title.vue';
@@ -57,8 +57,10 @@ gl.issueBoards.BoardSidebar = Vue.extend({
       return this.issue.labels && this.issue.labels.length;
     },
     labelDropdownTitle() {
-      return this.hasLabels ?
-        `${this.issue.labels[0].title} ${this.issue.labels.length - 1}+ more` : 'Label';
+      return this.hasLabels ? sprintf(__('%{firstLabel} +%{labelCount} more'), {
+        firstLabel: this.issue.labels[0].title,
+        labelCount: this.issue.labels.length - 1
+      }) : __('Label');
     },
     selectedLabels() {
       return this.hasLabels ? this.issue.labels.map(l => l.title).join(',') : '';

app/assets/javascripts/labels_select.js

@@ -4,7 +4,7 @@
 
 import $ from 'jquery';
 import _ from 'underscore';
-import { __ } from './locale';
+import { sprintf, __ } from './locale';
 import axios from './lib/utils/axios_utils';
 import IssuableBulkUpdateActions from './issuable_bulk_update_actions';
 import DropdownUtils from './filtered_search/dropdown_utils';
@@ -39,7 +39,7 @@ export default class LabelsSelect {
       showNo = $dropdown.data('showNo');
       showAny = $dropdown.data('showAny');
       showMenuAbove = $dropdown.data('showMenuAbove');
-      defaultLabel = $dropdown.data('defaultLabel') || 'Label';
+      defaultLabel = $dropdown.data('defaultLabel') || __('Label');
       abilityName = $dropdown.data('abilityName');
       $selectbox = $dropdown.closest('.selectbox');
       $block = $selectbox.closest('.block');
@@ -267,7 +267,10 @@ export default class LabelsSelect {
             return selectedLabels;
           }
           else if (selectedLabels.length) {
-            return selectedLabels[0] + " +" + (selectedLabels.length - 1) + " more";
+            return sprintf(__('%{firstLabel} +%{labelCount} more'), {
+              firstLabel: selectedLabels[0],
+              labelCount: selectedLabels.length - 1
+            });
           }
           else {
             return defaultLabel;

app/assets/stylesheets/pages/groups.scss

@@ -468,6 +468,7 @@ table.pipeline-project-metrics tr td {
     .stats {
       position: relative;
       line-height: normal;
+      text-align: right;
       flex-shrink: 0;
 
       > span {
@@ -513,7 +514,7 @@ table.pipeline-project-metrics tr td {
     }
 
     .last-updated {
-      position: absolute;
+      position: relative;
       right: 12px;
       min-width: 250px;
       text-align: right;

app/views/projects/blob/_editor.html.haml

@@ -6,8 +6,14 @@
       = sprite_icon('fork', size: 12)
       = ref
     - if current_action?(:edit) || current_action?(:update)
+<<<<<<< HEAD
       = text_field_tag 'file_path', (params[:file_path] || @path),
                                     class: 'form-control new-file-path js-file-path-name-input'
+=======
+      %span.editor-file-name
+        = text_field_tag 'file_path', (params[:file_path] || @path),
+                                      class: 'form-control new-file-path js-file-path-name-input'
+>>>>>>> upstream/master
 
     - if current_action?(:new) || current_action?(:create)
       %span.editor-file-name

changelogs/unreleased/50063-add-missing-i18n-strings-to-issue-boards.yml

+---
+title: Added missing i18n strings to issue boards lables dropdown
+merge_request: 21081
+author:
+type: other

changelogs/unreleased/50126-blocked-user-card.yml

 ---
 title: Fix blocked user card style
+<<<<<<< HEAD
 merge_request: 6849
+=======
+merge_request: 21095
+>>>>>>> upstream/master
 author:
 type: fixed

doc/api/projects.md

@@ -260,8 +260,7 @@ GET /projects?custom_attributes[key]=value&custom_attributes[other_key]=other_va
 
 ## List user projects
 
-Get a list of visible projects for the given user. When accessed without
-authentication, only public projects are returned.
+Get a list of visible projects owned by the given user. When accessed without authentication, only public projects are returned.
 
 ```
 GET /users/:user_id/projects

doc/development/contributing/design.md

@@ -18,23 +18,16 @@ To better understand the priority by which UX tackles issues, see the [UX sectio
 
 Once an issue has been worked on and is ready for development, a UXer removes the ~"UX" label and applies the ~"UX ready" label to that issue.
 
-The UX team has a special type label called ~"design artifact". This label indicates that the final output
-for an issue is a UX solution/design. The solution will be developed by frontend and/or backend in a subsequent milestone.
-Any issue labeled ~"design artifact" should not also be labeled ~"frontend" or ~"backend" since no development is
-needed until the solution has been decided.
+There is a special type label called ~"product discovery". It represents a discovery issue intended for UX, PM, FE, and BE to discuss the problem and potential solutions. The final output for this issue could be a doc of requirements, a design artifact, or even a prototype. The solution will be developed in a subsequent milestone.
 
-~"design artifact" issues are like any other issue and should contain a milestone label, ~"Deliverable" or ~"Stretch", when scheduled in the current milestone.
+~"product discovery" issues are like any other issue and should contain a milestone label, ~"Deliverable" or ~"Stretch", when scheduled in the current milestone.
 
-To prevent the misunderstanding that a feature will be be delivered in the
-assigned milestone, when only UX design is planned for that milestone, the
-Product Manager should create a separate issue for the ~"design artifact",
-assign the ~UX, ~"design artifact" and ~"Deliverable" labels, add a milestone
-and use a title that makes it clear that the scheduled issue is design only
-(e.g. `Design exploration for XYZ`).
+The initial issue should be about the problem we are solving. If a separate [product discovery issue](#product-discovery-issues) is needed for additional research and design work, it will be created by a PM or UX person. Assign the ~UX, ~"product discovery" and ~"Deliverable" labels, add a milestone and use a title that makes it clear that the scheduled issue is product discovery
+(e.g. `Product discovery for XYZ`).
 
-When the ~"design artifact" issue has been completed, the UXer removes the ~UX
+When the ~"product discovery" issue has been completed, the UXer removes the ~UX
 label, adds the ~"UX ready" label and closes the issue. This indicates the
-design artifact is complete. The UXer will also copy the designs to related
+UX work for the issue is complete. The UXer will also copy any designs to related
 issues for implementation in an upcoming milestone.
 
 ## Style guides

lib/banzai/filter/project_reference_filter.rb

+# frozen_string_literal: true
+
 module Banzai
   module Filter
     # HTML filter that replaces project references with links.

lib/banzai/reference_parser/project_parser.rb

+# frozen_string_literal: true
+
 module Banzai
   module ReferenceParser
     class ProjectParser < BaseParser

locale/gitlab.pot

@@ -119,6 +119,9 @@ msgstr[1] ""
 msgid "%{filePath} deleted"
 msgstr ""
 
+msgid "%{firstLabel} +%{labelCount} more"
+msgstr ""
+
 msgid "%{group_docs_link_start}Groups%{group_docs_link_end} allow you to manage and collaborate across multiple projects. Members of a group have access to all of its projects."
 msgstr ""
 

spec/lib/banzai/filter/project_reference_filter_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Banzai::Filter::ProjectReferenceFilter do

spec/lib/banzai/reference_parser/project_parser_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe Banzai::ReferenceParser::ProjectParser do