I agree, the ability to modify ticket status, create/reset approvals etc using rules, just as we can for incident and request tickets would take a lot of the pain out of using changes in GLPI.

I would prefer it if we did not waste space at the top of the viewable version of the KB article by including the words Subject and Content, instead it would be preferable if the header same header as above were formatted as follows

The line “…underlined team memberships would not be prevented,…” should have said “…underlined team memberships would be prevented,…”

Really requires a change window I.e. a wide proposed range of dates when the change could take place (giving higher chance of avoiding change freeze or delays in ticket processing etc i.e a window within which the change can be scheduled. These start/end dates should be defined while in New stays and certainly before leaving the Evaluation status.

But also requires a scheduled start and finish date/time, which should be defined when in the Accepted status. This should really be the Schedule status and is completed when the actual change work is scheduled. 

The ticket should be moved into the Pending (or Implement status at the scheduled start date/time.

in original post Assessment = Evaluation 

could also check if required fields have been completed first and warn/error.

e.g. moving from New to Evaluation could check that Plans tab fields have been completed 

Or moving from Evaluation to Approval could check that Analysis tab fields have been completed