anchor.diff:  ====
   Optaplanner does not currently support a `@PlanningVariable` annotation on a collection.
   ====
  -//I suggest removing this for now, the when you do implement `@PlanningVariable` add this note saying why you shouldn't use it: Although a future version will support it for flexibility reasons. it probably has an inherit performance and complexity cost, so it might be better to avoid it anyway.
  +
   +
   For example, in the Employee Rostering starter applicaion the `ShiftAssignment` class is the many-to-many relationship between `Shift` and `Employee`.
   `Shift` contains every shift time that needs to be filled with an employee.
  
positive.code: 
  
  . *Draw a class diagram of your domain model.*
  .. Normalize the diagram to remove duplicate data.
  // what does it mean to normalize a diagram?
  .. Create sample instances for each class. For example, in the Employee Rostering starter application, the samples for the `Employee` class are `Ann`, `Bert`, and `Carl`.
  
  . *Determine which relationships (or fields) change during planning and color them orange.* One side of these relationships will become a planning variable later on. For example, in the Employee Rostering starter application, the `Shift` to `Employee` relationship changes during planning, so it is orange. However, other relationships, such as from `Employee` to `Skill`, are immutable during planning
  
negative.code: [[designPatternsIntroduction]]
  == Design patterns introduction
  
  OptaPlanner design patterns are generic reusable solutions to common challenges in the model or architecture of projects that perform constraint solving. The design patterns in this section list and solve common design challenges.
  
  [[domainModelingGuide]]
  == Domain modeling guidelines
  