השלב הנוכחי:
המקרים לדוגמה פורסמו. ציר הזמן
בדף הזה מפורטות כמה שאלות שכדאי לשקול כשאתם יוצרים הסכם עם סופר טכני במסגרת Google Season of Docs. המאמר הזה לא נועד לייעוץ משפטי או לרשימה מקיפה של כל הנקודות שצריך להביא בחשבון כשיוצרים הסכמי כתיבה טכנית לפרויקטים בקוד פתוח. בהתאם לצרכים של הארגון או הפרויקט, כדאי להתייעץ עם הייעוץ המשפטי שלכם לפני שמצרפים כותב טכני.
היקף העבודה
- יוצרים רשימה של העבודות שמוגדרות בהסכם. חשוב להיות ספציפיים ככל האפשר. לדוגמה, במקום 'מסמכי תיעוד של API', אפשר ליצור רשימה של נקודות הקצה שצריך לתעד ואת המידע שצריך לכלול, כמו פקודת curl לדוגמה או רשימת פרמטרים.
- איך אפשר לדעת אם קטע תוכן מסוים 'הושלם'?
- דברים נוספים שכדאי להביא בחשבון:
- מי יהיה הבעלים של זכויות היוצרים על היצירה? באיזה רישיון הוא יפורסם (יש הבדלים בין הרישיונות האלה)? איזה קרדיט יקבל הסופר הטכני (אזכור באתר, ציון כתורם וכו')? מה קורה אם צריך לחדש את הרישיון לשימוש בתוכן בעתיד? לדוגמה, אם אתם מצפים שהכותב הטכני יחתום על הסכם רישיון לתורמים בפרויקט הקוד הפתוח שלכם, עליכם לציין זאת.
- אם אתם מצפים שהכותב הטכני ישתתף בכמה שלבי עריכה, ציינו זאת. לדוגמה, אפשר לציין שאתם מצפים לקבל טיוטה ראשונה, ולאחר מכן טיוטה שנייה לטיפול בבעיות טכניות, ולאחר מכן טיוטה אחרונה לצורך הגהה.
- אם אתם מצפים שהכותב הטכני יספק תוכן בפורמט ספציפי, כמו Markdown, כדאי לכלול זאת בהסכם.
- האם יש בפרויקט הנחיות לשימוש ב-AI גנרטיבי ליצירת מסמכים או קוד? חשוב לשתף את ההנחיות האלה עם הכותבים הטכניים.
פיצוי
- מסכמים עם הכותבים הטכניים על לוח זמנים לתשלומים שמקושר לתאריכים ולפריטי הגשה מוגדרים.
- האם תשלמו סכום מראש בתחילת העבודה?
- מה קורה אם אי אפשר להשתמש בעבודה או לאשר אותה (כי סדר העדיפויות של הפרויקט השתנה, כי אחד מהבודקים יצא מהפרויקט וכו')? יש לך אפשרות לשלם 'עמלת ביטול' כדי לפצות על הזמן שהסופר הטכני השקיע?
- מי יהיה אחראי על עמלות המרה של מטבע שקשורות לאמצעי התשלום שנבחר?
תקשורת
- האם אתם מצפים שהכותב הטכני יהיה זמין לשיחות וידאו או לפגישות?
- באילו ערוצי תקשורת תשתמשו ומה זמני התגובה הצפויים? לדוגמה, אם אתם מצפים שכותב טכני יגיב לאימיילים (או להודעות ב-Slack) תוך יום, צריך לציין זאת במפורש.
- למי מהפרויקט יכול הסופר הטכני לפנות בשאלות שונות, כמו בעיות בתשלומים, צורך בבדיקה, בעיות בביטול החסימה של כלים או ערוצים או חסמים אחרים?
- האם יש תהליך ספציפי שכותבים צריכים לפעול לפיו כדי לשלוח את העבודות שלהם או לקבל משוב או ביקורות?
כלים
- באילו כלים (או גרסאות של כלים) הכותבים הטכניים צריכים להשתמש כדי ליצור את העבודות שלהם?
- מי אחראי לעזור לכותב הטכני להגדיר את החשבון, לקבל גישה או לקבל הרשאות?
פתרון מחלוקות
- איך תפתרו מחלוקות לגבי איכות העבודה של הכותבים הטכניים? למי יש את המילה האחרונה?
- מה תהיה התהליך להוצאת הסופר הטכני מהפרויקט? לדוגמה, איחור בשלושה מועדים להגשה ברציפות או הגשה של עבודה באיכות לא מקובלת. כשאתם אוכפים את התהליך, כדאי לציין בבירור את השלבים הבאים (למשל, "אנחנו מצפים לקבל בקשת משיכה לגרסה הראשונה עד ליום שישי הבא" במקום "יש לשלוח את העבודה בהקדם האפשרי").
- אם כותב טכני צריך לפרוש, איך הוא צריך להודיע על כך? אם אפשר, האם כדאי לשלוח הודעה, ליצור מסמך העברה או לקיים שיחת העברה?
- חשוב לזכור את ההתחייבויות של הפרויקט לכותב הטכני. לדוגמה, אם מנהלי הפרויקט יוצאים מהפרויקט ולא ניתן להחליף אותם, או אם לא ניתן להשלים את הבדיקות שהובטחו, כדאי לשלם לכותב הטכני חלק מהכספים שנותרו, גם אם לא ניתן להשלים את הפרויקט, כדי לפצות אותו על הזמן שהקדיש.
- ציינו בבירור שהכותב הטכני מחויב לקוד ההתנהגות של הפרויקט, והוסיפו קישור לתהליך האכיפה של קוד ההתנהגות. מומלץ לציין בבירור שהפרות של כללי ההתנהגות יובילו לסיום הפרויקט ולביטול התשלום על עבודה שעדיין לא בוצעה.