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