Help build PluralBridge without putting users at risk.

Different backgrounds, shared workflow

PluralBridge may attract contributors from several worlds: professional software development, open-source maintenance, plural-community support, documentation, data preservation, security, accessibility, and user advocacy.

Those backgrounds do not all use the same habits or vocabulary. A professional developer may be new to GitHub Discussions, public issue triage, or open-source maintainer norms. An experienced open-source contributor may be new to the privacy, safety, and release-stability requirements of a project preserving sensitive plural System data.

This workflow exists so contributors do not have to guess. It explains where conversations happen, how work becomes accepted, when maintainers need to decide, and how PluralBridge protects users while still welcoming outside help.

Where project discussions happen

• Use GitHub Discussions for design proposals, broad questions, feature ideas, and governance conversations before work is scoped.
• Use GitHub Issues for accepted, actionable work.
• Use pull requests for review of actual code, documentation, website, or data-shape changes.
• Use Discord, Facebook, Reddit, email, and other community spaces for informal conversation and outreach.

Project decisions that affect code, documentation, privacy posture, release behavior, supported workflows, or public messaging should be captured in GitHub so future contributors can see the reasoning.

Security-sensitive or privacy-sensitive reports should use the project security reporting path instead of public discussion.

Branch roles

master

master is the production branch and represents the current public release.

• master only gets merged from dev.
• master must remain deployable.
• Release identity comes from tags on master.

dev

dev is the stable integration branch for the next release.

• dev receives reviewed project work from feature branches.
• dev should stay stable enough to preview and release.
• Release pull requests go from dev into master.

feature and patch branches

Active work happens on focused project branches.

• Create ordinary feature branches from dev.
• Create patch branches from master when a fix must start from the exact current release.
• Keep each branch focused on one coherent change.
• Use clear branch names such as feature/official-export-importer or patch/image-fix.

Feature branch decisions

Feature branches are proposal branches. Opening a pull request does not guarantee acceptance.

Small fixes may be opened directly as pull requests. Larger changes should start with an issue or discussion before implementation.

Discuss these changes before coding:

• Visual design or branding changes.
• Navigation or public website structure changes.
• Public messaging changes.
• Privacy, safety, or trust-boundary wording changes.
• Database schema, export format, importer, or normalizer behavior changes.
• Authentication, token, or secret-handling changes.
• REST API compatibility decisions.
• Client architecture decisions, large refactors, or new dependencies.
• Changes that affect nontechnical-user workflows.

Maintainers may ask for changes, split work into smaller pieces, defer work to a later milestone, redirect work into a different branch, or close work that does not fit the project.

Patch branches and production fixes

Patch branches are exceptional production-fix branches. They are used only when the current public release needs a targeted correction that should not wait for unreleased work already in dev.

Contributors may propose patch handling by opening an issue or discussion explaining the production impact. A maintainer decides whether the issue qualifies for patch handling.

Good reasons for a patch branch

• Live website breakage.
• Privacy or safety wording already published on master.
• Broken public install, export, or run instructions.
• Release artifact problems.
• Serious production-facing bugs.
• Small urgent corrections that must ship without unrelated dev changes.

Poor reasons for a patch branch

• Ordinary feature work.
• Broad documentation rewrites.
• Speculative refactoring.
• Experimental importer or viewer work.
• Wording polish that can wait for the next release.
• Changes that would pull unrelated dev work into production.

Patch workflow

1. A contributor or maintainer identifies the production-impacting issue.
2. A maintainer approves patch handling.
3. The patch branch is created from master.
4. The patch is kept narrow and reviewed through a pull request into master.
5. master is tagged if the patch changes the released version.
6. After the patch release goes live, master is merged or fast-forwarded back into dev.

Maintainer authority and delegation

PluralBridge welcomes outside contributions, but contribution access is not the same thing as production authority. Maintainers are responsible for protecting the project's privacy posture, public trust, release stability, and community safety.

Pull requests and previews

Website and documentation work should use GitHub pull requests and Cloudflare preview deployments so changes can be inspected before they reach users.

• Open ordinary feature pull requests into dev.
• Open release pull requests from dev into master.
• Use a short title and a clear description of what changed.
• List testing performed before requesting review.
• Preview website changes before merge when the page layout, navigation, images, or user-facing wording changed.

Finding the Cloudflare preview

1. Open the pull request conversation page.
2. Scroll to the merge/status box near the bottom of the pull request.
3. Expand the check details for the Cloudflare Pages deployment.
4. Open the deployment or preview page from the Cloudflare check row.

The preview URL is generated after the branch is pushed and the pull request check runs.

Contributor privacy rules

PluralBridge works with sensitive preservation data. Contributors must keep real user and System data out of public project work.

Do not include real exports, tokens, security logs, IP-bearing records, private notes, messages, member data, avatar images, friend data, fronting history, privacy buckets, generated databases, screenshots, or logs from real Systems in public issues, pull requests, examples, fixtures, or documentation.

Use synthetic test data or carefully redacted examples. Redaction must remove private values, stable identifiers, tokens, account data, and anything that could expose a real System.

Official Simply Plural exports should be treated as secret-bearing private backup files.

Project independence boundaries

PluralBridge is an independent preservation and continuity project. It is not affiliated with Simply Plural or Apparyllis.

Contributors must not contribute work based on decompiled code, reverse engineered private implementation details, copied Simply Plural UI layouts, copied branding, copied app flows, private server behavior, or authentication systems copied from Simply Plural or Apparyllis.

Interoperability work should stay focused on user-owned exported data, documented or public API behavior, local preservation, validation, migration, and future compatible interfaces where feasible.

Plural community conduct

PluralBridge serves plural Systems and people preserving sensitive personal records. Contributors should reduce friction and protect user agency.

• Respect plural Systems and plural-community language.
• Do not ask users to disclose private System details.
• Do not ask users to upload private exports for troubleshooting.
• Do not turn support or development threads into debates about identity, diagnosis, legitimacy, or community politics.
• Keep explanations practical, calm, and privacy-preserving.

Current ways developers can help

• Official Simply Plural export inspection and normalization using synthetic fixtures.
• Tests for normalizer behavior and export validation.
• SQLite support for local/offline use.
• Validation reports and readable summaries.
• Documentation for nontechnical users.
• Website accessibility and clarity improvements.
• SQL review and report-query improvements.
• Local viewer prototypes.
• Import bridges for other plural tools when those projects want them.
• Safe synthetic sample data shaped like Simply Plural data without exposing real System data.