I do not control change management for our organization, but we actually have two different "processes" running at the moment.   Since the process for our local campus is barely a process at all, and will soon mirror our more mature process for Shared Services... I'll focus on that.  

We have a CAB and eCAB.   Our CAB meets weekly on Fridays, an agenda is sent out prior to the meetings and the actual meetings take very little time.   Our official CAB (approvers) is very small indeed, but numerous interested parties join in on the meeting dependent on the agenda.   This usually includes one or more of our ServiceDesk managers for communication purposes, managers of teams that have other interests and occasionally the person putting forward a change to provide more information.   There is no one truly required on the call, but someone from the official CAB has to approve the Change.   Our CAB only approves Normal Changes.

Our eCAB does not meet, and obviously only approves Emergency changes.   This tends to be a larger group of people and Emergency changes are usually approved rather quickly and on the spot.

Standard changes do not require approval.

Required fields are a bit different based off of change type as well.   Standard changes require Category, CI, Risk, Type (though this is defaulted based on the type of change selected...if this is changed, the required fields change), Short Description, Description, Start/End date & time, Assignment group and Change Plan.   A Change plan is actually a KB article marked as a Change Plan (and will be moving to a separate KB with the Knowledge v3 update) that details out the standard change, including what all the technician should do to complete the change.   This makes it so the tech does not have to fill out Test, Backout, etc for each and every standard change.

Normal and Emergency changes require all the same fields except Change Plan and instead include Test plan, blackout plan and change plan.

We don't currently "calculate" risk, so much as rely on the technician to state the level of risk they believe a change has.   As we move forward, though, we plan to remove all but "Emergency" changes from the create new form, and force all other changes to go through a service catalog entry to spin up a change through a record producer.   We are hoping to better calculate risk and standardize the changes.   We also find that if make something too complicated it is less likely to be followed.   With dynamic forms we hope to make it easier and more intuitive for the staff.   We are also developing a formal process for CI changes in relation to Change Management.   We are also exploring some of the things that came from your presentation yesterday, including marking changes if an outage is expected.

Great presentation, and sorry for the wall of text!     I get a bit carried away sometimes...