DevKit updates for 3.x branch (#3836)

.github/ISSUE_TEMPLATE.md

@@ -1,8 +1,12 @@
-Delete this sentence after you read the "Issues" paragraph from the
-"guidelines for contributing" link above.
+<!--
+    Before you open an issue, make sure this one does not already exists.
+    Please also read the "guidelines for contributing" link above before posting.
+-->
 
-If you are reporting a bug, please try to fill in the following, otherwise
-remove it along with this sentence.
+<!--
+    If you are reporting a bug, please try to fill in the following.
+    Otherwise remove it.
+-->
 
 | Question       | Answer
 |----------------|-------------------------------

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,48 @@
+<!-- THE PR TEMPLATE IS NOT AN OPTION. DO NOT DELETE IT! -->
+
+<!--
+    Specify which issues will be fixed/closed.
+    Remove it if this is not related.
+-->
+
+Closes #
+
+### Changelog
+
+<!-- MANDATORY
+    Fill the changelog part inside the code block.
+    Remove unneeded sections.
+    Follow this schema: http://keepachangelog.com/
+-->
+
+```markdown
+### Added
+- Added some `Class::newMethod` to do great stuff
+
+### Changed
+
+### Deprecated
+
+### Removed
+
+### Fixed
+
+### Security
+```
+
+### Subject
+
+<!-- Describe your Pull Request content here -->
+
+### To do
+
+<!--
+    Complete the tasks.
+    You can add as many tasks as you want.
+    If some are not relevant, just remove them.
+-->
+
+- [ ] My PR stuff
+- [ ] Update the tests
+- [ ] Update the documentation
+- [ ] Add an upgrade note

CONTRIBUTING.md

@@ -130,6 +130,32 @@ Notes:
     * If your BC PR is accepted, you can do a new one on the `master` branch which remove the deprecated code.
     * SYMFONY DOC REF (same logic)?
 
+If you have a non-BC PR to propose, please first try to create a related BC PR first.
+This BC PR should mark every piece of code that needs to be removed / uncommented / reworked
+in the corresponding non-BC PR with the following marker comment : `NEXT_MAJOR`.
+When the BC PR is merged in the stable branch, wait for the stable branch to be
+merged in the unstable branch, and then work on your non-BC PR.
+
+For instance, assuming you want to introduce a new method to an existing interface, you should do something like this:
+
+```php
+<?php
+
+namespace Foo;
+
+interface BarInterface
+{
+
+  // NEXT_MAJOR: Uncomment this method
+  /**
+   * This method does useful stuff.
+   */
+  // public function usefulMethod();
+
+  // …
+}
+```
+
 Be aware that pull requests with BC breaks could be not accepted
 or reported for next major release if BC is not possible.