Further purge references to Jira

Also:

- Clarify that PRs don't need to have associated tickets
- Clean up some language here and there

docs/basics/community.md

@@ -12,9 +12,9 @@ Developers from around the globe use the following systems to communicate and co
 -   [Documentation](https://docs.civicrm.org)
 -   [Mattermost](https://chat.civicrm.org) offers live discussion in chat rooms and direct messages. It's a great place to go for any technical questions. Here, with a bit of luck, you'll often find an instant answer to your question or a pointer in the right direction. Definitely go here if you feel like you are banging your head against a wall.
 -   [Stack Exchange](http://civicrm.stackexchange.com/) - Question & answer site covering a range of topics relevant to developers and users. It is a great place to find answers to the millions of questions that have already been asked about CiviCRM, and to ask ones that haven't been asked already.
--   [Jira](https://issues.civicrm.org/jira) - Issue tracking
+-   [GitLab](https://lab.civicrm.org) - CiviCRM's tool for issue tracking community-based project management.
 -   [GitHub](https://github.com/civicrm) - Hosted git repositories for the entire CiviCRM codebase, as well as many smaller tools focused on developing CiviCRM.
--   [GitLab](https://lab.civicrm.org) - CiviCRM's tool for community-based project management.
+-   [Jira](https://issues.civicrm.org/jira) - _(deprecated) Issue tracking_
 
 !!! tip "Before you begin"
 
@@ -25,8 +25,8 @@ Developers from around the globe use the following systems to communicate and co
 
         The following communities provide a single sign-on once your CiviCRM.org account is approved.
 
-         -   Jira
          -   GitLab
+         -   Jira
          -   CiviCRM Wiki - *account can also be requested via the infrastructure channel on Mattermost*
 
     2.  [Mattermost](https://chat.civicrm.org/signup_email) - Create an account and join a team on this open-source version of Slack.

docs/basics/planning.md

@@ -32,7 +32,7 @@ Once you've written the requirements and specification document, you should go a
 
 ## Bugs
 
-Before starting work on a bug your first step should be to check  [JIRA](https://issues.civicrm.org/), the issue tracking system for CiviCRM for any open issues before creating one yourself or working on a pull request.
+Before starting work on a bug, your first step should be to check the [issue tracking systems](/tools/issue-tracking.md) for any open issues before creating one yourself or working on a pull request.
 
 In order to reproduce the bug you can reproduce the issue in the appropriate [CiviCRM Sandbox](https://civicrm.org/sandboxes). Enabling debugging can help to get more details.
 

docs/core/contributing.md

@@ -49,7 +49,7 @@ Read about [creating a pull request](/tools/git.md#pr) which includes informatio
 
 Once you submit your pull request, CiviCRM's [Jenkins server](/tools/jenkins.md) will build a copy of CiviCRM and run tests against it, beginning with `PHP_CodeSniffer`.  If tests fail, you will be able to follow a link to view details.
 
-Other developers may comment on your code, raising questions or concerns or marking the changes as approved.  This is fine, but it is important not to hide important discussion.  If substantive discussion occurs in a pull request, note it in Jira.  If a pull request is closed in favor of another, explain that in Jira and mention the old pull request in the new one.
+Other developers may comment on your code, raising questions or concerns or marking the changes as approved.  This is fine, but it is important not to hide important discussion.  If substantive discussion occurs in a pull request which has a separate ticket, make note of the discussion in the ticket.  If a pull request is closed in favor of another, explain that in the ticket and mention the old pull request in the new one.
 
 The goal is that the next person working on this feature area shouldn't have to do a lot of archeology to figure out the motivations, concerns, and impact of your changes.
 
@@ -65,4 +65,4 @@ Alternatively, you can use a custom PHP or template override directory.  While t
 
 CiviCRM works through the generosity of its users and the organizations that employ them.  Now that you have a pull request open (and some experience working with the CiviCRM codebase), why not take some time to [review another pull request](/core/pr-review.md)?  
 
-Pick one from the list of open pull requests, review the corresponding Jira ticket, merge the changes into your development copy of CiviCRM, and see how it works.  Share your thoughts on the pull request.  You'll notice that the time you spend reviewing others' code and interacting with the rest of the community will serve you well: you'll be a better CiviCRM developer, and you'll have a better product.
+You'll notice that the time you spend reviewing others' code and interacting with the rest of the community will serve you well: you'll be a better CiviCRM developer, and you'll have a better product.

docs/core/pr-review.md

@@ -29,7 +29,7 @@ Add a comment to the PR like "Reviewing this now" to let others know that you in
 
 ## Read about the issue
 
-Every PR *should* have an issue ID for [JIRA](https://issues.civicrm.org) linked from the PR's page on GitHub. Read the original issue and understand how to reproduce the problem and what the solution looks like as well.
+Many PRs will have an issue tracking ticket linked from the PR's page on GitHub. Read the original issue and understand how to reproduce the problem and what the solution looks like as well.
 
 ## Read the code changes
 
@@ -41,7 +41,7 @@ On the PR, click over to “Files Changed” and understand what the code is doi
 
 ## Reproduce the problem
 
-Confirm which branch the PR was created against. This is probably either `master` or the LTS. Setup an instance locally from that branch (e.g. with [buildkit](https://github.com/civicrm/civicrm-buildkit)), or test on the [public demo site if possible](https://civicrm.org/demo). Repeat the steps to reproduce described in the Jira Issue.
+Confirm which branch the PR was created against. This is probably either `master` or the LTS. Setup an instance locally from that branch (e.g. with [buildkit](https://github.com/civicrm/civicrm-buildkit)), or test on the [public demo site if possible](https://civicrm.org/demo). Repeat the steps to reproduce described in the ticket or PR.
 
 Confirm that the issue was a problem and a problem “worth solving”, generally worthy of being in core.
 

docs/core/verify-fix.md

@@ -3,7 +3,7 @@
 !!! note "See also"
     This page is about verifying a fix after it has been merged into CiviCRM core. Also see instructions on [reviewing a core pull request](/core/pr-review.md) to learn how to review fixes *before* they are merged.
 
-Suppose you (or some like-minded spirit) report a bug on the [Jira](/tools/issue-tracking.md#jira). With a bit of luck, someone from the community (perhaps a core developer) reproduces the bug, writes a fix, and announces gleefully: "It's fixed! It took four hours, but I did it!" Hooray! Now what? How do you get the fix running on your system? How do you verify that the fix fixed exactly your problem?
+Suppose you (or some like-minded spirit) [report a bug](/tools/issue-tracking.md#guidelines). With a bit of luck, someone from the community (perhaps a core developer) reproduces the bug, writes a fix, and announces gleefully: "It's fixed! It took four hours, but I did it!" Hooray! Now what? How do you get the fix running on your system? How do you verify that the fix fixed exactly your problem?
  
 ## Step 1. Check the "Fix Version" in JIRA
 

docs/standards/index.md

@@ -41,8 +41,7 @@ You can also [set up your IDE](/tools/phpstorm.md) to lint your code.
 ## Improving code conformance
 
 If you find code that is not meeting the standards, we encourage you to improve it! But please follow these guidelines when doing so: 
-
-* Create a Jira issue for your coding standards improvements which is separate from any other code changes you happen to be making at the time. 
+ 
 * Isolate your coding standards improvements into commits which do not contain otherwise unrelated changes.
 
 ### Orange Light code

docs/standards/review.md

@@ -26,7 +26,7 @@ Ensure the PR has an adequate explanation.
 
 If you were a site-builder reading the PR-log/release-notes and drilled into this PR, would you understand the description? If you were debugging a problem and traced the change back to this PR, would you understand why the change was made?
 
-It is strongly encouraged that PR's include URLs/hyperlinks for any explanatory material (when available) -- such as a [JIRA issue](/tools/issue-tracking.md#jira), [Gitlab issue](http://lab.civicrm.org/), [StackExchange question](https://civicrm.stackexchange.com/), related PR, or [Mattermost chat](https://chat.civicrm.org). However, hyperlinks are not a substitute for a description. The PR should still have a description.
+It is strongly encouraged that PR's include URLs/hyperlinks for any explanatory material (when available) -- such as a [Gitlab issue](http://lab.civicrm.org/), [JIRA issue](/tools/issue-tracking.md#jira), [StackExchange question](https://civicrm.stackexchange.com/), related PR, or [Mattermost chat](https://chat.civicrm.org). However, hyperlinks are not a substitute for a description. The PR should still have a description.
 
 PR descriptions should generally follow the [pull-request template](https://github.com/civicrm/civicrm-core/blob/master/.github/PULL_REQUEST_TEMPLATE.md), although this could be waived if another structure is more expressive.
 

docs/standards/review/template-del-1.0.md

@@ -2,7 +2,7 @@
 
 <!-- In each category, choose the option that most applies. Delete the others. Optionally, provide more details or explanation in the "Comments". -->
 
-* JIRA ([`r-explain`](https://docs.civicrm.org/dev/en/latest/standards/review/#r-explain))
+* Explain ([`r-explain`](https://docs.civicrm.org/dev/en/latest/standards/review/#r-explain))
     * __UNREVIEWED__
     * __PASS__ : The goal/problem/solution have been adequately explained in the PR.
     * __PASS__ : The goal/problem/solution have been adequately explained with a link (JIRA, Github, Gitlab, StackExchange).

docs/standards/review/template-mc-1.0.md

@@ -2,7 +2,7 @@
 
 <!-- In each category, choose the option that most applies. Optionally, provide more details or explanation in the "Comments". -->
 
-* JIRA ([`r-explain`](https://docs.civicrm.org/dev/en/latest/standards/review/#r-explain))
+* Explain ([`r-explain`](https://docs.civicrm.org/dev/en/latest/standards/review/#r-explain))
     * [ ] __PASS__ : The goal/problem/solution have been adequately explained in the PR.
     * [ ] __PASS__ : The goal/problem/solution have been adequately explained with a link (JIRA, Github, Gitlab, StackExchange).
     * [ ] __ISSUE__: Please provide a better explanation of the goal/problem being addressed.

docs/tools/git.md

@@ -88,7 +88,7 @@ When filing a pull-request, use a descriptive subject. These are good examples:
 A few elements to include:
 
  * **Acronyms** - You're welcome to use the [acronyms](#acronyms) below to flag your PR with certain characteristics.
- * **dev/_project_#_XXXX_** - This is a reference to the [GitLab issue tracker](/tools/issue-tracking.md#gitlab).
+ * **dev/_project_#_XXXX_** - This is a [GitLab issue reference](/tools/issue-tracking.md#gitlab-reference).
  * **CRM-_XXXXX_** - This is a reference to the now-deprecated [Jira issue tracker](/tools/issue-tracking.md#jira). A bot will set up crosslinks between JIRA and GitHub.
  * **Description** - Provide a brief description of what the pull-request does.
 

docs/tools/issue-tracking.md

 # Issue-tracking systems
 
-As of 2017 CiviCRM uses three different system for tracking and managing issues (aka tickets). This page offers a brief summary of the systems and helps developers understand when and how to use them.
+As of 2018 CiviCRM uses three different system for tracking and managing issues (aka tickets). This page offers a brief summary of the systems and helps developers understand when and how to use them.
 
 
 ## Systems
@@ -14,17 +14,29 @@ Used as an issue-tracking system for:
 * **[CiviCRM](https://lab.civicrm.org/groups/dev/-/issues)** (including `civicrm-core`, `civicrm-packages`, `civicrm-drupal`, `civicrm-joomla`, and `civicrm-wordpress`)
 * [civicrm.org website issues](https://lab.civicrm.org/marketing-team/civicrm-website)
 * [infrastructure issues](https://lab.civicrm.org/infrastructure/ops/issues)
-* *...and some [other projects](https://lab.civicrm.org/explore/projects)*
+* *...and many [other projects](https://lab.civicrm.org/explore/projects)*
 
-GitLab is divided into *groups* containing *projects* which may have *issues*.  Issues about CiviCRM itself are opened under projects within the Development Team group.
+#### How GitLab organizes things {:#gitlab-organizing}
 
-!!! info "GitLab Issue References"
-    With all the groups, projects, and issues, you may wonder how to consistently and clearly refer to a GitLab issue in a commit message, pull request, or other conversation.  GitLab has a standard style of `group/project#issue`, where `group` is the slug of the group, `project` is the name of the project, and `issue` is the issue number.
+* At the top level, GitLab is divided into [_groups_](https://lab.civicrm.org/dashboard/groups) (which are mostly analogous to _GitHub's_ concept of "organizations"). 
+* Groups own *projects* (and individual users can own projects, too).
+* Projects often contain *issues*.
 
-    For example, `dev/mail#1` refers to issue 1 from the Mailing project of the Development Team.
+Issues about CiviCRM itself are opened within the [Development Team's projects](https://lab.civicrm.org/dev/).
 
-    GitLab displays the issue reference at the bottom of the right-hand column along with a link that copies the reference to your clipboard:
+#### Referencing GitLab issues {:#gitlab-reference}
+
+Use text like `dev/core#1` to reference specific issues in your [commit messages](/tools/git.md#commit-messages), [pull request subjects](/tools/git.md#pr-subject), and other communication.
+
+In the above example:
 
+* `dev` is the *group*
+* `core` is the *project*
+* `1` is the *issue number*
+
+!!! tip
+    GitLab displays the issue reference at the bottom of the right-hand column along with a link that copies the reference to your clipboard:
+    
     ![Screenshot of GitLab issue reference](/img/gitlab-reference.png)
 
 ### GitHub {:#github}
@@ -41,7 +53,7 @@ Besides being a code repository for most CiviCRM projects, GitHub is used as an
 !!! note
     Some projects (e.g. CiviCRM core) have their repository hosted on GitHub but do *not* use the GitHub issue-tracking functionality. For these projects you will notice there is no "Issues" tab.
 
-### Jira {:#jira} (deprecated)
+### Jira (deprecated) {:#jira}
 
 **[issues.civicrm.org](https://issues.civicrm.org/jira)**
 
@@ -56,9 +68,9 @@ Used as an issue-tracking system until early 2018 for:
 
 ### When to create an issue {:#when-to-create}
 
-All changes to CiviCRM *Core*, however small, must receive a Jira issue. Among other things, this helps us assemble the [release notes](https://github.com/civicrm/civicrm-core/tree/master/release-notes).
+If you are ready to make a change to CiviCRM, you can [submit a pull request](/tools/git.md#pr) *without* creating an issue first.
 
-For other (non-core) ancillary projects, it's okay [submit a pull request](/tools/git.md#pr) *without* first creating an issue.
+Otherwise, you'll want to create an issue in order to track work that might need to be done at some point in the future.
 
 ### Check the latest version {:#check-version}
 
@@ -86,15 +98,23 @@ If you are able to coherently explain the problem and resolution—and reaso
 
 ### Research existing issues {:#research}
 
-It's now time to get your issue into [Jira](https://issues.civicrm.org/).  To start, search for existing issues that may be the same as or related to yours.  Jira's search will order by relevance, but you are searching over a decade of issues, so you may get overwhelmed with old items.  Consider filtering Created Date to two years ago or newer.
+Search for existing issues that may be the same as or related to yours. Because CiviCRM transitioned from [Jira](#jira) to [GitLab](#gitlab) in early 2018, you'll need to search in both systems for existing issues. Jira's search will order by relevance, but you are searching over a decade of issues, so you may get overwhelmed with old items.  Consider filtering Created Date to two years ago or newer.
 
 If an issue directly describes your situation, your job will be different: read it over, and edit or comment as necessary.  If the issue is marked as closed and completed, you should create a new issue indicating a regression, and you should link to the original issue you found.
 
 If issues you find are related but not quite the same, you should still record them so that you can mention them in the issue you create.
 
+### Open a blank issue {:#new}
+
+Begin creating your issue as follows:
+
+1. Sign in to [GitLab](https://lab.civicrm.org/)
+1. Navigate to the appropriate GitLab project. For CiviCRM core, look in the [Development Team's projects](https://lab.civicrm.org/dev/).
+1. Click the `+` button at the top of the screen and choose **New Issue**.
+
 ### Describe the issue {:#describe}
 
-Now's the time to create your issue.  Give it a title that describes your issue concisely, and explain the issue in the details.  In writing your issue, remember that your audience includes a variety of people:
+Give it a title that describes your issue concisely, and explain the issue in the details.  In writing your issue, remember that your audience includes a variety of people:
 
 -   Other users encountering the same problem now
 -   Maintainers deciding whether to include your code
@@ -118,7 +138,7 @@ The best leave no question as to what was going wrong or what has changed: somet
 
 #### Issue scope {:#scope}
 
-*It's important to keep your issue snappy and closeable.*  A Jira issue that stays open long after commits have been merged into core is confusing to users and demoralizing for contributors.  The way to prevent this is to make issues distinct and coherent so they're clearly done or not done.
+*It's important to keep your issue snappy and closeable.*  A issue that stays open long after commits have been merged into core is confusing to users and demoralizing for contributors.  The way to prevent this is to make issues distinct and coherent so they're clearly done or not done.
 
 Better yet, describe the issue distinctly and coherently yourself.  If you find an existing issue that was reported vaguely, there's no reason not to revise the description.  If the original issue involves several things, don't be shy about closing it and opening new ones--just document what you've done.
 
@@ -128,14 +148,6 @@ See also: [pull request scope](/tools/git.md#pr-scope)
 
 #### Categorization {:#categorization}
 
-Categorization is useful for finding issues in Jira, and it also determines how issues appear in the release notes.
-
-When setting the issue **Type**, "Bug" results in it being listed among Bugs Resolved in the release notes.  Otherwise, issues appear in Features.  
-
-The **Component/s** field determines where the issue goes in the notes, but it will only go one place.  There's no value in saying something is "Accounting Integration", "CiviContribute", "CiviEvent", and "WordPress Integration": the editor will pick the most relevant one for the notes.
-
-The **Priority** field can get contentious, but use your best sense as to the impact that your issue will have.  Think of it as the product of the breadth (the size of the user base that may notice) and depth (how much those users are affected) of the issue.
-
-**Affects Version/s** doesn't need to be each and every version that the problem affects, but it is helpful to indicate the extent of it.  Include the latest version you tested it on, and include the earliest version in the stable and long-term support series you know it to affect.
+Categorization is useful for finding issues, and it also determines how issues appear in the release notes.
 
-You might wonder what the **Funding Source** means.  If you plan on writing code yourself, mark it as "Contributed Code".  Otherwise, mark it as "Needs Funding".
+Use the Labels field to apply any relevant labels to your issue.