perlpolicy - מקוון בענן

תָכְנִית:

שֵׁם

perlpolicy - מדיניות והתחייבויות שונות ומגוונות הקשורות לליבת Perl

תיאור

מסמך זה הוא מסמך האב שמתעד את כל המדיניות הכתובה לגבי אופן הפעולה של Perl
5 סבלים יחד מפתחים ומתחזקים את ליבת Perl.

ממשלה

פרל 5 סבלים
מנויים ל-perl5-porters (הפורטרים עצמם) מגיעים בכמה טעמים. חלקם כן
אורבים סקרנים שקטים, שממעטים להסתובב ולצפות במקום זאת בהתפתחות המתמשכת
ודא שהם מקבלים התראה מוקדמת על שינויים או תכונות חדשות ב- Perl. חלקם נציגים של
ספקים, שנמצאים שם כדי לוודא שפרל ממשיכה להדר ולעבוד עליהם
פלטפורמות. חלקם מתקנים כל באג מדווח שהם יודעים לתקן, חלקם פעילים
תיקון אזור חיית המחמד שלהם (חוטים, Win32, המנוע regexp), בעוד שאחרים כנראה עושים זאת
שום דבר מלבד להתלונן. במילים אחרות, זה השילוב הרגיל שלך של אנשים טכניים.

מעל קבוצת הסבלים הזו יושב לארי וול. יש לו את המילה האחרונה במה עושה ומה
לא משתנה באף אחת משפות התכנות של Perl. בימים אלה, לארי מבלה את רובו
מזמנו ב-Perl 6, בעוד ש-Perl 5 הוא רועה על ידי "פומפינג", סבל אחראי
על ההחלטה מה נכנס לכל מהדורה והבטחת שההוצאה יקרה באופן קבוע
בסיס.

לארי רואה התפתחות של פרל בכיוון של ממשלת ארה"ב: יש בית המחוקקים
(הסבלים), הרשות המבצעת (ה-pumpking), ובית המשפט העליון (לארי). ה
המחוקק יכול לדון ולהגיש טלאים לרשות המבצעת כל מה שהם אוהבים, אבל
הרשות המבצעת חופשית להטיל עליהם וטו. לעתים רחוקות, בית המשפט העליון יתייצב לצד
הרשות המבצעת על הרשות המחוקקת, או הרשות המחוקקת על הרשות המבצעת.
אולם לרוב, הרשות המחוקקת והרשות המבצעת אמורים להסתדר ו
לפתור את ההבדלים ביניהם ללא הדחה או תיקי בית משפט.

לפעמים אתה יכול לראות התייחסות לכלל 1 ולכלל 2. כוחו של לארי כבית המשפט העליון הוא
מתבטא בכללים:

1. לארי תמיד בהגדרה צודק לגבי איך פרל צריך להתנהג. זה אומר שיש לו
סמכות וטו סופית על פונקציונליות הליבה.

2. לארי רשאי לשנות את דעתו לגבי כל עניין במועד מאוחר יותר, ללא קשר ל
האם הוא הפעיל בעבר את כלל 1.

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

תחזוקה ו תמיכה

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

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

עם זאת, אנו מעריכים את היציבות והאבטחה של Perl ויש לנו מזמן לא כתוב
אמנה עם קהילת Perl הרחבה יותר כדי לתמוך ולתחזק מהדורות של Perl.

מסמך זה מגבש את התחייבויות התמיכה והתחזוקה של קהילת Perl
צריך לצפות מהמפתחים של Perl:

· אנו תומכים "רשמית" בשתי סדרות המהדורות היציבות האחרונות. 5.16.x ומעלה
חסרים כעת תמיכה. החל מהשחרור של 5.22.0, נפסיק "רשמית" את התמיכה
עבור Perl 5.18.x, מלבד מתן עדכוני אבטחה כמתואר להלן.

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

· כמיטב יכולתנו, נספק תיקוני אבטחה "קריטיים" עבור
כל גרסה עיקרית של Perl שהשחרור 5.x.0 שלה היה בשלוש השנים האחרונות. אנחנו יכולים
רק מתחייבים לספק את אלה עבור מהדורת ה-.y העדכנית ביותר בכל סדרת 5.xy.

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

· אנו מעודדים את הספקים לשלוח את המהדורה הנתמכת העדכנית ביותר של Perl בזמן של
הקוד שלהם הקפאת.

· כספק, ייתכן שתהיה לך דרישה להחזיר תיקוני אבטחה מעבר ל-3 השנים שלנו
תמיכה במחויבות. אנו יכולים לספק לך תמיכה וייעוץ מוגבלים תוך כדי כך
ובמידת האפשר ינסה להחיל את התיקונים האלה על ענפי ה-maint הרלוונטיים ב
git, אם כי אנו עשויים או לא בוחרים לבצע מהדורות ממוספרות או תיקונים "רשמיים".
זמין. צור איתנו קשר ב[מוגן בדוא"ל]> להתחיל את התהליך הזה.

לְאָחוֹר תְאִימוּת ו בִּזוּי

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

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

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

בהמשך הדרך הזו מסתתר טירוף.

דרישה ממתכנתי משתמש קצה לשנות רק כמה מבני שפה, אפילו שפה
מבנים שאף מפתח משכיל אי פעם לא ישתמש בהם בכוונה הוא כמותו
אומר "אסור לשדרג למהדורה חדשה של Perl אלא אם כן יש לך 100% כיסוי בדיקה
ויכול לבצע ביקורת ידנית מלאה של בסיס הקוד שלך." אם היו לנו כלים שיכולים
שדרוג מהימן של קוד מקור Perl מגרסה אחת של Perl לאחרת, דאגה זו
ניתן להפחית באופן משמעותי.

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

תחביר וסמנטיקה קיימים צריכים להיות מסומנים להרס רק במקומות מוגבלים מאוד
נסיבות. אם מאמינים שהם משמשים לעתים רחוקות מאוד, עמוד בדרכו של ממש
שיפור לשפת Perl או פרל מתורגמן, ואם הקוד מושפע יכול להיות בקלות
עודכנו כדי להמשיך לעבוד, ייתכן שיישקלו להסירם. כאשר יש ספק, זהירות
מכתיב שנעדיף תאימות לאחור. כאשר תכונה הוצאה משימוש, א
הצהרת הנמקה המתארת ​​את תהליך ההחלטה תפורסם וקישור אליו
יסופקו במסמכי perldelta הרלוונטיים.

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

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

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

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

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

תכונות ניסוי חייבות להיות ניסיוניות בשתי מהדורות יציבות לפני סימון
לא ניסיוני. תכונות ניסוי יקבלו רק את הסטטוס הניסיוני שלהן
בוטלו כאשר אין להם עוד באגים משנים עיצוב פתוחים נגדם ומתי
הם נשארו ללא שינוי בהתנהגות לכל אורך מחזור הפיתוח.
במילים אחרות, ייתכן שתכונה הקיימת בגרסה 5.20.0 מסומנת ככזו שאינה ניסיונית עוד ב
v5.22.0 אם ורק אם ההתנהגות שלו לא תשתנה לאורך כל v5.21.

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

החל מ-Perl 5.12, תכונות ומודולים שהוצאו משימוש מזהירים את המשתמש בזמן השימוש בהם. מתי
מודול הוצא משימוש, הוא יהיה זמין גם ב-CPAN. מתקין אותו מ
CPAN ישתיק אזהרות הוצאה משימוש עבור אותו מודול.

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

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

הוסר
לאחר שתכונה, מבנה או מודול סומנו ככאלה שהוצאו משימוש, אנו עשויים להסיר אותם
מליבת פרל. באופן לא מפתיע, אנחנו אומרים שכן הוסר את הדברים האלה. כאשר מודול
הוסר, הוא לא יישלח עוד עם Perl, אבל ימשיך להיות זמין ב-
CPAN.

תחזוקה ענפים

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

אין צורך לכלול כל שינוי העומד בקריטריונים אלה, ובאופן כללי את
התמקדות צריכה להיות בטיפול בבעיות אבטחה, באגים קורסים, רגרסיות ורציניות
בעיות התקנה. הפיתוי לכלול שפע של שינויים מינוריים שלא
להשפיע על ההתקנה או הביצוע של perl (למשל תיקוני איות בתיעוד)
צריך להתנגד כדי להפחית את הסיכון הכולל להתעלם ממשהו. ה
הכוונה היא ליצור מהדורות תחזוקה שכדאיות וגם שמשתמשים יכולים
יש אמון מלא ביציבות של. (דאגה משנית היא למנוע שריפה
המתחייבים האחרים המעוררים או המכריעים שמצביעים על שינויים שיש לכלול (ראה
"קבלת שינויים לסניף ראשי" למטה).)

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

· תיקונים שמתקנים CVEs או בעיות אבטחה. שינויים אלה צריכים להיות מופעלים דרך
[מוגן בדוא"ל] רשימת תפוצה במקום להחיל ישירות.

· תיקונים שמתקנים באגים קורסים, כשלים בהצהרה ושחיתות זיכרון אך מתקנים זאת
לא לשנות אחרת את הפונקציונליות של perl או להשפיע לרעה על הביצועים.

· תיקונים שמתקנים רגרסיות בהתנהגות של perl ביחס למהדורות קודמות, לא
משנה בת כמה הרגרסיה, מכיוון שחלק מהאנשים עשויים לשדרג מגרסאות ישנות מאוד של
perl לגרסה העדכנית ביותר.

· תיקונים שמתקנים באגים בתכונות שהיו חדשות ביציבות 5.x.0 המקבילות
לשחרר.

· תיקונים שמתקנים כל דבר שמונע או משפיע באופן רציני על המבנה או
התקנה של perl.

· תיקוני ניידות, כגון שינויים ב-Configure ובקבצים ברמזים/תיקיה.

· תיקונים מינימליים שמתקנים כשלים בבדיקה ספציפית לפלטפורמה.

· עדכוני תיעוד המתקנים שגיאות עובדתיות, מסבירים באגים משמעותיים או
ליקויים ביישום הנוכחי, או לתקן סימון שבור.

· עדכונים למודולים חיים כפולים צריכים להיות מורכבים מתיקונים מינימליים לתיקון באגים קורסים או
בעיות אבטחה (כאמור לעיל). כל שינוי שנעשה במודולים בעלי חיים כפולים שעבורם מיועד CPAN
יש לתאם את הקנוני עם המחבר במעלה הזרם.

סוגי השינויים הבאים אינם מקובלים:

· תיקונים ששוברים תאימות בינארית. (נא לדבר עם שאיבה.)

· תיקונים שמוסיפים או מסירים תכונות.

· תיקונים שמוסיפים אזהרות או שגיאות חדשות או מוציאים משימוש תכונות.

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

· אין לייבא גרסאות חדשות של מודולים בעלי חיים כפולים ל- Maint. אלה שייכים ל
הסדרה היציבה הבאה.

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

מקבל שינויים אל תוך a maint סניף
מבחינה היסטורית, רק הדובדבן השואב משתנה מ-bleadperl ל-maintperl. זֶה
יש בעיות קנה מידה. במקביל, ענפי תחזוקה של גרסאות יציבות של פרל
צריך לטפל בזהירות רבה. לשם כך, החל מ-Perl 5.12, יש לנו תהליך חדש
לסניפי ניהול.

כל מתחייב רשאי לבחור כל התחייבות מבליד לסניף מנהל אם הוא שולח דואר ל
perl5-porters מכריזים על כוונתם לבחור דובדבן התחייבות ספציפית יחד עם
הרציונל לעשות זאת ולפחות שני מתחייבים נוספים מגיבים לרשימה שנותנת את שלהם
לְהַסכִּים. (מדיניות זו חלה על שאיבות נוכחיות וקודמות, כמו גם אחרות
מתחייבים.)

ניתן להשתמש במנגנוני הצבעה אחרים במקום זאת, כל עוד יש אותו מספר קולות
נאסף בצורה שקופה. ספציפית, הצעות אשר משתנות ל-Cherry Pick
חייב להיות גלוי לכולם ב-perl5-porters כך שדעותיהם של כל המעוניינים
להישמע.

אין זה הכרחי שההצבעה תתקיים על ערכים הקשורים ב-perldelta של קטיף דובדבן
עם שינויים שכבר נקטפו בדובדבן, וגם לא לשאיבה העיקרית
הצבעות על שינויים הנדרשים על ידי Porting/release_managers_guide.pod איפה שינויים כאלה יכולים
להיות מיושם באמצעי קטיף דובדבנים מדמם.

תרם מודולים

A חֶברָתִי חוזה על אמנותי שליטה
להלן הצהרה על שליטה אמנותית, המוגדרת כיכולת של מחברי
חבילות להנחות את עתיד הקוד שלהם ולשמור על שליטה על עבודתם. זה
הכרה בכך שלמחברים צריכה להיות שליטה על עבודתם, ושזה א
אחריות של שאר קהילת פרל להבטיח שהם ישמרו על השליטה הזו.
זהו ניסיון לתעד את הסטנדרטים שבהם אנו, כמפתחי פרל, מתכוונים לעמוד
בְּעָצמֵנוּ. זהו ניסיון לרשום הנחיות גסות לגבי הכבוד שאנו חבים לכל אחד
אחרים כמפתחי Perl.

הצהרה זו אינה חוזה משפטי. הצהרה זו אינה מסמך משפטי באף אחד
דרך, צורה או צורה. Perl מופץ תחת הרישיון הציבורי של GNU ותחת ה
רישיון אמנותי; אלה המונחים המשפטיים המדויקים. האמירה הזו לא עוסקת בחוק
או רישיונות. מדובר בקהילה, כבוד הדדי, אמון ושיתוף פעולה בתום לב.

אנו מכירים בכך הליבה של Perl, המוגדרת כתוכנה המופצת עם הלב של
פרל עצמו, הוא פרויקט משותף של כולנו. מדי פעם, תסריט,
מודול, או סט של מודולים (להלן פשוט "מודול") יוכיח זאת
שימושי נרחב ו/או כל כך אינטגרלי לתפקוד הנכון של Perl עצמו שהוא צריך
להיות מופץ עם ליבת Perl. אסור לעשות זאת בלי המחבר
הסכמה מפורשת, והכרה ברורה על כל החלקים שזה אומר שהמודול קיים
מופץ באותם תנאים כמו Perl עצמה. מחבר מודול צריך להבין את זה
הכללת מודול בליבת Perl משמעה בהכרח אובדן שליטה
זאת, מכיוון ששינויים עשויים להיעשות מדי פעם בהתראה קצרה או לצורך עקביות
שאר פרל.

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

· הגרסה של המודול בליבת Perl עדיין צריכה להיחשב כעבודה של
מחבר מקורי. יש להחזיר אליהם את כל התיקונים, דוחות הבאגים וכדומה.
יש לכבד את כיווני הפיתוח שלהם במידת האפשר.

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

· הגרסה של המודול המופצת עם Perl צריכה, במידת האפשר, להיות ה-
הגרסה האחרונה של המודול כפי שהופצה על ידי המחבר (הגרסה האחרונה שאינה בטא
במקרה של פרסומים ציבוריים של Perl), אם כי מחזיק הדלעת עשוי להתאפק
שדרוג גרסת המודול המופץ עם Perl לגרסה העדכנית ביותר עד
הגרסה האחרונה עברה מספיק בדיקות.

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

אולם כמוצא אחרון:

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

שוב, זה צריך להיות מוצא אחרון בלבד. באופן אידיאלי, זה לא צריך לקרות, וכל זה
יש לעשות מאמץ אפשרי לשיתוף פעולה ולפשרה לפני שעושים זאת. אם זה
האם מתגלה כנדרש כדי לחלק מודול לבריאות הכללית של Perl, קרדיט מתאים חייב
להינתן למחבר המקורי לנצח וההחלטה צריכה להיות מחדש כל הזמן
נבדק כדי לראות אם יש אפשרות להתמזג מחדש של שני הענפים בהמשך הדרך.

בכל ההתמודדות עם מודולים שנתרמו, כל מי שמתחזק את Perl צריך לזכור
שהקוד שייך למחבר המקורי, שאולי לא יהיו ב-perl5-porters בכלל
נתון זמן, וכי תיקון אינו רשמי אלא אם כן הוא שולבו ב-
עותק של המחבר של המודול. כדי לסייע בכך, ועם נקודות מס' 1, מס' 2 ו-3 לעיל,
יש לשמור מידע ליצירת קשר עם המחברים של כל המודולים שתרמו עם
הפצת פרל.

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

תיעוד

התיעוד של Perl הוא משאב חשוב עבור המשתמשים שלנו. זה חשוב להפליא עבור
התיעוד של פרל יהיה קוהרנטי באופן סביר וישקף במדויק את הזרם
יישום.

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

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

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

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

תקנים OF התנהגות

הפורום הרשמי לפיתוח של perl הוא רשימת התפוצה של perl5-porters,
שהוזכר לעיל, וה-bugtracker שלו ב-rt.perl.org. כל המשתתפים בדיון שם
צפויים לעמוד בסטנדרט התנהגות.

· היו תמיד אזרחיים.

· שימו לב למנחים.

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

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

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

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

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

קרדיטים

"חוזה חברתי על מודולים שנתרמו" במקור מאת ראס אלברי[מוגן בדוא"ל]>
וה-perl5-porters.

השתמש ב-perlpolicy באינטרנט באמצעות שירותי onworks.net