Clear rules on which entities are represented to which extent in Eiffel

[d-stahl-ericsson]

Description

Originally, Eiffel was designed to represent events in software pipelines. Its model can be applied to a great many things, though, and there's a chance/danger that Eiffel scope creeps into modeling more or less the universe.

Motivation

In every individual PR proposing an addition to the protocol, it's difficult to argue why this particular addition wouldn't be beneficial, but in a broader perspective there might be a point to clear boundaries on what Eiffel should concern itself with.

Exemplification

EiffelIssueStatusModifiedEvent and EiffelIssueAssignedEvent in #187.

Benefits

PR reviews could be more focused on defining conducive syntax and data representation, rather than veering off into a philosophical conversation about the raison d'être of the protocol.

Possible Drawbacks

Can't really think of any.

[e-backmark-ericsson]

The vision/mission was discussed in this TC meeting: https://hackmd.io/sL9z7MGwSCOGSCXeY27mFg?view#February-2-2023

---

• Compare to distributed tracing. Where do we draw the line? Should there be a spanId attribute in one of the activity events? Should we express an opinion on how deep down in the stack Eiffel should be used (build-as-a-service example)?
• How far towards the ops space (incidents etc)?
• Resource monitoring was used an example of what not to cover, but why not? A possible rule that might work is that events that are only useful outside the pipeline but never within the pipeline shouldn’t be part of Eiffel. That at least applies to the resource monitoring example. However, Eiffel can include references to where consumers can find resource usage data.
• Eiffel should be used for events/occurences, not “current status/state”.