1
Signal interest and choose a local path
A person should be able to join through an open registration path, an invitation path, or a local organizer-assisted path depending on how the relevant community operates.
Join the movement
Membership should be flexible enough for real communities.
Different chapters and communities may need different membership flows. Some will want open registration. Some will want invitation, payment, or approval. The movement should be able to support that variation without turning onboarding into chaos.
Member path
A draft lifecycle that can stay human instead of bureaucratic.
2
Complete the local membership flow
Different chapters or units may require different combinations of payment, approval, onboarding, or profile completion. The system should allow that variation instead of forcing one rigid path.
3
Activate participation, not just a record
Membership should lead directly into working groups, community activity, events, support channels, and chapter responsibilities rather than ending at a status row.
4
Unlock benefits that make participation easier
Where product maturity and capacity allow, membership should open access to aligned ProsperApps tools at friendlier prices so people can actually do the work.
Flexible states
Registration, payment, approval, and claim should be allowed to vary independently.
This is one of the reasons Prosper Movement can become a strong real-world use case for ProsperOrg. Local units need room to configure lifecycles that fit their context.
Feature
Open registration with payment pending
A member may register and still be waiting on dues or sponsorship before activation. That should be a normal supported path, not an edge case.
Feature
Paid but still pending approval
Some communities may want a payment step and an approval step. Those should remain separate states when needed.
Feature
Invited, accepted, and still completing requirements
Invitation acceptance should not force instant full activation when a chapter still needs onboarding, payment, or review.
Feature
Admin-created records that members claim later
A local organizer should be able to create a member record first and let the person verify or claim it later without breaking the lifecycle.
Practical outcome