diff --git a/bip-0003.md b/bip-0003.md
index 61e9cf05..4f0b2dc1 100644
--- a/bip-0003.md
+++ b/bip-0003.md
@@ -72,10 +72,10 @@ Through its high visibility, it facilitates the community-wide consideration of
 source to retrieve the latest version of any BIP. The repository transparently records all changes to each BIP and
 allows any community member to retain a complete copy of the archive easily.
 
-The BIPs repository is not a tool to track acceptance[^acceptance], adoption, or community consensus on BIPs, beyond
-providing a brief overview of BIP statuses (see [Workflow](#workflow) below) to the audience.
-There is no formal or informal decision body that governs Bitcoin development or decides acceptance of BIPs. Bitcoin
-development emerges from the participation of stakeholders across the ecosystem.
+The BIPs repository neither tracks community sentiment[^acceptance] nor ecosystem adoption[^adoption] of BIPs beyond
+the brief overview provided via the BIP status (see [Workflow](#workflow) below).
+Proposals are published in this repository if they are on-topic and fulfill the editorial criteria.
+No formal or informal decision body governs Bitcoin development or decides adoption of BIPs.
 
 ## BIP Format and Structure
 
@@ -540,7 +540,7 @@ mentioned in the [Changelog](#changelog) section.
 - "Other Implementations" sections are discouraged.[^OtherImplementations]
 - Auxiliary files are only permitted in the corresponding BIP’s subdirectory, as no one used the alternative of labeling
   them with the BIP number.
-- Tracking of adoption, acceptance, and community consensus is out of scope for the BIPs repository, except to determine
+- Tracking of community consensus and adoption is out of scope for the BIPs repository, except to determine
   whether a BIP is in active use for the move into or out of the Deployed status.
 - The distinction between recommended and acceptable licenses was dropped.
 - Most licenses that have not been used in the BIP process have been dropped from the list of acceptable licenses.
@@ -661,10 +661,19 @@ feedback, and helpful comments.
     aforementioned can be represented by _Closed_ without significantly impacting the information quality of the
     overview table. Where the many Status variants provided minuscule additional information, the simplification is more
     valuable and the Changelog section now collects specific details.
-[^acceptance]: **Why does the BIPs repository no longer track adoption?**  
-    BIP 2 made an attempt to gather community feedback into comment summaries in BIPs directly. Given the low adoption
-    and corresponding low information quality of the summaries that resulted from that feature, this BIP instead intends
-    to leave the evaluation of BIPs to the audience.
+[^acceptance]: **When is a BIP "accepted"?**  
+    Many standards processes such as the PEPs or the IETF have a mechanism for a proposal to be formally accepted by
+    some council or committee. The BIP Process does not have such a decision body. Bitcoin development and "acceptance"
+    of BIPs emerges from the participation of stakeholders across the ecosystem, and refers to some vague notion of community
+    interest and support for a proposal.  
+    BIP 2 had made an attempt to gather community feedback into comment summaries in BIPs directly. Given the low
+    participation and corresponding low information quality of the summaries that resulted from that feature, this BIP
+    instead intends to leave the evaluation of BIPs to the reviewers and users.
+[^adoption]: **Why does the BIPs repository no longer track adoption?**  
+    In the past, some BIPs maintained lists of projects that had implemented the BIP. These lists generated
+    noise for subscribers of the repository, often listed implementations of questionable quality, and quickly
+    grew outdated, therefore providing little value. The repository no longer tracks which projects have implemented
+    BIPs. Instead, it is recommended that projects publish a list of the BIPs they implement.
 [^markdown]: **Which flavor of Markdown is allowed?**  
     The author of this proposal has no opinion on Markdown flavors, but recommends that proposals stick to the basic
     Markdown syntax features commonly shared across Markdown dialects.