Add way to contribute by modifying data on an existing device #74

Parent

• Stage 3: Enable contributions to enrich device pages OpenHomeFoundation/roadmap#87

This epic is the web and pull-request contribution path for existing device data: adding or changing information and pictures on devices already in the DDB. The other way to contribute, participating in device data submission, stays with its own item. Reduced options and single contribution changes per #87's scope; merging multiple change requests is out of scope there.

Technical context

• Two contribution channels: the public website (edit on the device page) and pull requests against the data store; both must land in the same place and the same changelog
• Contributions must coexist with the automated ingest: the DDB keeps a staging and a live environment, and data moves from staging to live when it reaches publication thresholds, at the same time as the community edits live content
• Everyone should be able to contribute, with the barrier as low as possible, yet with enough authenticity that changes to the DDB can be attributed
• OHF must not become the moderation bottleneck; approval is automated as far as possible, with trust placed in the community for data quality and integrity, and an easy way to report faulty or malicious content
• Technical proposal and discussion: Draft technical proposal on contribution flows for the public web interface #135 (draft contribution flows for the public web interface), discussion Stage 3: Accounts and editing #152

Approach

• Authentication: lightweight identity for website contributors, per the proposal in Draft technical proposal on contribution flows for the public web interface #135 [Account 0.1 via GitHub, if that stands]; PR contributors are identified by their Git identity
• Approval: automated checks (schema, plausibility, rate and reputation) decide what goes live without a human in the loop; a report function on every device page feeds a review queue for the exceptions
• Versioning: every change, proposed and applied, from either channel, lands in a changelog visible to anyone consuming the DDB, so provenance and history are transparent
• Concurrency: define precedence and merge rules between staging-to-live promotion and community edits so neither silently overwrites the other; field-level rather than record-level writes where possible
• Picture contributions follow the same flow but need rights handling on upload (ties into the legal track under roadmap#256)

Deliverables

• Decided contribution flow from Draft technical proposal on contribution flows for the public web interface #135 / discussion Stage 3: Accounts and editing #152, recorded on this issue
• Release of scoped sub-items

Completion criteria

• A signed-in user can change an allowed field or add a picture on a device page and see it live after automated checks, with no OHF action required
• The same change made via PR produces an identical changelog entry
• A reported contribution is pulled from live or flagged within the defined window, and the reporter needs no account to report
• A staging-to-live promotion and a community edit on the same device within the same window both survive, with the precedence rule applied and visible in the changelog
• Every applied change on live is attributable to a contributor and a timestamp

Risks & dependencies

• Moderation rules are the least settled part of Stage 3: Enable contributions to enrich device pages OpenHomeFoundation/roadmap#87; automated approval without them either lets bad data through or quietly becomes manual review
• Low-barrier auth and spam resistance pull against each other; the reputation or rate limits need tuning after launch, not before
• Concurrency rules depend on the data store design; if the Git-based store lands, merge semantics come from Git, otherwise they have to be built
• Image rights and third-party content need terms before pictures can be accepted (legal track, roadmap#256)
• Overlap with external source merges (Further enrichment from public databases #27): precedence between community edits and imported data has to be one rule, not two