Singapore open-source sessions: discuss a change before building a large patch

The problem

A Singapore first-time contributor has already started a substantial feature, but cannot tell whether an open-source workshop will help resolve maintainer interest or merely produce a larger unsolicited patch.

Separate wanting a feature from proposing project work

Describe the inconvenience you encountered, who experiences it and the behaviour you would change. Then identify what the maintainers would have to support afterwards. A useful proposal exposes a trade-off: a specialised option may help your own workflow while increasing configuration and maintenance work for everyone else. Bring that question before a polished implementation. Start from an observation you can actually show: the permitted task, what happened and the user need it did not meet. Keep your preferred feature separate from that observation. A personal inconvenience can be real while the project already provides another route, or deliberately supports a different workflow. State which part you have examined and what remains unknown. Time spent preparing a prototype explains your preparation, not the project’s obligation to maintain it. You can use authorised local work to clarify an option without describing it as a requested contribution. If you cannot share the actual material, make an unrelated invented example and label its limit.

Make a behaviour and alternatives card

Use seven entries: current task and observation; user outcome sought; existing option investigated; proposed behaviour change; maintenance or compatibility question; smaller alternative; and decision you need from the project. Include a permitted small example rather than the whole implementation. Put “not examined” beside an existing option you have not checked. Name a consequence that matters: a new default could change what other users see, whereas explaining an existing option can leave that behaviour intact. Do not claim either is cheaper or acceptable without the relevant evidence. This card prepares a scope discussion; it does not replace the project’s issue template or decide the change on the maintainer’s behalf.

Use the actual project rules

FormSG's contribution guide requests discussion before a pull request. That is a concrete example of why a public repository does not make every proposed change welcome. Check the rules of the project used at your chosen session. An existing issue can explain intent, but confirm that its current scope still matches what you plan to do. Record the actual project instruction beside your next step: an existing discussion, a new proposal or another route it specifies. Do not turn an issue title or workshop invitation into agreement on your proposed implementation. A project may ask a question before it can choose an approach; retain that question rather than treating a polite reply as a go-ahead. Where the concern may involve a live security finding, keep it outside the ordinary public proposal and use the existing security-channel guide. This guide concerns a permitted ordinary feature discussion, not disclosure approval or permission to test systems.

• FormSG/CONTRIBUTING.md at develop · opengovsg/FormSG · GitHub ↗ · Source checked 20 October 2026

Bring a proposal with a smaller fallback

Prepare a short problem description, an example using invented data and one possible approach. Add a lower-effort alternative, such as improving an explanation or documenting a limitation. Ask whether the problem is in scope, which behaviour must remain stable and what evidence would help a decision. Do not present your time already spent as a reason for acceptance. State what the smaller alternative leaves unchanged and which need it may still fail to meet. A documentation explanation is useful only if an actual existing path addresses the reader’s task; it is not automatically a substitute for a missing capability. An unsent project question could say, “I observed [permitted task and result]. I am considering [behaviour change], while [existing option or smaller alternative] may address part of the need. Is this problem in scope, which behaviour should remain unchanged, and what observation would help you decide?” Fill it from what you know. The wording supplies neither a response nor authority to start the work.

Compare two approaches in a fictional project

Everything in this example is invented, including the project, work and replies. A contributor wants completed items hidden in a practice list. They have begun a patch that changes the default list for every user. The project already has an optional filter, but its tutorial does not explain it. The proposal records the default change as Option A and clarifying the filter instructions as Option B. B could help a reader choose the existing view while leaving the shared default intact; it would not satisfy a requirement for all lists to change automatically. The contributor asks whether the actual need is choosing a view or changing the project’s default. Until the project answers, a large default-changing patch does not resolve that scope question.

Use the partial answer to bound the next session

Continue the fictional case. A project representative replies that a tutorial proposal for the existing filter is welcome for discussion, while the default change is not yet wanted for implementation. Record the actual distinction: a narrow documentation proposal can be examined; the default change remains outside the work currently invited. The contributor prepares the relevant reader step and asks which evidence would support that correction, keeping their broader prototype as separate local learning. This is a completed choice of the next question and work boundary, not an accepted patch. If the reply only says “interesting”, keep both scope fields unresolved. Do not manufacture permission by choosing the most favourable interpretation.

Choose a session that can answer the proposal

A coding night may provide peers who can challenge your reasoning without a project maintainer being present. Look for explicit issue discussion or project participation when maintainer feedback is the purpose. After the session, update your proposal with the unresolved question. Keep implementation tentative until the project's own process gives you a sufficiently clear direction. Ask which part the session can help with: examining the user problem, checking the existing option, explaining the maintenance consequence or reaching the named project’s decision. A peer can help you expose a faulty assumption while being unable to approve the feature. Bring the card and one unresolved field rather than asking participants to review every file you have already changed. If no authorised project discussion is offered, use the session to improve the proposal and follow the repository’s ordinary route afterwards. A programme’s project name does not establish that your particular feature is on its agenda or that someone must allocate review time to it.

Retain the proposal version and the decision still open

After a permitted discussion, keep the observation, alternatives, reply and next action on the same record. In the fictional case, the outcome is permission to investigate a narrow documentation proposal, not approval of a global default or proof that a tutorial fix is merged. If a later answer changes the requested scope, retain that revision instead of silently applying the earlier reply. The existing review-feedback guide addresses the later repair, decline or unanswered review; the approval guide addresses completion when sign-off already exists. Use Boardzip’s free contribution search for a session that serves your present proposal question, then confirm its activity and support. Search access and a positive conversation cannot authorise a repository change.