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

43 lines
2.9 KiB
Markdown
Raw Normal View History

---
title: קריטריונים כלליים
---
!!! example "עבודה בתהליך"
העמוד הבא הוא עבודה בתהליך ואינו משקף את הקריטריונים המלאים להמלצות שלנו בשלב זה. דיון עבר בנושא זה: [#24](https://github.com/privacyguides/privacyguides.org/discussions/24)
להלן כמה דברים שחייבים לחול על כל ההגשות ל-Privacy Guides. לכל קטגוריה יהיו דרישות נוספות להכללה.
## גילוי פיננסי נאות
איננו מרוויחים כסף מהמלצה על מוצרים מסוימים, איננו משתמשים בקישורי שותפים, ואיננו נותנים התחשבות מיוחדת לתורמי הפרויקט.
## הנחיות כלליות
אנו מיישמים את סדרי העדיפויות הבאים כאשר אנו שוקלים המלצות חדשות:
- **מאובטח**: על הכלים לפעול לפי שיטות אבטחה מומלצות בכל מקום שניתן.
- **זמינות מקור**: פרויקטי קוד פתוח מועדפים בדרך כלל על פני חלופות קנייניות שוות.
- **חוצה פלטפורמות**: בדרך כלל אנו מעדיפים שההמלצות יהיו חוצות פלטפורמות, כדי למנוע נעילת ספקים.
- **פיתוח פעיל**: את הכלים שאנו ממליצים עליהם לפתח באופן פעיל, פרויקטים לא מתוחזקים יוסרו ברוב המקרים.
- **שימושיות**: כלים צריכים להיות נגישים לרוב משתמשי המחשב, אין צורך ברקע טכני יתר על המידה.
- **מתועד**: לכלים צריך להיות תיעוד ברור ונרחב לשימוש.
## הגשות עצמיות של מפתחים
יש לנו דרישות אלה לגבי מפתחים שרוצים להגיש את הפרויקט או התוכנה שלהם לשיקול.
- חייב לחשוף את ההשתייכות, כלומר את עמדתך בפרויקט המוגש.
- חייב להיות מסמך לבן אבטחה אם מדובר בפרויקט הכולל טיפול במידע רגיש כמו מסנג'ר, מנהל סיסמאות, אחסון מוצפן בענן וכו'.
- סטטוס ביקורת של צד שלישי. אנחנו רוצים לדעת אם יש לך אחד, או שיש לך אחד מתוכנן. במידת האפשר נא לציין מי יבצע את הביקורת.
- חייב להסביר מה הפרויקט מביא לשולחן בכל הנוגע לפרטיות.
- האם זה פותר בעיה חדשה כלשהי?
- למה שמישהו ישתמש בזה על פני האלטרנטיבות?
- חייבים לציין מהו מודל האיום המדויק עם הפרויקט שלהם.
- למשתמשים פוטנציאליים צריך להיות ברור מה הפרויקט יכול לספק ומה לא.
--8<-- "includes/abbreviations.he.txt"