Here's a list of all our current repositories. We use GitHub issues to track the work associated with each repository. That's where you can find things to work on.

We make extensive use of issue labels to designate the priority, status and beginner-friendliness of various issues.

Some helpful saved searches on GitHub than can assist with finding an issue:

• issues labeled good first issue
• issues labeled help-wanted
• PRs labeled help-wanted

Check the issue comments/labels to see whether someone else has indicated that they are working on it. If someone is already working on it and there has been activity within the last 7 days, you may want to find a different issue to work on.

Once you've found an issue you'd like to work on, please follow these steps to make your contribution. Start by proposing a new issue.

If you want to work on something that there is no GitHub issue for, including for submitting a new package, follow these steps:

1. Create a new GitHub issue associated with the relevant repository and propose your change there. Be sure to include implementation details and the rationale for the proposed change.
   • We are very reluctant to accept random pull requests without a related issue created first.
2. Wait for a project maintainer to evaluate your issue and decide whether it's something that we will accept a pull request for.
3. Once the project maintainer has approved the issue, you may start work on code as described in the Contribution process section above.

When in doubt, ask a question in the Discussions tab of the relevant repository.

1. Comment on it and say you're working on that issue. This is to avoid conflicts with others also working on the issue.
2. Fork the repository and create a new branch from the develop branch, with an appropriate name.
3. Write your code and run tests to check for regressions.
4. Update the tests (if required) and update documentation.
5. Submit your pull request. For PR titles, follow Conventional Commits.
6. Wait for code review and address any issues raised as soon as you can.

1. Comment on it and say you're working on that issue. This is to avoid conflicts with others also working on the issue.
2. Fork the repository and create a new branch from the default branch (usually master), with an appropriate name.
3. Write your code. Follow these guidelines for writing manifests:
   • Read the Wiki on how app manifests work - App Manifests - and how to create one - Creating an App Manifest.
   • Follow this general order of fields (whichever exist) in the JSON file. Or use the template for a starter file.
     • version
     • description
     • homepage
     • license
     • notes
     • depends
     • suggest
     • architecture
       • url
       • hash
     • extract_dir
     • extract_to
     • pre_install
     • installer
     • post_install
     • env_add_path
     • env_set
     • bin
     • shortcuts
     • persist
     • pre_uninstall
     • uninstaller
     • post_uninstall
     • checkver
     • autoupdate
   • Use a tab width of 4 spaces.
   • The license property should be a valid SPDX Identifier.
   • Portable configuration is highly preferred (by using persist).
   • If the program file is a CLI application, no need to add it in shortcuts.
   • If the program file is a GUI application and it doesn't accept any commandline arguments, no need to add it in bin.
   • If an array contains only one item, write it as a string.
   • If the application provides only a 32bit download, the architecture field is not required. In all other cases, architecture field is mandatory.
4. Test your manifest by installing, uninstalling, checking functionality, persistence etc.
5. Confirm that manifest gets updated automatically - see App Manifest Autoupdate.
6. Submit your pull request. Titles should follow these rules:
   • If it's a new manifest, use <app name>: Add version <version>.
   • If it's an update to an existing manifest, use <app name>@<version>: <small description>.
   • If it's something related to maintenance, use (chore): <small description>.
7. Manifest validations will be triggered automatically when a PR is created. If your changes fail one or more checks, please address the issues in the manifest and comment starting with /verify to rerun the checks.
8. Wait for code review and address any issues raised as soon as you can.

A note on collaboration: We encourage people to collaborate as much as possible. We especially appreciate contributors reviewing each others pull requests, as long as you are kind and constructive when you do so.