Picture contribution with checks #188

Summary

As a contributor, I want to add or replace a device's picture, through the website or via pull request, with clear rights acknowledgement and automated checks, so that device pages get good product images without exposing OHF or the community to licensing, privacy or abuse problems.

This feature covers everything specific to pictures in the first contribution iteration described in #74. The generic edit mode (#185), the PR channel (#184) and the moderation bot handle the shared parts; this issue defines what is different for images.

Image is one of the five starter fields in the first iteration. It is also the riskiest one: an image can carry third-party copyright, a person's face, a serial number or Wi-Fi password on a sticker, or plainly inappropriate content. The contribution proposal (#135) already treats images differently in moderation: a longer auto-merge window and a positive vote ratio for adding an image, a short window with no opposing votes for removing one. The licensing proposal puts contributed content under CC BY-SA 4.0 (alternative CC BY 4.0), pending legal review in #35.

"Checks" here means both: what the contributor must confirm, and what the system verifies before a picture proposal enters moderation.

Scope

Contribution of a picture

• Add a picture to a device without one, replace the current picture, or propose removal
• Available from edit mode on the website (Edit mode on the device page (website channel), reduced field set #185) and via direct PR (PR-based contribution path with the same validation #184) following the documented file conventions
• One picture per device in the first iteration (the gallery from the richer-pages prototype is a follow-up)

Rights acknowledgement (website channel)

• Before submit, the contributor confirms in one explicit step that they either hold the rights to the picture or that it is available under a licence compatible with the DDB content licence, and that they agree to publish it under that licence
• The acknowledgement text is provided by the legal track (Launch readiness for the public Device Database (public information, communication, Preview/Labs exit) #35) and referenced, not hard-coded, so it can change without a redeploy
• An optional source field (manufacturer press kit URL, own photo) travels with the proposal; strongly encouraged in the UI
• For the PR channel, the same acknowledgement is part of the PR template and is required by validation (PR-based contribution path with the same validation #184)

Automated technical checks (both channels)

• File type (allowed formats to be defined, e.g. JPEG, PNG, WebP), maximum file size and minimum and maximum dimensions
• Image is decodable and not corrupted; animated images rejected
• Metadata stripped on ingestion (EXIF including GPS and device identifiers) before the file is stored
• Duplicate detection against the device's current picture and against open proposals (hash-based), to avoid duplicate work
• Checks run in the same validation step as other trait changes (PR-based contribution path with the same validation #184), with clear messages when a check fails

Automated content checks (both channels, first iteration kept simple)

• Basic screening for explicit or clearly inappropriate content before a proposal becomes visible as pending
• Hypothesis: a lightweight classifier or a hosted moderation API; result only flags, never auto-rejects, so a human vote decides borderline cases

Moderation and lifecycle

• Picture proposals follow the stricter image merge rule from the proposal: longer auto-merge window, positive vote ratio required for adding or replacing; short window, no opposing votes for removing
• Pending picture proposals show a thumbnail on the device page so reviewers can judge without opening the PR
• Easy reporting of a live picture (rights issue, personal data, wrong device) through the reporting flow, with removal following the short-window rule

Storage and delivery

• Pictures are stored with the trait data per the repository conventions, or in an asset store referenced from the trait file (open question below)
• Delivered through the website with appropriate resizing and caching; original kept for re-processing

Acceptance criteria

• A contributor can propose adding, replacing or removing a device picture from edit mode and via PR
• Submission on the website is blocked until the rights acknowledgement is confirmed; the acknowledgement text comes from a configurable source agreed with the legal track
• Pictures failing type, size, dimension or integrity checks are rejected before a proposal is created, with a message naming the failing check
• Stored pictures contain no EXIF or other embedded metadata
• A picture identical to the current one or to an open proposal is detected and the contributor is told
• Picture proposals carry the image moderation rule and show a thumbnail as a pending edit on the device page
• A live picture can be reported from the device page, and removal proposals follow the short-window rule
• Checks are the same code path for website and PR submissions

Not in scope

• Photo gallery and multiple pictures per device (richer pages, Lane B of Stage 3: Enable contributions to enrich device pages OpenHomeFoundation/roadmap#87)
• Real-life setup photos, user-submitted "in my home" imagery (feedback features, separate opportunity)
• Automated sourcing of pictures from manufacturer sites or external databases (Further enrichment from public databases #27)
• Image editing in the browser (crop, rotate, background removal)
• Perceptual duplicate detection across different devices (nice to have, later)
• The licence decision itself (legal track in Launch readiness for the public Device Database (public information, communication, Preview/Labs exit) #35); this feature consumes the agreed text

Dependencies

• Legal: licence for contributed content and the acknowledgement wording (Launch readiness for the public Device Database (public information, communication, Preview/Labs exit) #35)
• Edit mode (Edit mode on the device page (website channel), reduced field set #185) for the website entry point and summary modal
• PR channel and shared validation (PR-based contribution path with the same validation #184)
• Moderation bot and per-trait rules, including the image rule
• Reporting flow feature for live pictures
• Data repository structure feature for where picture files live

Open questions

• Storage: pictures committed to the data repository (simple, but repository size grows) or an asset store with a reference in the trait file (lighter repository, extra service)? Affects the PR channel conventions
• Content screening: which service or model, hosting cost, and false-positive handling for product shots that trigger classifiers (e.g. skin-tone-like surfaces, packaging with people)
• Should manufacturer press images be allowed under "fair use" style reasoning, or only with an explicit compatible licence? Needs legal input
• Minimum quality bar: do we require a plain background or product-shot style, or accept any clear photo of the device in the first iteration?
• Attribution display: how the contributor and source are shown next to the picture on the page (CC BY-SA requires attribution)
• Rate limits for picture submissions per contributor, given the higher review cost