Singapore open-source contributors: decide whether to revise or stop after review

The problem

After a Singapore contribution workshop your patch is still unaccepted, and you cannot tell whether the review asks for a repair, declines the change itself or leaves a decision unanswered.

Start with the feedback attached to your actual patch

Bring the project’s current review or decision, the patch revision it concerns and the scope that was discussed before you worked. Write what is visible separately from your interpretation. “The review asks for a test for an empty input” is an observation; “the project dislikes beginners” is a conclusion that the comment does not establish. Identify any later message that changes or clarifies the earlier one. A patch waiting for review, a requested repair and a closed change with an explicit reason need different next actions. If no reason is stated, keep it unknown. Event attendance and time spent coding do not tell you which state the project intended. Use the record as it stands rather than remembering only the encouraging workshop conversation.

Classify the next decision without guessing acceptance

Use four rows: evidence repair; approach or scope decision; process requirement; unanswered question. An evidence repair might ask you to demonstrate a behaviour already within the agreed change. An approach decision might explain that the project wants a different solution or does not want that feature. A process requirement concerns the route or missing item the project asks for. An unanswered question has no sufficiently clear instruction yet. A single review can contain several rows, so do not choose a label for the whole discussion and ignore the rest. Record the actual text or a careful paraphrase and the person’s stated role. A peer’s suggestion can help you reason about a fix without settling project direction. Use these rows to identify the next answer needed; keep the project’s actual status wording alongside them.

Use the repair row to define evidence, not a larger feature

For a requested repair, write the expected behaviour, the precise observation missing, the smallest change you propose and how you will check it. Ask for clarification through the stated project route if the feedback could mean two different behaviours. In a fictional example, your patch prevents a tutorial example from failing on a blank field, but review says “show the blank-input case.” Your next action could be to identify the intended result with the project, add the relevant check and record the result for that revision. It is not to add a new input-management feature or claim every tutorial now works. Keep a reply tied to the review point: what you changed, what you checked and what remains untested. The reviewer can then assess the repaired evidence rather than infer it from a larger diff.

Treat a declined scope as a decision before another implementation

If an authorised project response says the proposed behaviour is outside its intended scope, identify that reason and the consequence for your patch. Repairing style or adding more tests may leave the scope objection unchanged. FormSG’s contribution guide asks for discussion before a pull request; it is a specific example of obtaining project direction before investing further work. Use your actual project’s process when asking whether a narrower alternative would be wanted. Do not reopen, repost or recast the same feature merely to evade the stated decision. You can preserve an authorised local learning example without presenting it as project work the maintainers requested. If an alternative is suggested but not agreed, label it a proposal with its own unanswered scope question.

• Open Government Products Singapore: FormSG contribution guide ↗ · Source checked 20 October 2026

Compare three invented review records

These cases are fictional and contain no actual repository reviews. Case A: the agreed task is a tutorial correction; review asks for the reader step to be repeated in the documented environment. Record “repair evidence,” run only the relevant permitted check and report its boundary. Case B: the patch adds an option the project explicitly declines to maintain. Record “scope declined,” keep the declined option out of a follow-up patch, and ask about a different task only through the project’s allowed route. Case C: a contributor receives “thanks, we will look” and no subsequent decision. Record “review decision unknown,” check the contribution instructions for the appropriate enquiry or waiting process, and do not describe it as either accepted or rejected. These notes lead to different use of the next session: evidence checking, a fresh agreed task, or clarification. None creates a guaranteed review time or an entitlement to acceptance.

Bring one question a Singapore peer session can examine

Choose the feedback point whose interpretation changes your next action. Prepare the public patch link where appropriate, the permitted relevant excerpt, the expected behaviour, the evidence already available and one unresolved question. Use only material permitted for that audience and purpose. For a security-related finding, check the project’s private reporting route before preparing any public workshop question. Ask the organiser whether reviewed-patch discussion is part of the session and whether anyone can speak for the named project. A general coding night may help you reproduce a test while leaving scope unanswered. A useful peer question could be: “Does my planned check address this review request, or am I changing behaviour beyond the agreed tutorial task?” A useful project question could be: “Is this narrower alternative wanted?” Identify which answer you still need after the session.

• Keep a security finding in the project’s appropriate reporting channel →

Keep a contribution record that can survive a declined patch

Use six fields: original agreed or proposed task; work actually done; evidence obtained and its limits; review or decision received; next action or reason you stopped; verified contribution status. In Case B, a truthful record could say “Prepared and submitted a proposed option; the project declined its scope; kept an independent learning example and did not claim integration.” In Case A, it could say “Added the requested check and submitted the revision; further project review remains pending.” Those descriptions preserve learning without inventing acceptance. Keep earlier review and revision history understandable when updating the work. A comment, an amended patch or a workshop certificate does not establish a merge or a user release. If sign-off is later given, still check the actual integration and release records before claiming either occurred.

Use the ledger to choose revise, clarify or stop

Choose a clear repair within the agreed scope, ask about an ambiguous requirement, or stop the declined work while retaining the contribution record. If the requested work no longer fits your available time, explain that limit through the project’s stated route and leave any proposed handover unconfirmed until agreed. Use Boardzip’s free event search for a contribution session that can examine the particular evidence or question, then confirm its admission and participant support. If no verified session serves that question, follow the project process directly; another event booking is not a prerequisite for the project’s decision.