they are excused from receiving notices and from voting on (almost all) members resolutions. so only voting shareholders receive members resolutions.
how should our system model this business logic?
just as we have defined roles of shareholder vs new_investor vs brand_new_investor, let us also define specialized subclasses of shareholder, as voting_shareholder vs nonvoting_shareholder.
these specializations should be available to the developer somewhere in the captable round object hierarchy.
this relates to #48, #127, #37, #84, and #85.
we should then update the demo master's available_templates sheet so the "To" column describes voting_shareholder, where now it describes shareholder.
along the way we may also update various templates to use inc_enumerate_shareholders and inc_enumerate_parties more rigorously.
they are excused from receiving notices and from voting on (almost all) members resolutions. so only voting shareholders receive members resolutions.
how should our system model this business logic?
just as we have defined roles of shareholder vs new_investor vs brand_new_investor, let us also define specialized subclasses of shareholder, as voting_shareholder vs nonvoting_shareholder.
these specializations should be available to the developer somewhere in the captable round object hierarchy.
this relates to #48, #127, #37, #84, and #85.
we should then update the demo master's available_templates sheet so the "To" column describes
voting_shareholder, where now it describesshareholder.along the way we may also update various templates to use
inc_enumerate_shareholdersandinc_enumerate_partiesmore rigorously.