Bug reporting program

Kiwisocial is a social network built around the feed, threads, direct messages, communities, and the tools people use every day to stay connected. This is a volunteer programme: there are no paid bounties, but we triage serious reports, fix what we can, and recognise contributors on the leaderboard when a report reaches Resolved.

About the program

Volunteer
Web: kiwisocial.eu
Account required

We use your submissions to reproduce issues, understand impact, and prioritise fixes. The more precise you are, the faster we can move from triage to a real outcome.

Severity and triage

Reports use a simple scale: N/A (not applicable or no security angle), Low, Medium, High, and Critical. Triage may adjust the level based on technical risk and where the bug shows up (for example, authentication versus a cosmetic settings glitch).

Leaderboard & points

When a report is Resolved, points depend on the final severity (and triage is counted once). See the Leaderboard tab for the current formula.

Priority product areas

We care most about issues that affect trust, data, or day‑to‑day use of the product. When you file, pick the closest Area in the form—this helps us route the report. Today’s categories include:

  • Feed / home
  • Threads & comments
  • Profile & connections
  • Direct messages (DMs)
  • Communities
  • Search & explore
  • Notifications
  • Account settings
  • Login & signup (OAuth, etc.)
  • Bookmarks
  • Subscriptions
  • Achievements & personal stats
  • Post composer / publishing
  • Ads (feed)
  • Layout / mobile web
  • Other / uncategorised

Guidelines

We welcome functional bugs, regressions, and security issues on the in‑scope service. Please:

  • Use an active Kiwisocial account to submit (so we can follow up and attribute recognition fairly).
  • Provide reproduction steps, what you expected, and what you observed.
  • Note the browser, OS, and URL when relevant; screenshots or short screen recordings help.
  • Keep communication factual and respectful—no harassment or spam.
  • Feature requests or pure UX opinions aren’t what this form is for—use support for product ideas when appropriate.

What we need in each report

  • One main issue per report. If you must show a chain of problems to prove impact, describe the links clearly in a single report.
  • A short title and a description that let us reproduce without guessing—include test data you created on your own account when useful.
  • For security findings, state the impact in plain language (who is affected, what could leak or break).
  • Do not publicly disclose details of an unfixed issue; wait until the team has completed handling it.

Responsible testing

Only test with accounts, communities, and content you control. Do not take actions that could harm the reliability of the service, other users, or our infrastructure. In particular:

  • No denial‑of‑service, credential stuffing, large‑scale scraping, or brute‑force attacks.
  • No testing against other people’s accounts or messages without their explicit permission.
  • Avoid noisy automated scanning against production; if you are unsure whether a test is safe, ask before you run it.