diff --git a/commit-access.rst b/commit-access.rst
new file mode 100644
index 000000000000..dbc50f2b5bd3
--- /dev/null
+++ b/commit-access.rst
@@ -0,0 +1,143 @@
+===============
+ Commit Access
+===============
+
+The drm-misc and drm-intel repositories operate in a maintainer/committer model
+with a large pool committers who can push patches in accordance with the stated
+merge criteria, and maintainers handling pull requests, topic branches, merges,
+and so on.
+
+This document outlines the requirements for becoming a committer.
+
+drm-misc
+--------
+
+TBD.
+
+drm-intel
+---------
+
+Requirements
+~~~~~~~~~~~~
+
+The baseline requirements for becoming a drm-intel committer are:
+
+- Comfortable with the open collaboration model we have.
+
+- Enough experience to gauge reasonably well how much review a patch needs, and
+  when pushing a patch, whether it needs acks from domain experts or
+  maintainers.
+
+- Strong presence in the project communication channels (intel-gfx mailing list
+  and #intel-gfx IRC channel) for topics in their area of expertise.
+
+Since everyone is different and has different focus in their work, there are no
+hard and fast rules, but just indicators and some judgement.
+
+Positive indicators are:
+
+- Decent amount of non-trivial patches merged in the past year (25+ patches,
+  excluding simple code movement, typo fixes and similar patches).
+
+- Decent amount of in-depth review, again 25+ in the past year as the threshold.
+
+- Lots of experience and commit rights in related open-source projects, like
+  Mesa, or kernel trees like drm-misc, since the processes are very similar. 2+
+  years as the threshold here, and this is also fulfilled after 2+ years of
+  working in the virtual upstream team (product tree hacking doesn't count).
+
+- Already merged a complex feature, e.g. spanning multiple subsystems or even
+  involving userspace.
+
+- Active member on freedesktop.org bugzilla. A developer that besides submitting
+  patches to fix bugs is also engaged on bugs discussion giving constructive
+  comments helping to drive the bug entry to a solution. Hence keeping bug list
+  active, clean, and under control.
+
+Contra-indicators are:
+
+- Not around on IRC (taking timezones into account of course).
+
+- Mostly simple patches and rubber-stamping reviews not resulting in in-depth
+  discussions.
+
+- No complete feature patch set merged yet.
+
+As a rule of thumb, commit rights will be granted when most positive indicators
+are fulfilled and no negative indicators present. The current project
+maintainers assess whether a candidate meets the requirements, and make the
+decisions about commit rights.
+
+Nomination
+~~~~~~~~~~
+
+Any developer, who already have demonstrated some of positive requirements, can
+be nominated at any time by anyone: maintainers, committers, managers, peers,
+and even self nomination are accepted.
+
+Nomination process is simply sending an email to the drm-intel
+maintainers. Please nominate one person per email, and Cc: the
+nominee. Nominations are processed by the maintainers on a first come, first
+served basis, as nominations are received.
+
+Nomination is not a guarantee of the commit rights. In case a nomination is
+rejected, the maintainers will give constructive feedback on what areas the
+nominee should try to work on.
+
+When there are several nominees at the same time, the ramp-up time on the tools
+and processes, and the support bandwidth limit the amount of rights that can be
+distributed at once. Maintainers are responsible for collecting all the
+candidates in a list that will be sorted out following some criteria:
+
+- More recent activity. It is easier to absorb and ramp-up a committer that is
+  currently active on i915 with pending patches to get merged.
+
+- More positive indicators.
+
+- Fewer contra-indicators.
+
+After the nomination has been processed and a decision has been made about
+giving or postponing giving out the commit rights to the nominee, there will be
+a reply from the maintainers to the the nominated person only.
+
+In case the nominee is accepted as a committer and accepts the new role, the
+nominee will need to request a freedesktop.org account according to
+https://www.freedesktop.org/wiki/AccountRequests/, and the drm-intel maintainers
+will ack adding the account with drm-intel access on the account request bug. If
+the nominee already has a freedesktop.org account, the drm-intel maintainers
+will file the access request bug.
+
+Revocation
+~~~~~~~~~~
+
+- Self abdicate. Anyone at any time can explicitly request to be removed from
+  the list of drm-intel committers.
+
+- Long period of inactivity on DRM projects and community. It is very common to
+  have people changing jobs and not contributing anymore to DRM related
+  projects. So, in order to keep the list clean and under control, after one
+  year of inactivity, commit rights can be withdrawn with or without
+  notification.
+
+- Repeatedly breaking the rules on pushing patches. Everyone makes mistakes,
+  especially when ramping up and getting used to the maintainer tools. However,
+  commit rights could be revoked when a committer has been repeatedly observed,
+  and notified, of:
+
+  - Pushing patches without review (or acks from maintainers or domain experts
+    when required).
+
+  - Pushing patches that had a clear rejection from maintainers or other
+    committers or unresolved review comments.
+
+  - Pushing patches without proper tags or links.
+
+  - Pushing patches to other branches than drm-intel-next-queued.
+
+  - Pushing patches without using dim tools.
+
+  - Pushing patches that didn’t pass CI.
+
+- Freedesktop.org Code of Conduct violations may lead to temporary or permanent
+  account or commit rights suspension according to freedesktop.org umbrella
+  rules.
diff --git a/index.rst b/index.rst
index d2142a7898f8..2db033161196 100644
--- a/index.rst
+++ b/index.rst
@@ -23,6 +23,7 @@ Contents:
    :maxdepth: 2
 
    repositories
+   commit-access
    drm-misc
    drm-intel
    dim
