meta: git controls for text changelogs; github controls

For the ChangeLog and files like it, use `merge=union` to bring in
content from both sides instead of having conflicts block merges because
someone else added a feature.

For GitHub, provide some "templates" which really just point people in
the right direction, but if the repointing fails, at least reduces the
pain a little.

3 files changed, 89 insertions, 0 deletions

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000000000..30567178e
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,7 @@
+# Using merge=union should make it easier to maintain changelogs across
+# branches, by using the text from both sides for the merge.
+#
+doc/doc-txt/NewStuff         merge=union
+doc/doc-txt/ChangeLog        merge=union
+doc/doc-txt/OptionLists.txt  merge=union
+src/README.UPDATING          merge=union
diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md
new file mode 100644
index 000000000..2a9348e2b
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE.md
@@ -0,0 +1,41 @@
+# The Exim Project does not use GitHub Issues
+
+Hey, we want your input, but we want to make sure that we actually see it and
+that your help is not wasted, so please read this.
+
+The GitHub repo exists for convenience for some folks, and to host our Wiki.
+The Git repo is an automated clone of our real repo over at
+<https://git.exim.org/exim.git>.
+
+Sometimes a maintainer will take a look at GitHub issues, just because we care
+about the software and want to know about issues, but expect long delays.
+It's not a really supported workflow.
+
+If you need help with configuration, or _think_ you've found a bug, then the
+Exim Users mailing-list is the place to start.  Many experienced postmasters
+hang out there: <https://lists.exim.org/mailman/listinfo/exim-users>
+
+Our documentation is _very_ extensive and if the behavior does not match the
+documentation, then that's a bug to be reported.
+<https://www.exim.org/docs.html>
+In addition, if using Debian or a derivative (such as *Ubuntu*), then you
+should read: <https://pkg-exim4.alioth.debian.org/README/README.Debian.html>
+
+If you're absolutely sure it's a bug, and it's not a security problem, then
+our Bugzilla is the main place to go: <https://bugs.exim.org/>
+
+If you've found a security bug, then please email <security@exim.org>.
+All Exim Maintainers can and do use PGP.
+Keyring: <https://ftp.exim.org/pub/exim/Exim-Maintainers-Keyring.asc>
+We don't have a re-encrypting mailer, just encrypt to all of them please.
+
+
+## If you MUST file an issue on GitHub
+
+Read "How to Report Bugs Effectively":
+<https://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
+
+Please include the OS details, output of `exim -d -bV 2>/dev/null`
+and as much information as you think is relevant.
+
+Thanks.
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index 000000000..8fa5a40df
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,41 @@
+# The Exim Project does not use GitHub Issues
+
+Hey, we want your input, but we want to make sure that we actually see it and
+that your help is not wasted, so please read this.
+
+The GitHub repo exists for convenience for some folks, and to host our Wiki.
+The Git repo is an automated clone of our real repo over at
+<https://git.exim.org/exim.git>.
+
+Sometimes a maintainer will take a look at GitHub pull requests, just because
+we care about the software and want to know about issues, but expect long
+delays.  It's not a really supported workflow.
+
+Our bug-tracker takes code-patches and is the place to go:
+<https://bugs.exim.org/>
+
+If you've found a security bug, then please email <security@exim.org>.
+All Exim Maintainers can and do use PGP.
+Keyring: <https://ftp.exim.org/pub/exim/Exim-Maintainers-Keyring.asc>
+We don't have a re-encrypting mailer, just encrypt to all of them please.
+
+## If this is too much hassle ...
+
+We do periodically get around to checking GitHub Pull Requests.
+It just won't be fast.
+
+Patches should update the documentation, `doc/doc-docbook/spec.xfpt`; if you
+like, just provide the plaintext which should go in there and we can mark it
+up.
+
+If it's a whole new feature, then please guard it with a build
+option `EXPERIMENTAL_FOO`; docs are in plaintext in
+`doc/doc-txt/experimental-spec.txt`.
+
+If you're feeling particularly thorough, these files get updated too:
+* `doc/doc-txt/ChangeLog` : all changes; workflow pre-dates Git
+* `doc/doc-txt/NewStuff` : if it's a change in intended behavior which postmasters should read
+* `doc/doc-txt/OptionLists.txt` : (we usually defer this until cutting a release)
+* `src/README.UPDATING` : if you're breaking backwards compatibility
+
+Thanks!