[Merged by Bors] - Improve bevy_ecs and bevy_app API docs where referenced by the new Bevy Book

crates/bevy_ecs/src/system/mod.rs

@@ -1,3 +1,21 @@
+//! The behavior building block of an ECS application.
+//!
+//! Systems define how an ECS based application behave. They have to be registered to a
+//! [`SystemStage`](crate::schedule::SystemStage) to be able to run. A system is usually written as a normal function.
+//! Then the [`.system()`](IntoSystem::system) trait extension method have to be converted
+//! into a Bevy system.
+//!
+//! System functions can have parameters, through which one can query and mutate Bevy ECS
+//! states. Some limitations on allowed parameters apply (See [`SystemParam`]).
+//!
+//! While the execution of systems is usually parallel and not deterministic, there are two
+//! ways to determine a certain degree of execution order:
+//!
+//! - **System Stages:** They determine hard execution synchronization boundaries inside of
+//!   which systems run in parallel by default.
+//! - **Labeling:** First, systems are labeled upon creation by calling `.label()`. Then,
+//!   methods such as `.before()` and `.after()` are appended to systems to determine
+//!   execution order in respect to other systems.
 mod commands;
 mod exclusive_system;
 mod function_system;

crates/bevy_ecs/src/system/system.rs

@@ -1,14 +1,3 @@
-/// The main building block in the Bevy ECS app model.
-///
-/// Systems are usually written as normal rust functions. Then the `.system()` trait
-/// extension method is called to make them be Bevy systems.
-///
-/// System functions can have parameters, through which one can query and
-/// mutate Bevy ECS states.
-/// See [The Bevy Book](https://bevyengine.org/learn/book/introduction/) for more information.
-///
-/// Systems are usually run in parallel, and the execution order is not deterministic.
-/// If you want more fine-grained control for order, see [`AppBuilder::add_system_to_stage`].
 use bevy_utils::tracing::warn;
 
 use crate::{