diff --git a/text/0089-loadable-lints.md b/text/0089-loadable-lints.md
index ae5fa935f57..78b948e00c4 100644
--- a/text/0089-loadable-lints.md
+++ b/text/0089-loadable-lints.md
@@ -11,7 +11,7 @@ Allow users to load custom lints into `rustc`, similar to loadable syntax extens
 There are many possibilities for user-defined static checking:
 
 * Enforcing correct usage of Servo's [JS-managed pointers](https://github.com/mozilla/servo/blob/master/src/components/script/dom/bindings/js.rs)
-* kballard's use case: checking that `rust-lua` functions which call `longjmp` never have destructors on stack variables
+* lilyball's use case: checking that `rust-lua` functions which call `longjmp` never have destructors on stack variables
 * Enforcing a company or project style guide
 * Detecting common misuses of a library, e.g. expensive or non-idiomatic constructs
 * In cryptographic code, annotating which variables contain secrets and then forbidding their use in variable-time operations or memory addressing
diff --git a/text/0236-error-conventions.md b/text/0236-error-conventions.md
index 071a61f41b4..b93a97f6724 100644
--- a/text/0236-error-conventions.md
+++ b/text/0236-error-conventions.md
@@ -228,7 +228,7 @@ comment for more detail.
 There are numerous possible suffixes for a `Result`-producing variant:
 
 * `_catch`, as proposed above. As
-  [@kballard points out](https://github.com/rust-lang/rfcs/pull/236#issuecomment-55344336),
+  [@lilyball points out](https://github.com/rust-lang/rfcs/pull/236#issuecomment-55344336),
   this name connotes exception handling, which could be considered
   misleading. However, since it effectively prevents further unwinding, catching
   an exception may indeed be the right analogy.
diff --git a/text/0240-unsafe-api-location.md b/text/0240-unsafe-api-location.md
index 58697bf4616..62e2842038b 100644
--- a/text/0240-unsafe-api-location.md
+++ b/text/0240-unsafe-api-location.md
@@ -88,7 +88,7 @@ and methods:
 
 The unsafe methods and static functions for a given type should be placed in
 their own `impl` block, at the end of the module defining the type; this will
-ensure that they are grouped together in rustdoc. (Thanks @kballard for the
+ensure that they are grouped together in rustdoc. (Thanks @lilyball for the
 suggestion.)
 
 # Drawbacks
@@ -125,7 +125,7 @@ There are a few alternatives:
   them `unsafe`), and given that rustdoc could easily provide API grouping, it's
   unclear exactly what the benefit is.
 
-* ([Suggested by @kballard](https://github.com/rust-lang/rfcs/pull/240#issuecomment-55635468)):
+* ([Suggested by @lilyball](https://github.com/rust-lang/rfcs/pull/240#issuecomment-55635468)):
 
   > Use `raw` for functions that construct a value of the type without checking
   > for one or more invariants.
@@ -140,7 +140,7 @@ There are a few alternatives:
   some_string.slice_unchecked(start, end)
   ```
 
-* Another suggestion by @kballard is to keep the basic structure of `raw`
+* Another suggestion by @lilyball is to keep the basic structure of `raw`
   submodules, but use associated types to improve the ergonomics. Details (and
   discussions of pros/cons) are in
   [this comment](https://github.com/rust-lang/rfcs/pull/240/files#r17572875).
diff --git a/text/2497-if-let-chains.md b/text/2497-if-let-chains.md
index 3b637cedd78..5d294da3c51 100644
--- a/text/2497-if-let-chains.md
+++ b/text/2497-if-let-chains.md
@@ -1422,18 +1422,18 @@ Interestingly, the `EXPR is PAT` idea was floated in the original RFC 160 that
 introduced `if let` expressions in the first place. There, the notion that an
 operator named `is`, which introduces bindings, is confusing was brought up.
 
-[kballard_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48515260
-[kballard_2]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48551196
+[lilyball_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48515260
+[lilyball_2]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-48551196
 [liigo_1]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49234092
-[kballard_3]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49242255
+[lilyball_3]: https://github.com/rust-lang/rfcs/pull/160#issuecomment-49242255
 
-It was also mentioned by [@kballard][kballard_1] that it would be appropriate
+It was also mentioned by [@lilyball][lilyball_1] that it would be appropriate
 if, and only if, it was limited to pattern matching, but not introducing any
 bindings. We make the same argument in this RFC. The issue of unintuitive
-scopes was also mentioned [by @kballard][kballard_2] there.
+scopes was also mentioned [by @lilyball][lilyball_2] there.
 
 Even the idea of `if EXPR match PAT` was floated by [@liigo][liigo_1] at the
-time but that idea was ultimately also rejected. [@kballard][kballard_3] opined
+time but that idea was ultimately also rejected. [@lilyball][lilyball_3] opined
 that using `match` as a binary operator would be *"very confusing"* but did not
 elaborate further at the time.