Add membership type field

[cttengsfmta]

Add membership type field to the provider API. We presume that more values could be added to the list of membership types. (Reopening #106, as requested)

[cttengsfmta]

More background on why we need this: optional field describes the general membership of the user taking the trip. The values and applicability would vary based by jurisdiction. Some programs allow members to sign up for subscription options (e.g., monthly or annual) in addition to paying as you go with a single ride fare. Additionally, SF’s programs have low-income options. Calculating total trips in the aggregate by type would be part of our regular reporting.

[hunterowens]

@cttengsfmta this looks good. We will also want to change the corresponding JSONSchema definitions for our validator codebases. Do you want to take a crack at that or should I?

[hunterowens]

I wonder how similar #126 and #76 are.

[cttengsfmta]

I don't see a way to add a new Enum in generate_provider_schema.py

[alexdemisch]

To summarize the discussion from the 4/11 call, the current proposal would be to add the membership_type field, starting with the enum values proposed earlier. This would be an optional field. While this field does provide information related to the user of the trip, it is still generalized and not PII. There are concerns that an enumerated list of values may not be able to capture quickly changing business models that may introduce new membership types, so the enum values would need to be actively managed. An experimental prefix (e.g., “ex-“) could be used to allow new values not explicitly added to the list of enumerated values.

[hunterowens]

moving this to 0.4.1 as an optional field.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Jose Quinteiro seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[hunterowens]

@dirkdk to rewrite based on discussion on 1/16 into a separate reporting / equity notes.

[schnuerle]

Would like to revisit this idea for adding this info directly to the Provider API, in addition to potentially adding to a Metrics API #486.

[schnuerle]

This is being discussed as part of a subset of a proposed Metrics API with aggregated (not trip level) information about special groups in #569.

[johnclary]

I'm strongly opposed to adding attributes to trip records that describe the users taking trips.

[alexdemisch]

We've discussed some of this already in some of the Provider WG calls on Metrics, but I'd consider this specific proposal to add additional elements to the detailed trip data to be abandoned in favor of the aggregate "special groups" reporting in the Metrics #569.

The only reason it would've be collected at a detailed level would be to roll it up anyway, so #569 is a better way to do this.

[schnuerle]

Closing this in favor of work on #569.