How to suggest feature ideas

[needsofmany]

Purpose

Use this category for early feature ideas before they become scoped Issues or Design Proposals.

Good topics include:

• new export helpers
• new validation reports
• local viewer ideas
• importer or bridge ideas for other plural tools
• documentation helpers
• regular-user workflow improvements
• accessibility improvements
• database or reporting ideas
• website improvements

What helps

A useful feature idea should usually include:

• the problem it would solve
• who it would help
• what the feature might do
• whether it affects privacy, safety, exports, tokens, or private user data
• whether it belongs in the exporter, documentation, website, database layer, viewer layer, or future service layer

Privacy boundary

Do not post private Simply Plural exports, real System data, API tokens, screenshots containing private data, avatar images from real Systems, notes, messages, friend data, fronting history, logs, or database files created from real exports.

Use synthetic examples or carefully redacted descriptions.

[needsofmany]

Update: import ideas are especially welcome

Since this discussion was created, import support has become a much more defined part of the PluralBridge roadmap.

Simply Plural remains our first import rail, but the import architecture is being designed to support additional plural applications and interchange formats over time. PluralSpace is one source we already expect to evaluate, and OpenPlural is being considered as a developing interoperability format.

Feature ideas around importing are therefore especially useful at this stage.

Useful topics include:

• source applications or formats that PluralBridge should eventually understand;
• data that existing migration tools commonly lose or misinterpret;
• source-specific fields or structures that should be preserved;
• ways to represent information that does not map cleanly into another system;
• provenance and source tracking;
• large-System and unusual System-shape requirements;
• import previews and summaries;
• reporting what PluralBridge understood, transformed, could not understand, or would omit;
• allowing users to review and abandon an import before anything is committed;
• recovery and migration workflows between plural applications;
• interoperability ideas involving formats such as OpenPlural.

An important design goal is truthful import behavior. PluralBridge should preserve as much information as it can while clearly identifying anything it cannot faithfully represent or understand.

As with all feature discussions, please use synthetic or carefully redacted examples. Do not post private exports or real System data.