From 4997e0dc337c017285ed1de66380cfb4aa8194cb Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Wed, 29 Oct 2025 12:00:09 -0700 Subject: [PATCH 1/9] update contributing.md --- how-to-DA/CONTRIBUTING.md | 249 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 249 insertions(+) diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md index 41b7e31..435ed60 100644 --- a/how-to-DA/CONTRIBUTING.md +++ b/how-to-DA/CONTRIBUTING.md @@ -1,3 +1,252 @@ +# CONTRIBUTING +** +**[TODO: rename this file to `README.md`; i.e. remove the template reference]** + +This is a template document for UC projects can use to help build the documentation in your project repos. It requires editing before it is ready to use, and you can find guides for using these templates on [our website](https://ucospo.net/oss-resources/#template-guides). Please feel free to [reach out to our Laura](mailto:lalangdon@ucdavis.edu), our Community Manager, if you have any questions! + +Search for the word `TODO` in this template to identify parts that require customization; e.g. line 3 above lets you know you should rename this file.. When you finish editing the template, remove the `TODO` bits. + +**[TODO: delete the lines between line 1 and the "Welcome" heading]** + +## Welcome! + +**[TODO: edit welcome text below]** + +Welcome! We're glad you want to contribute to our project! 💖 + +As you get started, you're in the best position to give us feedback on areas of our project that we need help with including: + +- Problems found during setting up a new developer environment +- Gaps in our Quickstart Guide or documentation +- Bugs in our automation scripts + +If anything doesn't make sense, or doesn't work when you run it, please open a bug report and let us know! + +## Table of Contents + +**[TODO: edit the Table of Contents]** + +- [Ways to Contribute](#ways-to-contribute) +- [Come to Community Calls](#come-to-community-calls) +- [Finding an Issue](#finding-an-issue) +- [Setting Up a Dev Environment](#setting-up-a-dev-environment) +- [Running Tests](#running-tests) +- [Asking for Help](#asking-for-help) +- [Norms for Commits](#norms-for-commits) +- [Pull Request Lifecycle](#pull-request-lifecycle) +- [Code of Conduct](#code-of-conduct) + +## Ways to Contribute + +**[TODO: edit this to reflect the kinds of contributions you'd like to receive for your project]** + +We welcome many different types of contributions, including: + +- New features +- Builds, CI/CD +- Bug fixes +- Documentation +- Issue Triage +- Answering questions on Slack/Mailing List +- Web design +- Communications/Social Media/Blog Posts +- Release management + +Not everything happens through a GitHub pull request. Please come to [our meetings](**TODO: link to your meetings**) or [contact us](**TODO: link to your preferred method of contact**) and let's discuss how we can work together. + +## Come to Community Calls + +**[TODO: Maybe your project doesn't have [community calls](https://opensource.com/open-organization/16/1/community-calls-will-increase-participation-your-open-organization), in which case you can omit this section. But you might consider trying them out!]** + +Anyone interested in our project is welcome to come to any of [our community calls](**TODO: add a link to your community calls**)! You never need an invite to join us. In fact, we want you to join us, even if you don’t have anything you feel like you want to contribute. Just being there is enough! + +You don’t have to turn on your video. The first time you come, just introducing yourself is perfectly fine. Over time, we hope that you feel comfortable voicing your opinions, giving feedback on others’ ideas, and even sharing your own ideas, and experiences. + +## Finding an Issue + +**[TODO: edit this section as needed]** + +We have good first issues for new contributors and help wanted issues suitable for any contributor. [`good first issue`](**TODO: link your project's `good first issue` label**) has extra information to help you make your first contribution. [`help wanted`](**TODO: link to your project's `help wanted` label**) are issues suitable for someone who isn't a core maintainer and is good to move onto after your first pull request. + +Sometimes there won’t be any issues with these labels. That’s ok! There is likely still something for you to work on. If you want to contribute but you don’t know where to start or can't find a suitable issue, you can **[TODO: explain how people can ask for an issue to work on]**. + +Once you see an issue that you'd like to work on, please post a comment saying that you want to work on it. Something like "I want to work on this" is fine. + +## Setting up a Dev Environment + +**[TODO: edit the steps provided for what's needed for your project]** + +Clone the project: + +```bash +git clone yourprojecturl +``` + +Install dependencies: + +```bash +install command +``` + +## Running Tests + +**[TODO: Describe the process you use to test code in your project]** + +1. Step one +2. Step two + +## Asking for Help + +The best way to reach us with a question when contributing is to ask on: + +**[TODO: Pick the way(s) that you prefer people ask for help]** + +- The original Github issue +- The developer mailing list +- Our Slack channel + +## Norms for Commits + +**[TODO: edit this section to reflect what's needed for your project]** + +Our project uses [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), and we require [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). Please let us know if you need help with these! + +## Pull Request Lifecycle + +> [!TIP] +> TODO: Edit the text below to describe your pull request process. You don't need to adopt every aspect! Pick and choose what makes sense for *your* project] + +### Before You Submit + +**[TODO: edit this section to reflect what's needed for your project]** + +When you submit your pull request, or you push new commits to it, our automated systems will run some checks on your new code. We require that your pull request passes these checks, but we also have more criteria than just that before we can accept and merge it. We recommend that you check the following things locally before you submit your code: + +- First thing to check +- Another thing to check + +#### When to Submit + +**[TODO: edit this section to reflect what's needed for your project]** + +Submit your pull request when you have a working implementation that addresses the issue or feature request. Your code should be tested and ready for review, even if you're open to suggestions for improvements. + +#### Draft vs. Ready PRs + +**[TODO: edit this section to reflect what's needed for your project]** + +- Use **Draft PRs** when your work is incomplete or you want early feedback on your approach +- Convert to **Ready for Review** when your implementation is complete and tested +- Mark as ready even if you expect minor changes during review + +#### Branch Strategy + +**[TODO: edit this section to reflect what's needed for your project]** + +Create a feature branch from the latest `main` branch. Use descriptive branch names like `feature/add-user-authentication` or `fix/memory-leak-in-parser`. + +### Submission Process + +#### PR Scope + +**[TODO: edit this section to reflect what's needed for your project]** + +We prefer **small, focused pull requests** that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs. + +#### Signaling Readiness + +**[TODO: edit this section to reflect what's needed for your project]** + +- Remove "Draft" status when ready for review +- Ensure all CI checks are passing +- Include a clear description of what the PR does and why +- Link to relevant issues using "Fixes #123" or "Addresses #456" + +### Review Process + +**[TODO: edit this section to reflect what's needed for your project]** + +**Initial Review Timeline**: Expect an initial review within **3-5 business days**. Complex PRs may take longer. + +**Follow-up Reviews**: After addressing feedback, expect follow-up reviews within **2-3 business days**. + +#### Requesting Reviews + +**[TODO: edit this section to reflect what's needed for your project]** + +- After pushing changes, add a comment like "Ready for re-review" or "@mention" specific reviewers +- If your PR hasn't been reviewed after the expected timeline, feel free to politely bump with a comment +- For urgent fixes, mention the urgency in your comment + +### Handling Common Situations + +#### Stalled Pull Requests + +**[TODO: edit this section to reflect what's needed for your project]** + +If your PR appears stalled: + +1. First, check if all feedback has been addressed +2. After 1 week of no activity, add a polite comment requesting status +3. If still no response after another week, reach out via [preferred communication channel] + +#### Abandoned Pull Requests + +**[TODO: edit this section to reflect what's needed for your project]** + +If you can no longer continue work on your PR: + +- Comment on the PR explaining the situation +- Maintainers may either: + - Take over the PR and push additional commits to complete it + - Close the PR and create a new issue for others to pick up + - Close the PR if the change is no longer needed + +#### Follow-up Work + +**[TODO: edit this section to reflect what's needed for your project]** + +- Small follow-up changes should be addressed in the same PR when possible +- Larger follow-ups or new issues discovered during review should be handled in separate issues/PRs +- Use "TODO" comments sparingly and create follow-up issues for any deferred work + +### After Your PR is Merged + +**[TODO: edit this section to reflect what's needed for your project]** + +**Release Timeline**: Merged pull requests are included in the next release, which typically happens: + +- **Patch releases**: Every 2-4 weeks for bug fixes +- **Minor releases**: Every 1-3 months for new features +- **Major releases**: As needed for breaking changes + +#### Release Process + +**[TODO: edit this section to reflect what's needed for your project]** + +After merge, your changes will: + +1. Be available immediately in the `main` branch +2. Go through additional testing in our staging environment +3. Be included in the next scheduled release +4. Be documented in the changelog with attribution + +#### Staying Updated + +**[TODO: edit this section to reflect what's needed for your project]** + +Watch the repository to be notified when your contributions are released. We'll also tag you in release notes when your PR introduces significant changes. + +--- + +_Questions about the PR process? Feel free to ask in the issue comments, discussions, or reach out to the maintainers directly._ + +## Code of Conduct + +Please read our [Code of Conduct](**TODO: link to your project's CoC**) + +**[TODO: merge content below with content above]** + # How to get started contributing to Distribute Aid We’re not currently set up for async-only contributions so if you’re interested in joining, we encourage you to get in touch with our tech team lead at to get properly onboarded. From 6ec2c51ff0a8303c86051e42b9afac6c2810d87d Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Wed, 5 Nov 2025 08:58:56 -0800 Subject: [PATCH 2/9] Merge previous versions with template --- how-to-DA/CONTRIBUTING.md | 218 ++++++++++++-------------------------- 1 file changed, 67 insertions(+), 151 deletions(-) diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md index 435ed60..d6b5c38 100644 --- a/how-to-DA/CONTRIBUTING.md +++ b/how-to-DA/CONTRIBUTING.md @@ -1,26 +1,25 @@ -# CONTRIBUTING -** -**[TODO: rename this file to `README.md`; i.e. remove the template reference]** +# README -This is a template document for UC projects can use to help build the documentation in your project repos. It requires editing before it is ready to use, and you can find guides for using these templates on [our website](https://ucospo.net/oss-resources/#template-guides). Please feel free to [reach out to our Laura](mailto:lalangdon@ucdavis.edu), our Community Manager, if you have any questions! +Welcome! We're glad you want to contribute to our work at DistributeAid! 💖 We’re not currently set up for async-only contributions so if you’re interested in joining, we encourage you to get in touch with our tech team lead at to get properly onboarded. -Search for the word `TODO` in this template to identify parts that require customization; e.g. line 3 above lets you know you should rename this file.. When you finish editing the template, remove the `TODO` bits. - -**[TODO: delete the lines between line 1 and the "Welcome" heading]** +## Expectations -## Welcome! +Most of our contributors put in an average of 5h a week. Volunteer participation fluctuates as people’s lives do, so we ask contributors to communicate proactively. -**[TODO: edit welcome text below]** +A lot of our team communication happens in virtual meetings: 1 sprint meeting/month and 2 tech hangs/week where we hang out and collaborate. We’ve seen that people who show up to these consistently are having a better experience, make more progress, growing in skills, personal abilities, and confidence! -Welcome! We're glad you want to contribute to our project! 💖 +Tech hangs: every Wednesday and Thursday from 6 to 8 pm CET/CEST +Sprint meetings: first hour of the tech hang on the first Wednesday of the month -As you get started, you're in the best position to give us feedback on areas of our project that we need help with including: +Any other collaboration usually happens via Slack. -- Problems found during setting up a new developer environment -- Gaps in our Quickstart Guide or documentation -- Bugs in our automation scripts +**Join our contributor team if:** -If anything doesn't make sense, or doesn't work when you run it, please open a bug report and let us know! +- You’re able and willing to communicate clearly +- You’re reliable, organised and focused +- You have some availability overlapping with Central European Time +- You can make it to at least 1 tech hang per month +- You can come to at least 1 sprint meeting per quarter ## Table of Contents @@ -29,8 +28,8 @@ If anything doesn't make sense, or doesn't work when you run it, please open a b - [Ways to Contribute](#ways-to-contribute) - [Come to Community Calls](#come-to-community-calls) - [Finding an Issue](#finding-an-issue) +- [Creating Issues](#creating-issues) - [Setting Up a Dev Environment](#setting-up-a-dev-environment) -- [Running Tests](#running-tests) - [Asking for Help](#asking-for-help) - [Norms for Commits](#norms-for-commits) - [Pull Request Lifecycle](#pull-request-lifecycle) @@ -40,27 +39,32 @@ If anything doesn't make sense, or doesn't work when you run it, please open a b **[TODO: edit this to reflect the kinds of contributions you'd like to receive for your project]** -We welcome many different types of contributions, including: - -- New features -- Builds, CI/CD -- Bug fixes -- Documentation -- Issue Triage -- Answering questions on Slack/Mailing List -- Web design -- Communications/Social Media/Blog Posts -- Release management +We’re looking for experienced engineers and designers, but you don’t need to already know our full stack as long as you know how to onboard yourself and ask for help if needed. Some experience with contributing to OSS is helpful. We welcome many different types of contributions, including: + +- [Frontend]( https://github.com/distributeaid/next-website-v2) + - As a Frontend Developer at Distribute Aid, you’ll create new pages for, update, and maintain the Distribute Aid website, often working closely with our designers or other devs + - Stack: NextJS, TypeScript, Strapi, Radix UI +- [Backend](https://github.com/distributeaid/aggregated-public-information) + - As a Backend Developer at Distribute Aid, you’ll develop and maintain our backend for our website, work with APIs to share and structure collected needs data for our needs assessment as well as data visualisations to show our work. You’ll most likely collaborate with other Backend devs. + - Stack: Strapi (our website’s backend), TypeScript, APIs +- Design + - As a designer at Distribute Aid, you’ll create designs for our website and any app we’re working on to make the lives of aid workers easier and more effective. You’ll collaborate with frontend developers and are expected to learn to create issues on GitHub. + - Stack: Figma, Canva, GitHub issues +- Data + - Part data engineer, part data analyst, you’ll work with historical data from our Needs Assessment as well as future incoming Needs Assessment data. One of your main responsibilities will be to structure and present the data, creating visualisations that we can use on the website or show to partners to emphasise our impact. + - Stack: Strapi, APIs, Salesforce +- [Documentation](https://github.com/distributeaid/docs) +- Communications/Social Media/Blog Posts **[TODO: This wasn't on the original list, but should it be added?] + +## What we offer -Not everything happens through a GitHub pull request. Please come to [our meetings](**TODO: link to your meetings**) or [contact us](**TODO: link to your preferred method of contact**) and let's discuss how we can work together. - -## Come to Community Calls +Having a team structure in place allows us to foster both collaboration and individual growth. We emphasise doing peer reviews and encourage contributors who are willing to take on more responsibility to step up and get on track to become maintainers. -**[TODO: Maybe your project doesn't have [community calls](https://opensource.com/open-organization/16/1/community-calls-will-increase-participation-your-open-organization), in which case you can omit this section. But you might consider trying them out!]** +Regular contributors get access to periodic 1on1s with our tech lead to check in and enable personal development and growth at Distribute Aid. We’re also happy to write references for regular contributors as needed. -Anyone interested in our project is welcome to come to any of [our community calls](**TODO: add a link to your community calls**)! You never need an invite to join us. In fact, we want you to join us, even if you don’t have anything you feel like you want to contribute. Just being there is enough! +If this sounds interesting to you, [get in touch](mailto:tech@distributeaid.org) and tell us a bit about yourself. -You don’t have to turn on your video. The first time you come, just introducing yourself is perfectly fine. Over time, we hope that you feel comfortable voicing your opinions, giving feedback on others’ ideas, and even sharing your own ideas, and experiences. +If anything doesn't make sense, or doesn't work when you run it, please open a bug report and let us know! ## Finding an Issue @@ -72,28 +76,30 @@ Sometimes there won’t be any issues with these labels. That’s ok! There is l Once you see an issue that you'd like to work on, please post a comment saying that you want to work on it. Something like "I want to work on this" is fine. -## Setting up a Dev Environment +## Creating Issues -**[TODO: edit the steps provided for what's needed for your project]** +## Creating Issues -Clone the project: +On the [Issues page on Github](https://github.com/distributeaid/next-website-v2/issues), click the green `New Issue` button or this [New Issue Link](https://github.com/distributeaid/next-website-v2/issues/new). -```bash -git clone yourprojecturl -``` +- Add a descriptive title with an optional `[type tag]` such as [component] or [page]. In the description body summarize the issue. +- Add external links, such as to figma designs or external documentation, if applicable. If a figma design exists, be sure to add screenshots. Visual explanations go a long way towards making things super clear. +- Add parts of the codebase where changes would be made. +- Assign the issue to yourself or someone else, or leave for another person to pick it up. +- Add appropriate labels and types. +- Add the issue to the project **DA Tech**. -Install dependencies: +If the issue needs some precursor set up before someone can work on the issue (particularly for parents of sub issues) such as library installations and page or folder creations, then you must first set the issue as `Triage` until those appropriate changes are made and reviewed in a pull request. Otherwise, set the issue as `Ready for Work`. -```bash -install command -``` +### Sub Issues -## Running Tests +For larger issues that can be split up into separate independent parts. For example a new parent page with multiple children components. You can create a parent issue, with multiple child issues. [See these slides](https://docs.google.com/presentation/d/1ToMum70-qDlaCv6m7X3HfGr3XjaX-UjyA36K4IElO5Y/edit?slide=id.g2dd259a195e_0_9#slide=id.g2dd259a195e_0_9) on how to create sub issues. -**[TODO: Describe the process you use to test code in your project]** +## Setting up a Dev Environment + +**[TODO: edit the steps provided for what's needed for your project]** -1. Step one -2. Step two +Dev environment setup across our repos, so please refer to the README for any repo you'd like to contribute to! ## Asking for Help @@ -109,7 +115,12 @@ The best way to reach us with a question when contributing is to ask on: **[TODO: edit this section to reflect what's needed for your project]** -Our project uses [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), and we require [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). Please let us know if you need help with these! +Most of our repos (except docs) use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). When crafting commit messages, group commits that are related to a particular topic. For example, if you're making commits related to the styling, only include files that are related to styling. This makes it easier to read through the commits and see the exact files that made changes to the styles. Proper commits make debugging easier in cases where we need to go through our git logs. + +A good commit message will ideally have the following attributes: + +- Subject => A summary of what you did in the commit. +- Body => A detailed explanation of the commit. ## Pull Request Lifecycle @@ -143,10 +154,17 @@ Submit your pull request when you have a working implementation that addresses t **[TODO: edit this section to reflect what's needed for your project]** -Create a feature branch from the latest `main` branch. Use descriptive branch names like `feature/add-user-authentication` or `fix/memory-leak-in-parser`. +We have a long-running branch (**saga**) and create short-lived branches to develop parts of the website. Our branch naming convention is `type/issue#/condensed-issue-name`. An example of a short-lived branch would be `feat/365/about-us`. Connect words using a "-" as branch names cannot include empty spaces. Always ensure you're working on a separate branch to avoid merge conflicts. ### Submission Process +- Include the purpose of the Pull Request and link the issue related to the PR (with the `#` sign) +- Consider providing an overview of why the work is taking place (with any relevant links). Don't assume familiarity with the history +- Be explicit about what feedback you want, if any: a quick pair of 👀 on the code, discussion on the technical approach, critique on design, a review copy +- Be explicit about when you want feedback, if the Pull Request is a work in progress, say so. Prefix the title of your PR with [WIP] +- @mention individuals that you specifically want to involve in the discussion and explain the help or input you need from them. +- Assign the issue author as a reviewer **[TODO: I think we found that contributors can't assign reviewers themselves?]** + #### PR Scope **[TODO: edit this section to reflect what's needed for your project]** @@ -244,105 +262,3 @@ _Questions about the PR process? Feel free to ask in the issue comments, discuss ## Code of Conduct Please read our [Code of Conduct](**TODO: link to your project's CoC**) - -**[TODO: merge content below with content above]** - -# How to get started contributing to Distribute Aid - -We’re not currently set up for async-only contributions so if you’re interested in joining, we encourage you to get in touch with our tech team lead at to get properly onboarded. - -## Expectations - -Most of our contributors put in an average of 5h a week. Volunteer participation fluctuates as people’s lives do, so we ask contributors to communicate proactively. - -A lot of our team communication happens in virtual meetings: 1 sprint meeting/month and 2 tech hangs/week where we hang out and collaborate. We’ve seen that people who show up to these consistently are having a better experience, make more progress, growing in skills, personal abilities, and confidence! - -Tech hangs: every Wednesday and Thursday from 6 to 8 pm CET/CEST -Sprint meetings: first hour of the tech hang on the first Wednesday of the month - -Any other collaboration usually happens via Slack. - -**Join our contributor team if:** - -- you’re able and willing to communicate clearly -- you’re reliable, organised and focused -- you have some availability overlapping with Central European Time -- you can make it to at least 1 tech hang per month -- you can come to at least 1 sprint meeting per quarter - -## What we’re looking for - -We’re looking for experienced engineers and designers, but you don’t need to already know our full stack as long as you know how to onboard yourself and ask for help if needed. Some experience with contributing to OSS is helpful. - -### Frontend - -As a Frontend Developer at Distribute Aid, you’ll create new pages for, update, and maintain the Distribute Aid website, often working closely with our designers or other devs. - -Stack: NextJS, TypeScript, Strapi, Radix UI - -### Backend - -As a Backend Developers at Distribute Aid, you’ll develop and maintain our backend for our website, work with APIs to share and structure collected needs data for our needs assessment as well as data visualisations to show our work. You’ll most likely collaborate with other Backend devs. - -Stack: Strapi (our website’s backend), TypeScript, APIs - -### Design - -As a designer at Distribute Aid, you’ll create designs for our website and any app we’re working on to make the lives of aid workers easier and more effective. You’ll collaborate with frontend developers and are expected to learn to create issues on GitHub. - -Stack: Figma, Canva, GitHub issues - -### Data - -Part data engineer, part data analyst, you’ll work with historical data from our Needs Assessment as well as future incoming Needs Assessment data. One of your main responsibilities will be to structure and present the data, creating visualisations that we can use on the website or show to partners to emphasise our impact. - -Stack: Strapi, APIs, Salesforce - -### Other areas - -Got any other skills you think could help us? Project management, writing, documentation, video, etc. Get in touch and let us know! - -# What we offer - -Having a team structure in place allows us to foster both collaboration and individual growth. We emphasise doing peer reviews and encourage contributors who are willing to take on more responsibility to step up and get on track to become maintainers. - -Regular contributors get access to periodic 1on1s with our tech lead to check in and enable personal development and growth at Distribute Aid. We’re also happy to write references for regular contributors as needed. - -If this sounds interesting to you, [get in touch](mailto:tech@distributeaid.org) and tell us a bit about yourself. - -## Relevant repos - -### Frontend: Next website v2 - -Repo link: https://github.com/distributeaid/next-website-v2 - -This is the website redesign that we’re currently working on. Once the redesign goes live the repo will be renamed to distributeaid.org. - -Our [“old” website repo](https://github.com/distributeaid/distributeaid.org), which contains the version of our site that's currently live, will be retired and archived once the next-website has been launched. -Technologies used - -- [Next.js](https://nextjs.org/docs) - Frontend framework -- [Typescript](https://www.typescriptlang.org/) - scripting language -- [Tailwind.css](https://tailwindcss.com/) CSS framework -- [npm](https://docs.npmjs.com/getting-started) - package manager -- [Prettier](https://prettier.io/) - code formatter (via the pretty-quick node module) -- [ESLint](https://eslint.org/) - Linting -- [Vercel](https://vercel.com/home) - Production and deployment - -### Backend: Strapi - -[Backend repo](https://github.com/distributeaid/aggregated-public-information) - - - -### Needs Assessment - -[Needs Assessment repo](https://github.com/distributeaid/needs-assessment-v2) - - - -### Documentation - -[Docs repo](https://github.com/distributeaid/docs) - -This is where most of our documentation is housed. From c7d670dfddf56de74893224a371e4d241388cf7e Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Wed, 12 Nov 2025 11:27:41 -0800 Subject: [PATCH 3/9] Add more details --- how-to-DA/CONTRIBUTING.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md index d6b5c38..3717ced 100644 --- a/how-to-DA/CONTRIBUTING.md +++ b/how-to-DA/CONTRIBUTING.md @@ -54,7 +54,6 @@ We’re looking for experienced engineers and designers, but you don’t need to - Part data engineer, part data analyst, you’ll work with historical data from our Needs Assessment as well as future incoming Needs Assessment data. One of your main responsibilities will be to structure and present the data, creating visualisations that we can use on the website or show to partners to emphasise our impact. - Stack: Strapi, APIs, Salesforce - [Documentation](https://github.com/distributeaid/docs) -- Communications/Social Media/Blog Posts **[TODO: This wasn't on the original list, but should it be added?] ## What we offer @@ -78,8 +77,6 @@ Once you see an issue that you'd like to work on, please post a comment saying t ## Creating Issues -## Creating Issues - On the [Issues page on Github](https://github.com/distributeaid/next-website-v2/issues), click the green `New Issue` button or this [New Issue Link](https://github.com/distributeaid/next-website-v2/issues/new). - Add a descriptive title with an optional `[type tag]` such as [component] or [page]. In the description body summarize the issue. @@ -97,24 +94,17 @@ For larger issues that can be split up into separate independent parts. For exam ## Setting up a Dev Environment -**[TODO: edit the steps provided for what's needed for your project]** - Dev environment setup across our repos, so please refer to the README for any repo you'd like to contribute to! ## Asking for Help The best way to reach us with a question when contributing is to ask on: -**[TODO: Pick the way(s) that you prefer people ask for help]** - - The original Github issue -- The developer mailing list - Our Slack channel ## Norms for Commits -**[TODO: edit this section to reflect what's needed for your project]** - Most of our repos (except docs) use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). When crafting commit messages, group commits that are related to a particular topic. For example, if you're making commits related to the styling, only include files that are related to styling. This makes it easier to read through the commits and see the exact files that made changes to the styles. Proper commits make debugging easier in cases where we need to go through our git logs. A good commit message will ideally have the following attributes: From ec20758a4728bd2d88a9fc60abfb702a39294d7a Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Fri, 16 Jan 2026 11:46:08 -0800 Subject: [PATCH 4/9] Refine pre-PR instructions --- how-to-DA/CONTRIBUTING.md | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md index 3717ced..3687006 100644 --- a/how-to-DA/CONTRIBUTING.md +++ b/how-to-DA/CONTRIBUTING.md @@ -117,28 +117,39 @@ A good commit message will ideally have the following attributes: > [!TIP] > TODO: Edit the text below to describe your pull request process. You don't need to adopt every aspect! Pick and choose what makes sense for *your* project] -### Before You Submit +### While You're Working -**[TODO: edit this section to reflect what's needed for your project]** +- when starting to work, merge main into your branch so that you're not behind and avoid merge conflicts later on +- when you're done for the day, commit and push your changes, even if it's not done or breaks, but if someone else needs to take over, then no work is lost and maintainers can get an idea of the progress of an issue -When you submit your pull request, or you push new commits to it, our automated systems will run some checks on your new code. We require that your pull request passes these checks, but we also have more criteria than just that before we can accept and merge it. We recommend that you check the following things locally before you submit your code: +- coding principles: before a PR, check if you have classes, files, etc. that do more that they should, dependencies that are unnecessary, etc. (keyword SOLID and KISS) +- run tests before creating a PR +- naming conventions e.g website specific: using reusable file names that make sense in more than one context. e.g. ~homepageData.ts~ testimonials.ts +- more naming conventions, when to use camelCase, PascalCase,etc. for things. there are common conventions, best practices, etc. that help keep it clean. This is probably repo specific. eg. for the website -- First thing to check -- Another thing to check +| Category | Example name | File name | Why | +|-----------|---------------|-----------|------| +| **React component** | `Testimonials` | `Testimonials.tsx` | Capitalized because JSX tags must start with an uppercase letter to be treated as components. | +| **Data / config / constants / plain TS modules** | `partnerTestimonials` | `partnerTestimonials.ts` | Lowercase (camelCase or sometimes snake_case) because they’re **values**, not types or components. | +| **Type or interface** | `ImpactItem` | (`.ts`/`.tsx`) | PascalCase to clearly mark a type-level construct rather than a runtime value. | +| **Constant / enum-like value** | `API_URL` | `constants.ts` | UPPER_SNAKE_CASE for immutable, global configuration values. | +| **Utility / helper function** | `formatNumber` | `formatNumber.ts` | camelCase because it’s a regular JavaScript function or exported helper. | -#### When to Submit + +### Before You Submit **[TODO: edit this section to reflect what's needed for your project]** -Submit your pull request when you have a working implementation that addresses the issue or feature request. Your code should be tested and ready for review, even if you're open to suggestions for improvements. +When you submit your pull request, or you push new commits to it, our automated systems will run some checks on your new code. We require that your pull request passes these checks, but we also have more criteria than just that before we can accept and merge it. We recommend that you check the following things locally before you submit your code: -#### Draft vs. Ready PRs +- Your branch is up to date with `saga` and any merge conflicts have been resolved +- Run the applicable formatting checks as specified in the repo's README.md -**[TODO: edit this section to reflect what's needed for your project]** +#### Draft vs. Ready PRs -- Use **Draft PRs** when your work is incomplete or you want early feedback on your approach -- Convert to **Ready for Review** when your implementation is complete and tested -- Mark as ready even if you expect minor changes during review +- Use **Draft PRs** when your work is incomplete +- Convert to **Ready for Review** when your implementation is complete and tested (mark as ready even if you expect minor changes during review) +- In either case, if you'd like feedback or a review please post in the #tech-github-chat on Slack #### Branch Strategy From 6529822665bc41d138a966120179f1e758904dad Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Wed, 21 Jan 2026 14:55:14 -0800 Subject: [PATCH 5/9] Implement changes from 16 Jan meeting --- how-to-DA/CONTRIBUTING.md | 81 +++++++++++---------------------------- 1 file changed, 22 insertions(+), 59 deletions(-) diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md index 3687006..ffb61b9 100644 --- a/how-to-DA/CONTRIBUTING.md +++ b/how-to-DA/CONTRIBUTING.md @@ -37,8 +37,6 @@ Any other collaboration usually happens via Slack. ## Ways to Contribute -**[TODO: edit this to reflect the kinds of contributions you'd like to receive for your project]** - We’re looking for experienced engineers and designers, but you don’t need to already know our full stack as long as you know how to onboard yourself and ask for help if needed. Some experience with contributing to OSS is helpful. We welcome many different types of contributions, including: - [Frontend]( https://github.com/distributeaid/next-website-v2) @@ -67,11 +65,9 @@ If anything doesn't make sense, or doesn't work when you run it, please open a b ## Finding an Issue -**[TODO: edit this section as needed]** - -We have good first issues for new contributors and help wanted issues suitable for any contributor. [`good first issue`](**TODO: link your project's `good first issue` label**) has extra information to help you make your first contribution. [`help wanted`](**TODO: link to your project's `help wanted` label**) are issues suitable for someone who isn't a core maintainer and is good to move onto after your first pull request. +We have good first issues for new contributors and help wanted issues suitable for any contributor. `good first issue` has extra information to help you make your first contribution. `help wanted`are issues suitable for someone who isn't a core maintainer and is good to move onto after your first pull request. -Sometimes there won’t be any issues with these labels. That’s ok! There is likely still something for you to work on. If you want to contribute but you don’t know where to start or can't find a suitable issue, you can **[TODO: explain how people can ask for an issue to work on]**. +Sometimes there won’t be any issues with these labels. That’s ok! There is likely still something for you to work on. If you want to contribute but you don’t know where to start or can't find a suitable issue, you can ask in Slack. Once you see an issue that you'd like to work on, please post a comment saying that you want to work on it. Something like "I want to work on this" is fine. @@ -79,18 +75,19 @@ Once you see an issue that you'd like to work on, please post a comment saying t On the [Issues page on Github](https://github.com/distributeaid/next-website-v2/issues), click the green `New Issue` button or this [New Issue Link](https://github.com/distributeaid/next-website-v2/issues/new). -- Add a descriptive title with an optional `[type tag]` such as [component] or [page]. In the description body summarize the issue. -- Add external links, such as to figma designs or external documentation, if applicable. If a figma design exists, be sure to add screenshots. Visual explanations go a long way towards making things super clear. -- Add parts of the codebase where changes would be made. -- Assign the issue to yourself or someone else, or leave for another person to pick it up. -- Add appropriate labels and types. -- Add the issue to the project **DA Tech**. +- Add a descriptive title with an optional `[type tag]` such as [component] or [page]. In the description body summarize the issue +- Add external links, such as to figma designs or external documentation, if applicable + - If a figma design exists, be sure to add screenshots. Visual explanations go a long way towards making things super clear! +- Add parts of the codebase where changes would be made +- Assign the issue to yourself or someone else, or leave for another person to pick it up +- Add appropriate labels and types +- Add the issue to the project **DA Tech** If the issue needs some precursor set up before someone can work on the issue (particularly for parents of sub issues) such as library installations and page or folder creations, then you must first set the issue as `Triage` until those appropriate changes are made and reviewed in a pull request. Otherwise, set the issue as `Ready for Work`. ### Sub Issues -For larger issues that can be split up into separate independent parts. For example a new parent page with multiple children components. You can create a parent issue, with multiple child issues. [See these slides](https://docs.google.com/presentation/d/1ToMum70-qDlaCv6m7X3HfGr3XjaX-UjyA36K4IElO5Y/edit?slide=id.g2dd259a195e_0_9#slide=id.g2dd259a195e_0_9) on how to create sub issues. +For larger issues that can be split up into separate independent parts—like a new parent page with multiple children components, for example—you can create a parent issue, with multiple child issues. [See these slides](https://docs.google.com/presentation/d/1ToMum70-qDlaCv6m7X3HfGr3XjaX-UjyA36K4IElO5Y/edit?slide=id.g2dd259a195e_0_9#slide=id.g2dd259a195e_0_9) on how to create sub issues. ## Setting up a Dev Environment @@ -112,50 +109,23 @@ A good commit message will ideally have the following attributes: - Subject => A summary of what you did in the commit. - Body => A detailed explanation of the commit. -## Pull Request Lifecycle - -> [!TIP] -> TODO: Edit the text below to describe your pull request process. You don't need to adopt every aspect! Pick and choose what makes sense for *your* project] - -### While You're Working - -- when starting to work, merge main into your branch so that you're not behind and avoid merge conflicts later on -- when you're done for the day, commit and push your changes, even if it's not done or breaks, but if someone else needs to take over, then no work is lost and maintainers can get an idea of the progress of an issue - -- coding principles: before a PR, check if you have classes, files, etc. that do more that they should, dependencies that are unnecessary, etc. (keyword SOLID and KISS) -- run tests before creating a PR -- naming conventions e.g website specific: using reusable file names that make sense in more than one context. e.g. ~homepageData.ts~ testimonials.ts -- more naming conventions, when to use camelCase, PascalCase,etc. for things. there are common conventions, best practices, etc. that help keep it clean. This is probably repo specific. eg. for the website - -| Category | Example name | File name | Why | -|-----------|---------------|-----------|------| -| **React component** | `Testimonials` | `Testimonials.tsx` | Capitalized because JSX tags must start with an uppercase letter to be treated as components. | -| **Data / config / constants / plain TS modules** | `partnerTestimonials` | `partnerTestimonials.ts` | Lowercase (camelCase or sometimes snake_case) because they’re **values**, not types or components. | -| **Type or interface** | `ImpactItem` | (`.ts`/`.tsx`) | PascalCase to clearly mark a type-level construct rather than a runtime value. | -| **Constant / enum-like value** | `API_URL` | `constants.ts` | UPPER_SNAKE_CASE for immutable, global configuration values. | -| **Utility / helper function** | `formatNumber` | `formatNumber.ts` | camelCase because it’s a regular JavaScript function or exported helper. | - - -### Before You Submit +## Dev Process -**[TODO: edit this section to reflect what's needed for your project]** - -When you submit your pull request, or you push new commits to it, our automated systems will run some checks on your new code. We require that your pull request passes these checks, but we also have more criteria than just that before we can accept and merge it. We recommend that you check the following things locally before you submit your code: - -- Your branch is up to date with `saga` and any merge conflicts have been resolved -- Run the applicable formatting checks as specified in the repo's README.md +### Branch Strategy -#### Draft vs. Ready PRs +We have a long-running branch `main` and create short-lived branches to develop parts of the website. Our branch naming convention is `type/issue#/condensed-issue-name`. An example of a short-lived branch would be `feat/365/about-us`. Connect words using a "-" as branch names cannot include empty spaces. Always ensure you're working on a separate branch to avoid merge conflicts. -- Use **Draft PRs** when your work is incomplete -- Convert to **Ready for Review** when your implementation is complete and tested (mark as ready even if you expect minor changes during review) -- In either case, if you'd like feedback or a review please post in the #tech-github-chat on Slack - -#### Branch Strategy +### While You're Working -**[TODO: edit this section to reflect what's needed for your project]** +The usual best practices apply: -We have a long-running branch (**saga**) and create short-lived branches to develop parts of the website. Our branch naming convention is `type/issue#/condensed-issue-name`. An example of a short-lived branch would be `feat/365/about-us`. Connect words using a "-" as branch names cannot include empty spaces. Always ensure you're working on a separate branch to avoid merge conflicts. +- We prefer **small, focused pull requests** that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs. +- Each time you start to work, merge `main` into your branch so that you're not behind and avoid merge conflicts later on +- When you're done for the day, commit and push your changes, even if it's not done or breaks, but so that maintainers can get an idea of the progress of an issue +- Make sure your [code is modular](https://dev.to/prxtikk/how-to-write-clean-and-modular-code-1d87) and free of unnecessary dependencies (see also the [SOLID design principles](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) and [KISS principle](https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/)) +- Make sure your code passes the applicable tests (see the README for the repo you're working in) +- Use reusable file names that make sense in more than one context. e.g. ~homepageData.ts~ testimonials.ts +- Follow the best practices for naming variables, case choice (like PascalCase, camelCase, or snake_case), etc. for each language you're writing in ### Submission Process @@ -164,13 +134,6 @@ We have a long-running branch (**saga**) and create short-lived branches to deve - Be explicit about what feedback you want, if any: a quick pair of 👀 on the code, discussion on the technical approach, critique on design, a review copy - Be explicit about when you want feedback, if the Pull Request is a work in progress, say so. Prefix the title of your PR with [WIP] - @mention individuals that you specifically want to involve in the discussion and explain the help or input you need from them. -- Assign the issue author as a reviewer **[TODO: I think we found that contributors can't assign reviewers themselves?]** - -#### PR Scope - -**[TODO: edit this section to reflect what's needed for your project]** - -We prefer **small, focused pull requests** that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs. #### Signaling Readiness From 69fa39cd50f1548061bbbd409122e2580a9ab5f5 Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Fri, 23 Jan 2026 11:59:58 -0800 Subject: [PATCH 6/9] Final draft after 23 Jan meeting --- how-to-DA/CONTRIBUTING.md | 80 +++++++++------------------------------ 1 file changed, 17 insertions(+), 63 deletions(-) diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md index ffb61b9..77b2bfb 100644 --- a/how-to-DA/CONTRIBUTING.md +++ b/how-to-DA/CONTRIBUTING.md @@ -32,14 +32,14 @@ Any other collaboration usually happens via Slack. - [Setting Up a Dev Environment](#setting-up-a-dev-environment) - [Asking for Help](#asking-for-help) - [Norms for Commits](#norms-for-commits) -- [Pull Request Lifecycle](#pull-request-lifecycle) +- [Dev Process](#dev-process) - [Code of Conduct](#code-of-conduct) ## Ways to Contribute We’re looking for experienced engineers and designers, but you don’t need to already know our full stack as long as you know how to onboard yourself and ask for help if needed. Some experience with contributing to OSS is helpful. We welcome many different types of contributions, including: -- [Frontend]( https://github.com/distributeaid/next-website-v2) +- [Frontend](https://github.com/distributeaid/next-website-v2) - As a Frontend Developer at Distribute Aid, you’ll create new pages for, update, and maintain the Distribute Aid website, often working closely with our designers or other devs - Stack: NextJS, TypeScript, Strapi, Radix UI - [Backend](https://github.com/distributeaid/aggregated-public-information) @@ -76,8 +76,8 @@ Once you see an issue that you'd like to work on, please post a comment saying t On the [Issues page on Github](https://github.com/distributeaid/next-website-v2/issues), click the green `New Issue` button or this [New Issue Link](https://github.com/distributeaid/next-website-v2/issues/new). - Add a descriptive title with an optional `[type tag]` such as [component] or [page]. In the description body summarize the issue -- Add external links, such as to figma designs or external documentation, if applicable - - If a figma design exists, be sure to add screenshots. Visual explanations go a long way towards making things super clear! +- Add external links, such as to Figma designs or external documentation, if applicable + - If a Figma design exists, be sure to add screenshots. Visual explanations go a long way towards making things super clear! - Add parts of the codebase where changes would be made - Assign the issue to yourself or someone else, or leave for another person to pick it up - Add appropriate labels and types @@ -122,12 +122,12 @@ The usual best practices apply: - We prefer **small, focused pull requests** that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs. - Each time you start to work, merge `main` into your branch so that you're not behind and avoid merge conflicts later on - When you're done for the day, commit and push your changes, even if it's not done or breaks, but so that maintainers can get an idea of the progress of an issue -- Make sure your [code is modular](https://dev.to/prxtikk/how-to-write-clean-and-modular-code-1d87) and free of unnecessary dependencies (see also the [SOLID design principles](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) and [KISS principle](https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/)) +- Make sure your [code is modular](https://dev.to/prxtikk/how-to-write-clean-and-modular-code-1d87) and free of unnecessary dependencies (see also the [SOLID design principles](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) and [KISS principle](https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/)) - Make sure your code passes the applicable tests (see the README for the repo you're working in) -- Use reusable file names that make sense in more than one context. e.g. ~homepageData.ts~ testimonials.ts +- Use reusable file names that make sense in more than one context. e.g. ~~`homepageData.ts`~~ `testimonials.ts` - Follow the best practices for naming variables, case choice (like PascalCase, camelCase, or snake_case), etc. for each language you're writing in -### Submission Process +### Making a Pull Request - Include the purpose of the Pull Request and link the issue related to the PR (with the `#` sign) - Consider providing an overview of why the work is taking place (with any relevant links). Don't assume familiarity with the history @@ -137,48 +137,27 @@ The usual best practices apply: #### Signaling Readiness -**[TODO: edit this section to reflect what's needed for your project]** - -- Remove "Draft" status when ready for review - Ensure all CI checks are passing +- Make sure your branch is up to date with `main` - Include a clear description of what the PR does and why - Link to relevant issues using "Fixes #123" or "Addresses #456" +- If your PR is currently in "Draft" status, click "Mark ready for review" +- Tag the appropriate review team +- Post a link to your PR in Slack and say it's ready for review ### Review Process -**[TODO: edit this section to reflect what's needed for your project]** - -**Initial Review Timeline**: Expect an initial review within **3-5 business days**. Complex PRs may take longer. - -**Follow-up Reviews**: After addressing feedback, expect follow-up reviews within **2-3 business days**. - -#### Requesting Reviews - -**[TODO: edit this section to reflect what's needed for your project]** +**Initial Review Timeline**: Expect an initial review within **3-5 business days**. Complex PRs may take longer. If you haven't heard anything from the team (a verbal response or an emoji reaction in Slack) within a week, please post again -- After pushing changes, add a comment like "Ready for re-review" or "@mention" specific reviewers -- If your PR hasn't been reviewed after the expected timeline, feel free to politely bump with a comment -- For urgent fixes, mention the urgency in your comment +**Follow-up Reviews**: After addressing feedback, please click "Re-request review" and post in Slack again ### Handling Common Situations -#### Stalled Pull Requests - -**[TODO: edit this section to reflect what's needed for your project]** - -If your PR appears stalled: - -1. First, check if all feedback has been addressed -2. After 1 week of no activity, add a polite comment requesting status -3. If still no response after another week, reach out via [preferred communication channel] - #### Abandoned Pull Requests -**[TODO: edit this section to reflect what's needed for your project]** - If you can no longer continue work on your PR: -- Comment on the PR explaining the situation +- Comment on the PR and post in Slack explaining the situation - Maintainers may either: - Take over the PR and push additional commits to complete it - Close the PR and create a new issue for others to pick up @@ -186,38 +165,13 @@ If you can no longer continue work on your PR: #### Follow-up Work -**[TODO: edit this section to reflect what's needed for your project]** - - Small follow-up changes should be addressed in the same PR when possible - Larger follow-ups or new issues discovered during review should be handled in separate issues/PRs - Use "TODO" comments sparingly and create follow-up issues for any deferred work -### After Your PR is Merged - -**[TODO: edit this section to reflect what's needed for your project]** - -**Release Timeline**: Merged pull requests are included in the next release, which typically happens: - -- **Patch releases**: Every 2-4 weeks for bug fixes -- **Minor releases**: Every 1-3 months for new features -- **Major releases**: As needed for breaking changes - -#### Release Process - -**[TODO: edit this section to reflect what's needed for your project]** - -After merge, your changes will: - -1. Be available immediately in the `main` branch -2. Go through additional testing in our staging environment -3. Be included in the next scheduled release -4. Be documented in the changelog with attribution - -#### Staying Updated - -**[TODO: edit this section to reflect what's needed for your project]** +### After Your PR is Approved -Watch the repository to be notified when your contributions are released. We'll also tag you in release notes when your PR introduces significant changes. +Once you've received an approval from a maintainer you can merge your PR. If your branch has become out of sync with `main`, GitHub will show an "Update branch" button on your PR. If you run into merge conflicts you're not sure how to handle or if you have any other questions, please post in Slack! --- @@ -225,4 +179,4 @@ _Questions about the PR process? Feel free to ask in the issue comments, discuss ## Code of Conduct -Please read our [Code of Conduct](**TODO: link to your project's CoC**) +Please read our [Code of Conduct](https://distributeaid.org/code-of-conduct/) From bb30e1c09279c690bef0e31a039e5e15a29f3dd3 Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Fri, 23 Jan 2026 12:14:41 -0800 Subject: [PATCH 7/9] Update ToC, fix typos --- how-to-DA/CONTRIBUTING.md | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-) diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md index 77b2bfb..fbdc5c6 100644 --- a/how-to-DA/CONTRIBUTING.md +++ b/how-to-DA/CONTRIBUTING.md @@ -1,6 +1,6 @@ -# README +# Contributing to Distribute Aid -Welcome! We're glad you want to contribute to our work at DistributeAid! 💖 We’re not currently set up for async-only contributions so if you’re interested in joining, we encourage you to get in touch with our tech team lead at to get properly onboarded. +Welcome! We're glad you want to contribute to our work at Distribute Aid! 💖 We’re not currently set up for async-only contributions so if you’re interested in joining, we encourage you to get in touch with our tech team lead at to get properly onboarded. ## Expectations @@ -23,16 +23,24 @@ Any other collaboration usually happens via Slack. ## Table of Contents -**[TODO: edit the Table of Contents]** - - [Ways to Contribute](#ways-to-contribute) -- [Come to Community Calls](#come-to-community-calls) +- [What We Offer](#what-we-offer) - [Finding an Issue](#finding-an-issue) - [Creating Issues](#creating-issues) + - [Sub Issues](#sub-issues) - [Setting Up a Dev Environment](#setting-up-a-dev-environment) - [Asking for Help](#asking-for-help) -- [Norms for Commits](#norms-for-commits) - [Dev Process](#dev-process) + - [Branch Strategy](#branch-strategy) + - [Norms for Commits](#norms-for-commits) + - [While You're Working](#while-youre-working) + - [Making a Pull Request](#making-a-pull-request) + - [Signaling Readiness](#signaling-readiness) + - [Review Process](#review-process) + - [Handling Common Situations](#handling-common-situations) + - [Abandoned Pull Requests](#abandoned-pull-requests) + - [Follow-Up Work](#follow-up-work) + - [After Your PR is Approved](#after-your-pr-is-approved) - [Code of Conduct](#code-of-conduct) ## Ways to Contribute @@ -100,7 +108,13 @@ The best way to reach us with a question when contributing is to ask on: - The original Github issue - Our Slack channel -## Norms for Commits +## Dev Process + +### Branch Strategy + +We have a long-running branch `main` and create short-lived branches to develop parts of the website. Our branch naming convention is `type/issue#/condensed-issue-name`. An example of a short-lived branch would be `feat/365/about-us`. Connect words using a "-" as branch names cannot include empty spaces. Always ensure you're working on a separate branch to avoid merge conflicts. + +### Norms for Commits Most of our repos (except docs) use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). When crafting commit messages, group commits that are related to a particular topic. For example, if you're making commits related to the styling, only include files that are related to styling. This makes it easier to read through the commits and see the exact files that made changes to the styles. Proper commits make debugging easier in cases where we need to go through our git logs. @@ -109,12 +123,6 @@ A good commit message will ideally have the following attributes: - Subject => A summary of what you did in the commit. - Body => A detailed explanation of the commit. -## Dev Process - -### Branch Strategy - -We have a long-running branch `main` and create short-lived branches to develop parts of the website. Our branch naming convention is `type/issue#/condensed-issue-name`. An example of a short-lived branch would be `feat/365/about-us`. Connect words using a "-" as branch names cannot include empty spaces. Always ensure you're working on a separate branch to avoid merge conflicts. - ### While You're Working The usual best practices apply: @@ -135,7 +143,7 @@ The usual best practices apply: - Be explicit about when you want feedback, if the Pull Request is a work in progress, say so. Prefix the title of your PR with [WIP] - @mention individuals that you specifically want to involve in the discussion and explain the help or input you need from them. -#### Signaling Readiness +### Signaling Readiness - Ensure all CI checks are passing - Make sure your branch is up to date with `main` From 76009c10d6484627e6af716581cc05eecb758600 Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Wed, 29 Oct 2025 12:00:09 -0700 Subject: [PATCH 8/9] update contributing.md --- how-to-DA/CONTRIBUTING.md | 190 -------------------------------------- 1 file changed, 190 deletions(-) delete mode 100644 how-to-DA/CONTRIBUTING.md diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md deleted file mode 100644 index fbdc5c6..0000000 --- a/how-to-DA/CONTRIBUTING.md +++ /dev/null @@ -1,190 +0,0 @@ -# Contributing to Distribute Aid - -Welcome! We're glad you want to contribute to our work at Distribute Aid! 💖 We’re not currently set up for async-only contributions so if you’re interested in joining, we encourage you to get in touch with our tech team lead at to get properly onboarded. - -## Expectations - -Most of our contributors put in an average of 5h a week. Volunteer participation fluctuates as people’s lives do, so we ask contributors to communicate proactively. - -A lot of our team communication happens in virtual meetings: 1 sprint meeting/month and 2 tech hangs/week where we hang out and collaborate. We’ve seen that people who show up to these consistently are having a better experience, make more progress, growing in skills, personal abilities, and confidence! - -Tech hangs: every Wednesday and Thursday from 6 to 8 pm CET/CEST -Sprint meetings: first hour of the tech hang on the first Wednesday of the month - -Any other collaboration usually happens via Slack. - -**Join our contributor team if:** - -- You’re able and willing to communicate clearly -- You’re reliable, organised and focused -- You have some availability overlapping with Central European Time -- You can make it to at least 1 tech hang per month -- You can come to at least 1 sprint meeting per quarter - -## Table of Contents - -- [Ways to Contribute](#ways-to-contribute) -- [What We Offer](#what-we-offer) -- [Finding an Issue](#finding-an-issue) -- [Creating Issues](#creating-issues) - - [Sub Issues](#sub-issues) -- [Setting Up a Dev Environment](#setting-up-a-dev-environment) -- [Asking for Help](#asking-for-help) -- [Dev Process](#dev-process) - - [Branch Strategy](#branch-strategy) - - [Norms for Commits](#norms-for-commits) - - [While You're Working](#while-youre-working) - - [Making a Pull Request](#making-a-pull-request) - - [Signaling Readiness](#signaling-readiness) - - [Review Process](#review-process) - - [Handling Common Situations](#handling-common-situations) - - [Abandoned Pull Requests](#abandoned-pull-requests) - - [Follow-Up Work](#follow-up-work) - - [After Your PR is Approved](#after-your-pr-is-approved) -- [Code of Conduct](#code-of-conduct) - -## Ways to Contribute - -We’re looking for experienced engineers and designers, but you don’t need to already know our full stack as long as you know how to onboard yourself and ask for help if needed. Some experience with contributing to OSS is helpful. We welcome many different types of contributions, including: - -- [Frontend](https://github.com/distributeaid/next-website-v2) - - As a Frontend Developer at Distribute Aid, you’ll create new pages for, update, and maintain the Distribute Aid website, often working closely with our designers or other devs - - Stack: NextJS, TypeScript, Strapi, Radix UI -- [Backend](https://github.com/distributeaid/aggregated-public-information) - - As a Backend Developer at Distribute Aid, you’ll develop and maintain our backend for our website, work with APIs to share and structure collected needs data for our needs assessment as well as data visualisations to show our work. You’ll most likely collaborate with other Backend devs. - - Stack: Strapi (our website’s backend), TypeScript, APIs -- Design - - As a designer at Distribute Aid, you’ll create designs for our website and any app we’re working on to make the lives of aid workers easier and more effective. You’ll collaborate with frontend developers and are expected to learn to create issues on GitHub. - - Stack: Figma, Canva, GitHub issues -- Data - - Part data engineer, part data analyst, you’ll work with historical data from our Needs Assessment as well as future incoming Needs Assessment data. One of your main responsibilities will be to structure and present the data, creating visualisations that we can use on the website or show to partners to emphasise our impact. - - Stack: Strapi, APIs, Salesforce -- [Documentation](https://github.com/distributeaid/docs) - -## What we offer - -Having a team structure in place allows us to foster both collaboration and individual growth. We emphasise doing peer reviews and encourage contributors who are willing to take on more responsibility to step up and get on track to become maintainers. - -Regular contributors get access to periodic 1on1s with our tech lead to check in and enable personal development and growth at Distribute Aid. We’re also happy to write references for regular contributors as needed. - -If this sounds interesting to you, [get in touch](mailto:tech@distributeaid.org) and tell us a bit about yourself. - -If anything doesn't make sense, or doesn't work when you run it, please open a bug report and let us know! - -## Finding an Issue - -We have good first issues for new contributors and help wanted issues suitable for any contributor. `good first issue` has extra information to help you make your first contribution. `help wanted`are issues suitable for someone who isn't a core maintainer and is good to move onto after your first pull request. - -Sometimes there won’t be any issues with these labels. That’s ok! There is likely still something for you to work on. If you want to contribute but you don’t know where to start or can't find a suitable issue, you can ask in Slack. - -Once you see an issue that you'd like to work on, please post a comment saying that you want to work on it. Something like "I want to work on this" is fine. - -## Creating Issues - -On the [Issues page on Github](https://github.com/distributeaid/next-website-v2/issues), click the green `New Issue` button or this [New Issue Link](https://github.com/distributeaid/next-website-v2/issues/new). - -- Add a descriptive title with an optional `[type tag]` such as [component] or [page]. In the description body summarize the issue -- Add external links, such as to Figma designs or external documentation, if applicable - - If a Figma design exists, be sure to add screenshots. Visual explanations go a long way towards making things super clear! -- Add parts of the codebase where changes would be made -- Assign the issue to yourself or someone else, or leave for another person to pick it up -- Add appropriate labels and types -- Add the issue to the project **DA Tech** - -If the issue needs some precursor set up before someone can work on the issue (particularly for parents of sub issues) such as library installations and page or folder creations, then you must first set the issue as `Triage` until those appropriate changes are made and reviewed in a pull request. Otherwise, set the issue as `Ready for Work`. - -### Sub Issues - -For larger issues that can be split up into separate independent parts—like a new parent page with multiple children components, for example—you can create a parent issue, with multiple child issues. [See these slides](https://docs.google.com/presentation/d/1ToMum70-qDlaCv6m7X3HfGr3XjaX-UjyA36K4IElO5Y/edit?slide=id.g2dd259a195e_0_9#slide=id.g2dd259a195e_0_9) on how to create sub issues. - -## Setting up a Dev Environment - -Dev environment setup across our repos, so please refer to the README for any repo you'd like to contribute to! - -## Asking for Help - -The best way to reach us with a question when contributing is to ask on: - -- The original Github issue -- Our Slack channel - -## Dev Process - -### Branch Strategy - -We have a long-running branch `main` and create short-lived branches to develop parts of the website. Our branch naming convention is `type/issue#/condensed-issue-name`. An example of a short-lived branch would be `feat/365/about-us`. Connect words using a "-" as branch names cannot include empty spaces. Always ensure you're working on a separate branch to avoid merge conflicts. - -### Norms for Commits - -Most of our repos (except docs) use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). When crafting commit messages, group commits that are related to a particular topic. For example, if you're making commits related to the styling, only include files that are related to styling. This makes it easier to read through the commits and see the exact files that made changes to the styles. Proper commits make debugging easier in cases where we need to go through our git logs. - -A good commit message will ideally have the following attributes: - -- Subject => A summary of what you did in the commit. -- Body => A detailed explanation of the commit. - -### While You're Working - -The usual best practices apply: - -- We prefer **small, focused pull requests** that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs. -- Each time you start to work, merge `main` into your branch so that you're not behind and avoid merge conflicts later on -- When you're done for the day, commit and push your changes, even if it's not done or breaks, but so that maintainers can get an idea of the progress of an issue -- Make sure your [code is modular](https://dev.to/prxtikk/how-to-write-clean-and-modular-code-1d87) and free of unnecessary dependencies (see also the [SOLID design principles](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) and [KISS principle](https://www.freecodecamp.org/news/keep-it-simple-stupid-how-to-use-the-kiss-principle-in-design/)) -- Make sure your code passes the applicable tests (see the README for the repo you're working in) -- Use reusable file names that make sense in more than one context. e.g. ~~`homepageData.ts`~~ `testimonials.ts` -- Follow the best practices for naming variables, case choice (like PascalCase, camelCase, or snake_case), etc. for each language you're writing in - -### Making a Pull Request - -- Include the purpose of the Pull Request and link the issue related to the PR (with the `#` sign) -- Consider providing an overview of why the work is taking place (with any relevant links). Don't assume familiarity with the history -- Be explicit about what feedback you want, if any: a quick pair of 👀 on the code, discussion on the technical approach, critique on design, a review copy -- Be explicit about when you want feedback, if the Pull Request is a work in progress, say so. Prefix the title of your PR with [WIP] -- @mention individuals that you specifically want to involve in the discussion and explain the help or input you need from them. - -### Signaling Readiness - -- Ensure all CI checks are passing -- Make sure your branch is up to date with `main` -- Include a clear description of what the PR does and why -- Link to relevant issues using "Fixes #123" or "Addresses #456" -- If your PR is currently in "Draft" status, click "Mark ready for review" -- Tag the appropriate review team -- Post a link to your PR in Slack and say it's ready for review - -### Review Process - -**Initial Review Timeline**: Expect an initial review within **3-5 business days**. Complex PRs may take longer. If you haven't heard anything from the team (a verbal response or an emoji reaction in Slack) within a week, please post again - -**Follow-up Reviews**: After addressing feedback, please click "Re-request review" and post in Slack again - -### Handling Common Situations - -#### Abandoned Pull Requests - -If you can no longer continue work on your PR: - -- Comment on the PR and post in Slack explaining the situation -- Maintainers may either: - - Take over the PR and push additional commits to complete it - - Close the PR and create a new issue for others to pick up - - Close the PR if the change is no longer needed - -#### Follow-up Work - -- Small follow-up changes should be addressed in the same PR when possible -- Larger follow-ups or new issues discovered during review should be handled in separate issues/PRs -- Use "TODO" comments sparingly and create follow-up issues for any deferred work - -### After Your PR is Approved - -Once you've received an approval from a maintainer you can merge your PR. If your branch has become out of sync with `main`, GitHub will show an "Update branch" button on your PR. If you run into merge conflicts you're not sure how to handle or if you have any other questions, please post in Slack! - ---- - -_Questions about the PR process? Feel free to ask in the issue comments, discussions, or reach out to the maintainers directly._ - -## Code of Conduct - -Please read our [Code of Conduct](https://distributeaid.org/code-of-conduct/) From b04d4dc95411c05c7d7dcb86c0021fdb8fc7bc15 Mon Sep 17 00:00:00 2001 From: Laura Langdon <48335772+LauraLangdon@users.noreply.github.com> Date: Thu, 19 Feb 2026 19:31:10 +0100 Subject: [PATCH 9/9] Final edits fr fr --- how-to-DA/CONTRIBUTING.md | 183 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 183 insertions(+) create mode 100644 how-to-DA/CONTRIBUTING.md diff --git a/how-to-DA/CONTRIBUTING.md b/how-to-DA/CONTRIBUTING.md new file mode 100644 index 0000000..5dbebda --- /dev/null +++ b/how-to-DA/CONTRIBUTING.md @@ -0,0 +1,183 @@ +# Contributing to Distribute Aid + +Welcome! We're glad you want to contribute to our work at Distribute Aid! 💖 We’re not currently set up for async-only contributions so if you’re interested in joining, we encourage you to get in touch with our tech team lead at to get properly onboarded. + +## Expectations + +Most of our contributors put in an average of 5h a week. Volunteer participation fluctuates as people’s lives do, so we ask contributors to communicate proactively. + +A lot of our team communication happens in virtual meetings: 1 sprint meeting/month and 2 tech hangs/week where we hang out and collaborate. We’ve seen that people who show up to these consistently are having a better experience, make more progress, growing in skills, personal abilities, and confidence! + +Tech hangs: every Wednesday and Thursday from 6 to 8 pm CET/CEST +Sprint meetings: first hour of the tech hang on the first Wednesday of the month + +Any other collaboration usually happens via Slack. + +**Join our contributor team if:** + +- You communicate clearly +- You’re reliable, organised and focused +- You have some availability overlapping with Central European Time +- You can make it to at least 1 tech hang per month +- You can come to at least 1 sprint meeting per quarter + +## Table of Contents + +- [Ways to Contribute](#ways-to-contribute) +- [What We Offer](#what-we-offer) +- [Finding an Issue](#finding-an-issue) +- [Creating Issues](#creating-issues) + - [Sub Issues](#sub-issues) +- [Setting Up a Dev Environment](#setting-up-a-dev-environment) +- [Asking for Help](#asking-for-help) +- [Dev Process](#dev-process) + - [Branch Strategy](#branch-strategy) + - [Norms for Commits](#norms-for-commits) + - [While You're Working](#while-youre-working) + - [Making a Pull Request](#making-a-pull-request) + - [Signaling Readiness](#signaling-readiness) + - [Review Process](#review-process) + - [Handling Common Situations](#handling-common-situations) + - [Abandoned Pull Requests](#abandoned-pull-requests) + - [Follow-Up Work](#follow-up-work) + - [After Your PR is Approved](#after-your-pr-is-approved) +- [Code of Conduct](#code-of-conduct) + +## Ways to Contribute + +We’re looking for experienced engineers and designers, but you don’t need to already know our full stack as long as you know how to onboard yourself and ask for help if needed. Some experience with contributing to OSS is helpful. We welcome many different types of contributions, including: + +- [Frontend](https://github.com/distributeaid/next-website-v2) + - As a Frontend Developer at Distribute Aid, you’ll create new pages for, update, and maintain the Distribute Aid website, often working closely with our designers or other devs + - Stack: NextJS, TypeScript, Strapi, Radix UI +- [Backend](https://github.com/distributeaid/aggregated-public-information) + - As a Backend Developer at Distribute Aid, you’ll develop and maintain our backend for our website, work with APIs to share and structure collected needs data for our needs assessment as well as data visualisations to show our work. You’ll most likely collaborate with other Backend devs. + - Stack: Strapi (our website’s backend), TypeScript, APIs +- Design + - As a designer at Distribute Aid, you’ll create designs for our website and any app we’re working on to make the lives of aid workers easier and more effective. You’ll collaborate with frontend developers and are expected to learn to create issues on GitHub. + - Stack: Figma, Canva, GitHub issues +- Data + - Part data engineer, part data analyst, you’ll work with historical data from our Needs Assessment as well as future incoming Needs Assessment data. One of your main responsibilities will be to structure and present the data, creating visualisations that we can use on the website or show to partners to emphasise our impact. + - Stack: Strapi, APIs, Salesforce +- [Documentation](https://github.com/distributeaid/docs) + +## What we offer + +Having a team structure in place allows us to foster both collaboration and individual growth. We emphasise doing peer reviews and encourage contributors who are willing to take on more responsibility to step up and get on track to become maintainers. + +Regular contributors get access to periodic 1on1s with our tech lead to check in and enable personal development and growth at Distribute Aid. We’re also happy to write references for regular contributors as needed. + +If this sounds interesting to you, [get in touch](mailto:tech@distributeaid.org) and tell us a bit about yourself. + +## Finding an Issue + +All available issues can be found in the "Ready for work" column on our [project board](https://github.com/orgs/distributeaid/projects/15). + +Once you see an issue that you'd like to work on, please assign yourself to it. + +## Creating Issues + +On the [Issues page on Github](https://github.com/distributeaid/next-website-v2/issues), click the green `New Issue` button or this [New Issue Link](https://github.com/distributeaid/next-website-v2/issues/new). + +- Add a descriptive title with an optional `[type tag]` such as [component] or [page]. In the description body summarize the issue +- Add external links, such as to Figma designs or external documentation, if applicable + - If a Figma design exists, be sure to add screenshots. Visual explanations go a long way towards making things super clear! +- Add parts of the codebase where changes would be made +- Assign the issue to yourself or someone else, or leave for another person to pick it up +- Add appropriate labels and types +- After you create the issue, it'll be automatically added to our [project board](https://github.com/orgs/distributeaid/projects/15) + +If the issue needs some precursor set up before someone can work on the issue (particularly for parents of sub issues) such as library installations and page or folder creations, then you must first set the issue as `Triage` until those appropriate changes are made and reviewed in a pull request. Otherwise, set the issue as `Ready for Work`. + +### Sub Issues + +For larger issues that can be split up into separate independent parts—like a new parent page with multiple children components, for example—you can create a parent issue, with multiple child issues. [See these slides](https://docs.google.com/presentation/d/1ToMum70-qDlaCv6m7X3HfGr3XjaX-UjyA36K4IElO5Y/edit?slide=id.g2dd259a195e_0_9#slide=id.g2dd259a195e_0_9) on how to create sub issues. + +## Setting up a Dev Environment + +Dev environment setup varies across our repos, so please refer to the README for any repo you'd like to contribute to! + +## Asking for Help + +The best way to reach us with a question when contributing is to ask on: + +- The original Github issue +- Our Slack channel + +## Dev Process + +### Branch Strategy + +We have a long-running branch `main` and create short-lived branches to develop parts of the website. Our branch naming convention is `type/issue#/condensed-issue-name`. An example of a short-lived branch would be `feat/365/about-us`. Connect words using a "-" as branch names cannot include empty spaces. Always ensure you're working on a separate branch to avoid merge conflicts. + +### Norms for Commits + +Most of our repos (except docs) use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). When crafting commit messages, group commits that are related to a particular topic. For example, if you're making commits related to the styling, only include files that are related to styling. This makes it easier to read through the commits and see the exact files that made changes to the styles. Proper commits make debugging easier in cases where we need to go through our git logs. + +A good commit message will ideally have the following attributes: + +- Subject => A summary of what you did in the commit. +- Body => A detailed explanation of the commit. + +### While You're Working + +The usual best practices apply: + +- We prefer **small, focused pull requests** that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs. +- Each time you start to work, merge `main` into your branch so that you're not behind and avoid merge conflicts later on +- When you're done for the day, commit and push your changes, even if it's not done or breaks, but so that maintainers can get an idea of the progress of an issue +- Make sure your [code is modular](https://dev.to/prxtikk/how-to-write-clean-and-modular-code-1d87) and free of unnecessary dependencies (see also the [SOLID design principles](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) and [KISS principle](https://changingminds.org/techniques/language/persuasive/keep_it_simple.htm)) +- Make sure your code passes the applicable tests (see the README for the repo you're working in) +- Use reusable file names that make sense in more than one context. e.g. ~~`homepageData.ts`~~ `testimonials.ts` +- Follow the best practices for naming variables, case choice (like PascalCase, camelCase, or snake_case), etc. for each language you're writing in + +### Making a Pull Request + +- Include the purpose of the Pull Request and link the issue related to the PR (with the `#` sign) +- Consider providing an overview of why the work is taking place (with any relevant links). Don't assume familiarity with the history +- Be explicit about what feedback you want, if any: a quick pair of 👀 on the code, discussion on the technical approach, critique on design, a review copy +- Be explicit about when you want feedback, if the Pull Request is a work in progress, say so. Prefix the title of your PR with [WIP] +- Each repo is configured to require a review from the repo's review team, but if you'd like to add review requests from specific individuals (like if you’ve already discussed them reviewing the PR ahead of time, for instance, or if you want their particular input), that's fine! + +### Signaling Readiness + +- Ensure all CI checks are passing +- Make sure your branch is up to date with `main` +- If your PR is currently in "Draft" status, click "Mark ready for review" +- Post a link to your PR in the `#tech-github-chat` channel on Slack and say it's ready for review + +### Review Process + +**Initial Review Timeline**: Expect an initial review within **3-5 business days**. Complex PRs may take longer. If you haven't heard anything from the team (a verbal response or an emoji reaction on the `#tech-gitbub-chat` channel in Slack) within a week, please post again + +**Follow-up Reviews**: After addressing feedback, please click "Re-request review" and post in Slack again + +### Handling Common Situations + +#### Abandoned Pull Requests + +If you can no longer continue work on your PR: + +- Comment on the PR and post in Slack explaining the situation +- Maintainers may either: + - Take over the PR and push additional commits to complete it + - Close the PR and create a new issue for others to pick up + - Close the PR if the change is no longer needed + +#### Follow-up Work + +- Small follow-up changes should be addressed in the same PR when possible +- Larger follow-ups or new issues discovered during review should be handled in separate issues/PRs +- Use "TODO" comments sparingly and create follow-up issues for any deferred work + +### After Your PR is Approved + +Once you've received an approval from a maintainer you can merge your PR. If your branch has become out of sync with `main`, GitHub will show an "Update branch" button on your PR. If you run into merge conflicts you're not sure how to handle or if you have any other questions, please post in Slack! + +--- + +_Questions about the PR process? Feel free to ask in the issue comments, discussions, or reach out to the maintainers directly._ + +## Code of Conduct + +Please read our [Code of Conduct](https://distributeaid.org/code-of-conduct/)