more tweaks

commands/best-practices.md

@@ -81,7 +81,7 @@ private Command setAngle(DoubleSupplier angle) {
 }
 ```
 
-If a command needs configuration or other information from elsewhere, then the factory should take a `Supplier`, e.g. a `BooleanSupplier` or a `DoubleSupplier`.
+If a command needs configuration or other information from elsewhere, then either the factory or the Subsystem constructor should take a `Supplier`, e.g. a `BooleanSupplier` or a `DoubleSupplier`.
 This supplier should be providing outside information, not implementation specifics.
 We prefer to pass a `Supplier` rather than a specific value because we want to be able to support dynamic configuration where the value changes.
 We prefer to pass a `Supplier` rather than injecting a `Subsystem` because we don't want to tie the implementations together; we should assume the minimum possible about where the information comes from.

commands/commandscheduler.md

@@ -1,6 +1,13 @@
 # CommandScheduler
 
-When you are first taught to program, you are usually shown what is called the "imperative" style.  That means that you are in control of what happens when.  In a command-based robot, you have to use an "event-driven" style.  You must learn how to break your code up into small pieces that execute quickly and rely on the `CommandScheduler` to call them at the right time.  The `CommandScheduler` will manage commands, calling their four lifecycle methods (`initialize`, `execute`, `isFinished`, `end`).  It will also call the `periodic` methods of your subsystems and test any triggers you may have (mostly this will be joystick buttons).  It is also responsible for managing the requirements of two commands, so two commands with overlapping requirements are never scheduled at the same time.
+When you are first taught to program, you are usually shown what is called the "imperative" style.
+That means that you are in control of what happens when.
+In a command-based robot, you have to use an "event-driven" style.
+You must learn how to break your code up into small pieces that execute quickly and rely on the `CommandScheduler` to call them at the right time.  
+
+The `CommandScheduler` will manage commands, calling their four lifecycle methods (`initialize`, `execute`, `isFinished`, `end`).
+It will also call the `periodic` methods of your subsystems and test any triggers you may have (mostly this will be joystick buttons).
+It is also responsible for managing the requirements of two commands, so two commands with overlapping requirements are never scheduled at the same time.
 
 There are a number of ways to invoke the `CommandScheduler`:
 
@@ -17,7 +24,7 @@ There are a number of ways to invoke the `CommandScheduler`:
 * Attempts to add the command to the list of scheduled commands.
 * If a scheduled command has overlapping requirements, then either the other commands will be cancelled or if the other commands are non-interruptible (rare), then the attempt will fail.
 * This should be called by `Robot.automomousInit` to set the autonomous command.
-* It's fairly rare for teams to call `schedule` in any other context.  The main example is a pattern where you create a state machine by having each state be a separate command, with all of them sharing the same requirements.  Outside that, if you find yourself wanting to call this anywhere else, you're probably doing something wrong.
+* It's fairly rare for teams to call `schedule` in any other context.  The main example is a pattern where you create a state machine by having each state be a separate command, with all of them sharing the same requirements, but it is usually better to [do the scheduling indirectly via `Trigger`s](/best-practices.html).  Outside that, if you find yourself wanting to call this anywhere else, you're probably doing something wrong.
 * Calls to `schedule` from inside a command lifecycle method are deferred until after all the scheduled commands have been run.
 
 ## `Command.cance()`