Site guide

Overview

This website manages the SPB community, replacing MeetUp. It gives us more ownership of our data, and allows for more customised functionality.

Migration

The following data is migrated from MeetUp:

  • Events: all past and future (including image, venue and description), along with rsvps and comments. RSVPs by people who are not on MeetUp anymore have disappeared.
  • Users (both members and applicants): nickname, picture, application question responses, location, membership date and status. Note that the users list will only be populated as users register for the website; their data is stored in a temporary table to populate their profile when they register.
  • The user’s “allowed level” is imported from the membership spreadsheet.
  • Direct messages between users are not imported (as we obviously do not have access to them).

Users

Users (visitors/members) have the following fields/properties:

  • During registration, users need to specify first & last name, display name, e-mail, and create a username and password.They also need to check a box to accept the privacy policy..
  • Mandatory when migrating and when applying: gender, orientation, province, checkbox to accept the CoC
  • Mandatory when applying: application questions
  • Optional fields: pronouns, town, fb profile (only for validating access to secret fb group)
  • Membership admin fields: caretaker, remote, allowed level 

Website users have one of the following roles:

  • Visitor: default role when registering as a new user. Limited access to public information, possibility to apply for membership. Can RSVP for public events (e.g. Cafés)
  • Member: Full SPB member
  • Coordinator. Can access all info on members&visitors, can change events and users

On top of this, Members/Coordinators can have extra privileges:

  • Events: can manage all events 
  • Membership: has access to membership-specific functions

The role is shown in the user profile. 

Once accepted as a member, all fields except first name, last name, e-mail and fb profile are visible to other members. This includes the answers to the application questions that will be visible to other members. There is also a Biography field which is shown somewhat more prominently

  • Application questions:
    • Tell us something meaningful about yourself.
    • Why do you want to join our community?
    • How did you find us?
    • What other sex-positive communities/groups have you been part of?
    • We are inclusive (LGTBQAI+) & covet diversity; let us know how you’ll balance our group.
    • Tell us how you handle Boundaries and Consent (Yours & in/of others)
    • In what way could you contribute to the group?

A user can answer the application questions in the “Application” tab in their profile. This can be saved and picked up again at a later time. Once ready, they “Submit” the application. They can still bring it back to “User Input” mode after that if needed. Or they can bring it back to “Draft” by revoking their application.

The application can have the following statuses:

  • Draft: Not submitted and hence not being processed by the membership coordinator
  • Review: Submitted for review by the membership coordinator
  • User input: Submitted but back in edit mode (either you want to make changes, or the coordinator has requested changes)
  • Proceed: Application has been reviewed and positively evaluated; the coordinator will contact you for further steps
  • Orientation: You have been, or will be, invited to an orientation
  • Approved: Your application has been approved for SPB Membership
  • Declined: The application was declined; you remain free to re-apply at a future date
  • Rejected: The application was rejected, and you cannot re-apply

The Coordinator reviewing the application will either ask more questions and put the application back in Editing, or, if happy, put it in Proceed status, meaning the user can be invited for an orientation.

Applicants have an extra tab “comments & messages” in the applicant’s profile, which is also visible to Membership Admins. Membership can add (private comments) in here, and can put a message for the applicant; some other events, such as a status change of the application, are also logged here.
The applicant only sees the messages of Membership, and can reply with their own messages.

After a successful orientation, and acceptance of membership by the applicant, the coordinator can change the user’s role to Member.

Users get notifications (in the side bar of the site) containing new events, RSVP actions, messages… 

The Member directory gives a list of members with limited search functionality. The inclusivity dashboard gives some graphs about inclusivity spread.

For coordinators, reports of Members or Visitors can be made with extensive filtering. Some graphs are also automatically added. Two membership management pages exist: Application management is like the visitor report but more tuned for applications. Membership todo shows all “userlogs” (messages and status changes in the applicants profile) with a todo checkbox. The checkbox is currently unchecked for status changes caused by the applicant, and for messages from the applicant.

Events

Event fields:

  • “Level”, with options Level 1, Level2, Level 3, Level 4, and Outing. For multilevel events, e.g. 2-3, please use the lowest one.
  • “Access Level” indicates who can see it and who can RSVP:
    • “Members”: for regular SPB events. Only members can see and RSVP.
    • “Visitors”: for Cafés or other public events. Both members and non-members can see and RSVP. Note that non-members still need to have registered and logged in. For cafés, it probably doesn’t hurt to state that RSVP is not mandatory to attend.
    • “Invited Visitors”: for L1 events allowing non-members to be invited. Visitors cannot see the event to avoid uninvited attendance.
  • Number of spaces: if 0, no RSVP is possible. If 999, the maximum is not mentioned (considered unlimited)
  • Waiting list: whether RSVPs are added to a waiting list when the event is full. In case of a cancellation, the next RSVP on the waiting list will automatically be activated.
  • Approval needed
  • Allow invites: how many (named) visitors can an attending member invite?
  • Extra people: Allows people to add extra (unnamed) attendees, e.g. to a café.

Coordinator and Event admins can manage events, RSVPs and locations from the front end. 

Irrespective of the event settings, coordinators/event admins/event host can always add/remove RSVPs and +1s, and push them from/to the waiting list. They can also add/remove hosts.

If Visitors can see an event, it will only show (User) for each participant and for the host(s). Visitors cannot see comments, names of hosts or other attendees.While members can create a draft event, only coordinators and Event admins can publish it.

Members will see other RSVPs with their display names (with avatar and link to profile) for members, but (Visitor) for visitors. Coordinators will see all RSVP names.

The host, a coordinator or an Event admin start a group messaging thread with attendees.

Users can start a group messaging thread with the host(s) of the event.

From the “Care” page, members can start a group messaging thread with Caretakers.

Communication

The messaging interface is more chat than e-mail like.

  • Person-to-person(s) (or person-to-group) messages:
    • Via the destination user’s profile
    • Directly from the messaging interface, with an autocomplete search on display name
    • Via crafted links (e.g. message attendees to an event)
  • Visitors do not have access to the messaging function, and cannot be messaged by members. Instead, they can communicate with the Membership Admins via the Admin messages tab in their profile. 

Email notifications when either kind of message is received, are sent (only if offline & after 15’). Replies by mail to these mails are not possible, but they contain a URL to the messaging interface through which a reply is possible.

Other

Information pages can be published; their visibility is subject to the role system. Editing is currently only through back-end.

Posts (e.g. what’s new) can also be published (through back-end, so only admin/coordinator)

Technicalities

  • The site is currently hosted at one.com, which provides a “one-click WordPress install” as part of the current subscription. Beware, this is NOT a managed WordPress install.
  • The hosting also includes domain name, TLS connection and certificate, CDN coverage, mailboxes, etc.
  • Authentication happens with username and password (min 8 characters, must be “strong”)
  • Privileges based on WordPress roles (see section on Users)
  • Administrator login only possible via hosting company login
  • Backups of site and DB performed by hosting company: daily, retention 15 days
  • Registration and login form have Google reCAPTCHA v3 enabled