Tenant Union Database Development Thread

Membership Committee Website & Technology
1

Project Goal

Build a permanent accountability system that tracks housing issues across changing owners, managers, and tenants — creating evidence for organizing and ensuring issues do not fall through the cracks.

Why This Matters

Current Problem

We do not have an organized way to track tenant issues. Using a basic checklist or excel database would mean that when landlords sell or change managers, we would lose the ability to attribute complaint histories to the correct people.

Impact

While we may start solving issues in the short term, we would lose the ability to build on our work over time.

Solution

Create a database that preserves relationships over time.

What We’re (Trying to) Build

Core Database Design

  • Track four key entities: Tenants, Properties, Owners, Managers
  • Preserve historical relationships (who owned what, when)
  • Link complaints to all relevant parties at time of occurrence

Temporal Tracking System

  • Records survive property sales
  • Complaints follow landlords to new properties
  • Management company patterns visible across all clients

Audit Trail

  • Every entry is traceable: who collected it, reported it, and when
  • Document which solutions worked for specific problems

Key Capabilities

Allow Us to Find Patterns

  • “80% of Landlord X’s properties have maintenance issues”
  • “PM Company Y harasses tenants across multiple properties”
  • “Building Z has pest problems regardless of owner”

Allow Us to Act Strategically

  • Identify worst landlords/PMs for targeted campaigns
  • Predict future problems based on ownership changes
  • Connect tenants facing similar issues

Implementation

Integration Points

  • Solidarity.Tech: Canvassing and communication tool with tenants. Can house survey data that are tenant related.
  • Discourse forum: Treat issues like tickets that can be tracked.
  • Assignment workflow: Ensure at least one WCU member is assigned an issue and responsible for keeping tenant(s) in the loop.

Data Flow

  • New tenant → Link to building/landlord → Collect issues/problems
  • Issue reported → Forum thread created → Assigned to WCU member
  • Tenant associations can view/create threads for their buildings

Next Steps

Initial Next Steps

Technical Foundation

  • Choose database technology
  • Create a version control repository
  • Document data model decisions

Core Schema Design

  • Define minimum viable tables (WCU Membership, people, properties, units, issues)
  • Implement temporal fields
  • Design audit fields (created by, modified by/at)

Initial Data Mapping

  • Export data from county
  • (Maybe) Incorporate data from PropertyRadar
  • Export data from solidarity.tech
  • Identify how data has to be cleaned up, mapped to fields, and use n8n to automate the data migration

MVP Baseline

  • Figure out what MVP development baseline level is
2 Likes
2

A reply from a comrade elsewhere…

I’m half working on another project that is trying to make connections between state and local data in CO. Very annoying to try and match up what the state’s data for a particular business and the muni’s data. NYCDB is the inspiration but NYC has nice, clean data, but even then they’re using fuzzy search to connect names and addresses across data sets.
GitHub - nycdb/nycdb: Database of NYC Housing Data

But if you have a basic data model that you could normalize across variegate datasets, then scoped to particular regions, you could make a simple site that lists the apartments/owners/PMs and just let people comment on it. Could take off as a way to complain about your landlord, which could help tenant organizers. I have to check Google reviews for that kind of info.

NYCDB was used to build this https://whoownswhat.justfix.org/en/
Example landlord: https://whoownswhat.justfix.org/en/address/MANHATTAN/1641/2%20AVENUE

3

Evictorbook is similar and also has a graph for how they network information together: Evictorbook

image
image1150×839 50.5 KB

Here’s what we have worked on in the past:

Here’s some information from someone else on a survey they used:

Here’s a diagram. Pretty basic. There’s a survey, it has questions, which have answers. There are survey responses for the survey, which have response answers associated with the survey questions. Some features:

  • survey_questions.required allows you to require an answer to the question
  • survey_questions.kind can be something like ‘single-choice’, ‘multiple-choice’, ‘open-ended’. You would have some logic in your app to ensure that single-choice questions only have a single response answer.
  • survey_response_answers.answer_given is for open-ended questions, where the person taking the survey can fill in comments or whatever. Also allows the person taking the survey to give an explanation for single-choice and multiple-choice answers.
  • survey_questions.sequence and survey_answers.sequence is to show them in a specific order when being displayed
    survey_schema
    survey_schema1271×284 33.2 KB
4

Here’s another example: https://antievictionmap.com/
https://sfownership.antievictionmap.com/about.html