diff --git a/003-better-default-branch-name.md b/003-better-default-branch-name.md
new file mode 100644
index 0000000..95952a5
--- /dev/null
+++ b/003-better-default-branch-name.md
@@ -0,0 +1,187 @@
+title: A better name for the default branch
+id: 003
+status: submitted
+discussion: https://issues.guix.gnu.org/76407
+authors: Liliana Marie Prikler
+sponsors: Simon Tournier, Ian Eure, Vagrant Cascadian, Ludovic Courtès
+date: 2025-02-18
+SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only
+---
+
+# Summary
+
+Currently, much of Guix's development takes place on the “master”
+branch.  This name is neither particularly meaningful nor inclusive;
+choosing to use it may inadvertently alienate potential contributors.
+To mitigate these effects, we should more clearly communicate, what the
+default branch is all about.
+
+# Motivation
+
+It is well known, that Git works with whatever branch name one chooses.
+However, for historical reasons, the default/initial/main branch for
+development used to be “master” — particularly in 2012, when the first
+commit to Guix was made.
+
+Recent versions of Git support arbitrary initial branches and the
+default branch name is subject to change upstream, at least in part
+because the current default — “master” — may be perceived as harmful.
+While the intended meaning is something close to “an original, from
+which copies are made”, there are several other meanings of the word
+that spring to mind more easily, some of have a racist or sexist
+connotation.
+
+One goal of the Guix community is to foster a healthy community around
+the software we use.  Using clear language that does not pertain to
+harmful stereotypes is a key towards achieving this goal.  Thus, as a
+proactive step, we should rename the default branch.
+
+# Detailed Design
+
+This section explains the chosen solution among the available options,
+the scope of the proposed migration, and a migration path.
+
+## Scope of this document
+
+This document discusses only to change the name of the default branch,
+not to change the branching strategy.  Such ideas, e.g. to have a
+“stable” branch containing only bug-fixes and well-tested features
+and an “unstable” or “experimental” branch would need to be discussed
+in a separate document.
+
+## Choice of branch name
+
+In this section, we discuss potential branch names that have been
+considered.  The goal is to find a name that Guix contributors, as a
+whole, feel comfortable with.
+
+While this GCD is still being reviewed, new suggestions may be added,
+and benefits and drawbacks for each name discussed.  Once this GCD is
+accepted, these benefits and drawbacks shall be shortly summarized,
+and a final decision with a short justification as the one at the end
+of this section shall be the last paragraph of this section.
+
+- The currently used “master” has more than ten different meanings,
+  some of them pertaining to slavery, others to dominance, and yet
+  others merely to skill and expertise.  It is understandable that some
+  contributors would feel uncomfortable with this name, given that not
+  all uses are equally frequent.
+
+- The currently proposed alternative “main” has several meanings
+  relating to “importance”, the most obvious being “most important”.
+
+- Other alternatives would be “trunk” as a visual metaphor from
+  which “branches” spawn, and “base” with the same meaning.
+
+- “guix” being the name of the project also serves as an option,
+  albeit one that is not clearly defined (are the other branches
+  not guix as well?)
+
+- Similar to “guix”, “development” merely signifies that some sort
+  of development happens on the branch; a fact that should hold for
+  most, if not all branches.
+
+We choose “main” simply because it is currently the explicit initial
+branch for a git checkout as per `git-fetch` in `(guix build git)`.
+Another name could be chosen by any means that support achieving a
+consensus, e.g. comments on this GCD or a popular vote.
+
+## Manual Updates
+
+Sections 19 (Security Updates) and 22 (Contributing) of the Guix manual
+would need to be reworded to reflect the new default branch.  Other
+sections mentioning “master” branches may be reworded at any time
+regardless of this GCD.  Some mentions of the word “master” are tied to
+particular services and thus subject to rewording only once upstream
+adopts a different terminology.
+
+## Repository Update Path
+
+For a complete list of repositories associated with the Guix project,
+see GCD 002 ‘Migrating repositories, issues, and patches to Codeberg’.
+Most repositories can rename their default branch with no issue
+(see also Cost of Reverting below).
+
+For Guix itself, we would decide on a **flag day** 14 days after
+acceptance of this GCD at the earliest, and 30 days at the latest.
+On that day, the main development branch would become "main".
+A commit would reflect that by updating:
+
+  1. the `branch` field in `.guix-channel`;
+  2. the `branch` field of `%default-guix-channel` in `(guix channels)`;
+  3. any other reference to the "master" branch of the Guix repository
+     that may appear in the repository (in particular the Manual Updates
+     above).
+
+Following this commit, an entry in `etc/news.scm` would explain the
+migration.  The `master` branch would then point at the commit of said
+news entry, and would need to be updated only after said news are
+translated into another language.  The `master` branch may keep following
+the `main` branch for a grace period of 30 days anyways.
+
+Even after the `master` branch no longer syncs up to main, it may be
+important to still have it pointing at some commit.  Old installation
+media, handcrafted `channels.scm`, external documentation and scripts
+may all still be referring to the `master` branch even long after the
+rename (see also Cost of Reverting below).  To ensure that these do
+not fail immediately, the old branch shall not be deleted until
+
+1. at least one year has passed since this GCD has been accepted, AND
+2. enough Guix releases have been made in the meantime, meaning
+   a. at least one major release, OR
+   b. at least three minor releases.
+
+## Continuous Integration
+
+The jobset for the `master` branch would be removed and a jobset for the
+`main` branch with the highest priority and the same set of architectures
+would be created.
+
+## Relation to other Guix Consensus Documents
+
+Since this change has the potential to affect users and contributors in
+ways that will disrupt their workflow for some amount of time as they
+reconfigure their local checkouts to point at the new branch, it should
+best be adopted as the same time as other, similar changes.  In particular,
+an adoption at the same time as GCD 002 ‘Migrating repositories, issues,
+and patches to Codeberg’ is desirable.
+
+The repository update path in this GCD is only valid as long as it is
+simultaneously upheld by other, similar GCDs.  Again GCD 002 ‘Migrating
+repositories, issues, and patches to Codeberg’ needs to be considered as
+a possibly simultaneous change.  For the sake of clarity, the promises
+made in the repository update path w.r.t. the availability of the old
+branch shall not exceed those of any other accepted GCD and instead
+be updated to match.
+
+## Cost of Reverting
+
+This change mostly affects contributors, who would have to run the following
+command once to pull from (and in the case of committers push to) the new
+main branch:
+
+  $ git branch --set-upstream-to <origin>/main
+
+Users of the `guix` CLI would be advised to run `guix pull` again to fetch
+the latest commit from the main branch.  Users of old installation media
+(e.g. disk images for version 1.4.0) would continue to use the "master" branch
+and the default channel URL of said installation media until they run
+`guix pull`.  A new release may mitigate this annoyance somewhat.
+
+The main branch may be renamed to any other name (including "master") by
+repeating the steps laid out in the Repository Update Path and
+Continuous Integration above, using <name> instead of "main".
+
+# Drawbacks and Open Issues
+
+There is an ongoing political debate as to whether the name “master”,
+standing alone, should be considered harmful.  Similar debates may
+well surround other names given enough time and particular
+circumstances.  More generally, as language continues to evolve,
+meanings that appear obvious today may no longer remain so in the
+future.
+
+It is unclear, what effect, if any, the name of the default branch has
+to contributor satisfaction.  The choice of a name may well appear
+similar to choosing the colour of a bikeshed.  What constitutes a
+meaningful branch name will inevitably be a matter of opinion.
