Conversation
There was a problem hiding this comment.
Worth adding a section around community considerations? Or adding it to an existing section?
tbh - every change has been aggressively backwards compatible so far. There has been no breaking change iirc. Pretty much the only team/dep that has leeway is if they are the first to implement on this project and their service (i.e. no risk of breaking someone else's implementation).
Maintainers should recognise that breaking changes affect more than the originating team.
A breaking change introduced by one department (e.g altering expected API response formats) can force other departments to rework their integrations, which may take considerable time and resource.
The project does not support multiple major versions in parallel, downstream users who cannot immediately upgrade may also be prevented from applying later security fixes.
We can start using semver/breaking change aggressively but poses a lot of risk. Not all members are in the slack community either so harder for them to discuss/stand their ground.
Another thing, not sure if we want this to be a maintainers' responsibility, but generally when there is a CI issue (GitHub actions change, version change breaking build etc which is not related to the PR) I have been resolving and merging that first.
| - We focus on **GOV.UK-style** digital forms and journeys. | ||
| - Avoid adding features that: | ||
| - conflict with GOV.UK Design System and Service Standard, or | ||
| - turn the project into a generic “do everything” app builder. |
There was a problem hiding this comment.
Do we want to add examples of "do everything"? or describe the architecture / how XGovFormBuilder should fit into architectures?
| - Do not commit secrets. If a leak happens, rotate and document the incident. | ||
| - Follow GOV.UK and general security best practices (input validation, output | ||
| encoding, etc.). | ||
|
|
There was a problem hiding this comment.
I think this is the right place to put this? or we the above section?
| - New contributors have GitHub Actions blocked by default. Maintainers are responsible for confirming that PRs are safe before enabling GitHub Actions. | |
| - Being good stewards of the community (see CODE_OF_CONDUCT.md) | ||
|
|
||
| If you’re not a maintainer, see CONTRIBUTING.md instead. |
There was a problem hiding this comment.
minor - could we make these links to reduce friction please? (if you're reading on GitHub/preview for example)
2 participants
In advance of welcoming new maintainers onboard, here is a suggestion for some additional guidance - the goal is to ensure we are all aligned and the quality of the project is maintained.
Feedback always welcome!