Help build PluralBridge
PluralBridge needs careful builders now.
Simply Plural has shut down. The next PluralBridge milestone is the first browser-based release: sign in, review a Simply Plural export before saving it, and work with member profiles in the browser.
Help is needed from developers, users/Systems, and subject matter experts working together on privacy, safety, usability, and release quality.
The current build target
The first browser-based release should give preserved Simply Plural data somewhere safe to land. The immediate product path is account setup, import preview before saving, and member profiles that can be viewed, added, and updated.
Privacy, user ownership, membership boundaries, auditability, and careful import review matter as much as the visible screens.
Current areas where help matters
Developers
- .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.
- Automated tests, synthetic fixtures, validation reports, and failure-case coverage.
Users/Systems
- Review workflows for clarity, safety, and practical usability.
- Flag confusing wording, risky assumptions, or missing real-world scenarios.
- Help validate that public guidance protects privacy while staying usable under stress.
Subject Matter Experts
Subject matter experts provide domain guidance across privacy/safety, consent boundaries, accessibility, data handling, and lived-practice realities, including but not limited to therapists, advocates, researchers, and other qualified specialists.
- Review safety boundaries and consent implications in planned features.
- Review accessibility and communication quality for public-facing guidance.
- Identify domain-specific risks before they become user harm.
GitHub Discussions
- Propose ideas, clarify scope, and surface risks before coding begins.
- Align developers, users/Systems, and subject matter experts on decisions.
- Capture decisions and rationale in public threads so future contributors can follow context.
Community participation: We actively participate in plural-community spaces such as
r/SimplyPlural and r/plurals (including as Sharky_J_Yellowfish).
When appropriate, we also share relevant PluralBridge updates there.
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.
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.
- 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.
- 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.
master
master is the production branch and represents the current public release.
mastermust 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.
devreceives reviewed project work from feature branches.devshould stay stable enough to preview and release.- Release pull requests go from
devintomaster.
feature and patch branches
Active work happens on focused project branches.
- Create ordinary feature branches from
dev. - Create patch branches from
masteronly for narrow production fixes. - Keep branch names clear, such as
feature/import-previeworpatch/website-safety-copy.
- 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.
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
devintomaster. - 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.
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.
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.
- 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.
Start with the browser release goal, then use GitHub Discussions or Issues to find work that fits your skill set. Keep private user data out of public project spaces.