Add CONTRIBUTING.md instead of README.commits

Add general information about code contribution to GVfs. Consequently
remove superseded README.commits.

2 files changed, 13 insertions, 68 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000..8caf3b38
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,13 @@
+# Contributing to GVfs
+
+For more GVfs development resources see https://wiki.gnome.org/Projects/gvfs.
+
+## Source Repository
+
+GVfs source repository is at https://gitlab.gnome.org/GNOME/gvfs.
+
+## Code Contribution
+
+See https://wiki.gnome.org/GitLab for general informations about GitLab workflow
+for code contribution. GVfs still uses linear GIT history without merge commits,
+please see general commit guidelines at https://wiki.gnome.org/Git/CommitMessages.
\ No newline at end of file
diff --git a/README.commits b/README.commits
deleted file mode 100644
index 85c26474..00000000
--- a/README.commits
+++ /dev/null
@@ -1,68 +0,0 @@
-GVfs is part of the GNOME git repository. At the current time, any
-person with write access to the GNOME repository, can make changes to
-GVfs. This is a good thing, in that it encourages many people to work
-on GVfs, and progress can be made quickly. However, we'd like to ask
-people committing to GVfs to follow a few rules:
-
-0) Ask first. If your changes are major, or could possibly break existing
-   code, you should always ask. If your change is minor and you've
-   been working on GVfs for a while it probably isn't necessary
-   to ask. But when in doubt, ask. Even if your change is correct,
-   somebody may know a better way to do things.
-
-   If you are making changes to GVfs, you should be subscribed
-   to gvfs-list@gnome.org. (Subscription address:
-   gvfs-list-request@gnome.org.) This is a good place to ask
-   about intended changes.
-
-   #nautilus on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
-   is also a good place to find GVfs developers to discuss changes with.
-
-1) Ask _first_.
-
-2) With git, we no longer maintain a ChangeLog file, but you are expected
-   to produce a meaningful commit message. Changes without a sufficient
-   commit message will be reverted. See below for the expected format
-   of commit messages.
-
-3) Try to separate each change into multiple small commits that are
-   independent ("micro commits" in git speak). This way its easier to
-   see what each change does, making it easier to review, to cherry pick
-   to other branches, to revert, and to bisect.
-
-Notes:
-
-* When developing larger features or complicated bug fixes, it is
-  advisable to work in a branch in your own cloned GVfs repository.
-  You may even consider making your repository publically available
-  so that others can easily test and review your changes.
-
-* The expected format for git commit messages is as follows:
-
-=== begin example commit ===
-Short explanation of the commit
-
-Longer explanation explaining exactly what's changed, whether any
-external or private interfaces changed, what bugs were fixed (with bug
-tracker reference if applicable) and so forth. Be concise but not too brief.
-=== end example commit ===
-
-  - Always add a brief description of the commit to the _first_ line of
-    the commit and terminate by two newlines (it will work without the
-    second newline, but that is not nice for the interfaces).
-
-  - First line (the brief description) must only be one sentence and
-    should start with a capital letter unless it starts with a lowercase
-    symbol or identifier. Don't use a trailing period either. Don't exceed
-    72 characters.
-
-  - The main description (the body) is normal prose and should use normal
-    punctuation and capital letters where appropriate. Normally, for patches
-    sent to a mailing list it's copied from there.
-
-  - When committing code on behalf of others use the --author option, e.g.
-    git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.
-
-
-Alexander Larsson
-17 Apr 2009