Community & Review
Guidelines

Malaka connects people around real sailing experiences — from a whole-yacht holiday to a single berth, or finding a skipper for a yacht you already have. These Guidelines explain how to take part respectfully, how reviews work, what stays private, and what can be reported.

They cover expected conduct across Malaka, the difference between a public Review and private Feedback, how Skipper responses work, what kinds of content may be reported, how reports are reviewed, and how review moderation differs from Support and from Trust & Safety. They're written to be useful to Travellers and Skippers alike.

These Guidelines apply to everyone taking part on Malaka and to the public and account interactions that happen here — including public Skipper profiles, Experiences, Departures, Bookings, Trips, Crew coordination, Skipper Requests, Offers, Messages, Reviews and contact with Support.

One identity, several roles

A single Malaka identity may act in more than one role at different times. Conduct expectations apply according to the relevant context — there is no separate "customer community" and "skipper community".

Malaka is a place for real people planning real time on the water together. We ask everyone to communicate with the same courtesy they'd expect on a boat with people they've just met. The categories below describe conduct that has no place on Malaka.

Serious personal-safety or integrity concerns should be routed to Malaka's appropriate Trust & Safety process rather than debated in public content. This page describes how things fit together; it is not itself an investigation portal.

People book Trips on Malaka because they trust what they read. Marketplace integrity is about keeping that trust intact — accurate information, honest identities, and fair dealing between everyone involved.

Malaka's Skipper Request and Offer flow helps a customer find the right skipper — it is not a bidding war. There's no "winner", no "lowest bidder", no undercutting. Offers are private between the relevant customer and Skipper, and competing Skippers cannot see one another's Offers or conversations.

Conduct expectations apply to messages across Malaka — but that does not mean every message is public. Different message spaces exist for different reasons.

Don't move private information into group or public contexts. That includes private Booking terms, payment details, sensitive traveller data, competing Offers, and identity documents. The Privacy Policy governs how personal data is handled.

Trip Group is for operational coordination — arranging meeting points, timings and logistics. It shouldn't become a public social feed.

Reviews help future travellers choose well and help skippers build an honest reputation. Malaka keeps public and private information clearly separate.

A review is linked to real activity. There are two supported sources — both begin with a completed Trip.

Reviewers are free to write in their own words. If it helps, useful reviews often touch on things like:

These themes are descriptive only. Reviewers are never forced into them, and Malaka does not attach any sentiment score to them.

Private Feedback is a way to share something with Malaka or a Skipper without it appearing publicly. It is not shown to public visitors, and it does not appear in the public rating by default. It may be used for product or service improvement according to final privacy and policy rules.

A public rating should draw only on eligible public reviews, according to final product rules. It excludes private feedback and reviews that have been removed from public view. Ratings are not manipulated.

A Skipper may respond publicly to a review where the product supports it. A good response is a chance to add context and show how feedback is being handled.

Reviews can be associated with completed Malaka activity where the product supports review eligibility. On Malaka, an eligible review is linked to a completed Malaka Trip — we don't use the phrase "verified purchase".

Some review content may need moderation. These are generic categories of what can be reviewed — not a verdict on any particular review, and not a claim that content in these areas is automatically removed.

A public review may use the product's public display identity, according to final privacy settings. Legal or contact identity should not be exposed unnecessarily.

If a public review or response seems to breach these Guidelines, it can be reported. The walkthrough below shows how reporting works in the product. Choosing a reason simply tells moderation what to look at — it does not prove a violation.

The generic reasons above — Personal information, Harassment, Discriminatory content, Threats / safety concern, Spam, Misleading / unrelated, Conflict of interest, and Other — help route a report. None of them, when selected, proves that a violation occurred.

Moderation is described as human-led where appropriate. Malaka does not assign an AI toxicity score, sentiment score, credibility score or truth score, and does not automatically classify anyone as guilty.

A review's moderation state and its public visibility are tracked separately. A report is one state; whether content is shown to the public is another.

Separately from moderation state, a review has its own lifecycle: Submitted → Published → Hidden → Removed. The two are not the same thing and shouldn't be conflated.

Content can be removed from public display while moderation and history records may be retained, according to final policy and privacy rules. Because history may be preserved, this is described as "removed from public view" rather than "deleted".

Editing a review

Reviewers can't necessarily edit a review indefinitely. If the product supports versioning, review history is preserved conceptually.

Reviews only mean something if they're genuine. The following concepts are the kinds of behaviour that undermine that trust:

A potential conflict of interest can be reported and reviewed — but a report does not, on its own, conclude that a review is fake. Similarly, multiple reports do not prove a violation; duplicate reports may simply be linked together operationally.

Three different workflows handle three different kinds of issue. They can link to one another, but they stay distinct.

A payment complaint is not resolved by editing or removing a review — payment records belong to the Payments and Booking workflows. A cancellation disagreement may be mentioned in a review if otherwise permitted, but refund entitlement is governed by the Booking and Cancellation Policy (Page 100), not by moderation.

Serious-concern handling protects the people involved. Malaka doesn't unnecessarily disclose a reporter's identity, restricted evidence, a full investigation narrative, private message history, or sensitive documents.

These synthetic examples are non-binding illustrations of the principles above.

Serious or repeated policy violations may have consequences for an account or a professional relationship with Malaka. This prototype does not define automatic bans, a strike system, or a fixed penalty schedule — for example, there is no "three reports means suspension" or "one safety report means a ban".

These Guidelines may be updated as Malaka evolves. Each published version carries its own metadata so you can see what applied and when.

For community questions, the published contact route is [To be provided.] For help with a Booking, Trip or account, use Malaka's Help or Contact channels. For a serious concern, use the report, Support or Trust & Safety routes described above.