{"id":22835431,"url":"https://github.com/dxw/tech-team-rfcs","last_synced_at":"2025-05-06T20:48:14.556Z","repository":{"id":37890530,"uuid":"206280500","full_name":"dxw/tech-team-rfcs","owner":"dxw","description":"dxw staff use this repository as a forum to make and document technical decisions.","archived":false,"fork":false,"pushed_at":"2025-04-22T09:37:42.000Z","size":681,"stargazers_count":2,"open_issues_count":14,"forks_count":1,"subscribers_count":19,"default_branch":"main","last_synced_at":"2025-04-22T10:58:41.417Z","etag":null,"topics":["delivery-plus","govpress","internal","rfcs","tech-ops"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dxw.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":null,"code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-09-04T09:19:04.000Z","updated_at":"2025-04-22T09:37:45.000Z","dependencies_parsed_at":"2023-09-25T13:23:08.391Z","dependency_job_id":"f030ffe3-4254-48c6-a849-be3f24842cec","html_url":"https://github.com/dxw/tech-team-rfcs","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dxw%2Ftech-team-rfcs","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dxw%2Ftech-team-rfcs/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dxw%2Ftech-team-rfcs/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dxw%2Ftech-team-rfcs/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dxw","download_url":"https://codeload.github.com/dxw/tech-team-rfcs/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252769136,"owners_count":21801373,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["delivery-plus","govpress","internal","rfcs","tech-ops"],"created_at":"2024-12-12T22:09:53.011Z","updated_at":"2025-05-06T20:48:14.513Z","avatar_url":"https://github.com/dxw.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# dxw's technology team's requests for comment (RFCs)\n\ndxw's technology team uses this repository as a forum to make and document\ntechnical decisions.\n\n## Current RFCs\n\nOur currently adopted RFCs are linked below, categorised into \"ways of working\"\nand \"tools and technology\".\n\n### Ways of working\n\nThese are RFCs that are more general in focus. They aren't about using\nparticular tools and technology, or types of tools and technology, but rather\nmore general approaches we like to take.\n\n- [Our decision making process is public][018]\n- [Use changelogs to track changes][019]\n- [Use the \"Scripts To Rule Them All\" pattern for common tasks][023]\n- [Adopt a code of conduct for public repositories][028]\n- [Source code should be open source by default][029]\n- [Don't use `master` as a branch name][036]\n- [Script imports of production data][079]\n- [Testing our work][173]\n- [Use automated accessibility checks in feature tests][244]\n\n### Tools and technology\n\nThese are RFCs about using specific types of tools and technology. This includes\nRFCs specific to one of our core frameworks or languages, e.g. GovPress, Rails\nor TypeScript, which are subcategorised for ease of reference.\n\n- [Use Docker to deploy and run our applications in containers][013]\n- [Use Auth0 as the default auth provider][021]\n- [Use linting tools across all of our projects][035]\n- [Use existing libraries where possible][087]\n\n#### GovPress\n\n- [Optimise Dependabot rules in GovPress repos][088]\n\n#### Rails\n\n- [Use Rollbar to monitor application errors for Rails projects][020]\n- [Use ERB by default in our Rails projects][022]\n- [Use Brakeman on all Rails projects][024]\n\n\u003c!-- markdownlint-disable MD026 --\u003e\n\n## How it works...\n\n\u003c!-- markdownlint-enable MD001 --\u003e\n\n### ...for a proposer\n\n1. Create a new branch named `rfc/my-proposal-title`\n1. Make a copy of `rfc-000-template.md` renamed `rfc-000-my-proposal-title.md`\n   and add it to the relevant directory (`/tools-and-technologies`, its\n   subdirectories, or `ways-of-working`). You may create a new subdirectory if\n   relevant\n1. Write your proposal\n   - Include any images or supporting documents in a separate directory named\n     `rfc-000` and link to them from the proposal\n1. When you're ready, push your branch and create a **draft** Pull Request (PR)\n   for it\n1. Rename your file (and directory of images and supporting documents if you\n   created one) with the number of the PR and push an amended commit\n1. Update `README.md` to include the title and link to the RFC file at the\n   bottom of the relevant section. All the links are provided as numbered\n   references at the bottom of `README.md`. If your RFC supersedes or deprecates\n   a previous one, remove it from the list\n1. When you are satisfied, mark your PR as **ready for review**\n   - Assign some reviewers if there's anyone you think your proposal might be\n     particularly relevant to\n1. Post a link to your PR in `#dxw-tech-team` or `#dxw-govpress-team` on Slack,\n   @mentioning anyone you want particular attention from. Some RFCs will\n   naturally fall more within the remit of GovPress, Ops or Delivery+, but if\n   you are unsure which channel to use, please post in both channels\n1. As comments and questions come in, respond to them in the PR comments to keep\n   a record of the discussion\n1. If changes are agreed, make them in your proposal and push them as new\n   commits to keep a record of the development of the proposal\n   - For trivial changes like fixing typos, amend the commits that introduced\n     them instead\n1. No sooner than 14 days after broadcasting your proposal in Slack, if\n   consensus has been reached through GitHub reviews, and at least 3 people have\n   voted to approve without any outstanding votes to reject, merge the PR and\n   post a link to the accepted proposal in #dxw-tech-team on Slack to let\n   everyone know that it's now in place\n   - If the consensus is to reject the proposal, or a consensus can't be\n     reached, close the PR with a comment explaining the resolution\n1. If a proposal has been open for more than 60 days, consider closing it as\n   stale\n\nAs the proposer, you are responsible for gathering consensus on your proposal.\nThis means reaching out to others for comment, resolving issues, and reminding\npeople of your proposal's existence.\n\nOnce a proposal is accepted, it becomes everyone's responsibility to put it into\naction and live by it.\n\n### ...for a reviewer\n\nWhen a proposal PR is marked as **ready for review**, anyone is welcome to\ncontribute to the discussion. Review the proposal and any existing comments and\nmake inline comments on the document or general comments in the PR. To vote on\nthe proposal, [create a GitHub review](#voting-with-a-github-review).\n\n## Voting with a GitHub review\n\nWe use GitHub's review system to send clear signals of individual reviewers'\nstances on the proposal. Each type of review has a different meaning, as\nfollows.\n\nNote that emoji and reactions do not indicate preferences or votes.\n\n### Comment\n\nA **comment** review is not a vote. It can be used for asking questions or\nmaking suggestions. It's also suitable for correcting typos or other minor\nchange suggestions that don't materially alter the proposal.\n\n### Approve\n\nBy creating a **approve** review, a reviewer is saying the proposal SHOULD be\naccepted. It is not necessary to add a comment to an approval if there's nothing\nto add. It is also acceptable to approve with optional suggestions as with a\n**comment** review.\n\n### Request changes\n\nBy creating a **request changes** review, a reviewer is saying the proposal\nSHOULD NOT be accepted as written unless the accompanying commented consequences\nare acceptable. A review of this kind MUST be accompanied by an explanation and\nthe reviewer SHOULD be prepared to respond to further comments.\n\n## Our principles\n\n### 1. We make decisions together\n\nEveryone is informed of proposals and is given a fair amount of time to join the\ndiscussion.\n\nDecisions are not made alone. We require at least 3 approvals before a proposal\ncan be accepted.\n\n### 2. Reaching consensus shouldn't be a chore\n\nWe understand that not everyone in the team has the time, headspace, expertise,\nor opinions to be involved in every decision. Provided those decisions are\ncommunicated more widely, consensus should be possible between those actively\ninvolved in the discussion.\n\n### 3. Some guidance is better than none\n\nIf consensus isn't clear, we default to no action, but sometimes we don't have a\nstatus quo to fall back on. In that case, we believe that some guidance is\nnearly always better than none.\n\n### 4. Standards are defaults\n\nThe decisions we make and record here are defaults. In many cases, they are\nintended as guidance and not constraints. If there's a reason to depart from\nthem, as long as it's documented and justified, we should be able to adapt to\nspecific situations and needs.\n\n### 5. Authors are responsible for their proposals\n\nThe people making proposals tend to be the people most invested in their\noutcome. It's up to them to get a decision made by engaging with and encouraging\nothers to get involved in discussions.\n\n### 6. We close stale proposals\n\nIf a proposal is inactive and doesn't have the momentum to reach a consensus, we\nclose it. Proposals that aren't moving probably aren't important or are too\ncontentious to make a decision about. This doesn't stop them from being reopened\nat a later time.\n\nBy closing stale proposals, we keep the discussion focused on current issues,\nrelevant to the team now.\n\n### 7. We document our rationale\n\nThese RFCs document our decisions and the discussions that led to them being\nmade. This helps our future selves and new people joining our team understand\nwhy we do the things we do. This understanding will allow us to make more\ninformed decisions in the future and help us empathise with the decisions we\nhave already made.\n\n## Linting\n\n### Language and style\n\nWe use the\n[IETF's RFC best practices style guide](https://www.ietf.org/rfc/rfc2119.txt)\nfor our RFCs to help make sure we're consistent and clear in our language and\nintent.\n\n### Running the linter\n\nFirst, install dependencies:\n\n```sh\nnpm install\n```\n\nTo run the linter locally:\n\n```sh\nnpm run lint\n```\n\nTo automatically fix most linting issues:\n\n```sh\nnpm run lint:fix\n```\n\nThis repository is set up to run the linter automatically on pull requests and\nfix any issues it can, so you usually won't need to run it yourself.\n\nIf you notice the linter doing unexpected things to your formatting, it's\nusually a sign that your original formatting wouldn't have been parsed as you\nintended it to be.\n\n\u003c!-- prettier-ignore-start --\u003e\n[013]: tools-and-technology/rfc-013-use-docker-to-deploy-and-run-applications-in-containers.md\n[018]: ways-of-working/rfc-018-our-decision-making-process-is-public.md\n[019]: ways-of-working/rfc-019-use-changelogs-to-track-changes.md\n[020]: tools-and-technology/rails/rfc-020-use-rollbar-to-monitor-rails-errors.md\n[021]: tools-and-technology/rfc-021-use-auth0-as-the-default-auth-provider.md\n[022]: tools-and-technology/rails/rfc-022-use-erb-as-default-templating-language.md\n[023]: ways-of-working/rfc-023-use-scripts-to-rule-them-all.md\n[024]: tools-and-technology/rails/rfc-024-use-brakeman.md\n[028]: ways-of-working/rfc-028-adopt-a-code-of-conduct.md\n[029]: ways-of-working/rfc-029-source-code-should-be-open-source-by-default.md\n[035]: tools-and-technology/rfc-035-use-linting-tools-across-all-our-projects.md\n[036]: ways-of-working/rfc-036-dont-use-master-as-a-branch-name.md\n[079]: ways-of-working/rfc-079-script-imports-of-production-data.md\n[087]: tools-and-technology/rfc-087-use-libraries-where-possible.md\n[088]: tools-and-technology/govpress/rfc-088-optimise-dependabot-config-files-in-govpress-repos.md\n[173]: ways-of-working/rfc-173-testing-our-work.md\n[244]: ways-of-working/rfc-244-use-automated-accessibility-checks-in-feature-tests.md\n\u003c!-- prettier-ignore-end --\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdxw%2Ftech-team-rfcs","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdxw%2Ftech-team-rfcs","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdxw%2Ftech-team-rfcs/lists"}