name | about | title | source |
---|---|---|---|
Contribution Guidelines |
We do all of our development [on GitHub](https://github.com/ScoopInstaller/). If you are not familiar with GitHub or pull requests, [here is an excellent guide to get started](https://guides.github.com/activities/hello-world/). |
Contribution Guidelines |
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:
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:
- Comment on it and say you're working on that issue. This is to avoid conflicts with others also working on the issue.
- Fork the repository and create a new branch from the
develop
branch, with an appropriate name. - Write your code and run tests to check for regressions.
- Update the tests (if required) and update documentation.
- Submit your pull request. For PR titles, follow Conventional Commits.
- Wait for code review and address any issues raised as soon as you can.
- Comment on it and say you're working on that issue. This is to avoid conflicts with others also working on the issue.
- Fork the repository and create a new branch from the default branch (usually
master
), with an appropriate name. - 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.
- Test your manifest by installing, uninstalling, checking functionality, persistence etc.
- Confirm that manifest gets updated automatically - see App Manifest Autoupdate.
- 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>
.
- If it's a new manifest, use
- Add a comment starting with "/verify" after raising the PR - this will kick in the automatic manifest verifier.
- 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.
If you want to work on something that there is no GitHub issue for, follow these steps:
- 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.
- Wait for a project maintainer to evaluate your issue and decide whether it's something that we will accept a pull request for.
- 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.