diff --git a/ServerSelection.md b/ServerSelection.md
index 0e3963f..9c4ec90 100644
--- a/ServerSelection.md
+++ b/ServerSelection.md
@@ -3,7 +3,7 @@
 Different users of Tahoe-LAFS have different desires for "Which servers should I upload which shares to?".
 
  * allmydata.com wants to upload to a random selection, evenly distributed among servers which are not full; This is, unsurprisingly, what Tahoe v1.5 currently does.
- * Brian has mentioned that an allmydata.com-style deployment might prefer to have the servers with more remaining capacity receiving more shares, thus "filling up faster" than the servers with less remaining capacity.
+ * Brian has mentioned that an allmydata.com-style deployment might prefer to have the servers with more remaining capacity receiving more shares, thus "filling up faster" than the servers with less remaining capacity (#872).
  * Kevin Reid wants, at least for one of his use cases, to specify several servers each of which is guaranteed to get at least K shares of each file, in addition to potentially other servers also getting shares.
  * Shawn Willden wants, likewise, to specify a server (e.g. his mom's PC) which is guaranteed to get at least K shares of certain files (the family pictures and movies files).
  * Some people -- I'm sorry I forget who -- have said they want to upload at least K shares to the K fastest servers.
@@ -67,4 +67,5 @@ The main ticket:
 Related tickets:
  * #302 (stop permuting peerlist, use SI as offset into ring instead?)
  * #466 (extendable Introducer protocol: dictionary-based, signed announcements)
- * #467 (change peer-selection to allow introducerless explicit serverlist, alternative backends)
\ No newline at end of file
+ * #467 (change peer-selection to allow introducerless explicit serverlist, alternative backends)
+ * #872 (Adjust the probability of selecting a node according to its storage capacity (or other fitness measure))
\ No newline at end of file