Boat Issues, “Frogs,” and Service Visits

This area helps the team keep boats safe and usable. It records what was noticed, which boat it affects, what evidence exists, and whether the report was fixed or rejected.

What “Frog” means

The word Frog is used for a category of boat problem. A category gives similar reports the same name, which makes them easier to filter and count.

There are two different records:

• a Frog category is a reusable label, such as a type of damage or defect;
• a boat issue is one real report about one boat.

Changing a category does not repair any boat, and closing one issue does not change the category used by other issues.

Why issue categories exist

Without categories, the same problem could be written in many different ways and would be difficult to find later. Categories help the team:

• group similar problems;
• filter a boat's issue history;
• see repeated problem types in reports;
• keep member and operator wording consistent.

Deactivating a category stops it being a normal choice for new work. Existing issues must keep their meaning, so historical records are not automatically removed or resolved.

Recording a boat issue

Create an issue when a member, operator, or inspection finds something that needs to be recorded. The record can contain a category, explanation, photos, a public comment, an internal comment, and the person who wrote the internal comment.

flowchart LR
    A[Problem noticed] --> B[Choose boat and category]
    B --> C[Add clear description and evidence]
    C --> D{Valid report?}
    D -- No --> E[Reject as mistaken or duplicate]
    D -- Yes --> F[Keep open while work is needed]
    F --> G[Repair or inspect]
    G --> H[Mark fixed and record date]

Use the public comment only for information that may safely be shown outside the operations team. Use the internal comment for operational context. Do not place passwords, access codes, payment details, or unnecessary personal information in either field or in photos.

Fixed and rejected mean different things

• Fixed means the accepted problem was addressed. Record the real completion date and enough context to understand what was done.
• Rejected means the report should not be treated as a valid issue, for example because it is a duplicate or was entered against the wrong boat.

Rejecting a real unresolved problem merely to hide it damages the boat history. Marking an issue fixed without a repair or inspection gives later operators a false sense of safety.

How trip reports connect to issues

A member can report a problem during check-in or check-out. The booking keeps a reference to that issue so the team can understand when it was noticed and who was using the boat.

This link matters when reviewing or rejecting an issue. A rejected issue may still be mentioned in an old trip record, because history is preserved rather than rewritten.

Service visits are a separate record

A service check-in records a period when a boat is inspected, cleaned, repaired, or otherwise handled by the service team. It can include start/end dates, condition checks, comments, ratings from the previous member, and files.

An issue says what is wrong. A service visit says what operational work or inspection took place and when. One service visit may address several issues, and one issue may need more than one visit.

The current system does not provide a full workshop work-order process with technician assignments, parts, labour costs, or automatic maintenance schedules. Those activities need a separate process if the company requires them.

Safe operating checklist

Technical reference

Frog category screens are under admin/templates/frogs. Boat issue and service screens are under admin/templates/resources. Symfony stores boat issues in resource_issues and exposes issue and service operations under the boat/resource admin routes. Photos are stored separately and linked by file ID.