privacyguides/privacyguides.org
1
0
Fork 0
mirror of https://github.com/privacyguides/privacyguides.org.git synced 2025-11-03 21:07:55 +00:00
Code Issues Activity

docs: Expand on developer self-submission requirements (#2727)

Browse Source 
Signed-off-by: Jonah Aragon <jonah@privacyguides.org>
Signed-off-by: kimg45 <138676274+kimg45@users.noreply.github.com>
Signed-off-by: Daniel Gray <dngray@privacyguides.org>
This commit is contained in:
redoomed1
2024-09-11 00:54:27 +00:00
committed by Daniel Gray
parent 4f505086f8
commit 102693168a
1 changed files with 10 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/about/criteria.md
View File

@@ -4,11 +4,11 @@ title: General Criteria
Below are some general priorities we consider for all submissions to Privacy Guides. Each category will have additional requirements for inclusion. Below are some general priorities we consider for all submissions to Privacy Guides. Each category will have additional requirements for inclusion.
- **Security**: Tools should follow security best-practices wherever applicable. - **Security**: Tools should follow security best practices wherever applicable.
- **Source Availability**: Open-source projects are generally preferred over equivalent proprietary alternatives. - **Source Availability**: Open-source projects are generally preferred over equivalent proprietary alternatives.
- **Cross-Platform Availability**: We typically prefer recommendations to be cross-platform, to avoid vendor lock-in. - **Cross-Platform Availability**: We typically prefer recommendations to be cross-platform to avoid vendor lock-in.
- **Active Development**: The tools that we recommend should be actively developed, unmaintained projects will be removed in most cases. - **Active Development**: The tools that we recommend should be actively developed. Unmaintained projects will be removed in most cases.
- **Usability**: Tools should be accessible to most computer users, an overly technical background should not be required. - **Usability**: Tools should be accessible to most computer users. An overly technical background should not be required.
- **Documentation**: Tools should have clear and extensive documentation for use. - **Documentation**: Tools should have clear and extensive documentation for use.
## Financial Disclosure ## Financial Disclosure
@@ -19,14 +19,16 @@ We do not make money from recommending certain products, we do not use affiliate
We have these requirements in regard to developers which wish to submit their project or software for consideration. We have these requirements in regard to developers which wish to submit their project or software for consideration.
- Must undergo our [self-submission process](https://discuss.privacyguides.net/t/about-the-project-showcase-category/114) as a way to engage with our community, address any potential concerns, and elicit any feedback that can help improve your project.
- Must disclose affiliation, i.e. your position within the project being submitted. - Must disclose affiliation, i.e. your position within the project being submitted.
- Must have a security whitepaper if it is a project that involves handling of sensitive information like a messenger, password manager, encrypted cloud storage, etc. - Must have a security whitepaper if it is a project that involves the handling of sensitive information like a messenger, password manager, encrypted cloud storage, etc.
- Third party audit status. We want to know if you have one, or have one planned. If possible please mention who will be conducting the audit. - Regarding third party audit status, we want to know if you have undergone one, or have requested one. If possible please mention who will be conducting the audit.
- Must explain what the project brings to the table in regard to privacy. - Must explain what the project brings to the table in regard to privacy.
- Does it solve any new problem? - What new problem(s), if any, does it solve?
- Why should anyone use it over the alternatives? - Why should anyone use it over the alternatives?
- Must state what the exact threat model is with their project. - Must state what the exact threat model is with their project.
- It should be clear to potential users what the project can provide, and what it cannot. - It should be clear to potential users what the project can provide, and what it cannot. Ideally, a developer should be able to identify what [common threat(s)](../basics/common-threats.md) their project protects against.