Guide changes 3

roadmap/implementers-guide/src/node/collators/collation-generation.md

@@ -99,7 +99,6 @@ On `ActiveLeavesUpdate`:
 * If there is no collation generation config, ignore.
 * Otherwise, for each `activated` head in the update:
   * Determine if the para is scheduled on any core by fetching the `availability_cores` Runtime API.
-    > TODO: figure out what to do in the case of occupied cores; see [this issue](https://github.com/paritytech/polkadot/issues/1573).
   * Determine an occupied core assumption to make about the para. Scheduled cores can make `OccupiedCoreAssumption::Free`.
   * Use the Runtime API subsystem to fetch the full validation data.
   * Invoke the `collator`, and use its outputs to produce a `CandidateReceipt`, signed with the configuration's `key`.

roadmap/implementers-guide/src/node/utility/chain-selection.md

@@ -24,10 +24,13 @@ Delete data for all orphaned chains and update all metadata descending from the
 
 Update the approval status of the referenced block. If the block was stagnant and thus non-viable and is now viable, then the metadata of all of its descendants needs to be updated as well, as they may no longer be stagnant either. Update the set of viable leaves accordingly.
 
+### `ChainSelectionMessage::Leaves`
+
+Gets all leaves of the chain, i.e. block hashes that are suitable to build upon and have no suitable children. Supplies the leaves in descending order by score.
+
 ### `ChainSelectionMessage::BestLeafContaining`
 
-If the required block is unknown or not viable, then return `None`.
-Iterate over all leaves, returning the first leaf containing the required block in its chain, and `None` otherwise.
+If the required block is unknown or not viable, then return `None`. Iterate over all leaves in order of descending weight, returning the first leaf containing the required block in its chain, and `None` otherwise.
 
 ### Periodically