Add 'Priyanka' to spelling exceptions

A name we use in user stories. Don't mark it as a spelling error.

doc/.vale/gitlab/spelling-exceptions.txt

@@ -347,6 +347,7 @@ prepending
 prepends
 Prettifier
 Pritaly
+Priyanka
 profiler
 Prometheus
 protobuf

doc/api/applications.md

@@ -33,7 +33,7 @@ Parameters:
 | `name`         | string  | yes      | Name of the application.         |
 | `redirect_uri` | string  | yes      | Redirect URI of the application. |
 | `scopes`       | string  | yes      | Scopes of the application.       |
-| `confidential` | boolean | no       | The application will be used where the client secret can be kept confidential. Native mobile apps and Single Page Apps are considered non-confidential. Defaults to `true` if not supplied |
+| `confidential` | boolean | no       | The application is used where the client secret can be kept confidential. Native mobile apps and Single Page Apps are considered non-confidential. Defaults to `true` if not supplied |
 
 Example request:
 
@@ -83,7 +83,7 @@ Example response:
 ```
 
 NOTE:
-The `secret` value will not be exposed by this API.
+The `secret` value is not exposed by this API.
 
 ## Delete an application
 

doc/api/broadcast_messages.md

@@ -12,8 +12,8 @@ Broadcast messages API operates on [broadcast messages](../user/admin_area/broad
 
 As of GitLab 12.8, GET requests do not require authentication. All other broadcast message API endpoints are accessible only to administrators. Non-GET requests by:
 
-- Guests will result in `401 Unauthorized`.
-- Regular users will result in `403 Forbidden`.
+- Guests result in `401 Unauthorized`.
+- Regular users result in `403 Forbidden`.
 
 ## Get all broadcast messages
 

doc/api/users.md

@@ -416,7 +416,7 @@ Parameters:
 | `note`                               | No       | Admin notes for this user                                                                                                                               |
 | `organization`                       | No       | Organization name                                                                                                                                       |
 | `password`                           | No       | Password                                                                                                                                                |
-| `private_profile`                    | No       | User's profile is private - true, false (default), or null (will be converted to false)                                                                 |
+| `private_profile`                    | No       | User's profile is private - true, false (default), or null (is converted to false)                                                                 |
 | `projects_limit`                     | No       | Number of projects user can create                                                                                                                      |
 | `provider`                           | No       | External provider name                                                                                                                                  |
 | `public_email`                       | No       | The public email of the user                                                                                                                            |
@@ -458,7 +458,7 @@ Parameters:
 | `note`                               | No       | Admin notes for this user                                                                                                                               |
 | `organization`                       | No       | Organization name                                                                                                                                       |
 | `password`                           | No       | Password                                                                                                                                                |
-| `private_profile`                    | No       | User's profile is private - true, false (default), or null (will be converted to false)                                                                 |
+| `private_profile`                    | No       | User's profile is private - true, false (default), or null (is converted to false)                                                                 |
 | `projects_limit`                     | No       | Limit projects each user can create                                                                                                                     |
 | `provider`                           | No       | External provider name                                                                                                                                  |
 | `public_email`                       | No       | The public email of the user                                                                                                                            |

doc/development/api_styleguide.md

@@ -34,7 +34,7 @@ for a good example):
 - `desc` for the method summary. You should pass it a block for additional
   details such as:
   - The GitLab version when the endpoint was added. If it is behind a feature flag, mention that instead: _This feature is gated by the :feature\_flag\_symbol feature flag._
-  - If the endpoint is deprecated, and if so, when will it be removed
+  - If the endpoint is deprecated, and if so, its planned removal date
 
 - `params` for the method parameters. This acts as description,
   [validation, and coercion of the parameters](https://github.com/ruby-grape/grape#parameter-validation-and-coercion)
@@ -72,7 +72,7 @@ parent namespaces.
 
 – <https://github.com/ruby-grape/grape#include-parent-namespaces>
 
-In most cases you will want to exclude parameters from the parent namespaces:
+In most cases you should exclude parameters from the parent namespaces:
 
 ```ruby
 declared(params, include_parent_namespaces: false)
@@ -94,7 +94,7 @@ User.create(declared(params, include_parent_namespaces: false).to_h)
 ```
 
 NOTE:
-`declared(params)` return a `Hashie::Mash` object, on which you will have to
+`declared(params)` return a `Hashie::Mash` object, on which you must
 call `.to_h`.
 
 But we can use `params[key]` directly when we access single elements.
@@ -109,7 +109,7 @@ Model.create(foo: params[:foo])
 ## Array types
 
 With Grape v1.3+, Array types must be defined with a `coerce_with`
-block, or parameters will fail to validate when passed a string from an
+block, or parameters, fails to validate when passed a string from an
 API request. See the [Grape upgrading
 documentation](https://github.com/ruby-grape/grape/blob/master/UPGRADING.md#ensure-that-array-types-have-explicit-coercions)
 for more details.
@@ -140,7 +140,7 @@ before do
 end
 ```
 
-With this change, a request to PUT `/test?user_ids` will cause Grape to
+With this change, a request to PUT `/test?user_ids` causes Grape to
 pass `params` to be `{ user_ids: [] }`.
 
 There is [an open issue in the Grape tracker](https://github.com/ruby-grape/grape/issues/2068)
@@ -148,7 +148,7 @@ to make this easier.
 
 ## Using HTTP status helpers
 
-For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behavior (`not_found!`, `no_content!` etc.). These will `throw` inside Grape and abort the execution of your endpoint.
+For non-200 HTTP responses, use the provided helpers in `lib/api/helpers.rb` to ensure correct behavior (`not_found!`, `no_content!` etc.). These `throw` inside Grape and abort the execution of your endpoint.
 
 For `DELETE` requests, you should also generally use the `destroy_conditionally!` helper which by default returns a `204 No Content` response on success, or a `412 Precondition Failed` response if the given `If-Unmodified-Since` header is out of range. This helper calls `#destroy` on the passed resource, but you can also implement a custom deletion method by passing a block.
 
@@ -249,7 +249,7 @@ In order to avoid N+1 problems that are common when returning collections
 of records in an API endpoint, we should use eager loading.
 
 A standard way to do this within the API is for models to implement a
-scope called `with_api_entity_associations` that will preload the
+scope called `with_api_entity_associations` that preloads the
 associations and data returned in the API. An example of this scope can
 be seen in
 [the `Issue` model](https://gitlab.com/gitlab-org/gitlab/blob/2fedc47b97837ea08c3016cf2fb773a0300a4a25/app%2Fmodels%2Fissue.rb#L62).
@@ -259,7 +259,7 @@ In situations where the same model has multiple entities in the API
 discretion with applying this scope. It may be that you optimize for the
 most basic entity, with successive entities building upon that scope.
 
-The `with_api_entity_associations` scope will also [automatically preload
+The `with_api_entity_associations` scope also [automatically preloads
 data](https://gitlab.com/gitlab-org/gitlab/blob/19f74903240e209736c7668132e6a5a735954e7c/app%2Fmodels%2Ftodo.rb#L34)
 for `Todo` _targets_ when returned in the [to-dos API](../api/todos.md).
 

doc/development/cached_queries.md

@@ -29,7 +29,7 @@ more expensive from a memory perspective. They could mask
 so you should treat them the same way you treat regular N+1 queries.
 
 In cases of N+1 queries masked by cached queries, the same query is executed N times.
-It will not hit the database N times but instead returns the cached results N times.
+It doesn't hit the database N times but instead returns the cached results N times.
 This is still expensive because you need to re-initialize objects each time at a
 greater expense to the CPU and memory resources. Instead, you should use the same
 in-memory objects whenever possible.

doc/development/deprecation_guidelines/index.md

@@ -15,7 +15,7 @@ It's important to understand the difference between **deprecation** and
 **removal**:
 
 **Deprecation** is the process of flagging/marking/announcing that a feature
-will be removed in a future version of GitLab.
+is scheduled for removal in a future version of GitLab.
 
 **Removal** is the process of actually removing a feature that was previously
 deprecated.

doc/development/diffs.md

@@ -79,7 +79,7 @@ File diffs are collapsed (but are expandable) if 100 files have already been ren
 Gitlab::Git::DiffCollection.collection_limits[:safe_max_lines] = Gitlab::Git::DiffCollection::DEFAULT_LIMITS[:max_lines] = 5000
 ```
 
-File diffs will be collapsed (but be expandable) if 5000 lines have already been rendered.
+File diffs are collapsed (but be expandable) if 5000 lines have already been rendered.
 
 ```ruby
 Gitlab::Git::DiffCollection.collection_limits[:safe_max_bytes] = Gitlab::Git::DiffCollection.collection_limits[:safe_max_files] * 5.kilobytes = 500.kilobytes

doc/development/emails.md

@@ -83,7 +83,7 @@ See the [Rails guides](https://guides.rubyonrails.org/action_mailer_basics.html#
      expunge_deleted: false
    ```
 
-   As mentioned, the part after `+` is ignored, and this will end up in the mailbox for `gitlab-incoming@gmail.com`.
+   As mentioned, the part after `+` is ignored, and this message is sent to the mailbox for `gitlab-incoming@gmail.com`.
 
 1. Run this command in the GitLab root directory to launch `mail_room`:
 

doc/development/fe_guide/security.md

@@ -73,7 +73,7 @@ such as with reCAPTCHA, which cannot be used without an `iframe`.
 
 ## Avoiding inline scripts and styles
 
-In order to protect users from [XSS vulnerabilities](https://en.wikipedia.org/wiki/Cross-site_scripting), we will disable
+In order to protect users from [XSS vulnerabilities](https://en.wikipedia.org/wiki/Cross-site_scripting), we intend to disable
 inline scripts in the future using Content Security Policy.
 
 While inline scripts can be useful, they're also a security concern. If

doc/development/multi_version_compatibility.md

@@ -89,7 +89,7 @@ Puma enqueues jobs with an extra parameter that the old Sidekiq cannot handle.
 
 ### Database migrations
 
-The following graph is a simplified visual representation of a deployment, this will guide us in understanding how expand and contract is implemented in our migrations strategy.
+The following graph is a simplified visual representation of a deployment, this guides us in understanding how expand and contract is implemented in our migrations strategy.
 
 There's a special consideration here. Using our post-deployment migrations framework allows us to bundle all three phases into one milestone.
 

doc/development/query_recorder.md

@@ -10,7 +10,7 @@ QueryRecorder is a tool for detecting the [N+1 queries problem](https://guides.r
 
 > Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/helpers/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-foss/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a)
 
-As a rule, merge requests [should not increase query counts](merge_request_performance_guidelines.md#query-counts). If you find yourself adding something like `.includes(:author, :assignee)` to avoid having `N+1` queries, consider using QueryRecorder to enforce this with a test. Without this, a new feature which causes an additional model to be accessed will silently reintroduce the problem.
+As a rule, merge requests [should not increase query counts](merge_request_performance_guidelines.md#query-counts). If you find yourself adding something like `.includes(:author, :assignee)` to avoid having `N+1` queries, consider using QueryRecorder to enforce this with a test. Without this, a new feature which causes an additional model to be accessed can silently reintroduce the problem.
 
 ## How it works
 

doc/development/renaming_features.md

@@ -22,9 +22,9 @@ The more of the following that are true, the more likely you should choose the f
 
 - You are not confident the new name is permanent.
 - The feature is susceptible to bugs (large, complex, needing refactor, etc).
-- The renaming will be difficult to review (feature spans many lines, files, or repositories).
-- The renaming will be disruptive in some way (database table renaming).
+- The renaming is difficult to review (feature spans many lines, files, or repositories).
+- The renaming is disruptive in some way (database table renaming).
 
 ## Consider a façade-first approach
 
-The façade approach is not necessarily a final step. It can (and possibly *should*) be treated as the first step, where later iterations will accomplish the complete rename.
+The façade approach is not necessarily a final step. It can (and possibly *should*) be treated as the first step, where later iterations accomplish the complete rename.

doc/development/shared_files.md

@@ -12,7 +12,7 @@ etc. Having so many shared directories makes it difficult to deploy GitLab on
 shared storage (e.g. NFS). Working towards GitLab 9.0 we are consolidating
 these different directories under the `shared` directory.
 
-This means that if GitLab will start storing puppies in some future version
+This means that if GitLab begins storing puppies in some future version
 then we should put them in `shared/puppies`. Temporary puppy files should be
 stored in `shared/tmp`.
 

doc/raketasks/backup_restore.md

@@ -268,7 +268,7 @@ You can exclude specific directories from the backup by adding the environment v
 - `pages` (Pages content)
 - `repositories` (Git repositories data)
 
-All wikis will be backed up as part of the `repositories` group. Non-existent wikis will be skipped during a backup.
+All wikis are backed up as part of the `repositories` group. Non-existent wikis are skipped during a backup.
 
 NOTE:
 When [backing up and restoring Helm Charts](https://docs.gitlab.com/charts/architecture/backup-restore.html), there is an additional option `packages`, which refers to any packages managed by the GitLab [package registry](../user/packages/package_registry/index.md).

doc/user/project/members/index.md

@@ -96,7 +96,7 @@ invitation, change their access level, or even delete them.
 
 ![Invite user members list](img/add_user_email_accept.png)
 
-While unaccepted, the system will automatically send reminder emails on the second, fifth,
+While unaccepted, the system automatically sends reminder emails on the second, fifth,
 and tenth day after the invitation was initially sent.
 
 After the user accepts the invitation, they are prompted to create a new