privacyguides.org/docs/about/criteria.he.md

---
title: קריטריונים כלליים
---

!!! example "עבודה בתהליך"

    העמוד הבא הוא עבודה בתהליך ואינו משקף את הקריטריונים המלאים להמלצות שלנו בשלב זה. דיון עבר בנושא זה: [#24](https://github.com/privacyguides/privacyguides.org/discussions/24)

להלן כמה דברים שחייבים לחול על כל ההגשות ל-Privacy Guides. לכל קטגוריה יהיו דרישות נוספות להכללה.

## גילוי פיננסי נאות

איננו מרוויחים כסף מהמלצה על מוצרים מסוימים, איננו משתמשים בקישורי שותפים, ואיננו נותנים התחשבות מיוחדת לתורמי הפרויקט.

## הנחיות כלליות

אנו מיישמים את סדרי העדיפויות הבאים כאשר אנו שוקלים המלצות חדשות:

- **מאובטח**: על הכלים לפעול לפי שיטות אבטחה מומלצות בכל מקום שניתן.
- **זמינות מקור**: פרויקטי קוד פתוח מועדפים בדרך כלל על פני חלופות קנייניות שוות.
- **חוצה פלטפורמות**: בדרך כלל אנו מעדיפים שההמלצות יהיו חוצות פלטפורמות, כדי למנוע נעילת ספקים.
- **פיתוח פעיל**: את הכלים שאנו ממליצים עליהם לפתח באופן פעיל, פרויקטים לא מתוחזקים יוסרו ברוב המקרים.
- **שימושיות**: כלים צריכים להיות נגישים לרוב משתמשי המחשב, אין צורך ברקע טכני יתר על המידה.
- **מתועד**: לכלים צריך להיות תיעוד ברור ונרחב לשימוש.

## הגשות עצמיות של מפתחים

יש לנו דרישות אלה לגבי מפתחים שרוצים להגיש את הפרויקט או התוכנה שלהם לשיקול.

- חייב לחשוף את ההשתייכות, כלומר את עמדתך בפרויקט המוגש.

- חייב להיות מסמך לבן אבטחה אם מדובר בפרויקט הכולל טיפול במידע רגיש כמו מסנג'ר, מנהל סיסמאות, אחסון מוצפן בענן וכו'.
    - סטטוס ביקורת של צד שלישי. אנחנו רוצים לדעת אם יש לך אחד, או שיש לך אחד מתוכנן. במידת האפשר נא לציין מי יבצע את הביקורת.

- חייב להסביר מה הפרויקט מביא לשולחן בכל הנוגע לפרטיות.
    - האם זה פותר בעיה חדשה כלשהי?
    - למה שמישהו ישתמש בזה על פני האלטרנטיבות?

- חייבים לציין מהו מודל האיום המדויק עם הפרויקט שלהם.
    - למשתמשים פוטנציאליים צריך להיות ברור מה הפרויקט יכול לספק ומה לא.

--8<-- "includes/abbreviations.he.txt"