I can't doc v2

docs/migrating.rst

@@ -30,9 +30,11 @@ The biggest example of this are the events `on_member_add`, `on_member_update`/`
 
 Bots
 ~~~~~
-| For bots (with the member intent), it's simple.
-| They request all guild members with an OPCode 8 (chunk the guild), and receive respective `GUILD_MEMBER_*` events, that are then parsed by the library and dispatched to users.
-| If the bot has the presence intent, it even gets an initial member cache in the `GUILD_CREATE` event.
+For bots (with the member intent), it's simple.
+
+They request all guild members with an OPCode 8 (chunk the guild), and receive respective `GUILD_MEMBER_*` events, that are then parsed by the library and dispatched to users.
+
+If the bot has the presence intent, it even gets an initial member cache in the `GUILD_CREATE` event.
 
 Users
 ~~~~~~
@@ -41,7 +43,8 @@ Users
 
 | But, here's the twist: users do not receive `GUILD_MEMBER_*` reliably.
 | They receive them in certain circumstances, but they're usually rare and nothing to be relied on.
-| If the Discord client ever needs member objects for specific users, it sends an OPCode 8 with the specific user IDs/names.
+
+If the Discord client ever needs member objects for specific users, it sends an OPCode 8 with the specific user IDs/names.
 This is why this is recommended if you want to fetch specific members (implemented as :func:`Guild.query_members` in the library).
 The client almost never uses the :func:`Guild.fetch_member` endpoint.
 | However, the maximum amount of members you can get with this method is 100 per request.
@@ -56,15 +59,16 @@ First, let's make sure we understand a few things:
 
 The member list uses OPCode 14, and the `GUILD_MEMBER_LIST_UPDATE` event.
 
-| One more thing you need to understand, is that the member list is lazily loaded.
+One more thing you need to understand, is that the member list is lazily loaded.
 You subscribe to 100 member ranges, and can subscribe to 2 per-request (needs more testing).
 So, to subscribe to all available ranges, you need to spam the gateway quite a bit (especially for large guilds).
+
 | Once you subscribe to a range, you'll receive `GUILD_MEMBER_LIST_UPDATE`s for it whenever someone is added to it (i.e. someone joined the guild, changed their nickname so they moved in the member list alphabetically, came online, etc.), removed from it (i.e. someone left the guild, went offline, changed their nickname so they moved in the member list alphabetically), or updated in it (i.e. someone got their roles changed, or changed their nickname but remained in the same range).
 | These can be parsed and dispatched as `on_member_add`, `on_member_update`/`on_user_update`, and `on_member_remove`.
 
 You may have already noticed a few problems with this:
 
-1. You'll get spammed with `member_add/remove`s whenever someone changes ranges.
+1. You'll get spammed with `member_add\/remove`s whenever someone changes ranges.
 2. For guilds with >1k members you don't receive offline members. So, you won't know if an offline member is kicked, or an invisible member joins/leaves. You also won't know if someone came online or joined. Or, if someone went offline or left.
 
 | #1 is solveable with a bit of parsing, but #2 is a huge problem.