[Enhancement]: Proposal to Make `current_relationship` on Stakeholder a list

[JSv4]

Description of Enhancement :

This was discussed quite some time ago (over a year). We debated making relationship a multi-select and decided against it. I'm remembering now that it may have been related to not having the version history for changes to that field and concerns about the list going stale. Think there was also some concern with not all vendors having this information and, if they export a single relationship, it would not be clear whether this is the entirety of the relationships a given stakeholder has or whether the vendor just doesn't track it. Anyway, there is a lot of interest in the legal working group having a list for this field, possibly making it a list of objects with start and end dates for the various relationship objs.

Why is this Needed?

Lot of interest in having more data in this field, particularly because current approach is known to be unable to capture common situations - e.g. ex-employee who becomes an adviser or someone who is a board member and then becomes an investor. An issue here, again, is all vendors may not have this.

Anything else we need to know?

[pjohnmeyer]

In order to make this change in a non-breaking way, we would change the Stakeholder model to allow one field or the other:

1. The existing field, current_relationship OR
2. A new array field, relationships which will contain 1 or more StakeholderRelationship entries with the shape: a. type: StakeholderRelationshipType enum b. start_date c. end_date

Neither 1 or 2 will be required, although 2 will be necessary for high-quality OCX output.

We would then desire a way to "remember" to eliminate 1 when we make a 2.0 release.

[JSv4]

To track the deprecations, let's use a GitHub issue.

Versioning we're planning to use major changes for breaking changes.

Some questions:

1. How often do we release breaking changes?
   1. How do we define a breaking change? Validations fail.
2. Do we issue breaking changes periodically? Based on volume?
3. Do we want to have versions on an object level? This would be more advantageous for maintaining backwards compatibility.
   1. Where would we put the version codes?
      1. We should only do this for objects.
   2. would we put the versions in API endpoints?

TODO - build this change with mind towards fleshing out what object-level versioning looks like.

[naveedn]

I have some thoughts on a potential approach we could take:

• Rather than capturing state changes and timeframes on the stakeholder object itself (as a list with start and end dates, which could get complicated for vendors to reproduce faithfully), what if we created a StakeholderChange transaction that would represent the updates to the Stakeholder object at a certain point in time?
• StakeholderChange transactions could represent legal name changes (e.g. marriage), Address changes, and would make pinpointing the start/end dates of a Stakeholders relationship with the Issuer trivial to compute (e.g. on board of directors from 2020-02 to 2021-03-19).
• This also gives the advantage where we can represent stakeholders "as of" a specific timeframe, which is useful when we want to dig into, for example, an ex-employee's address on file when they exercised their options.
• This also naturally extends the the event transaction model that we're using for securities.

I'll edit this comment later with a hypothetical schema for how this transaction could look like.

[JSv4]

Per TWG discussion, it doesn't seem like this is actually required for OCX at all. If not, let's punt this to when we do version control / change logs for all objects (which we intentionally decided not to add to v 1.0.0).

Full list of discussion points from the meeting:

1. We might want to update enum to track employees of subs
2. @naveedn's proposal still doesn't engage with we might want to track multiple positions at once so a list here probably makes sense
3. @naveedn's proposal makes sense IF this is in support of OCX. If not, let's revisit changes 2 and 3. Per @arthur-clara's point, though, 1 is pretty simple and may make sense as a very simple update now (just update the enums)

[JSv4]

Discussion re: supporting multiple positions simultaneously:

• Not everyone supports having multiple relationships simultaneously
• Some do
• Folks do see use-cases for supporting simultaneous relationships.
• If we add date ranges or support multiples, suggest changing field name
• Could be an event too

[JSv4]

Revisiting this after a long while... since we've opened up issuer events, I'd say let's just go with stakeholder events too and do this right. An event-based system an ADD_RELATIONSHIP and REMOVE_RELATIONSHIP event seems right to me.

[pjohnmeyer]

Unassigning myself for now; I may return to this but I don't want to be perceived as a blocker.

[JSv4]

Will also be relevant for ISO/NSO split.