PluralBridge needs careful builders now.

Current areas where help matters

• .NET / C# API work for accounts, membership, import, member profiles, authorization, audit, and validation.
• Browser-side HTML, CSS, and JavaScript for clear, accessible workflows.
• SQL Server / Azure SQL schema review, migrations, constraints, and reporting queries.
• Import preview design for preserved Simply Plural exports.
• Privacy and security review for token handling, export handling, account boundaries, and public examples.
• Automated tests, synthetic fixtures, validation reports, and failure-case coverage.
• Documentation for users who are not developers.
• Website clarity, accessibility, and public messaging review.

Contributor privacy rules

PluralBridge works around sensitive System 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, documentation, or tests.

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

Different backgrounds, shared workflow

PluralBridge may attract contributors from 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. This workflow exists so contributors know 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 community spaces for informal conversation, outreach, and helping people find the right public project page.

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.

Before you open a pull request

• Check whether the work already has an issue, discussion, or active branch.
• Ask before starting large architectural changes.
• Keep each branch focused on one coherent change.
• Use synthetic data only.
• Write down what you tested.
• Explain user-facing behavior in plain language.

Branch roles

master

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

• master must remain deployable.
• Release identity comes from tags on master.
• Ordinary feature work does not go directly to 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 only for narrow production fixes.
• Keep branch names clear, such as feature/import-preview or patch/website-safety-copy.

Discuss these before coding

• Authentication, authorization, membership, or account-boundary changes.
• Import behavior, export interpretation, normalizer behavior, or database schema changes.
• Privacy, safety, token, secret-handling, or trust-boundary changes.
• REST API compatibility decisions.
• Large client architecture changes or new dependencies.
• Public website structure, navigation, or major messaging changes.
• 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.

Pull requests and previews

Website and documentation work should use GitHub pull requests and 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 layout, navigation, images, or user-facing wording changed.

Project independence boundaries

PluralBridge is an independent project. It is not affiliated with Simply Plural, Apparyllis, or the Simply Plural development team.

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.

Ways to help without writing code

• Review public pages for clarity and accessibility.
• Help turn technical notes into user-readable documentation.
• Test browser flows with synthetic data.
• Review whether privacy warnings are clear.
• Help identify confusing wording before users see it.
• Watch public discussions and route people to the right page without collecting private data.