Substantially rewrite a lot of pages

Rework our front page to be a lot more useful, as well as links to getting involved and starting new projects. Rewrite our mission statement to be more consistent with what we've actually interpreted it as for the last ten years. This probably requires further tweaking. Make a first cut at improving the specs page, though this needs a lot more work. Mostly rewrite infrastructure-related pages to semi-accurately reflect the current state of things. LightDM has fully moved to GitHub now, so have their page just be a redirect rather than an orphan.
author: Daniel Stone <daniels@collabora.com> 2019-02-18 19:35:52 +0000
committer: Daniel Stone <daniels@collabora.com> 2019-02-18 19:35:52 +0000
commit: ff5c2a0f479921c28ab40e2e6ef162e3a78929ef (patch)
tree: ca7785eefecb3d00f15ae0a8e59ec7a82658aedd
parent: 139acf42b7874c98be14d55ecf70aeed472a6529 (diff)
17 files changed, 204 insertions, 587 deletions
diff --git a/AccountMaintenance.mdwn b/AccountMaintenance.mdwn
index 4784f838..5678d563 100644
--- a/AccountMaintenance.mdwn
+++ b/AccountMaintenance.mdwn
@@ -1,40 +1 @@
-
-This page is not about getting new accounts.  If you do not currently have a fd.o account, see [[AccountRequests]]. 
-
-
-# Account Maintenance
-
-freedesktop.org uses a user management system entitled userdir-ldap.  More information on ud-l can be found at [[Debian's information page|http://db.debian.org/doc-mail.html]]. 
-
-This page describes the mail interface, which assumes you have a GPG key attached to your account.  If this is not the case, please file a bug on [[the Account Changes component|https://bugs.freedesktop.org/enter_bug.cgi?product=freedesktop.org]] in Bugzilla first, with your GPG key attached as a text/plain file, and noting the account which the key should be attached to.  Please also make sure it's visible on the subkeys.pgp.net keyserver. 
-
-The web interface is not operational at this time. 
-
-
-## Adding/removing SSH keys
-
-The mail gateway maintains SSH keys by _replacing_ all keys with the contents of the mail.  Send the mail, GPG-signed, each key on a new line: 
-
-    cat ~/.ssh/key1.pub ~/.ssh/key2.pub ~/.ssh/key3.pub | gpg --clearsign | mail change@db.freedesktop.org
-
-You will receive a mail back within a few minutes confirming your changes.  Note again that this replaces the entire list of keys: following the example above, if you previously had key1 and key4 active, the new set would be key1, key2, and key3: key4 would be excluded.  Note that this is important as password logins are not available on freedesktop.org. 
-
-**(EC)DSA keys are not accepted!** Due to security reasons relating to an OpenSSL vulnerability, (EC)DSA keys (as well as legacy RSA1 keys) will not be accepted. 
-
-**Note: Your total key length must be <=1024 characters in ascii, hence anything longer than a 4096bit key will not work** 
-
-**Note2: If you get the error: "Message Error: Verification of signature failed" your email is probably being line wrapped, try a different client** 
-
-**Note3: If you never get a reply back, make sure your return address is actually valid.** 
-## Changing email address
-
-    echo 'emailforward: new@address.com' | gpg --clearsign | mail change@db.freedesktop.org
-
-## Getting a copy of your current details
-
-
-    echo 'show' | gpg --clearsign | mail change@db.freedesktop.org
-
-Your LDAP record will be mailed back to you, GPG-encrypted.  Most of these details can be changed by sending the same string back to [[change@db.freedesktop.org|mailto:change@db.freedesktop.org]], e.g.: 
-
-    echo 'gecos: Full Name' | gpg --clearsign | mail change@db.freedesktop.org
+This page used to contain information about how to modify legacy freedesktop.org SSH accounts. Since these accounts are mostly not used any more, the content has been removed. If you need to modify an existing SSH account, please file a [new issue on freedesktop/freedesktop](https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new) and an admin will help you.
diff --git a/AccountRequests.mdwn b/AccountRequests.mdwn
index 875ebcab..64723d30 100644
--- a/AccountRequests.mdwn
+++ b/AccountRequests.mdwn
@@ -1,60 +1,13 @@
 # How to request a freedesktop.org account
 
-## Wiki accounts
-
-To be able to edit wiki pages at freedesktop.org, you don't need an SSH account, you need a wiki account. These are easy to get, requiring just the assistance of someone with an ssh account. Check out the [401 unauthorized](http://wiki.freedesktop.org/sitewranglers/wiki/401/) page for instructions.
-
-## SSH accounts
-
-To obtain an ssh account for a project hosted by freedesktop.org, you must follow these rules. Failure to do so will probably result in your request getting dropped on the floor. Don't take it personally if it does, the rules are there to make sure it doesn't happen, so if they aren't followed ... 
-
-## What you need
-
-Passwords are not used for the accounts at freedesktop.org. Instead, SSH keys are used. Therefore, you will need to have you SSH key at hand when requesting an account. Also, you must have a GPG key available so that you can identify yourself for future account maintainance requests. 
-
-If you already have an account, and these key are already in place, then you don't need to supply them with your request. 
-
-
-## Requesting a New Account
-
-
-### What you do
-
-* go to <http://bugs.freedesktop.org>
-* Create a bug asking for an account. Select the Product that corresponds to the Project for which you are requesting access.  If there's no product in bugzilla for the project in question, file it against the freedesktop.org product, in the New Accounts component. 
-* You MUST include your real name, email address, and a preferred account name. 
-* You MUST attach both your SSH (RSA only -- no DSA!) and GPG public keys to this bug.  Please attach them as text/plain.  Please make sure you add them as attachments, not inline in the bug. 
-* Verify that your GPG key is visible via subkeys.pgp.net and/or pgp.mit.edu: `gpg --keyserver subkeys.pgp.net --send-keys 0xdeadbeef`
+The good news is ... you don't need to!
 
-(replace `0xdeadbeef` with your key id; note also that the server is subkeys.**pgp**.net, not subkeys.gpg.net) 
+For almost all freedesktop.org projects, you can simply register with [our GitLab instance](https://gitlab.freedesktop.org) and immediately contribute back through issues and merge requests. At the maintainer's discretion, they may give you access to directly push your own code to the project.
 
-To generate a GPG key, run `gpg --gen-key`, and `gpg --export -a <your email address>` to export the public key in a format suitable for attaching.  You MUST keep your private key secure; anyone with your private key can now get access to fd.o machines, and potentially compromise source code!  A strong passphrase is recommended, as is not keeping it on any public machines.  If a private key is found on a freedesktop.org machine, it will be removed from the keyring, and a new one will have to be created. 
-
-To generate an SSH key, run `ssh-keygen -t rsa -f ~/.ssh/mykey-fdo`.
-Neither (EC)DSA nor RSA1 keys will be accepted, so choose another key type, such as `rsa` or `ed25519`.
-This will put your new public key in `~/.ssh/mykey-fdo.pub`; to use it, add `-i ~/.ssh/mykey-fdo` to your SSH command line (e.g. `ssh -i ~/.ssh/mykey-fdo annarchy.freedesktop.org`), or create a stanza in `~/.ssh/config` like so: 
-
-    Host *.freedesktop.org
-        User myusername
-        IdentityFile ~/.ssh/mykey-fdo
-
-Mac users should see [[MacGPG|http://macgpg.sourceforge.net/]] for information about running GPG on Mac.  Windows users should see [[PuTTY|http://www.chiark.greenend.org.uk/~sgtatham/putty/]] for information on using SSH clients in Windows, including key generation. 
-
-_DO NOT ATTACH YOUR PRIVATE SSH KEY.  DOUBLE CHECK THAT IT IS A ONE-LINE PUBLIC KEY, AND NOT A PRIVATE KEY._ 
-
-
-### What the Project Leader does
-
-* Review and approve the request for an account & access to your project. 
-* Reassign the bug to the **freedesktop.org** Product with the Component set to **New Accounts**, Make sure the owner is changed to ** [[sitewranglers@lists.freedesktop.org|mailto:sitewranglers@lists.freedesktop.org]] **. 
-If everything is in order, and all of the data is provided, then the account will be created, usually within a few days, with possible exceptions around holidays and major conferences.  Don't freak out if it ends up taking longer than this: we're all humans, sometimes we're busy humans.  Your request isn't being ignored or forgotten, it's just that no-one has the time to get to it right now. 
-
-
-## Requesting Modifications
-
-If you want to add a GPG key to your account or get added to another project, this requires manual intervention.  Go to [[Bugzilla|https://bugs.freedesktop.org/enter_bug.cgi]] and file a new bug.  If you need to add a GPG key, assign it to freedesktop.org, component Account Changes; if you need to be added to a new project, assign it to that project (not freedesktop.org) for approval by the project maintainer.  Project leaders will follow the same procedure as above to approve an addition request. 
+Most projects should have a `CONTRIBUTING` file in their main repository, describing how you can get started by contributing code. Usually this will involve pushing a new feature or bugfix in your own fork of the repository, then contributing this back via a GitLab merge request, where the project reviewers and maintainers may ask you to make some changes before they can merge it. For some projects, a mail-based workflow is used, where you have to email your patches to a mailing list. These instructions should be clearly documented by the project.
 
+## Wiki accounts
 
-# Account Maintenance
+To be able to edit wiki pages at freedesktop.org, you don't need an SSH account, you need a wiki account. These are easy to get, requiring just the assistance of someone with an ssh account. Check out the [401 unauthorized](http://wiki.freedesktop.org/sitewranglers/wiki/401/) page for instructions.
 
-For details on how to change your SSH keys, email address, etc, see [[AccountMaintenance]]. 
+If you would like to contribute to the kernel repositories (`drm`, `drm-firmware`, `drm-misc`, `drm-tip`, `drm-amd`, `drm-intel`), then in this case you still need a SSH account. In this case, please [file an issue on freedesktop/freedesktop](https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new) and choose the 'New SSH account' template from the drop-down on the top left.
diff --git a/GettingInvolved.mdwn b/GettingInvolved.mdwn
index 6f3bddd5..85f16358 100644
--- a/GettingInvolved.mdwn
+++ b/GettingInvolved.mdwn
@@ -1,64 +1,39 @@
-## Getting Involved in freedesktop.org
+## Getting involved in freedesktop.org projects
 
-freedesktop.org is always looking for more involvement. Remember that freedesktop.org is a project for developers interested in working on shared desktop code, specifications, or documentation. 
+freedesktop.org and our member projects are always looking for more involvement: contributions of code, testing, documentation, QA, triage, support, and more, are always welcome.
 
-<a name="MailingLists"></a> 
-### Mailing Lists
-
-If you're interested in working on specifications, the best way to get started is to join our mailing list; mail [[xdg-request@lists.freedesktop.org|mailto:xdg-request@lists.freedesktop.org]] with the word "subscribe" in the subject of your email. xdg-list has archives and on-the-web subscription [[here|http://lists.freedesktop.org/mailman/listinfo/xdg]]. 
-
-For other mailing lists and archives, go [[here|http://lists.freedesktop.org/mailman/listinfo]]. 
-
-Again, because this is important: XDG is not a diplomacy project, we want to actually work on specifications rather than discussing what the specifications could contain. Whenever possible, discussion on xdg should focus on a concrete _draft specification_ or _existing code_. It's best to post a draft of a document, or go ahead and code something up, rather than asking for comments on an abstract topic. 
+Generally, the first point of call is to find the project you want to work on. You can find a list of [[our software projects|Software]] and [[our specifications|Specifications]] on this wiki. Most of these projects and/or specifications will have their own Git tree, wiki, and mailing list, where you can browse the code and any current open issues, and get involved with development.
 
-For general freedesktop.org discussion, please mail [[freedesktop@lists.freedesktop.org|mailto:freedesktop@lists.freedesktop.org]]. 
+There are also guidelines for [[proposing a new project|NewProject]], or for anything else you can [[contact the administrators|https://lists.freedesktop.org/mailman/listinfo/sitewranglers]].
 
 
-### Source Code: Subversion
-
-A few FD.o projects use Subversion as their revision control system. Developer access is possible using _svn+ssh://$user@svn.freedesktop.org/svn/$project_. And then [[there's WebSVN, too|http://websvn.freedesktop.org/]]. TODO: is there anonsvn available at all? 
-
-<a name="GIT"></a> 
-### Source Code: Git
-
-Most FD.o projects have been moved to the git revision control system.  See [[UsingGit|UsingGit]] for more information on using git. 
-
-Read-only [[Git|http://git.or.cz/]] repositories are hosted at git://git.freedesktop.org, browsable online [[using cgit|https://cgit.freedesktop.org/]].  Each project may create a repository on git.freedesktop.org in `/srv/git.freedesktop.org` using `GIT_DIR=/srv/git.freedesktop.org/{project}.git git init-db` and then they can push commits to that tree with git push. 
-
-<a name="CVS"></a> 
-### Source Code: CVS
+<a name="MailingLists"></a> 
+### Mailing lists
 
-Anonymous CVS is available from: 
+You can browse [[all our mailing lists|https://lists.freedesktop.org]]. Most projects have their own mailing list, or specifications are mostly discussed on [[the xdg@ list|https://lists.freedesktop.org/mailman/listinfo/xdg]].
 
-    cvs -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/<project> login
-    cvs -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/<project> co <module>
+All these mailing lists are open subscription: you are more than welcome to join.
 
-You can browse the modules via web at [[http://webcvs.freedesktop.org|http://webcvs.freedesktop.org]]. 
+Please be specific when sending mails: the more detail you can include about what you are trying to achieve (and more importantly, why!), the higher the odds that we can help you.
 
-**Beware**: for projects that have moved to git, the source code in CVS is out of date. 
+For general discussion about freedesktop.org as a project, we have [[the freedesktop@ list|https://lists.freedesktop.org/mailman/listinfo/freedesktop]].
 
-CVS commits can be monitored on a per-project basis.  See the project's page for more info. 
 
-See [[UsingCvs]] for help with developer CVS access.  Check out the [[MAINTAINERS|http://webcvs.freedesktop.org/xorg/doc/xorg-docs/MAINTAINERS?view=markup]] list for information about which lists or which people to contact about a given piece of software. 
+<a name="GIT"></a> 
+### Source code and bugs
 
-If you have some code that may be of cross-desktop interest, we're happy to host it on our CVS server, and you may want to bring it up for discussion on xdg-list. Mail [[the fd.o admins|mailto:sitewranglers@lists.freedesktop.org]] with requests for CVS access; be sure to include a pointer to the work you want to put in CVS. 
+Almost all freedesktop.org projects will have one or more projects on [[our GitLab instance|https://gitlab.freedesktop.org]]. From here, you can clone the existing code, browse existing and file new issues, push back your own contributions and raise a merge request, and more. This is the main entry point for a lot of our projects.
 
-<a name="Bugzilla"></a> 
-### Bugzilla
+You are free to create new accounts on GitLab in order to contribute to our projects.
 
-The freedesktop.org bugzilla can be found on [[https://bugs.freedesktop.org|https://bugs.freedesktop.org]].
 
 <a name="Translations"></a> 
 ### Translations
 
 See the [[Translations]] page to find out where you can contribute translations for some freedesktop.org packages. 
 
+
 <a name="IRC"></a> 
 ### IRC
 
-Join us on #freedesktop on [[freenode|http://freenode.net/]]. 
-
-<a name="Wiki"></a> 
-### Wiki
-
-Active work on this website is found at [[RecentChanges]].  Work to be done on the website can be found in [[WantedPages]] and [[OrphanedPages]]. 
+If you have an IRC client, you can join us on #freedesktop on [[freenode|http://freenode.net/]]. You may not get a response immediately, so please be patient and wait in the channel if you would like to discuss anything.
diff --git a/Infrastructure.mdwn b/Infrastructure.mdwn
new file mode 100644
index 00000000..3ea97fdb
--- /dev/null
+++ b/Infrastructure.mdwn
@@ -0,0 +1,52 @@
+# freedesktop.org infrastructure
+
+Our infrastructure falls into two categories.
+
+## GitLab
+
+gitlab.fd.o is hosted on the Google Cloud Platform within us-east1, run on Kubernetes with Helm charts. The [Helm charts](https://gitlab.freedesktop.org/freedesktop/helm-gitlab-omnibus) and the [Helm configuration](https://gitlab.freedesktop.org/freedesktop/helm-gitlab-config) used to deploy are both publicly available.
+
+Repositories and the PostgreSQL database are both stored on persistent disks mapped into the Kubernetes service pods.
+
+Docker Registry images, file uploads and attachments, and backups, are all stored within Google Cloud Storage buckets. Backups are retained for one week.
+
+There are two shared runners available for all GitLab CI jobs:
+* fdo-gitlab-gce-runner3 executes 4 concurrent jobs, and is a 22 vCPU, 128GB RAM worker hosted in GCE's us-east1, with 1TB of NVMe storage
+* gst-gitlab-htz-runner1 executes 6 concurrent jobs, and is a 24 vCPU, 128GB RAM worker hosted in Hetzner Germany, with 256GB of SSD storage
+
+Given the level of concurrency, you should aim for each job to parallelise with 4 concurrent processes.
+
+It is possible to add runners for your own projects, however this has significant caveats. Most obviously, your runners should be faster than the shared runners, unless your goal is just to remove load from the shared runners. Speed of storage is quite important here, and you should also have a fast network to Google us-east1, especially if your pipeline has multiple stages, as the build contents are saved, uploaded, and re-downloaded, between each stage. If you need to run Docker-in-Docker (e.g. to build Docker images to execute in), your runner must have the `privileged` flag set, which means you must consider the host machine to be completely compromised as the root user. Using tools such as [[buildah|https://github.com/containers/buildah]], [[kaniko|https://github.com/GoogleContainerTools/kaniko]] or [[img|https://github.com/genuinetools/img]] may help you avoid the need for a privileged runner.
+
+If you would like to donate execution time for shared runners, please [[file an issue|https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new]] or [[contact the admins|https://lists.freedesktop.org/mailman/listinfo/sitewranglers]] and we can discuss this. Our main considerations when accepting new runners are performance (should be similar to existing runners), reliability (should not unduly cause failures, or huge spikes in build times due to external load), and security.
+
+How Git itself is served is in the [[Git page|Infrastructure/git]].
+
+## Everything else
+
+All the other services are run on a small fleet of machines hosted at Portland State University. These machines all run Debian. They are all (with the exception of fruit?) virtual machines.
+
+This list is not quite complete.
+
+* fruit.fd.o (admin only): runs OpenLDAP and a very ancient fork of Debian's userdir-ldap, used to produce our user account database which is then distributed to all the other machines with rsync
+* gabe.fd.o (restricted access): serves DNS with Bind for fd.o and X.Org; MX with Postfix for all incoming fd.o/x.org mail and the only outgoing mail relay; runs Apache for web access to Mailman lists; hosts some confidential X.Org Board of Directors information; is still somehow 32-bit
+* kemper.fd.o (restricted access): git.fd.o host for master Git repo storage; users can push with Git but not get a shell; exports read-only NFS mountpoint for git
+* annarchy.fd.o (open access): serves HTTP with Apache for most project-specific pages, the www.fd.o wiki, and people.fd.o; general shell host; much abused for arbitrary user file storage and exchange; serves home directories over NFS
+* molly.fd.o (admin only): serves anongit with git-daemon over NFS mounts from kemper/annarchy; serves cgit via Apache; runs Postfix for incoming bug mail
+* culpepper.fd.o (admin only): serves Bugzilla over Apache
+* emeril.fd.o (restricted access): serves Patchwork (in Python venv) and members.x.org (in Docker container); runs Postfix for incoming Patchwork mail
+
+Virtual machines:
+* patrick.fd.o (admin only): used for adminstering VMs?
+* ray.fd.o (admin only): VM host?
+* todd.fd.o (admin only): VM host?
+* cornelius.fd.o (admin only): VM host?
+* patrick2, lyle, teodor (admin only): ?
+
+## Plans
+
+Most of our planning is discussed in [[freedesktop/freedesktop issues|https://gitlab.freedesktop.org/freedesktop/freedesktop/issues]] on GitLab.
+
+## Contacts
+
+The admins are reachable through GitLab issues or the [[sitewranglers list|https://lists.freedesktop.org/mailman/listinfo/sitewranglers]].
diff --git a/Infrastructure/git.mdwn b/Infrastructure/git.mdwn
index 13e74cd7..1f9abe0c 100644
--- a/Infrastructure/git.mdwn
+++ b/Infrastructure/git.mdwn
@@ -1,41 +1,23 @@
+freedesktop.org provides its code through Git, most of which can be found on [[our GitLab instance|https://gitlab.freedesktop.org]], or linked from our [[Software]] page.
 
+For more information on using Git, plenty of documentation is available on the internet, e.g. [[the Git book|https://git-scm.com/book/en/v2]] or GitLab's own help, available from the top of every page.
 
-## Users
+## How our Git is served
 
-Information for users who want to check out repositories and use them to build code and isolate bugs can find more information on [[the users page|Infrastructure/git/Users]]. 
+The following is probably not interesting to you, unless you care about the particular details of how our servers are configured.
 
+gitlab.fd.o is the master for all Git repositories (apart from the kernel), which is hosted on the Google Cloud Platform. For more details, see [[Infrastructure]].
 
-## Developers
+git.fd.o, anongit.fd.o, and cgit.fd.o are still run on the 'old' fd.o fleet at Portland State University, on the kemper.fd.o VM for git and molly.fd.o for anongit and cgit. git.fd.o/kemper has the master storage, exporting a read-only NFS mount to anongit/cgit. Similarly, annarchy.fd.o's `/home` (for people.fd.o) is NFS mounted into molly to allow cloning as well as cgit access.
 
-Information for developers who want to commit code and push and/or send patches can be found on [[the developers page|Infrastructure/git/Developers]]. 
+All repositories which started off on git.fd.o are still push-mirrored back from GitLab to the old locations; new repositories are not mirrored.
 
-Owen Taylor has created a tool for integrating git and bugzilla updates.   Documentation is [[provided with the tool|http://git.fishsoup.net/cgit/git-bz/tree/git-bz.txt]] and it has been further described in Owen's blog: [[git-bz: Bugzilla subcommand for Git|http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/]], [[git bz push|http://blog.fishsoup.net/2009/09/05/git-bz-push/]]. 
+The mirroring is performed in a `post-receive` Git hook on the GitLab server. The hook is common to all repositories, in a common location with symlinks being manually placed in each repo's `custom_hooks` directory when the repo is created.
 
+Most manual hooks are still run from git.fd.o: anything that in particular sends email cannot be done directly from GitLab's GCP server, so we do this from kemper.
 
-## Creating your own repository
+## GitHub mirror
 
-Please see the [[repository admin page|Infrastructure/git/RepositoryAdmin]]. 
+The [[GitHub freedesktop mirror|https://github.com/freedesktop]] is controlled by us, and run from kemper. Each repo has a `post-receive` hook which writes the repo path into a socket; a daemon then runs and pushes out as a full mirror to GitHub with a magic hidden SSH key.
 
-
-## cia.vc integration
-
-If you want your notifications on IRC, we support integration with CIA.vc.  File a ticket to have your hook scripts updated, and make sure to tell us what the cia.vc project name is. 
-
-
-## Migration from CVS
-
-Instructions on [[migrating from CVS|Infrastructure/git/Migration]] are available. 
-
-
-## Wishlist
-
-We are also maintaining a rough wishlist of what we'd like to see [[changed in git|Infrastructure/git/UIFlaws]]. 
-
-
-## More Resources
-
-More documentation for both users and developers can be found at these sites: 
-
-* [[GitWiki: Git Documentation|http://git.or.cz/gitwiki/GitDocumentation]] 
-* [[The Git Community Book|http://book.git-scm.com/]] 
-* [[The Git Parable|http://tom.preston-werner.com/2009/05/19/the-git-parable.html]] 
-\ No newline at end of file
+This means that pushes are doubly chained: the user pushes to gitlab.fd.o, which synchronously runs a `post-receive` hook that pushes to git.fd.o; git.fd.o synchronously runs its `post-receive` hooks, with the GitHub mirror running asynchronously. This means that pushes to GitLab may hang, or return errors, if git.fd.o is unavailable or its hooks fail.
diff --git a/Infrastructure/git/Developers.mdwn b/Infrastructure/git/Developers.mdwn
index 29d9f240..074f2fa7 100644
--- a/Infrastructure/git/Developers.mdwn
+++ b/Infrastructure/git/Developers.mdwn
@@ -1,152 +1 @@
-Several projects have been moved to the git revision control system.  While there exist tutorials out there for using git, one of git's features is that it allows people to use many different workflows, so many of those tutorials won't apply to git as it's used in X.Org projects.  We might call what we usually do "shared central repository" mode.
-
-Things which are within the scope of this document:
-
-* Checking out code
-* Committing code
-* Resolving conflicts
-* Working on branches
-Things which are not within the scope of this document:
-
-* Using the index for selective committing
-First note about git: there are many commands.  Each command exists as an argument to the git command (`git clone`) and also as a hyphenated version to aid in tab-completion ("git-clone").
-
-The next thing to understand is that when you check out code from a remote git repository, you end up with a full-fledged git repository yourself.  When you diff, commit, etc. code, you are doing it against your local repository.  Clone, pull, and push are used to move changes between repositories.  Your local repository is stored in the .git directory at the top of the tree.
-
-
-## Checking out
-
-If you have an anonymously-checked out repository which you now wish to use to push, you can edit `.git/remotes/origin` and replace the contents of the `URL: ` line (change `git://` to `ssh://`, and `anongit.freedesktop.org` to `git.freedesktop.org`).
-
-If your username at freedesktop.org is different from local, the refspec becomes `ssh://myusername@git.freedesktop.org/git/xorg/lib/libX11`, or you can just add the following to `~/.ssh/config` to tell ssh your default username for all of freedesktop.org:
-
-    Host *.freedesktop.org
-            User myusername
-
-## Viewing diffs
-
-Now, you have a copy of the master branch of the tree.  Go ahead and build it and whatever else.  If you make some changes, you can see what files you would commit with `git status -a` or get a diff of the local tree against the repository with ` git status -a -v`
-
-The `-a` flag means all local updates.  The git system actually has this concept of an "index", managed using `git-update-index`, which lets you selectively commit changes.  However, because this adds to confusion, I will leave learning about the index up to you to do later.
-
-
-## Getting the latest upstream code
-
-There are two ways to update your local repository. Which one to use depends on whether you have committed changes in the meantime.
-
-
-### No changes: pull
-
-The command to update your local repository is:
-
-    git pull
-
-It will pull down the latest repository information from the `origin` remote file (which points at where you initially cloned the repository from), then merge.  If the new changes don't conflict with anything locally, the merge will "fast-forward" your branch reference to the new head.  If new changes do conflict, it will try to do an automatic merge using a couple of different schemes, and then automatically commits the merge if it's satisfied.  If you notice that your pull resulted in a merge (in the output of pull), you might want to use `gitk` to see if the merge did what you expected it to.  If it isn't satisfied, then you have to resolve the conflict manually.
-
-
-### You've made changes: fetch and rebase
-
-If you have committed local changes, then `git-pull` will create a spurious "Merge" commit, which will pollute the change list when you later push upstream. To avoid this, do these two commands:
-
-    git fetch
-    git rebase origin
-
-Instead of merging, this attempts to insert the changes you pull from the origin repository before your local changes, avoiding the merge message.
-
-
-## Dealing with conflicts
-
-If you get a serious conflict that can't be merged automatically, git will leave familiar conflict markers in the files, and `git status` should say that you've got unmerged files.  Go edit them and fix your conflicts, and test.  After you do so, `git status` will still be noisy about unmerged files (since you haven't updated the index to say you've merged them), but you can still do
-
-    git commit -a
-
-and commit your merge.  It hands you a default log message for the merge, and it will retain the information on the parents of the commit you did, so that branch history is maintained.
-
-
-## Reverting commits
-
-It may happen that you commit something you really didn't want to go into the repository.  This is not referring to broken changes, but things like mis-merges or getting branches confused.  If you haven't pushed the code upstream, then it's really easy to make it look like the commit didn't happen.  To reset to the immediate previous revision, you would run:
-
-    git reset --hard HEAD^
-
-
-## Reverting code prior to commit
-
-git doesn't have a revert command like svn. Instead, just run `git checkout -- <yourfile>` to revert it to the last committed version. The `--` isn't necessary in most cases, but does provide extra insurance.
-
-
-## Committing code
-
-If you're satisfied with your diff, you could commit it with: `git commit -a`
-
-The commit message should have a one-line summary ('Add support for FooBazzle 700'), and then a longer explanatory paragraph, separated by a blank line, e.g.:
-
-    Add support for FooBazzle 700
-
-    Add support for the FooBazzle 700, which is an interesting device in
-    that it does not actually exist.  This is our first driver for an
-    entirely ficticious device, and as such, it performs no rendering.
-
-Your subject line should include the subsystem name (for example, 'KDrive: Fix keymap memory leak', not just 'Fix leak'), unless it's entirely redundant.
-
-After you enter your log message, it will quickly terminate.  You've now committed your diff to your local repository.  You could run:
-
-    gitk
-
-to see your diff in the history now.  Note that the `gitk` output actually shows two branches: master and origin.  The `master` branch is the head of development in the local tree.  The `origin` branch is the last version from upstream.
-
-
-## Pushing your code upstream
-
-Now that you've resolved the conflicts (if any) with others upstream, you're ready to push your changes.  To do this, type
-
-    git push origin
-
-This tells git to push every branch in a `Push:` line in the `origin` remote upstream (more on the Push: lines later).  Unlike `git pull`, `git push` does require you to specify the remote and doesn't have a default.
-
-
-## Emailing your code upstream
-
-If you do not have direct commit access or wish to get patch review, type: `git format-patch origin` (assuming you're on master)
-
-This will generate a few sequentially-numbered text files, one per patch (e.g. `0001-Add-support-for-FooBazzle-700.txt`, `0002-Fix-memory-leak.txt`), in mbox format.  These can be sent individually.  If part of a series, use the `-n` argument to `git format-patch`, so their subjects will be '[PATCH 1/7] Add support for FooBazzle 700', and so on, and so forth.
-
-Traditionally, a '[PATCH 0/7] FooBazzle-related enhancements' mail would be sent to the list first, giving a relatively long explanation of the patchset, as well as a very brief rundown of the individual patches.  You should then edit your patches before you send them, to include an `In-Reply-To` and `References` header listing the `Message-Id` of the 0th message, so it doesn't break threading.
-
-
-## Working on branches
-
-Now you've learned how to check out HEAD code, diff, update, commit, and push code back upstream.  The next thing to talk about is branching.
-
-You can see what branch you're on using `git branch` -- it should show `master` initially.  To switch branches in your current repository, do:
-
-    git checkout <branch>
-
-If you've got local changes, there are flags to either throw out your local changes, or try to merge them across to the new branch.  By default it will just refuse to change.
-
-If you want to make a new branch, you can do:
-
-    git checkout -b <new-branch>
-
-Now you've got a new branch.  However, git checkout doesn't set up the branch: branch-origin mapping that we want.  There's a rule in using git, which is: **Never commit to the right side of a Pull line**.  This is referring to the contents of `.git/remotes/<remotename>`.  The `.git/remotes/origin` (what you're using currently) file should currently have:
-
-    URL: git://anongit.freedesktop.org/git/whatever
-    Pull: master:origin
-
-This means that the current remote master is mapped to the local origin.  When working on a branch where you'll be committing code, add a few more lines:
-
-    Push: master:master
-    Pull: new-branch:new-branch-origin
-    Push: new-branch:new-branch
-
-The first says "map the remote new-branch to new-branch-origin in the local repository".  The second says "when pushing code, push from new-branch locally into new-branch remotely".  If you haven't set any `Push:` lines, then git implies a `master:master` mapping for pushes.  Once we add our new-branch push line, we also have to add `master:master` if you intend to ever commit to master.
-
-Now, you're set up for committing and pushing the branch.  There's one more trick to know about.  When you do `git pull`, it is now pulling the remote branches into what they're mapped to locally.  So, the latest new-branch upstream code is in new-branch-origin.  To merge it to your local new-branch code, do:
-
-    git pull . new-branch-origin
-
-This means "merge the new-branch-origin code into the current working directory".  Like the other `git pull` command we mentioned, it will by default commit the merge, unless it runs into conflicts which aren't automatically resolvable.
-
-And, to push, you do it just like when you were working on master.
-
-    git push origin
+This page used to contain some very basic notes about Git usage. However, it is extremely outdated, and you should consult [[the Git book|https://git-scm.com/book/en/v2]], GitLab's help, or any other documentation on the internet.
diff --git a/Infrastructure/git/Migration.mdwn b/Infrastructure/git/Migration.mdwn
index 891b0e73..e776e02e 100644
--- a/Infrastructure/git/Migration.mdwn
+++ b/Infrastructure/git/Migration.mdwn
@@ -1,3 +1,6 @@
+## It is extremely unlikely that any of the information on this page will be useful to you
+
+
 ## Migrating a CVS module to Git.
 
 This page provides some instructions on how to migrate a module from CVS to git using the parsecvs utility (which desperately needs UI work).
diff --git a/Infrastructure/git/RepositoryAdmin.mdwn b/Infrastructure/git/RepositoryAdmin.mdwn
index 845be76e..c59eef0f 100644
--- a/Infrastructure/git/RepositoryAdmin.mdwn
+++ b/Infrastructure/git/RepositoryAdmin.mdwn
@@ -1,28 +1,4 @@
-Repositories on fd.o take two forms: project repositories (e.g. dbus, cairo), and personal user repositories, which may contain anything.  Project repositories are only available to projects already hosted on freedesktop.org.
-
-
-## Projects
-
-If you want a 'project' repository on fd.o, file a bug with [[Bugzilla|http://bugs.freedesktop.org/enter_bug.cgi?product=freedesktop.org]] requesting a new repository and including the information described in [[NewProject|http://www.freedesktop.org/wiki/NewProject]].  If you want commit notifications, please also state that, and let us know where they should go to.
-
-Conversion using the parsecvs tool is also available: this has converted the X.Org, Cairo and XCB repositories, among others, mostly without incident.
-
-Your repository will be available as `ssh://git.freedesktop.org/git/projectname` for commit access, and `git://anongit.freedesktop.org/git/projectname` for anonymous access.
-
-
-## Personal repositories
-
-For personal repositories, SSH to people.freedesktop.org and execute:
-
-    git --git-dir=repo-name.git init
-    cd repo-name.git
-    touch git-daemon-export-ok
-    vim description
-    mv hooks/post-update.sample hooks/post-update
-    chmod +x hooks/post-update
-
-You can now push into it from your local repository with: `git push --force --all ssh://people.freedesktop.org/~username/repo-name`
-
-and it will be available from `git://people.freedesktop.org/~username/repo-name`; it will take up to one hour to be visible on cgit.
-
-To add the new repository as a remote, on your local machine run `git remote add fdo ssh://people.freedesktop.org/~username/repo-name`. You can then push to it with `git push fdo branchname`.
+Creating repositories on freedesktop.org can be done in three ways:
+* personal repositories can just be created directly on [[our GitLab instance|https://gitlab.freedesktop.org]] without admin intervention, however please try to keep these at least vaguely on topic for fd.o's scope
+* if you administer an existing project, you can create a new repository within your GitLab group without admin intervention
+* if you would like to host a new project and create a new GitLab group, please see [[our new projects page|NewProjects]]
diff --git a/Infrastructure/git/UIFlaws.mdwn b/Infrastructure/git/UIFlaws.mdwn
index 2a53c9d7..c03d7dfe 100644
--- a/Infrastructure/git/UIFlaws.mdwn
+++ b/Infrastructure/git/UIFlaws.mdwn
@@ -1,20 +1 @@
-
-This page attempts to document the most egregious git UI offenses, in the hope that they'll get fixed someday. 
-
-Update:  Since this page was created Git has come a long way.  All of the issues listed have been addressed and this page should probably be retired. 
-
-* There is no way to tell `git-fetch` (or therefore `git-pull`) to grab all newly available branches.  You have to ask for them  by two names (as above), and then there's no way to get those names automatically into your remotes list (also as above).  _Solved:    git remote update_ 
-* `git pull`'s default behaviour on a branch is unhelpful: even when there is an explicit Pull: branch1:branch1 line, a `git pull` with branch1 checked out will still pull in master.   _Solved:  the "merge" variable in the config holds which branch to merge by default_ 
-* `git-fetch` requires that the branch be named on both sides of the :.  It should treat `foo` as an alias for `foo:foo`.  _Solved:  the config now holds the associated remote to fetch by default_ 
-* `git-revert` will refuse to back out multi-parent commits, ie, merges.  The obvious behaviour is to do basically what `git-show [commit] | patch -p1 -R` would do, ie, roll back the tree state to the branch you came from. _Solved:  git revert -m1_ 
-* The command to merge branch B onto branch A is not `git-merge A B`.  Instead it's `git-checkout A && git-pull . B`.  _Solved:  The documentation now makes it clear that you can only merge with checked out branch, eg.  git checkout A && git merge B_ 
-* branch:branch-origin (or something) should be the default pull.  _Solved:  config holds which branch to fetch and merge for each local branch_ 
-* `git-rebase` claims you should `git-rebase --continue` after you fix up the merges; it really means you should `git-update-index` followed by `git-rebase --continue`.  _Solved:  User is informed of proper steps (git add, etc)_ 
-* branch:branch should be the default push for all branches, but only push the current branch unless a flag is added. _Solved:  the config holds a mapping of local branch name to remote branch name so there is no need to give it on command line_ 
-* `git-rebase foo` is a noop, when foo is the name of local branch.  You would expect it to fetch the branch named foo from upstream, and rebase your foo branch on top of it.  _Solved:  Documentation makes it clear that Git is designed to work offline; users should not expect network activity for local operations_ 
-* An update command should be created that:     _Solved:  git pull --no-commit     performs the operations as outlined below_ 
-   * fetches the current branch's upstream to its -origin locally (or all branches, perhaps); 
-   * merges the current branch origin to the branch locally; 
-   * commits if it was a fast-forward, and leaves uncommitted diffs otherwise. 
-* Fundamentally, the entire approach of making the UI painful to deal with and forcing the user to deal with all the warts (instead of just making the hairy low-level commands available), because people will write nice wrappers around it, is the same reason people laughed at tla, and still do.  _Solved:  Fundamentally this wasn't ever a problem, but Git is now just a single command "git" with sub-commands_ 
-* The index should be second-class, i.e. no -a flags to avoid the index.  _Solved:  Documentation is more clear now.  Users can choose one of many GUI's and avoid command line altogether if they find -a hard to type_ 
-\ No newline at end of file
+This page used to contain a list of criticisms of the UI offered by early Git versions. It is no longer relevant.
diff --git a/Infrastructure/git/Users.mdwn b/Infrastructure/git/Users.mdwn
index 0ea0a5cd..074f2fa7 100644
--- a/Infrastructure/git/Users.mdwn
+++ b/Infrastructure/git/Users.mdwn
@@ -1,50 +1 @@
-
-This is about one-way use of git.  For information on committing, merging, and pushing, please see [[the developers page|Infrastructure/git/Developers]]. 
-
-Also note the [[documentation on the git wiki|http://git.or.cz/gitwiki/GitDocumentation]]. 
-
-
-## Checking out a repository
-
-To check out any project repository on fd.o, run: `git clone git://anongit.freedesktop.org/git/name`, e.g. `git://anongit.freedesktop.org/git/cairo`.  A full list of projects is available on [[cgit|http://cgit.freedesktop.org]]. 
-
-To switch to a particular branch, use `git checkout branchname`; a list of branches is available with `git branch`.  If you want to use a particular tag, use `git checkout -b temp tagname`, e.g. `git checkout -b temp xorg-server-1.1.99.3`.  A list of tags is available with `git tag -l`. 
-
-`git checkout master` will return to the main development branch ('trunk'). 
-
-
-## Keeping up to date
-
-`git pull` will download the latest changes.  Note that if you are on a branch, then you should type `git pull origin branchname:branchname`, otherwise you will merge the master branch, instead of simply keeping your current branch up to date. 
-
-
-## Basic repository information
-
-`git log` will give you a list of all changes.  To see changes since a particular version, or between a particular version, use `version1..version2` as an argument; if version1 is unspecified (i.e. `..version2`), it is assumed as the first revision.  Conversely, if version2 is unspecified (i.e. `version1..`), it is assumed as the current revision (not necessarily the most recent in the repository, but the one you currently have checked out).  Examples: 
-
-* `git log xorg-server-1.2.0..` â changes since xorg-server 1.2.0 
-* `git log ..xorg-server-1.2.0` â changes up until xorg-server 1.2.0 
-* `git log xorg-server-1.2.0..xorg-server-1.2.1` â changes between xorg-server 1.2.0 and 1.2.1 
-To examine a particular revision, including the diff, run `git show commitid`.  The commit ID does not have to be the full SHA1 sum, but only enough to be unambiguous; the first 6 characters are usually sufficient. 
-
-
-## CVS cheat sheet
-
-* cvs checkout: `git clone` 
-* cvs status: `git status` 
-* cvs diff: `git diff -a` 
-* cvs update: `git pull` (with caveats) 
-
-## Bisecting
-
-Bisecting allows you to determine which commit introduced breakage, by iterative testing.  As an example, assume that the code worked one month ago, and now segfaults. 
-
-First, run git log, to determine where you want to roll back to.  If it worked one month ago, say five weeks to be safe.  Find the sha1 sum of the commit where you think things last worked.  Take note of this (say it's 123456...). 
-
-`git bisect start` â start the process `git bisect bad` â the current revision is broken `git bisect good 123456` â the revision starting with 123456 works 
-
-You will get output something like: `Bisecting: 297 revisions left to test after this` 
-
-Run make, and check if it works.  If it works, type `git bisect good`, else `git bisect bad`.  This will give you a new revision to try: run make, check if it works, and type bad/good, accordingly. 
-
-If you are unable to compile a particular revision (say it's picked one that introduced a compile breakage), type `git bisect god/bad`, and then continue as usual.  The manpage for git-bisect has some more in-depth details, as does [[kernel.org|http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt]]. 
+This page used to contain some very basic notes about Git usage. However, it is extremely outdated, and you should consult [[the Git book|https://git-scm.com/book/en/v2]], GitLab's help, or any other documentation on the internet.
diff --git a/MissionStatement.mdwn b/MissionStatement.mdwn
index 0c00b5d2..acc17318 100644
--- a/MissionStatement.mdwn
+++ b/MissionStatement.mdwn
@@ -1,31 +1,29 @@
 ## freedesktop.org Mission Statement
 
-freedesktop.org was formed in March 2000 to encourage cooperation among open source desktops for the X Window System.
+freedesktop.org was originally formed in March 2000 to encourage cooperation among open source desktops for the X Window System by developing interoperability specifications.
 
-An X desktop is a graphical environment designed to give a technologically advanced, user-friendly face to the X Window System running on UNIX-like operating systems. Most X desktops also provide a development infrastructure for writing applications that integrate well with the desktop.
+Since then, our mission has expanded. Not only do we support much more than just the X Window System, but we support the development of a wide range of software - mostly building blocks to support free and open-source operating systems. We also take the 'desktop' of 2000 to have a wider scope in the modern day: desktops and cloud application servers, phones and tablets, in-car and in-flight entertainment, often have the same needs as freedesktop.org originally set out to address.
 
-freedesktop.org has the following **concrete goals**:
+freedesktop.org's specifications are developed with the following **concrete goals**:
 
- *  Collect existing specifications, standards, and documents related to X desktop interoperability and make them available in a central location;
- *  Promote the development of new specifications and standards to be shared among multiple X desktops;
- *  Integrate desktop-specific standards into broader standards efforts, such as Linux Standard Base and the ICCCM;
- *  Work on the implementation of these standards in specific X desktops;
- *  Serve as a neutral forum for sharing ideas about X desktop technology;
- *  Implement technologies that further X desktop interoperability and free X desktops in general;
- *  Promote X desktops and X desktop standards to application authors, both commercial and volunteer;
- *  Communicate with the developers of free operating system kernels, the X Window System itself, free OS distributions, and so on to address desktop-related problems;
- *  Provide source code hosting, web hosting, mailing lists, and other resources to free software projects that work toward the above goals.
+ * Collect existing specifications, standards, and documents related to open-source desktop interoperability and make them available in a central location;
+ * Support the development of new specifications and standards to be shared among multiple open-source desktops;
+ * Integrate desktop-specific standards into broader standards efforts, such as the Linux Standard Base, the ICCCM, and Khronos;
+ * Serve as a neutral forum for sharing ideas about open-source desktop technology;
+ * Implement technologies that further open-source desktop interoperability and free desktops in general;
+ * Communicate with the developers of free operating system kernels, the lower layers of the OS stack, free OS distributions, and so on to address desktop-related problems;
+ * Provide source code hosting, web hosting, mailing lists, and other resources to free software projects that work toward the above goals.
 
 The concrete goals of freedesktop.org stem from the following **general principles**:
 
  *  _Developers_ should be able to use the development environment of their choice without limiting their potential userbase to users of a particular desktop environment
- *  _Users_ should have a maximum amount of choice in selecting the applications they wish to run. Users should not be limited to a certain subset of applications; ideally, even the components of the desktop environment (window manager, panel, file manager, etc.) would be interchangeable.
+ *  _Users_ should have a maximum amount of choice in selecting the applications they wish to run
  *  _Code sharing_ and _modularity_ are a good thing. When possible, a common implementation not dependent on a specific desktop increases stability, increases interoperability, reduces system footprint, and optimizes the use of free software development resources.
  *  _Concept sharing_ is a good thing. Users do not benefit from the existence of multiple desktops if those desktops do not share their good ideas and work together toward common goals.
  *  freedesktop.org is first and foremost a _work project_; we intend to develop specifications, and then write code where needed. Work is the only currency that matters in the free software world.
- *  freedesktop.org is an organization made up of developers, designed to help developers do development. XDG does not intend to provide user resources.
- *  freedesktop.org's code will be placed under free licenses that encourage wide use; most commonly, the LGPL for libraries, or an X-style license when appropriate.
+ *  freedesktop.org is an organization made up of developers, designed to help developers do development
+ *  freedesktop.org's code will be placed under free licenses, placing all users and contributors on an equal footing
 
-**Most importantly**: the goal of an X desktop is to provide a service to users (including not only the users of the desktop environment, but also the developers who use the development infrastructure). freedesktop.org should be judged by how well it serves the interests of X desktop users.
+**Most importantly**: the goal of a desktop is to provide a service to users (including not only the users of the desktop environment, but also the developers who use the development infrastructure). freedesktop.org should be judged by how well it serves the interests of our target audience.
 
 The goals of freedesktop.org specifically _exclude_ "blessing" or legislating formal standards, because freedesktop.org does not have the formal infrastructure for that. This site is about catching interoperability issues much earlier in the development process, ideally before code has been written, and providing a forum to work on specifications. Some of these specifications may be standardized by other bodies, but only after "de facto" acceptance most likely. You can look at freedesktop.org as a way to oil the wheels of "de facto" shared specifications.
diff --git a/NewProject.mdwn b/NewProject.mdwn
index b036fd4e..a821a4dc 100644
--- a/NewProject.mdwn
+++ b/NewProject.mdwn
@@ -1,20 +1,30 @@
-# THIS IS A DRAFT
+# Hosting your project on freedesktop.org
 
+freedesktop.org is a broad church of projects. We do not dictate roadmaps or technical direction, but these are instead decided by our projects day to day. We provide hosting and infrastructure support as well as community oversight.
 
-# How to request a new freedesktop.org project
+In return for the freedom and support we provide, we ask that you act responsibly as an open-source community project. Specifically:
+* Respect and uphold our [[Code of Conduct|CodeOfConduct]]
+* Provide source code under a license adhering to the [[Debian Free Software Guidelines|https://www.debian.org/social_contract#guidelines]]
+* Be open to accepting contributions from the whole community, e.g. not just your co-workers
+* Accept contributions on even terms: asymmetric CLAs which provide you with more rights to a project than the contributors are not OK
+* Be willing to hand over maintainership if a good candidate appears and is willing to prolong the project
+* Not unduly use freedesktop.org's name or claim specific approval from us ('freedesktop.org says this is the best joystick library and you have to use it')
 
-First, please make sure your project fits within the [[MissionStatement|MissionStatement]], if it doesn't, it will be rejected. We prefer hosted projects to be using our infrastructure, so if you plan to use Freedesktop.org just for bug tracking for instance, your project will be rejected.  Not using all Freedesktop.org services is acceptable, but just using a single one will probably cause your project to be rejected. 
+Conversely, if your project is hosted with freedesktop.org, we will:
+* Provide you with source code, web, and mailing list hosting under freedesktop.org
+* Keep you informed of changes or developments in our services
+* Listen and take into account your feedback on the services we provide, and try to meet your needs
+* Support your project in external discussion, e.g. request on your behalf new features or improvements to services we run
+* Help and support you to move your project if you decide that freedesktop.org is no longer the best place for it to live
 
-If you are in doubt about whether your project is appropriate for freedesktop.org, please start a discussion about it on the freedesktop mailing list. 
+## How to request a new freedesktop.org software project
 
+Our [[mission statement|MissionStatement]] broadly sums up what we are trying to achieve. You can also look at our existing [[software|Software]] and [[specifications|Specifications] to help decide if freedesktop.org is the right place for your project.
 
-# Requesting a new project
+If the project fits, please [[file an issue on freedesktop/freedesktop|https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new]] and select the 'new project' template.
 
-* go to [[http://bugs.freedesktop.org|http://bugs.freedesktop.org]] 
-* file a bug on the freedesktop.org product with the component set to "Project Creation Requests".  Make sure the bug includes the following information: 
-    * project name (if there are any ambiguities about what the unix group name should be, please suggest one as well, else we'll use our best judgement) 
-    * who should be able to approve new members into your project 
-    * if you need git hosting: which git repositories you want, each with a short description (to go into .git/description) 
-    * if you need bugzilla, we need a short product description and a list of components (each with a short description and default assignee) 
-    * if you need mailing lists, we need the names of all of them and who should be the list administrator. 
-    * if you need file upload space 
+If you are in doubt or would like to discuss it, please feel free to file an issue regardless, or discuss mail [[the freedesktop@ list|https://lists.freedesktop.org/mailman/listinfo/freedesktop]]. You can also ask on IRC in Freenode's #freedesktop, though please note it may take some time to receive an answer, so please don't leave the channel right away.
+
+## How to create a new freedesktop.org specification
+
+To create a new specification, please discuss it either by filing a GitLab issue in the most relevant [[xdg project|https://gitlab.freedesktop.org/xdg]], or on the [[xdg@ mailing list|https://lists.freedesktop.org/mailman/admindb/xdg]].
diff --git a/Software.mdwn b/Software.mdwn
index 2032a3ae..06fafd89 100644
--- a/Software.mdwn
+++ b/Software.mdwn
@@ -4,6 +4,10 @@ The following is an incomplete list of some of the software projects that are, o
 
 You can go to [[our GitLab instance|https://gitlab.freedesktop.org/]] to view and download the code, file bugs, and contribute code through merge requests.
 
+freedesktop.org does not itself run these projects day to day: we provide hosting and infrastructure for the communities which themselves run the projects.
+
+All projects hosted by us are available under open-source licenses under equitable terms to all parties. These projects do not require Contributor License Agreements which assign more rights to one party than another. They may require an assertion like the [[Developer's Certificate of Origin|https://developercertificate.org]] which is simply a more formal document to state that you are leally permitted to contribute under the project's license; you do not, however, need to assign anyone rights that you do not yourself receive to others' contributions.
+
 ### Desktop middleware and frameworks
 
 These projects provide foundational services to desktops.
@@ -35,28 +39,29 @@ These projects allow applications to render graphics on screen, including suppor
 
 * [[Beignet|Software/Beignet]] is an OpenCL implementation for older Intel GPUs, now superseded by the NEO driver.
 * [[Cairo|https://www.cairographics.org]] is a vector graphics library with cross-device output support. 
+* DRM is the Linux kernel graphics subsystem, with development on the [[dri-devel list|https://lists.freedesktop.org/mailman/listinfo/dri-devel]]
 * [[drm_hwcomposer|https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer]] is a backend for Android's HWComposer running on DRM/KMS devices.
 * [[Mesa|http://www.mesa3d.org]] provides both hardware-accelerated and software implementations of the OpenGL, OpenGL ES, Vulkan, EGL, and GLX rendering APIs.
-** [[Nouveau|https://nouveau.freedesktop.org/]] is a reverse-engineered driver for NVIDIA GPUs.
-** [[Piglit|https://piglit.freedesktop.org]] is a test suite for OpenGL and OpenGL ES implementations.
-** [[VirGL|https://virgil3d.github.io]] provides OpenGL and OpenGL ES acceleration to virtualised guests inside VMs.
+* [[Nouveau|https://nouveau.freedesktop.org/]] is a reverse-engineered driver for NVIDIA GPUs.
+  * [[Piglit|https://piglit.freedesktop.org]] is a test suite for OpenGL and OpenGL ES implementations.
+  * [[VirGL|https://virgil3d.github.io]] provides OpenGL and OpenGL ES acceleration to virtualised guests inside VMs.
 * [[Pixman|http://www.pixman.org]] is a low-level software-only 2D pixel manipulation and composition library.
 * [[Plymouth|Software/Plymouth]] provides a splash screen and progress updates during early boot.
 * [[Wayland|https://wayland.freedesktop.org]] is a window system used by a variety of desktops.
 * [[X.Org|http://www.x.org]] is an implementation of the X Window System, known as X11.
-** [[XCB|https://xcb.freedesktop.org]] provides a low-level client library for the X11 protocol.
-** [[Xephyr|Software/Xephyr]] is a nested X11 server, primarily used for testing.
-** [[xrestop|Software/xrestop]] is a 'top' like X Server resource usage monitor that uses the XRes extension. 
-** [[xsettings|Software/xsettings]] allows configuration of settings 
-** [[X Testing|Software/XTesting]] provides information on various software for testing X Servers and Clients. 
-** [[xwininfo|Software/wininfo]] is a window information utility for developers of applications, toolkits, and window managers. 
+  * [[XCB|https://xcb.freedesktop.org]] provides a low-level client library for the X11 protocol.
+  * [[Xephyr|Software/Xephyr]] is a nested X11 server, primarily used for testing.
+  * [[xrestop|Software/xrestop]] is a 'top' like X Server resource usage monitor that uses the XRes extension. 
+  * [[xsettings|Software/xsettings]] allows configuration of settings 
+  * [[X Testing|Software/XTesting]] provides information on various software for testing X Servers and Clients. 
+  * [[xwininfo|Software/wininfo]] is a window information utility for developers of applications, toolkits, and window managers. 
 
 ### Input, internationalisation (i18n), and font rendering
 
 These projects provide support for keyboard, pointer, tablet, and other input, as well as input processing and font rendering.
 
 * [[fontconfig|Software/fontconfig]] is a library for configuring and customizing font access. 
-** [[Xft|Software/Xft]] is a library for client-side font rendering.
+  * [[Xft|Software/Xft]] is a library for client-side font rendering.
 * [[uchardet|Software/uchardet]] is an encoding detector library, which takes a sequence of bytes in an unknown character encoding and attempts to determine the encoding of the text.
 * [[UTF-8|Software/utf-8]] is a project to document and evangelize the use of UTF-8 encodings for open source projects. 
 * [[xkeyboard-config|Software/XKeyboardConfig]] is a repository of XKB keyboard layouts, used in most desktops and window systems.
@@ -92,10 +97,10 @@ These projects provide higher-level support for hardware devices.
 * [[cups-pk-helper|Software/cups-pk-helper]] provides fine-grained PolicyKit authentication integration to allow users to configure the CUPS printing services.
 * [[fprint|Software/fprint]] offers hardware support for a variety of fingerprint readers .
 * [[libinput|Software/libinput]] is a higher-level wrapper library for input devices.
-** [[libevdev|Software/libevdev]] is a low-level wrapper library for kernel event devices.
+  * [[libevdev|Software/libevdev]] is a low-level wrapper library for kernel event devices.
 * [[ModemManager|Software/ModemManager]] is a DBus system service which provides a unified high level API for communicating with mobile broadband modems. 
-** [[libmbim|Software/libmbim]] is a lower-level library to manage MBIM-powered mobile broadband modems. 
-** [[libqmi|Software/libqmi]] is a lower-level library to manage QMI-powered mobile broadband modems. 
+  * [[libmbim|Software/libmbim]] is a lower-level library to manage MBIM-powered mobile broadband modems. 
+  * [[libqmi|Software/libqmi]] is a lower-level library to manage QMI-powered mobile broadband modems. 
 
 ## Projects hosted elsewhere
 
diff --git a/Software/LightDM.mdwn b/Software/LightDM.mdwn
index 88a500de..332d503d 100644
--- a/Software/LightDM.mdwn
+++ b/Software/LightDM.mdwn
@@ -1,88 +1,5 @@
-# The Light Display Manager (LightDM)
+# Project moved
 
-## Description
+LightDM is now [[hosted at GitHub|https://github.com/CanonicalLtd/lightdm]].
 
-*LightDM* is a cross-desktop display manager.
-A display manager is a daemon that:
-
-* Runs display servers (e.g. X) where necessary.
-* Runs greeters to allow users to pick which user account and session type to use.
-* Allows greeters to perform authentication using PAM.
-* Runs session processes once authentication is complete.
-* Provides remote graphical login options.
-
-Key features of LightDM are: 
-
-* Cross-desktop - supports different desktop technologies.
-* Supports different display technologies (X, Mir, Wayland ...).
-* Lightweight - low memory usage and fast performance.
-* Guest sessions.
-* Supports remote login (incoming - XDMCP, VNC, outgoing - XDMCP, pluggable).
-* Comprehensive test suite.
-
-## Installation
-
-LightDM is available most distributions and is the recommended way to install. The package name is generally "lightdm".
-
-Development is hosted on [[GitHub|https://github.com/CanonicalLtd/lightdm]].
-[[Tarball releases|https://github.com/CanonicalLtd/lightdm/releases]] are available.
-
-Releases are synchronised with the [[Ubuntu release schedule|https://wiki.ubuntu.com/Releases]] and supported for the duration of each Ubuntu release. Each release is announced on the [[mailing list|http://lists.freedesktop.org/mailman/listinfo/lightdm]].
-
-The core LightDM project does not provide any greeter with it and you should install a greeter appropriate to your system.
-Popular greeter projects are:
-
-* [[LightDM GTK+ Greeter|https://launchpad.net/lightdm-gtk-greeter]] - a greeter that has moderate requirements (GTK+).
-* [[LightDM KDE|http://projects.kde.org/lightdm]] - greeter used in [[KDE||http://kde.org]] (Qt)
-* [[LXqt Greeter|https://github.com/lxde/lxqt-lightdm-greeter]] - greeter used in [[LXqt|http://lxqt.org]] (Qt)
-* [[Pantheon Greeter|https://launchpad.net/pantheon-greeter]] - greeter used in [[Elementary OS|http://elementaryos.org]] (GTK+/Clutter).
-* [[Unity Greeter|https://launchpad.net/unity-greeter]] - greeter used in [[Unity|https://launchpad.net/unity]].
-* [WebKit2 Greeter](https://github.com/antergos/lightdm-webkit2-greeter) - greeter that can be themed using HTML/CSS/Javascript
-* Run with no greeter (automatic login only)
-* [[Write your own|Software/LightDM/Development]]...
-
-## Configuration
-
-LightDM configuration is provided by the following files:
-
-    /usr/share/lightdm/lightdm.conf.d/*.conf
-    /etc/lightdm/lightdm.conf.d/*.conf
-    /etc/lightdm/lightdm.conf
-
-System provided configuration should be stored in */usr/share/lightdm/lightdm.conf.d/*.
-System administrators can override this configuration by adding files to  */etc/lightdm/lightdm.conf.d/* and */etc/lightdm/lightdm.conf*.
-Files are read in the above order and combined together to make the LightDM configuration.
-
-For example, if a sysadmind wanted to override the system configured default session (provided in */usr/share/lightdm/lightdm.conf.d*) they should make a file */etc/lightdm/lightdm.conf.d/50-myconfig.conf* with the following:
-
-    [Seat:*]
-    user-session=mysession
-
-Configuration is in keyfile format.
-For most installations you will want to change the keys in the [Seat:*] section as this applies to all seats on the system (normally just one).
-A configuration file showing all the possible keys is provided in [[data/lightdm.conf|https://github.com/CanonicalLtd/lightdm/blob/master/data/lightdm.conf]].
-
-See [[Common Configuration|CommonConfiguration]] for common configuration options.
-
-## Questions
-
-Questions should be asked on the [[mailing list|http://lists.freedesktop.org/mailman/listinfo/lightdm]].
-All questions are welcome.
-
-[[Stack Overflow|http://stackoverflow.com/search?q=lightdm]] and [[Ask Ubuntu|http://askubuntu.com/search?q=lightdm]] are good sites for frequently asked questions.
-
-## Development
-
-See [[Development]].
-
-## Packaging links
-
-Here are links to some distributions that package it:
-
-* [[Arch|https://www.archlinux.org/packages/?name=lightdm]]
-* [[Debian|http://packages.qa.debian.org/l/lightdm.html]]
-* [[Fedora|https://apps.fedoraproject.org/packages/lightdm]]
-* [[Gentoo|http://packages.gentoo.org/package/x11-misc/lightdm]]
-* [[Mageia|http://mageia.madb.org/package/show/name/lightdm/application]]
-* [[OpenSUSE|http://software.opensuse.org/package/lightdm]]
-* [[Ubuntu|https://launchpad.net/ubuntu/+source/lightdm]]
+Please go there to see and contribute to the project.
diff --git a/Specifications.mdwn b/Specifications.mdwn
index 4e166ed2..49956255 100644
--- a/Specifications.mdwn
+++ b/Specifications.mdwn
@@ -1,25 +1,32 @@
 # Interoperability specifications
 
-freedesktop.org is not an official standards body. These specifications describe protocols and interfaces to help different desktops and applications work well together.
+freedesktop.org produces specifications for interoperability, but we are not an official standards body. There is no requirement for projects to implement all of these specifications, nor certification.
 
-### Specifications that have pretty good de facto adoption/agreement:
+Below are some of the specifications we have produced, many under the banner of 'XDG', which stands for the _Cross-Desktop Group_.
 
+Some of these specifications are in (very) active use and have a large body of interested developers. Many of them are seen to be stable, in no need of further development, and may not have active devlopment. Some of them are not used or widely implemented.
+
+If you would like to propose a new specification, or a change to an existing specification, please file an issue on the spec under the [[GitLab XDG project|https:///gitlab.freedesktop.org/xdg]], or discuss it on the [[xdg@ mailing list|https://lists.freedesktop.org/mailman/listinfo/xdg]].
+
+**Please note that some of the links and information on this page is quite outdated. We are in the process of updating it and making sure it is accurate. Please consult the mailing list or GitLab if you are in doubt about anything.**
+
+### Specifications that are in wide use:
 
 *  [[Autostart|Specifications/autostart-spec]]: how applications can be started automatically after the user has logged in, and how removable media can request a specific application to be executed or a specific file on the media to be opened after the media has been mounted.
-*  [[Desktop base directories|Specifications/basedir-spec]]: how desktops should locate files, such as config files or application data files.
-*  [[Desktop entries|Specifications/desktop-entry-spec]]: files describing information about an application such as the name, icon, and description. These files are used for application launchers and for creating menus of applications that can be launched.
-*  [[Desktop menus|Specifications/menu-spec]]: how menus are built up from desktop entries. 
+*  [[Desktop base directories (basedir)|Specifications/basedir-spec]]: how desktops should locate files, such as config files or application data files.
+*  [[Desktop entries (.desktop)|Specifications/desktop-entry-spec]]: files describing information about an application such as the name, icon, and description. These files are used for application launchers and for creating menus of applications that can be launched.
+*  [[Desktop menus (menu)|Specifications/menu-spec]]: how menus are built up from desktop entries. 
 *  [[File manager D-Bus interface|Specifications/file-manager-interface]]: a common way to interact with the desktop's file manager.
 *  [[File URIs|Specifications/file-uri-spec]]: how to create and interpret interpret `file://` URIs, as used for drag and drop and other desktop uses.
 *  [[Free media player specifications|Specifications/free-media-player-specs]]: standard ways to store and read metadata across players and media formats. 
 *  [[Icon themes|Specifications/icon-theme-spec]]: a common way to store icon themes.
 *  [[Media Player Remote Interfacing Specification (MPRIS)|Specifications/mpris-interfacing-specification]]: A D-Bus interface to control media players
-*  [[Shared MIME database|Specifications/shared-mime-info-spec]]: contains common MIME types, descriptions, and rules for determining the types of files. 
+*  [[Shared MIME database (shared-mime-info)|Specifications/shared-mime-info-spec]]: contains common MIME types, descriptions, and rules for determining the types of files. 
 *  [[Startup notifications|Specifications/startup-notification-spec]]: a mechanism to allow desktop environments to track application startup, to provide user feedback and other features. 
 *  [[Trash|Specifications/trash-spec]]: a common way in which all "Trash can" implementations should store, list, and undelete trashed files.
 *  [[XML Bookmark Exchange Language (XBEL)|http://pyxml.sourceforge.net/topics/xbel/]]: an internet "bookmarks" interchange format. 
 
-X-related specifications:
+## X11-specific specifications that are in wide use:
 
 *  [[DnD|http://www.newplanetsoftware.com/xdnd/]]: a drag-and-drop specification shared between [[GTK+|GTK+]] and [[Qt|Qt]]. A [[local copy|Specifications/XDND]] of the spec resides on the wiki, along with some [[proposed revisions|Specifications/XDNDRevision]].
 *  [[UTF8_STRING|http://www.pps.jussieu.fr/~jch/software/UTF8_STRING]]: selection format for interchange of UTF-8 data. 
@@ -51,10 +58,6 @@ X-related specifications:
 If you feel any of these specs should be moved among the "standard", "de facto", and "proposed" categories, please let us know on [[xdg-list@lists.freedesktop.org|mailto:xdg-list@lists.freedesktop.org]]. 
 
 
-### X protocol extensions:
-
-* See <http://www.x.org/releases/current/doc/index.html#protocol> for the latest X protocol extension specs.
-
 ### Specifications currently in the planning/requirements-gathering stages:
 
 *  [[Shared File Metadata Spec|Specifications/shared-filemetadata-spec]] (reading/writing/searching file based metadata) 
@@ -72,7 +75,7 @@ If you feel any of these specs should be moved among the "standard", "de facto",
 *  [[DBPC - DBus for process control|Specifications/DBPC]] is layer above DBUS which define a standard set of objects, interfaces and methods for use in process control. It will provide a common standard for industrial communication, especially between HMI, SCADA and field electronic equipement. 
 
 
-### Retracted or obsolete specifications
+### Retracted or obsolete specifications:
 
 *  The [[Desktop Color Scheme specification|Specifications/colorscheme-spec]] is a draft specification that defines names for colors to be used for rendering user interface elements.  It also provides an algorithm for generating a matching set of colors from a single base color (**The colorscheme spec has been pulled on request of its authors**). 
 *  The [[GHNS and DXS specs|http://ghns.freedesktop.org/spec/]] (dead link as of May 2018) describe a collaborative data exchange platform based on the HTTP protocol and web service interaction.
diff --git a/UsingCvs.mdwn b/UsingCvs.mdwn
index bd677d2c..8b17f9e2 100644
--- a/UsingCvs.mdwn
+++ b/UsingCvs.mdwn
@@ -1,18 +1 @@
-# Using anonymous CVS
-
-    cvs -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/<project> login
-    cvs -d:pserver:anoncvs@anoncvs.freedesktop.org:/cvs/<project> co <module>
-
-# Browsing CVS
-
-CVS Repositories can be browsed online from <http://webcvs.freedesktop.org/>.  If you want to link to a particular project's repository, append the project name to the end of the URL (eg. <http://webcvs.freedesktop.org/xorg/>). 
-
-
-# Using developer CVS
-
-* Get a username: 
-    * See <http://www.freedesktop.org/wiki/AccountRequests> for details. 
-* Using your username. 
-    * `export CVS_RSH=ssh`
-    * `export CVSROOT=:ext:<developer>@cvs.freedesktop.org:/cvs/<project> cvs -z3 co <module>`
-    * If you specified a passphrase when running ssh-keygen, then you must enter that passphrase now. 
+freedesktop.org no longer provides CVS services. For information on how to access our current projects, please see our [[Software]] page, or [[our GitLab instance|https://gitlab.freedesktop.org]] which now hosts our development trees.
diff --git a/index.mdwn b/index.mdwn
index 26cef6e1..f0dfea0f 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,41 +1,59 @@
 # Welcome to freedesktop.org
 
-freedesktop.org is open source / open discussion software projects working on interoperability and shared technology for X Window System desktops. The most famous [[X desktops|Desktops]] are [[GNOME|http://www.gnome.org]] and [[KDE|http://www.kde.org]], but developers working on any Linux/UNIX GUI technology are welcome to participate. 
+freedesktop.org hosts the development of free and open source software, focused on interoperability and shared technology for open-source graphical and desktop systems. We do not ourselves produce a desktop, but we aim to help others to do so.
 
-freedesktop.org is building a base platform for desktop software on Linux and UNIX.  The elements of this platform have become the backend for higher-level application-visible APIs such as Qt, GTK+, XUL, VCL, WINE, GNOME, and KDE.  The base platform is both [[software|Software]] and [[specifications|Specifications]]. 
+Our loose community of projects mostly produce [[software|Software]] and/or [[specifications|Specifications]].
 
 
-## Software
+## Software projects
 
-freedesktop.org hosts any "on-topic" software projects.  If you have a project that fits into our mission and needs hosting, please make a request using our [[bugzilla|http://bugs.freedesktop.org]]. Mailing lists about freedesktop software are hosted [[here|http://lists.freedesktop.org/mailman/listinfo]]. 
+Most of our member projects produce software to be used as libraries or services. A full list is available at [[our software page|Software]].
 
+Much of the software we host is focused on drivers and middleware for graphics and media devices, inter-process communication and authorization, input and internationalization.
 
-## Standards
+All the software on freedesktop.org is available as open source and open to community contribution. The [[software page|Software]] explains how to report bugs and propose changes to each of these projects.
 
-freedesktop.org is not a formal standards organization, though some see a need for one that covers some of the areas we are working on.  For Linux operating system standards, look at the [[Linux Standard Base|http://www.linuxbase.org]] project.  [[The X.Org Foundation|http://www.x.org]] and the [[IETF|http://www.ietf.org]] are other groups that do formal standards. The [[Free Standards Group|http://www.freestandards.org]] is one group that publishes "de jure" standards for free software; freedesktop.org is loosely affiliated with the FSG. 
 
-Unlike a standards organization, freedesktop.org is a "collaboration zone" where ideas and code are tossed around, and de facto specifications are encouraged.  The primary entry to these discussions is the [[xdg mailing list|http://lists.freedesktop.org/mailman/listinfo/xdg]]. 
+## Specifications
+
+We also host discussion and development of specifications for interoperability. A full list is available at [[our specifications page|Specifications]].
+
+These specifications mostly cover low-level desktop issues, such as identifying file types, launching applications, and exchanging data between applications and desktops. They are often called 'XDG' specifications, as an acronym for the _Cross-Desktop Group_.
+
+freedesktop.org is not a formal standards body, and is not in itself a platform; we do not have a compliance test nor a certification. Anyone is free to use and implement the specifications on this site; the [[specifications page|Specifications]] explains how to propose changes and existing specifications, or entirely new specifications.
+
+
+## Infrastructure
+
+The infrastructure we use to provide these services to our projects is documented on [[our infrastructure page|Infrastructure]]. You can quickly get access to [[our GitLab instance|https://gitlab.freedesktop.org]] where most of our code lives, [[our mailing lists|https://lists.freedesktop.org]], or browse these wiki pages further to find out more.
 
 
 ## Getting Involved
 
-You can get involved in a number of ways.  See the [[MissionStatement]] for our principle activities.  See [[GettingInvolved]] for concrete suggestions on how you can contribute. See [[AccountRequests]] for information on how to obtain commit access to a project.  See [[NewProject]] for how to start a new project. 
+The first point of entry is to find the project you would like to work on, usually through our [[software|Software]] or [[specifications|Specifications]] page. Each project should have a clear link of how to report issues, discuss changes, and contribute back - this will almost certainly be on that project's page on [[our GitLab instance|https://gitlab.freedesktop.org]].
 
-## Contributor Covenant
+If you would like to create a new freedesktop.org project, or request hosting of an existing project you would like to move here, please see [[the new project page|NewProject]].
 
-freedesktop.org has adopted the [[Contributor Covenant|CodeOfConduct]] for the fora it provides. Please conduct yourself in an appropriate manner, avoiding abusive, bullying, and/or discriminatory behaviour. For more information, including where to report any inappropriate behaviour, please consult the [[CodeOfConduct]].
 
-## Privacy Policy
+## Code of Conduct
+
+freedesktop.org has adopted the Contributor Covenant for all the services we host. Please conduct yourself in an appropriate manner, avoiding abusive, bullying, and/or discriminatory behaviour. For more information, including where to report any inappropriate behaviour, please consult the full [[Code of Conduct|CodeOfConduct]].
+
+
+## Privacy and personal information
 
 When you use freedesktop.org services, you might disclose personally-identifying information to us. Our [[Privacy Policy|PrivacyPolicy]] explains how we collect and use this data.
 
-## Contacting freedesktop
 
-If you have any comments or questions about this site or its infrastructures, please send a message to the [[xdg list|http://lists.freedesktop.org/mailman/listinfo/xdg]] or on [[#freedesktop|https://webchat.freenode.net/?channels=freedesktop]] on Freenode.
+## Contact us
+
+If you have questions about the site itself or our infrastructure, the administrators can be reached on the [sitewranglers list|https://lists.freedesktop.org/mailman/listinfo/sitewranglers]], or also on Freenode's #freedesktop IRC channel. Platform-wide announcements and discussions are generally on the [[freedesktop mailing list|https://lists.freedesktop.org/mailman/listinfo/freedesktop]].
+
+Please note that it may take some time to answer your question on IRC, and we are also unlikely to be able to help with project-specific issues (e.g. 'why does ModemManager crash?'). Questions or issues with a specific member project should be directed to that project's own mailing list or bug tracker.
 
 
 ## Sponsors
 
-The freedesktop.org servers are generously hosted by [[Portland State University|http://www.pdx.edu]].  [[Intel|http://www.intel.com]], [[HP|http://www.hp.com]] and [[Google|http://www.google.com]] have sponsored the servers themselves and [[Collabora|http://www.collabora.com]] are sponsoring sysadmin time. 
+freedesktop.org is a completely volunteer organisation with no corporate backing or funding stream.
 
-This wiki is undergoing [[conversion]]. If you have a fd.o shell account, you can help!
+We would like to thank [[Portland State University|https://www.pdx.edu]] for providing physical and network hosting, as well as [[GitLab|https://about.gitlab.com]] for sponsoring some of our hosting costs. We are also grateful to [[Google|https://www.google.com]], [[Intel|https://www.intel.com]], and [[HP|https://www.hp.com]] for previously sponsoring some of our servers. These kind donations have made it possible for us to run the services we do.
author	Daniel Stone <daniels@collabora.com>	2019-02-18 19:35:52 +0000
committer	Daniel Stone <daniels@collabora.com>	2019-02-18 19:35:52 +0000
commit	ff5c2a0f479921c28ab40e2e6ef162e3a78929ef (patch)
tree	ca7785eefecb3d00f15ae0a8e59ec7a82658aedd
parent	139acf42b7874c98be14d55ecf70aeed472a6529 (diff)