Skip to content

Support "individual members" #466

Open
@vdhamer

Description

@vdhamer

Background

In The Netherlands, clubs are federated into what's called "de Koninklijke Fotobond". But you can also be an individual member of this "Fotobond", allowing you to participate in certain competitions, receive newsletters, etc. Possibly/probably other countries have a comparable organizational setup.

Requirements

IndivFotobondMemb = member of the Koninklijke Fotobond that is not affiliated with a club.

  • Obviously support for Fotobond clubs and non-Fotobond clubs should stay.
  • Add support for portfolio's of IndvFotobondMembs.
  • Nice if it clearly visible when photographers are IndvFotobondMemb. It will be somehow visible anyway because the app shows club affiliations.
  • An IndvFotobondMemb may have been a member of one of the clubs in the past. This should be visible.
  • No intention to support totally independent photographers (Club is our app's middle name!). But a photographer can always declare themselves a 1-person club. But it might be more convenient to band together with a few friends (either nearby online friends).

Design alternatives

  1. Promote each IndivFotobondMemb to a fake club (too many clubs).
  2. Cluster all IndivFotobondMembs into one fake club (too many members).
  3. Cluster all IndivFotobondMembs into one new Organization Type (too many members)
  4. Cluster all IndivFotobondMembs into a fake club per region (no reliable way to distinguish fake from real clubs)
  5. Cluster all IndivFotobondMembs into one new OrganizationType for a given region.
  6. Add a boolean to Organization to distinguish "real" from "fake" clubs. Roughly equivalent to 5.

In the case of fake clubs, software cannot distinguish between real and fake ones. Humans can tell by some kind of naming convention, at least for the country where they live.

In all cases, the app assumes that photographers are member of "something". And it assumes that this "something" can coordinate across its members. This suggests going for a "per region" approach where a region can manage the Level 2 data for multiple but not too many free floating photographers.

So having a tree structure helps make the data manageable, but does imply one responsible contact person.

Metadata

Metadata

Assignees

No one assigned

    Labels

    EnhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions