Intros

Code Climate guidelines

If PR is urgent, ask a GitHub repo admin to approve in Code Climate, then immediately fix the offenses. Don't open a new ticket.
If PR is not urgent, take the time to understand the issue and fix it, unless it's a false positive.
Walk through reading up on offense in CC

https://www.sandimetz.com/blog/2009/06/12/ruby-case-statements-and-kind-of
It is not the job on any object to tell any other object how to behave.
Objects create behavior by passing messages back and forth. They tell each other what, not how.
What is the event/notification/request and it is the responsibility of the sender.
How is the behavior/implementation and it should be completely hidden in the receiver.
Each object knows its own implementation and it exhibits that behavior when it receives a message.
No object in your system should have to know the class of any other object in order to know how to behave. Everything is a Duck. Tell the Duck what and the Duck should know how.
The last object that could possibly receive the message is the object that should implement the behavior.

https://vimeo.com/91672848
The only thing an object can do with another object is send it a message
The only thing an object can know about another object is what messages it accepts
Message describes the what, and hides the how
To control complexity, one must embrace simplicity
Traffic light example: all it knows about is its current color state and the passage of time. It doesn't know anything about what type of intersection, vehicles, etc.
End goal: malleable, extensible, reusable, simple
Blind trust: allows objects to collaborate without binding themselves to context and is necessary in any application that expects to grow and change.
OO design requires that you shift from thinking of the world as a collection of predefined procedures to modeling the world as a series of messages that pass between objects.

Adding a new appeal type will require modifying the all method, leading to Divergent Change.
The logic and data for combining the events for each appeal type is jammed into one class, resulting in a Large Class
AppealEvents should not know how LegacyAppeal implements all
Tell, Don't Ask
AppealEvent takes in different arguments at different times: hearing, type, disposition

Reveals unused code: AppealEvent#to_hash, calling to_hash in V2::LegacyAppealStatusSerializer#events
Code is easier to read
Makes testing easier, not clear where everything is tested. For example, supplemental claims tested in spec/feature/api/v2/appeals_spec.rb
Reveals missing specs: appeal_events_spec was only testing legacy appeals
Reveals code in AppealEvent that only applies to legacy appeals and can be extracted out: disposition=, issue_disposition=
date, type Data Clump or Parameter Object

Moving lines from a class into a concern and the including the concern back in the class (shoving under the rug)