Update the contributor guide (#16326)

CONTRIBUTING.md

@@ -2,9 +2,11 @@
 
 First off, thanks for your interest in contributing!
 
+For video guides, you can watch [D Contributor Tutorials on YouTube](https://www.youtube.com/playlist?list=PLIldXzSkPUXXSkM5NjBAGNIdkd4Q2Zf0R).
+
 ## Reporting bugs
 
-We exclusively use [bugzilla](https://issues.dlang.org/) for issue tracking, which is why Github issues are disabled on this repository.
+While we are still transitioning to GitHub issues, we use [bugzilla](https://issues.dlang.org/) for issue tracking.
 Before reporting a bug, please [check bugzilla](https://issues.dlang.org/query.cgi) to see if it's already reported.
 If it isn't, [create a new issue](https://issues.dlang.org/enter_bug.cgi).
 
@@ -13,7 +15,7 @@ For questions about a specific behavior, the [D.Learn](https://forum.dlang.org/g
 ### Content
 
 When creating a new issue, include:
-- the version of DMD being used (which can be found by running `dmd` with no argument).
+- the version of DMD being used (which can be found by running `dmd --version`).
 - A test case:
   - Make it a [short, self-contained, and compilable example](http://sscce.org/).
   - Avoid dependencies on foreign code (e.g. dub packages).
@@ -42,26 +44,83 @@ Note that after a version has entered the release window (there is a beta / the
 
 ## Solving bugs / Submitting pull requests
 
-Before submitting a PR, check the following to make the pulling process run smoothly are:
+### Setting up a development environment
+Fork [dmd](https://github.com/dlang/dmd/fork) and [phobos](https://github.com/dlang/phobos/fork), and clone them.
 
-- Make sure to target the right branch. Regressions go to stable, and everything else to master, as outlined in [our release process](https://wiki.dlang.org/DIP75).
+```console
+git clone git@github.com:your-github-username/dmd.git
+git clone git@github.com:your-github-username/phobos.git
+```
 
-- When fixing a Bugzilla issue, use the title: 'Fix issue XXXXX - Issue title'.  This is recognized by both Bugzilla and our GitHub bot (dlang-bot),
+To be able to pull in updates after the fork is created, add the upstream repositories as a remote.
+
+```console
+cd dmd
+git remote add upstream git@github.com:dlang/dmd.git
+cd ../phobos
+git remote add upstream git@github.com:dlang/phobos.git
+```
+
+You can try building DMD by following the [instructions in the src folder](https://github.com/dlang/dmd/tree/master/compiler/src).
+
+### Finding bugs to work on
+
+You probably already have bugs that you want to see fixed, but if you need some easier bug fixes to start with, you can look for bugs with certain keywords such as:
+
+- [trivial](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=trivial&product=D).
+- [bootcamp](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=bootcamp&product=D).
+- [preapproved](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=preapproved&product=D).
+
+Improving error messages (keyword [diagnostic](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=diagnostic&product=D)) is also a great area to start.
+
+If you have a bug that isn't in the issue list yet, please file it.
+
+### Finding relevant code
+
+When you're not familiar yet with the code base, it can be hard to find where to make the appropriate changes.
+
+- Check the (DMD Source guide)[https://github.com/dlang/dmd/blob/master/compiler/src/dmd/README.md] to get an overview of the compiler's source structure.
+
+- Browse [Existing Pull Requests](https://github.com/dlang/dmd/pulls?q=is%3Apr) solving similar issues to see what files need to be updated for a certain kind of fix.
+
+- Searching for related error messages is also often helpful. For example: if you want to know where to find code that does implicit conversion, search "cannot implicitly convert expression".
+
+### Creating the fix
+
+Check out the `master` or `stable` branch, and pull in the latest changes.
+If you just forked the repository, you're probably already up to date.
+If it's been a while and you don't update, you might get merge conflicts and spurious test suite failures.
+
+```
+git checkout stable
+git pull --ff-only upstream stable
+```
+
+- Make sure to target the right branch.
+Regressions and bug fixes go to stable, new features go to master.
+See also: [our release process](https://wiki.dlang.org/DIP75).
+
+Create a new branch, and commit your code changes on there.
+```
+git checkout -b fix-bug
+```
+
+
+
+- When fixing a Bugzilla issue, use the title: 'Fix bugzilla issue XXXXX - Issue title'.  This is recognized by both Bugzilla and our GitHub bot (dlang-bot),
   and will automatically link the issue and the pull request together (by providing a link to the issue in Github, and automatically closing bugs when pull requests are merged).
 
+### General guidelines
+
 - Document the 'why' (the change is necessary and was done this way) rather than the 'how'.
 
-- Ensure newly introduced symbols are documented and that updates to existing symbols are reflected in the documentation.
+- Ensure newly introduced functions / variables are documented and that updates to existing ones are reflected in the documentation.
 
-- Add a link to the PR to the Bugzilla entry (if the dlang-bot failed to do it).
+- Confine a PR to addressing one issue, unless multiple issues are different aspects of the same bug.
 
-- Confine a PR to addressing one Bugzilla entry, unless multiple entries are different aspects of the same bug.
-
-- If submitting a bug fix PR that does not have a Bugzilla entry, add a Bugzilla entry for it and then submit the PR
-that fixes it.
 
 - If the pull request affects the language specifications in any way (i.e. changing the grammar, deprecating a feature, or adding a new one),
-  a pull request to [the website](https://github.com/dlang/dlang.org) should be submitted in parallel.
+  a pull request to [the specification in the dlang.org repository](https://github.com/dlang/dlang.org) should be submitted in parallel.
 
 - Follow the usual git good practice:
   - [Provide descriptive commit messages](https://chris.beams.io/posts/git-commit/)
@@ -69,13 +128,6 @@ that fixes it.
   - Separate commit for separate concerns
   - Keep pull requests focused on one single topic or bug.  For example, if the fix requires a refactoring, then submit the refactoring as a separate pull request.
 
-### Find bugs to work on
-
-For first-time contributors, look for issues categorized as [trivial](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=trivial&product=D).
-Continue with issues categorized [bootcamp](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=bootcamp&product=D).
-
-For a hassle-free contribution look for issues categorized as [preapproved](https://issues.dlang.org/buglist.cgi?component=dmd&keywords=preapproved&product=D).
-
 ## Refactoring
 
 The purpose of refactoring is to make the code easier to understand and extend. It is not to change the behavior of the
@@ -141,7 +193,7 @@ for comment blocks.
 If slicing from a `char*` is required then use `dmd.utils.toDString`
 or the member function `.toString` that is implemented in many classes.
 
-4. Use `ref`/`out` instead of raw pointers.
+4. Use `ref`/`out` parameters instead of raw pointers.
 
 5. Use nested functions to get rid of rats' nests of goto's.
 
@@ -187,7 +239,7 @@ without control flow statements.
 This was done successfully in src/dmd/escape.d, it wasn't easy, but
 it was well worth it.
 
-17. Try to eliminate reliance on `global.errors`.
+17. Try to eliminate reliance on `global.errors`, use `dmd.errorsink: ErrorSink` instead.
 
 18. For aggregates that expose public access to fields, think hard about why this is
 necessary and if it can be done better. Merely replacing them with read/write properties