Вытворчасць з адкрытым зыходным кодам

Як прамысловасці паспеў, некалькі ўзаемазвязаных змены адбыліся адначасова. Дзікія разнастайнасць апаратных канструкцыі паступова саступіла месца некалькі пераможцы-пераможцаў праз перадавыя тэхналогіі, галоўнае маркетынг, або спалучэнне таго і іншага. У той жа час, і не зусім выпадкова, развіццё так званага "высокага ўзроўню" моў праграмавання азначала, што можна было б напісаць праграму адзін раз на адной мове, і ён аўтаматычна перакладаецца ("складзены") для запуску на розных відах кампутараў. Наступствы гэтага былі не выслізнула ад вытворцаў апаратнага забеспячэння: кліент можа цяпер распачаць сур'ёзныя намаганні распрацоўкі праграмнага забеспячэння не абавязкова замак сябе ў адной канкрэтнай архітэктуры сістэмы. Калі гэта было ў спалучэнні з паступовым звужэннем розніца ў прадукцыйнасці паміж рознымі кампутарамі, як менш эфектыўныя праекты былі пустазеллі, вытворцы, якія разглядалі яго апаратнай часткі ў якасці адзінага актыву можа разлічваць на будучыню зніжэнне прыбытку. Сыравіна вылічальнай магутнасці становіцца ўзаемазаменнымі добра, у той час як праграмнае забеспячэнне становіцца адзнакай. Продаж праграмнага забеспячэння, або, па крайняй меры разглядаючы яго ў якасці складовай часткі апаратных продажаў, стаў глядзець, як добрая стратэгія.

Гэта азначала, што вытворцы былі пачаць захавання аўтарскіх правоў на свой код больш строга. Калі карыстальнікі проста працягвалі абменьвацца і змяняць код свабодна паміж сабой, яны могуць самастойна перавызначыць некаторыя паляпшэнні ў цяперашні час прадаецца "дабаўленую вартасць" ад пастаўшчыка. Горш таго, агульны код можа трапіць у рукі канкурэнтаў. Іронія заключаецца ў тым, што ўсё гэта адбывалася ў часы Інтэрнэт быў атрымліваць ад зямлі. Проста, калі па-сапраўднаму свабодны праграмнае забеспячэнне для доступу, нарэшце, становіцца тэхнічна магчымым, змены ў кампутарны бізнэс зрабіў яго эканамічна непажадана, па меншай меры з пункту гледжання якой-небудзь адной кампаніі. Пастаўшчыкоў спыніў, альбо адмова карыстальнікам доступ да коду, які кіраваў іх машыны, ці настойваць на пагаднення аб невыдаванні, які зрабіў эфектыўнага абмену немагчыма.

Не пералічваючы кожны праект і кожная ліцэнзія, можна з упэўненасцю сказаць, што да канца 1980-х гадоў, было шмат вольнага праграмнага забеспячэння, даступнага ў шырокім дыяпазоне ліцэнзій. Разнастайнасць ліцэнзій адлюстраваны адпаведныя разнастайнасць матывацый. Нават некаторыя з праграмістаў, якія абралі GNU GPL былі значна менш ідэалагізаваны, чым праект GNU сябе. Хоць яны і прыемна працаваць на вольным праграмным забеспячэнні, шматлікія распрацоўнікі не лічаць уласнае праграмнае забеспячэнне сацыяльнага зла. Былі людзі, якія адчувалі маральную імпульс, каб пазбавіць свет "праграмнае забеспячэнне назапашвання" (тэрмін Столлмана для несвабоднай ПА), але іншыя былі больш матываваныя тэхнічнай хвалявання, або задавальненне працаваць з аднадумцамі супрацоўнікаў, ці нават з дапамогай простага чалавечага жадання славы. Але ў агульным і цэлым гэтыя разрозненыя матывы не ўзаемадзейнічаюць у згубным чынам. Гэта часткова таму, што праграмнае забеспячэнне, у адрозненне ад іншых творчых формаў, як проза або выяўленчага мастацтва, павінны прайсці паў-аб'ектыўныя тэсты для таго, каб лічыць паспяховым: ён павінен працаваць, і быць дастаткова свабодным ад памылак. Гэта дае ўсім удзельнікам праекта выгляд аўтаматычнага агульную мову, розум і рамкі для сумеснай працы, не занадта клапаціцца аб кваліфікацыі за межы тэхнічнай.

Распрацоўнікам прыйшлося яшчэ адна прычына трымацца разам, а таксама: апынулася, што ў свеце вольнага ПА вырабляў вельмі высокай якасці кода. У некаторых выпадках, гэта быў відавочна тэхнічна пераўзыходзіць бліжэйшага несвабоднай альтэрнатыўных, у іншых яна была па меншай меры супастаўныя, і, вядома, гэта заўсёды танней. Хоць толькі нешматлікія людзі маглі быць матываваныя, каб працаваць вольнага праграмнага забеспячэння на строга філасофскіх падстаў, вельмі многія людзі былі шчаслівыя, каб запусціць яго, таму што ён лепш. І тых, хто выкарыстаў яго, нейкі адсотак заўсёды былі гатовыя ахвяраваць сваім часам і навыкі, якія дапамогуць падтрымліваць і паляпшаць праграмнае забеспячэнне.

Гэтая тэндэнцыя вырабляць добры код, вядома, не універсальны, але гэта адбываецца ўсё часцей і часцей ў свабодных праграмных праектаў па ўсім свеце. Прадпрыемствы, якія моцна залежалі ад праграмнага забеспячэння паступова пачалі звяртаць увагу. Многія з іх выявілі, што яны ўжо выкарыстоўваюць свабоднае праграмнае забеспячэнне ў дзень-у дзень аперацыі, і проста не ведаў яго (вышэйшае кіраўніцтва не заўсёды ў курсе ўсяго ІТ-аддзел робіць). Карпарацыі сталі гуляць больш актыўную і прыкметную ролю ў свабодных праграмных праектаў, якія спрыяюць часу і абсталявання, а часам і прамое фінансаванне развіцця свабодных праграм. Такія інвестыцыі могуць, у лепшым сцэнары, пагасіць самі шмат разоў. Спонсар аплачвае толькі невялікае лік экспертаў праграмістаў прысвяціць сябе праекту поўны працоўны дзень, але прыносіць перавагі ўклад кожнага чалавека, уключаючы працу з добраахвотнікамі бясплатна і ад праграмістаў надаецца іншымі карпарацыямі.

Як карпаратыўны свет даў больш і больш увагі на свабоднае праграмнае забеспячэнне, праграмісты сутыкнуліся з новымі пытаннямі прэзентацыі. Адзін з іх слова "свабодны" само па сабе. На першым слуханні тэрмін "свабоднае праграмнае забеспячэнне" многія людзі памылкова думаюць, яно азначае толькі "нулявы кошту ПА." Гэта праўда, што ўсе вольнае праграмнае забеспячэнне з нулявой коштам, ^{[ 7 ],} але не ўсе з нулявой коштам праграмнае забеспячэнне з'яўляецца бясплатным. Напрыклад, падчас бітвы браўзэраў у 1990-х гадоў, як Netscape і Microsoft аддалі свае канкуруючыя вэб-браўзэры на бязвыплатнай аснове, у сутычцы, каб атрымаць долю на рынку. Ні браўзэр бясплатна ў "свабоднае ВА" сэнсе. Вы не маглі атрымаць зыходны код, і нават калі б вы маглі, вы не маюць права змяняць або распаўсюджваць яго. ^{[ 8 ]} Адзінае, што вы маглі зрабіць, гэта загрузіць выкананы файл і запусціць яго. Браўзэры былі не больш свабоднымі, чым спакавалі праграмнага забеспячэння купіў у краме, яны проста былі больш нізкай цане.

Гэтая блытаніна на слова "бясплатна" абумоўлена выключна няшчасны двухсэнсоўнасць ў англійскай мове. Большасць іншых мовах адрозніваць нізкія цэны ад волі (адрозненне паміж бязвыплатна і Libre адразу ясна размаўлялых на раманскіх мовах, напрыклад). Але пазіцыя англійская як мост дэ-факта мова Інтэрнэту азначае, што праблемы з ангельскай, у некаторай ступені, праблема для ўсіх. Непаразуменні вакол слова "свабодны" было настолькі распаўсюджанае, што свабодных праграмістаў у канчатковым выніку ператварылася ў стандартную формулу адказу: "Гэта бясплатна, як ва ўмовах свабоды, думаю, свабоду слова, а не бясплатнае піва". Тым не менш, прыходзіцца тлумачыць гэта зноў і зноў, стомна. Многія праграмісты адчувалі, з некаторымі агаворкамі, што неадназначнае слова "свабодны" было перашкаджае разуменню грамадскасцю гэтага праграмнага забеспячэння.

Але праблема пайшлі глыбей. Слова "бясплатна" цягне за сабой непазбежнае маральнае канатацыю: калі свабода была самамэтай, гэта не мела Ці свабоднае праграмнае забеспячэнне таксама апынуліся лепш, або больш выгадна для некаторых прадпрыемстваў у пэўных абставінах. Гэта былі ўсяго толькі прыемным пабочныя эфекты матыў, які быў, у сутнасці, ні тэхнічных, ні гандлёвага, але і маральная. Акрамя таго, "бясплатна, як ва ўмовах свабоды" пазіцыі вымушаныя абуральнае неадпаведнасць у дачыненні да карпарацый, якія хацелі падтрымаць прыватнасці свабодных праграм у адным з аспектаў свайго бізнесу, але працягваюць маркетынг прапрыетарнага праграмнага забеспячэння ў іншых.

Гэтыя дылемы прыйшлі да супольнасці, што ўжо на парозе крызісу ідэнтычнасці. Праграмістаў, якія на самай справе напісаць свабоднае праграмнае забеспячэнне ніколі не было адзінага меркавання аб канчатковай мэты, калі такія маюцца, руху вольнага праграмнага забеспячэння. Нават сказаць, што меркаванні працаваць ад адной крайнасці да іншай можа ўвесці ў зман, у тым, што было б памылкова мяркуюць лінейнай вобласці, дзе ёсць замест шматмернага рассеяння. Тым не менш, дзве шырокія катэгорыі веры можна вылучыць, калі мы гатовыя ігнараваць тонкасці на дадзены момант. Адна група бярэ гледжання Столлмана, што свабоду сумесна выкарыстоўваць і змяняць гэта самае галоўнае, і што, такім чынам, калі перастаць гаварыць пра свабоду, вы пакінулі з асноўных пытанняў. Іншыя лічаць, што само праграмнае забеспячэнне з'яўляецца найбольш важным аргументам у яе карысць, і няёмка з абвяшчэньня прапрыетарнае праграмнае забеспячэнне першапачаткова дрэнных. Некаторыя, але не ўсё, свабодны праграмісты лічаць, што аўтар (ці працадаўцы, у выпадку аплачваную працу) павінны мець права на кантроль умоў распаўсюджвання, і што не маральнае меркаваньне неабходна быць далучаны да выбару канкрэтных умоў.

Для доўгага часу, гэтыя адрозненні не павінны быць старанна вывучаны і сфармуляваны, але які расце поспех свабоднага праграмнага забеспячэння ў свеце бізнесу робяць пытанне непазбежна. У 1998 годзе тэрмін з адкрытым зыходным кодам быў створаны як альтэрнатыва "бясплатна", кааліцыяй праграмістаў, якія ў канчатковым выніку стаў Open Source Initiative (OSI). ^{[ 9 ]} OSI адчуваў, што не толькі "вольнае ПА" быў патэнцыйна супярэчлівай, але, што слова "свабодны" было толькі адным сімптомам агульнай праблемы: што рух неабходна маркетынгавую праграму, каб перадаць яго ў карпаратыўным свеце, і, што казаць пра мараль і сацыяльныя выгады ад абмену ніколі не будзе лятаць у залах пасяджэнняў. Па іх уласным словах:

Саветы многіх айсбергаў спрэчак бачныя ў гэтым тэксце. Яно спасылаецца на "нашы перакананні", але спрытна пазбягае напісання, што менавіта гэтыя перакананні. Для некаторых, гэта можа быць упэўненасць, што код, распрацаваны ў адпаведнасці з адкрытага працэсу будзе лепш код, для іншых гэта можа быць упэўненасць, што ўся інфармацыя павінна быць агульнай. Там у выкарыстанні словы "крадзеж" у стаўленні (магчыма) "для незаконнага капіявання, выкарыстання, што многія аб'ект, на той падставе, што гэта не крадзёж, калі першапачатковы ўладальнік да гэтага часу пункт пасля. Там у дразнящий намёк, што руху вольнага праграмнага забеспячэння можа быць памылкова абвінавачваюць у анты-камерцыі, але яна пакідае старанна недаследаваны пытанне аб тым, такіх абвінавачанне будзе мець ніякіх падстаў.

Ні адзін з якіх павінен сказаць, што вэб-сайт Інстытута "Адкрытае грамадства з'яўляецца несумяшчальным або ўводзіць у зман. Гэта не так. Хутчэй, гэта прыклад таго, што OSI прэтэнзіі былі адсутнічаюць руху вольнага праграмнага забеспячэння: добры маркетынг, дзе "добра" азначае "жыццяздольным у дзелавым свеце." Open Source Initiative даў шмат людзей, што менавіта яны шукалі-слоўнік для гаворым аб свабодным праграмным забеспячэнні ў якасці метадалогіі развіцця і бізнес-стратэгіі, а не як маральны крыжовы паход.

Пастаўце сябе на месца тых, хто проста чуў аб вашым праекце, магчыма, якія маюць натыкнуўся на гэта пры пошуку праграмнага забеспячэння, каб вырашыць некаторыя праблемы. Першае, што яны сутыкнецеся гэтае імя праекта.

Добрае імя не будзе аўтаматычна зрабіць праект паспяховым, і дрэннае імя не будзе Doom гэта, ну, сапраўды дрэннае імя, верагодна, можа зрабіць гэта, але мы зыходзім з таго, што ніхто тут актыўна спрабуе зрабіць свой ??праект няўдачу. Аднак, дрэннае імя можа запаволіць прыняцце праекта, альбо таму, што людзі не прымаюць яго сур'езна, ці таму што яны проста баіцеся забыць яго.

Добрае імя:

Як толькі яны знайшлі вэб-сайце праекта, наступная рэч людзі будуць глядзець на гэта Кароткае апісанне, місія, так што яны могуць вырашыць (на працягу 30 секунд) або не яны зацікаўлены ў атрыманні дадатковай інфармацыі. Гэта павінна быць на бачным месцы на першай старонцы, пажадана прама пад назвай праекта.

Місія павінна быць канкрэтнай, абмежаванне, і, перш за ўсё, кароткі. Вось прыклад добры, з http://www.openoffice.org/ :

Усяго некалькі слоў, яны патрапілі ўсе яркія моманты, у асноўным, абапіраючыся на папярэднія веды чытача. Гаворачы "як супольнасці", яны паказваюць, што ні адна карпарацыя будзе дамінаваць развіцця; "міжнародных" азначае, што праграмнае забеспячэнне дазволіць людзям працаваць на некалькіх мовах і моў; "усіх асноўных платформаў" азначае, што ён будзе пераносным на Unix, Macintosh, і Windows. Астатнія сігналы, адкрытыя інтэрфейсы і зразумелыя фарматы файлаў важнай часткай мэты. Яны не прыходзяць прама і кажуць, што яны спрабуюць быць бясплатная альтэрнатыва Microsoft Office, але большасць людзей, верагодна, можа чытаць паміж радкоў. Хоць гэтая місія выглядае шырокім, на першы погляд, на самай справе гэта даволі абмежаваны: словы "офісны пакет" азначае што-то вельмі канкрэтнае для тых, хто знаёмы з такімі праграмамі. Зноў жа, мяркуецца папярэдняе веданне чытача (у дадзеным выпадку, верагодна, ад MS Office) выкарыстоўваецца для захоўвання кароткай місіі.

Характар ??місіі залежыць збольшага ад таго, хто піша, а не толькі на праграмным забеспячэнні ён апісвае. Напрыклад, гэта мае сэнс для OpenOffice.org выкарыстоўваць словы "абшчына", таму што праект быў пачаты, і да гэтага часу ў значнай ступені аўтарамі, на Sun Microsystems. У тым ліку гэтыя словы, Sun паказвае на яго адчувальнасць да асцярогі, што яна магла б паспрабаваць дамінаваць у працэсе развіцця. З такога роду рэчы, а толькі дэманструе ўсведамленне патэнцыялу праблема выходзіць далёка ў бок пазбегнуць праблему цалкам. З іншага боку, праекты, якія не з'яўляюцца аўтарамі якога з'яўляліся адной карпарацыі, верагодна, не маюць патрэбу ў такой мову, у рэшце рэшт, развіццё супольнасці з'яўляецца нормай, таму якія звычайна не падставай для ўключэння яго ў якасці часткі місіі.

Тыя, хто па-ранейшаму зацікаўлены пасля чытання місіі будзе наступны жадаеце ўбачыць больш дэталяў, можа быць, які-небудзь карыстальнік або распрацоўшчык дакументацыі, і ў канчатковым выніку будзе хацець што-то спампаваць. Але перш, чым любое з гэтага, яны павінны быць упэўненыя, што гэта з адкрытым зыходным кодам.

На першай старонцы павінны недвухсэнсоўна зразумець, што праект з адкрытым зыходным кодам. Гэта можа здацца відавочным, але вы былі б здзіўлены, як шмат праектаў забываюць гэта зрабіць. Я бачыў, свабоднае праграмнае забеспячэнне праекта вэб-сайты, дзе галоўнай старонцы не толькі не кажуць, якія менавіта свабоднай ліцэнзіяй праграмнае забеспячэнне распаўсюджваецца пад, але нават не дзяржава наўпрост, што праграмнае забеспячэнне было бясплатным на ўсіх. Часам важна біт інфармацыі была зьвяду на старонку загрузкі, ці Распрацоўшчыкі старонцы, або ў іншым месцы, што патрабуецца яшчэ адзін пстрычка мышы, каб дабрацца да. У крайніх выпадках, ліцэнзія не была прадастаўлена ў любым месцы на вэб-сайце усё-адзіны шлях, каб знайсці яго было для загрузкі праграмнага забеспячэння і зазірніце ўнутр.

Не рабіце гэтую памылку. Такое бяздзеянне можа страціць шмат патэнцыйных распрацоўшчыкаў і карыстальнікаў. Дзяржава наперад, прама пад місіі, што праект з'яўляецца "свабодным праграмным забеспячэннем" або "з адкрытым зыходным кодам", і даць дакладную ліцэнзіі. Кароткае кіраўніцтва па выбары ліцэнзіі прыведзены ў раздзеле "Выбар ліцэнзіі і яе прымянення" далей у гэтым раздзеле, і пытанні ліцэнзавання падрабязна разглядаюцца ў чале 9, ліцэнзіі, аўтарскія правы і патэнты.

У гэты момант наш гіпатэтычны наведвальнік вызначаецца, верагодна ў хвіліну ці менш, што яна зацікаўлена ў выдаткі, скажам, па крайняй меры яшчэ пяць хвілін расследаванне гэтага праекта. Наступныя раздзелы апісваюць тое, што яна павінна сустрэчы ў тым, што пяць хвілін.

Там павінен быць кароткі пералік асаблівасцяў праграмнага забеспячэння падтрымлівае (калі што-то яшчэ не завершана, вы можаце спісе, але паставіць "плануецца" або "падчас" побач з ім), і выгляд вылічальнай асяроддзя, неабходныя для запуску праграмнага забеспячэння. Падумайце аб магчымасці / пералік патрабаванняў, як тое, што вы маглі б даць каму-то просіць кароткі агляд праграмнага забеспячэння. Гэта часта проста лагічным пашырэннем місіі. Напрыклад, місія можа сказаць:

Асаблівасці і патрабаванні спіс вызначае дэталі, удакладнення сферы місіі ў:

З дапамогай гэтай інфармацыі, чытачы могуць хутка адчуць Ці гэта праграмнае забеспячэнне мае ўсе надзеі, якія працуюць на іх, і яны могуць разгледзець магчымасць атрымання удзел як распрацоўнікі таксама.

Людзі заўсёды хочуць ведаць, як праект робіць. Для новых праектаў, яны хочуць ведаць, разрыў паміж абяцаннямі праекта і бягучай рэальнасці. Для сталай праектаў, яны хочуць ведаць, наколькі актыўна ён падтрымліваецца, як часта гэта ставіць новыя рэлізы, наколькі адказна ён, верагодна, будзе для паведамленні пра памылку і г.д.

Каб адказаць на гэтыя пытанні, вы павінны падаць раз развіцця статусу, спіс бліжэйшых мэтаў праекта і патрэбаў (напрыклад, гэта можа быць трэба для распрацоўнікаў з пэўнага віду экспертызы). Старонка можа таксама даць гісторыю мінулых рэлізах, з функцыяй спісы, так што наведвальнікі могуць атрымаць уяўленне аб тым, праект вызначае "Прагрэс" і як хутка гэта робіць прагрэс у адпаведнасці з гэтым азначэннем.

Не бойцеся глядзець не гатовая, і не паддавацца на спакусы шуміха развіцця статусу. Усім вядома, што праграмнае забеспячэнне развіваецца паэтапна, там не сорамна сказаць "Гэта альфа-праграмнае забеспячэнне з вядомых памылак Яна працуе, і працуе па крайняй меры час ад часу, але выкарыстоўвайце на свой страх і рызыку.." Такі мова не адпудзіць відаў распрацоўшчыкаў неабходна на дадзеным этапе. Што ж тычыцца карыстальнікаў, адна з горшых рэчаў, праект можа зрабіць, гэта прыцягнуць карыстальнікаў, перш чым праграма гатовая для іх. Рэпутацыю нестабільнасці або грубых памылак вельмі цяжка пазбавіцца, як толькі набыў. Кансерватызм акупляецца ў доўгатэрміновай перспектыве, гэта заўсёды лепш для праграмнага забеспячэння, каб быць больш стабільным, чым чакае карыстальнік, чым менш, і прыемныя сюрпрызы вырабляюць лепшы выгляд з вуснаў у вусны.

Праграмнае забеспячэнне павінна быць загружаны ў выглядзе зыходнага кода ў стандартных фарматах. Калі праект першага Прыступаючы да працы, двайковы (выкананы файл) пакеты не з'яўляюцца неабходнымі, калі праграмнае забеспячэнне такіх складаных пабудаваць патрабаванні або залежнасці, якія проста прымусіць яго працаваць будзе шмат працы для большасці людзей. (Але калі гэта так, то праект прыйдзецца нялёгка прыцягнуць распрацоўнікаў у любым выпадку!)

Механізму размеркавання павінны быць максімальна зручным, стандартным, і нізкія накладныя выдаткі, як гэта магчыма. Калі вы спрабавалі выкараніць хваробы, вы б не распаўсюджваць медыцыны такім чынам, што яна патрабуе нестандартнага памеру шпрыца ў кіраванні. Акрамя таго, праграмнае забеспячэнне павінна адпавядаць стандартнай зборкі і ўстаноўкі метадаў, тым больш яна адхіляецца ад стандартаў, тым больш патэнцыйных карыстальнікаў і распрацоўшчыкаў будзе здавацца і сыходзіць блытаць.

Гэта здаецца відавочным, але шматлікія праекты не папрацавалі унармоўваць свае працэдуры ўстаноўкі да самага канца ў гульню, кажучы сабе яны могуць зрабіць гэта ў любы час: "Мы ўладзіць ўсё такое, калі код бліжэй да гатоўнасці. "Тое, што яны не разумеюць, што, адкладаючы сумную працу аздобных зборкі і ўстаноўкі працэдур, яны на самой справе робіць код займае больш часу, каб падрыхтавацца, таму што яны перашкаджаюць распрацоўшчыкаў, якія маглі б спрыялі кода. Большасць падступна, яны не ведаюць, яны губляюць усе тыя распрацоўшчыкі, таму што працэс назапашвання не-падзеі: хтосьці наведвае вэб-сайт, загрузкі праграмнага забеспячэння, спрабуе будаваць яе, не атрымоўваецца, здаецца і сыходзіць. Хто ніколі не ведаю, што адбылося, за выключэннем асобы самі? Ніхто не працуе над праектам зразумее, што хто-то цікавасць і добрай волі былі ціха растрачаныя марна.

Свідравыя працы з высокім выйгрышу заўсёды павінна быць зроблена загадзя, і значнага зніжэння бар'ера праекта на ўваход праз добрая ўпакоўка прыносіць вельмі высокую аддачу.

Калі вы адпусціце загружаны пакет, важна, што вы даяце унікальны нумар версіі рэлізу, так што людзі могуць параўнаць любыя два-рэлізы і ведаць, якія замяняе іншы. Падрабязнае абмеркаванне Нумарацыя версій можна знайсці ў раздзеле "Выпуск нумарацыі", і дэталі стандартызацыі зборкі і ўстаноўкі працэдуры апісаны ў раздзеле "Упакоўка" , як у чале 7, Упакоўка, вызваленнем і штодзённая развіцця.

Загрузка пакеты зыходнага кода, выдатна падыходзіць для тых, хто проста хочуць, каб усталяваць і выкарыстоўваць праграмнае забеспячэнне, але гэта не дастаткова для тых, хто хоча адладжваць або дадаць новыя функцыі. Начныя крыніца здымкі могуць дапамагчы, але яны ўсё яшчэ не дробназярністай дастаткова для квітнеючай развіцця суполак. Людзі маюць патрэбу ў рэальным часе доступ да апошняй версіі зыходнага кода, і спосаб даць ім, што з'яўляецца выкарыстанне сістэмы кіравання версіямі. Наяўнасць ананімна даступная версія кантраляваных крыніц ўваходу для карыстальнікаў і распрацоўшчыкаў, што гэты праект робіць намаганні, каб даць людзям тое, што яны павінны ўдзельнічаць. Калі вы не можаце прапанаваць кантролю версій адразу, то мірыцца знак кажу, што вы збіраецеся ўсталяваць яго ў бліжэйшы час. Версія кіравання інфраструктурай падрабязна абмяркоўваецца ў раздзеле "Упраўленне версіямі" ў раздзеле 3, тэхнічная інфраструктура.

Тое ж самае тычыцца памылка трэкера праекта. Важнасць памылка сістэмы сачэння заключаецца не толькі ў яе карыснасці для распрацоўнікаў, але ў тым, што гэта азначае для праекта назіральнікаў. Для многіх людзей, даступнай базы дадзеных памылка з'яўляецца адной з самых моцных прыкмет таго, што праект павінен быць сур'ёзна. Акрамя таго, тым вышэй колькасць памылак у базе дадзеных, тым лепш выглядае праект. Гэта можа здацца нелагічным, але памятайце, што колькасць памылак запісаны сапраўды залежыць ад трох рэчаў: абсалютная колькасць памылак у цяперашні час праграмнае забеспячэнне, колькасць карыстальнікаў пры выкарыстанні праграмнага забеспячэння, і зручнасць, з якой гэтыя карыстальнікі могуць рэгістраваць новыя памылкі. З гэтых трох фактараў, апошнія два з'яўляюцца больш значнымі, чым першы. Любое праграмнае забеспячэнне дастатковага памеру і складанасці мае істотна адвольнае колькасць памылак чакае свайго адкрыцця. Пытанне ў тым, наколькі добра будзе рабіць праект на запіс і прыярытэтнасці гэтых памылак? Праект з вялікім і добраўпарадкаванай памылка базы дадзеных (гэта значыць памылкі з'яўляюцца адказалі аператыўна, не дубляваць памылак адзіныя, і г.д.), такім чынам, робіць лепшае ўражанне, чым праект з не памылка базы дадзеных, або амаль пусты базай дадзеных.

Вядома, калі ваш праект толькі пачынаецца, то памылка база дадзеных будзе ўтрымліваць вельмі мала памылак, і ёсць не так шмат можна зрабіць з гэтай нагоды. Але калі статус раз падкрэслівае праекта моладзі, і калі людзі, гледзячы на памылку базы дадзеных можна бачыць, што большасць заявак мелі месца ў апошні час, яны могуць экстрапаляваць з таго, што праект па-ранейшаму мае здаровы ўзровень заявак на рэгістрацыю, і яны не будуць празмерна устрывожаны нізкім абсалютная колькасць памылак запісваецца.

Звярніце ўвагу, што памылка трэкеры часта выкарыстоўваюцца для адсочвання не толькі памылкі праграмнага забеспячэння, але павышэнне запытаў, змены ў дакументацыі, нявырашаных задач, і многае іншае. Падрабязная інфармацыя аб запуску памылка трэкера разглядаюцца ў раздзеле "Bug ??Tracker" ў раздзеле 3, тэхнічная інфраструктура, таму я не буду ўдавацца ў іх тут. Галоўнае з прэзентацыі пункту гледжання проста мець памылка трэкера, і каб пераканацца, што факт, бачная з галоўнай старонкі праекта.

Наведвальнікі звычайна хочуць ведаць, як дасягнуць чалавечага істоты, звязаныя з праектам. Забяспечыць адрасы спісаў рассылання, чаты, і IRC-каналы, і любыя іншыя форумы, дзе іншыя, звязаныя з праграмным забеспячэннем можа быць дасягнута. Зрабіць ясна, што вы і іншыя аўтары праекта падпісаны на гэтыя спісы рассылання, так што людзі бачаць, што ёсць спосаб, каб даць зваротную сувязь, якая дасягне распрацоўнікаў. Ваша прысутнасць у спісах не азначае абавязацельства адказаць на ўсе пытанні і выканаць усе пажаданні. У канчатковым рахунку, большасць карыстальнікаў, верагодна, ніколі не далучыцца форумах так ці інакш, але яны суцешацца ведаць, што яны могуць, калі яны калі-небудзь трэба.

У ранніх стадыях праекта, няма неабходнасці мець асобныя супольнасці карыстальнікаў і распрацоўшчыкаў форумах. Гэта значна лепш мець усё, звязаныя з праграмным забеспячэннем казаць разам, у адной "пакоі". Сярод ранніх, адрозненні паміж распрацоўшчыкам і карыстальнікам часта недакладныя, у той меры, адрозненне можа быць зроблена, стаўленне распрацоўнікаў да карыстальнікам, як правіла, значна вышэй у першыя дні праекта, чым пазней. Хаця вы не можаце лічыць, што кожнае ранняе ўсынавіцелі праграміст, які хоча, каб секчы на ??праграмнае забеспячэнне, можна выказаць здагадку, што яны па крайняй меры зацікаўлены ў наступных абмеркавання пытанняў развіцця і ў атрыманні пачуццё напрамкі праекта.

Як гэтая кіраўнік толькі аб атрыманні праекта пачалася, дастаткова проста сказаць, што гэтыя паведамленні форумах неабходнасць існуе. Пазней, у раздзеле "Апрацоўка росту" ў чале 6, сувязі, мы разгледзім, дзе і як стварыць такія форумы, якім чынам яны могуць мець патрэбу ўмерана або іншыя кіравання, і як асобныя форумы карыстальнікаў ад форуме распрацоўнікаў, калі прыйдзе час, не ствараючы непераадольную прорву.

Калі хто-то разглядае ўклад ў праект, яна будзе шукаць кіраўніцтва распрацоўніка. Распрацоўшчык кіруючыя прынцыпы не столькі тэхнічныя, сацыяльныя: яны тлумачаць, як распрацоўнікі ўзаемадзейнічаюць адзін з адным і з карыстальнікамі, і ў канчатковым выніку, як ўсё зроблена.

Гэтая тэма падрабязна апісана ў раздзеле "Даць усё гэта ўніз" ў главе 4, сацыяльнай і палітычнай інфраструктуры, але асноўныя элементы кіраўніцтва распрацоўніка з'яўляюцца:

Няма ўніжальнае сэнсе маецца на ўвазе пад "дыктатурай", дарэчы. Гэта цалкам нармальна для запуску тыраніі, дзе адзін канкрэтны распрацоўнік мае права вета на ўсе змены. Шматлікія паспяховыя праекты працуюць менавіта так. Важна тое, што праект прыходзяць прама і сказаць. Тыраніі робячы выгляд, што дэмакратыя будзе выключаюць людзей; тыранію, якая кажа, што гэта тыранія будзе рабіць добра да таго часу, як тыран валодае кампетэнцыяй і даверам.

Глядзіце http://subversion.apache.org/docs/community-guide/ для прыкладу асабліва падрабязныя кіруючыя прынцыпы распрацоўніка, або http://www.openoffice.org/dev_docs/guidelines.html для больш шырокіх кіруючых прынцыпаў, якія надаваць больш увагі кіраванню і дух ўдзелу і менш па тэхнічных пытаннях.

Асобны пытанне аб прадастаўленні праграміста ўвядзенне ў ПА, абмяркоўваюцца ў раздзеле "Дакументацыя для распрацоўшчыкаў" далей у гэтым раздзеле.

Дакументацыя з'яўляецца істотным. Там павінна быць нешта для людзей, каб чытаць, нават калі яна ў зачаткавым стане і няпоўным. Гэта кладзецца ў "цяжкай" катэгорыі, указанай вышэй, і часта з'яўляецца першым вобласці, дзе новы праект з адкрытым кодам падае. Прыдумляючы заяву і спіс магчымасцяў, выбару ліцэнзіі, падводзячы вынікі развіцця статусу-ўсё гэта адносна невялікія задачы, якія могуць быць канчаткова завершаны, і звычайна не павінны быць вернутыя, каб яшчэ зрабіць. Дакументацыя, з іншага боку, ніколі не скончыцца, што можа быць адной з прычын людзі часам затрымкі пачатку яго наогул.

Найбольш падступнае справа ў тым, што ўтыліта дакументацыі на гэтыя запісаўшы яго ў парадку, зваротным яго карыснасць для тых, хто будзе чытаць. Найбольш важнай дакументацыі для карыстальнікаў пачатковага асновы: як хутка наладзіць праграмнае забеспячэнне, агляд таго, як яна працуе, магчыма, некаторыя кіраўніцтва да выканання агульных задач. Але гэта як раз рэчы пісьменнікаў дакументацыі занадта добра ведаюць усё-так добра, што гэта можа быць цяжка для іх, каб зірнуць на рэчы з чытача кропку гледжання, і з працай загавор з крокаў, якія (для аўтараў) здаюцца відавочна, каб быць нявартай згадкі.

Там няма чароўнага рашэння гэтай праблемы. Хто-то проста трэба сесці і напісаць матэрыял, а затым запусціць яго, тыповых новых карыстальнікаў, каб праверыць яго якасць. Выкарыстоўвайце простыя, лёгкія для рэдагавання фарматы, такія як HTML, просты тэкст, Texinfo, або нейкі варыянт XML-тое, што зручна для лёгкага, хуткага паляпшэння пад уплывам моманту. Гэта не толькі выдаляць любыя выдаткі, якія могуць перашкаджаць арыгінальных пісьменнікаў з паступовых паляпшэнняў, а таксама для тых, хто далучыцца да праекту пазней, і хачу працаваць на дакументацыю.

Адным з спосабаў забеспячэння асноўнай зыходнай дакументацыі, можа быць зроблена, каб абмежаваць яго рамкі загадзя. Такім чынам, ліст гэта па меншай меры не будзе адчуваць сябе як адкрытыя задачы. Добрае правіла ў тым, што яна павінна адказваць наступным мінімальным крытэрам:

Апошні пункт мае больш шырокае значэнне, уласна, і можа быць ужыты да ўсяго праекту, а не толькі дакументацыю. Дакладны ўлік вядомых недахопаў з'яўляецца нормай у свеце адкрытага зыходнага кода. Вы не павінны перабольшваць недахопы праекту, проста ідэнтыфікаваць іх старанна і справядліва, калі кантэкст патрабуе яго (будзь то ў дакументацыі, у памылка адсочвання базе дадзеных, або на абмеркаванне спіс рассылкі). Ніхто не ўспрыме гэта як пораженчество на частку праекта, ні як абавязацельствы вырашыць праблемы да вызначанага тэрміну, калі праект робіць такія абавязацельствы ў відавочным выглядзе. Так як любы, хто выкарыстоўвае праграмнае забеспячэнне будзе выявіць недахопы для сябе, гэта значна лепш для іх, каб быць псіхалагічна падрыхтаваныя-то праект будзе выглядаць як яна цвёрдых ведаў пра тое, як ён робіць.

Калі праект уключае ў сябе графічны інтэрфейс карыстальніка, або калі ён вырабляе графічны ці іншым адметным выхад, паставіць некаторыя ўзоры на вэб-сайце праекту. У выпадку інтэрфейсу, гэта азначае, скрыншоты, для выйсця, гэта можа быць скрыншоты або проста файлы. Як задаволіць патрэбнасць у людзей для імгненнага ўзнагароджання: адзін здымак экрана можа быць больш пераканаўчым, чым пункты апісальных тэксту і спісу рассылання балбатню, таму што скрыншот Бясспрэчна, доказ таго, што праграмнае забеспячэнне працуе. Гэта можа быць памылка, гэта можа быць цяжка ўсталяваць, яна можа быць цалкам дакументаваны, але што скрыншот яшчэ доказы таго, што калі пакласці ў досыць высілкаў, можна прымусіць яе працаваць.

Ёсць некалькі сайтаў, якія прадастаўляюць бясплатны хостынг і інфраструктуру для праектаў з адкрытым кодам: вэб-прасторы, кантроль версій, памылка трэкера, дэма-версія, чат форумах, рэгулярнае рэзервовае капіяванне і г.д. Падрабязная інфармацыя адрознівацца ад сайта да сайта, але тое ж самае Асноўныя паслугі прадастаўляюцца на ўсіх з іх. Пры выкарыстанні аднаго з гэтых сайтаў, вы атрымаеце шмат бясплатна, тое, што вы адмаўляецеся, відавочна, з'яўляецца дэталёвы кантроль над карыстальнікам. Хостынг вырашае, якое праграмнае забеспячэнне сайт працуе, і можа кантраляваць або, па крайняй меры уплываць на знешні выгляд вэб-старонкі праекта.

Глядзіце частку пад назвай "Кансервы Хостынг" ў раздзеле 3, тэхнічнай інфраструктуры для больш дэталёвага абмеркавання пераваг і недахопаў кансерваў хостынг, а таксама спіс сайтаў, якія прапаноўваюць яе.

Калі Вас задавальняе праекта кодзе патэнцыйна быць выкарыстаны ва ўласных праграм, а затым выкарыстоўваць MIT / X-падобнай ліцэнзіяй. Гэта самы просты з некалькіх мінімальных ліцэнзіі, зрабіць трохі больш, чым сцвярджаць, намінальная аўтарскага права (без фактычнага абмежавання капіявання) і паказаць, што код пастаўляецца без гарантыі. Глядзіце раздзел "MIT / X Window System ліцэнзіі" для падрабязнасьцяў.

Калі вы не хочаце, каб ваш код, каб выкарыстоўваць ва ўласных праграм, выкарыстанне GNU General Public License ( http://www.gnu.org/licenses/gpl.html ). GPL, верагодна, найбольш шырока прызнаных ліцэнзія на вольнае ПА у свеце. Гэта само па сабе вялікая перавага, паколькі многія патэнцыйныя карыстальнікі і ўдзельнікі будуць ужо знаёмыя з ім, і таму не прыйдзецца марнаваць дадатковы час, каб прачытаць і зразумець вашу ліцэнзію. Глядзіце частку пад назвай "GNU General Public License" у чале 9, ліцэнзіі, аўтарскія правы і патэнты для дэталяў.

Як толькі вы выбралі ліцэнзію, вы павінны стан яго на галоўнай старонцы праекта. Вам не трэба ўключаць сам тэкст ліцэнзіі там проста даць назву ліцэнзіі, і зрабіць гэта спасылка на поўны тэкст ліцэнзіі на іншы старонцы.

Гэта кажа грамадскасці, што ліцэнзіі вы збіраецеся праграмнага забеспячэння як выпушчаныя на ўмовах, але гэта не дастаткова для юрыдычных мэтаў. Для гэтага, само праграмнае забеспячэнне павінна ўтрымліваць ліцэнзіі. Стандартны спосаб зрабіць гэта, каб пакласці поўны тэкст ліцэнзіі ў файл з імем капіявання (ліцэнзіі), а затым пакласці кароткі тэрмін у верхняй частцы кожнага зыходнага файла, назваўшы дату капірайту, трымальнік, і ліцэнзія, і казаў, дзе знайсці поўны тэкст ліцэнзіі.

Ёсць шмат варыяцый на гэтую карціну, таму мы разгледзім толькі адзін прыклад. GNU GPL кажа пакласці паведамлення, як гэта ў пачатак кожнага зыходнага файла:

Copyright (C) <год> <імя аўтара>

Гэтая праграма з'яўляецца свабодным праграмным забеспячэннем: вы можаце распаўсюджваць яе і / або мадыфікаваць
ён у адпаведнасці з умовамі ліцэнзіі GNU General Public License, апублікаванай
Free Software Foundation, альбо версіі 3 ліцэнзіі, або
(Па вашаму выбару) любы больш позняй версіі.

Гэтая праграма распаўсюджваецца ў надзеі, што яна будзе карыснай,
але без якіх-небудзь ГАРАНТЫЙ, нават без пэўныя гарантыі
Або ПРЫДАТНАСЬЦІ ДЛЯ пэўныя мэты. Паказаць
GNU General Public License для больш падрабязнай інфармацыі.

Вы павінны былі атрымаць копію GNU General Public License
Разам з гэтай праграмай. Калі няма, гл <http://www.gnu.org/licenses/>

Ён не кажа канкрэтна, што копія ліцэнзіі, атрыманыя разам з праграмай у капіяваньні файлаў, але гэта, дзе гэта звычайна ставіцца. (Вы можаце змяніць вышэй апавяшчэнне сцвярджаць, што напрамую.) Гэты шаблён таксама дае геаграфічнае адрас, з якога запытаць копію ліцэнзіі. Іншы распаўсюджаны метад, каб даць спасылку на вэб-старонку, якая змяшчае ліцэнзіі. Проста выкарыстоўвайце ваш суд і паказваюць на месца, куды вы адчуваеце сябе найбольш пастаянную копію ліцэнзіі захоўваецца, што можа быць проста дзесьці на вэб-сайце праекту. Увогуле, апавяшчэнне вы кладзе ў кожны зыходны файл не павінен выглядаць гэтак жа, як адзін вышэй, да тых часоў, як яна пачынаецца з той жа апавяшчэнне праваўладальніка і даты, стану назва ліцэнзіі, і ясна, дзе Паглядзець поўную ліцэнзію.

Нават пасля таго як вы прынялі праект грамадскасці, вы і іншыя заснавальнікі будзеце часта знаходзіць сабе жадаючых вырашыць цяжкія пытанні прыватнымі сувязі паміж унутранай акружнасці. Гэта асабліва актуальна ў першыя дні праекта, калі Ёсць так шмат важных рашэнняў, каб зрабіць, і, як правіла, некалькі добраахвотнікаў кваліфікаваным, каб зрабіць іх. Усе відавочныя недахопы грамадскага абмеркавання спіс будзе маячыць адчувальна перад вамі: затрымка уласцівыя электроннай пошты размовы, неабходна пакінуць дастаткова часу для дасягнення кансенсусу па форме, клопатаў працы з добраахвотнікамі, якія наіўна думаюць, што разумеюць усе пытанні, але на самай справе не (кожны праект мае гэтыя, часам яны зоркі ў наступным годзе ўдзельнікамі, часам яны застаюцца наіўнымі назаўсёды), чалавек, які не можа зразумець, чаму вы хочаце, каб вырашыць праблему X, калі яна, відавочна, падмноства больш шырокай праблемы Y, і гэтак далей. Спакуса для прыняцця рашэнняў за зачыненымі дзвярыма і прадставіць іх у якасці факце, які адбыўся, або, па крайняй меры, як фірма рэкамендацыі адзінай і ўплывовай галасавання блок, будзе вяліка.

Не рабіце гэтага.

Як павольным і грувасткім, як грамадскіх абмеркаванняў можа быць, яны амаль заўсёды пераважней ў доўгатэрміновай перспектыве. Прыняцця важных рашэнняў у прыватным, як распыленне ўклад рэпеленты на вашым праекце. Ні адзін сур'ёзны добраахвотнікаў бы застацца на доўгі час у асяроддзі, дзе тайны савет прымае ўсе важныя рашэнні. Акрамя таго, грамадская дыскусія карысныя пабочныя эфекты, якія будзе доўжыцца за ўсе эфемерныя тэхнічны пытанне быў на пытанне:

Нарэшце, існуе магчымасць таго, што хто-то ў спісе можа зрабіць рэальны ўклад у размову, але, збіраючыся з ідэяй вы ніколі не меркавалася. Цяжка сказаць, наколькі верагодна, гэта, гэта проста залежыць ад складанасці кода і ступень спецыялізацыі патрабуецца. Але калі неафіцыйныя дадзеныя могуць быць дазволеныя, я б небяспека, што гэта больш верагодна, чым можна было б чакаць, інтуітыўна. У праекце Subversion, мы (заснавальнiкаў) верыў, што мы сутыкнуліся з глыбокім і складаным комплексам праблем, якія мы думалі пра жорсткіх у працягу некалькіх месяцаў, і мы шчыра сумняваўся, што хто-небудзь на зноў створаны спіс рассылкі, верагодна, зрабіць рэальнай ўклад у абмеркаванне. Таму мы прынялі гультаяваты маршрут і пачалі міргнуўшы некаторыя тэхнічныя ідэі і назад у прыватных лістоў, пакуль назіральнік ад праекту ^{[ 10 ]} злавіў вецер, што адбываецца і спытаў, для абмеркавання перанесці ў адкрыты спіс. Rolling нашых вачах трохі, мы зрабілі, і былі здзіўлены колькасцю праніклівыя каментары і прапановы, якія хутка прывялі. У многіх выпадках людзі прапануюць ідэі, якія ніколі нават не прыйшло ў галаву нам. Аказалася, там былі некаторыя вельмі разумныя людзі ў гэтым спісе, яны проста чакалі права прынады. Гэта праўда, што наступнае абмеркаванне заняло больш часу, чым гэта было б, калі б мы трымалі размова сам-насам, але яны былі настолькі значна больш прадуктыўным, што гэта варта дадатковага часу.

Без змяншэнні ў руку-размахваючы абагульненняў, як "група заўсёды разумнейшыя, чым асобныя" (мы ўсё сустрэліся досыць груп, каб ведаць лепш), то варта прызнаць, што існуюць пэўныя віды дзейнасці, на якім групы Excel. Massive калегіяльнага агляду з'яўляецца адным з іх; генерацыі вялікай колькасці ідэй хутка гэта зусім іншае. Якасць ідэй залежыць ад якасці мыслення, якія ўвайшлі ў іх, вядома, але вы не будзеце ведаць, якія мысляры там пакуль вы будзеце стымуляваць іх складанай задачай.

Натуральна, Ёсць некаторыя дыскусіі, якія павінны мецца ў прыватным парадку, у гэтай кнізе мы разгледзім прыклады з іх. Але прынцып павінен быць заўсёды: Калі няма ніякіх прычын для таго, каб быць закрытым, ён павінен быць публічным.

Стварэнне гэтай мэты патрабуе дзеянняў. Гэта не дастаткова проста забяспечыць, каб усе вашы ўласныя паведамленні Вярнуцца ў публічны спіс. Вы таксама павінны падштурхнуць іншых людзей залішне прыватных гутарках ў спіс занадта. Калі хтосьці спрабуе пачаць прыватнай гутарцы, і няма ніякіх прычын для таго, каб быць прыватнымі, то гэта ўскладаецца на Вас, каб адкрыць адпаведны мэта-дыскусія адразу. І нават не каментаваць першапачатковай тэме, пакуль вы альбо паспяхова кіраваў размова на грамадскае месца, або ўстаноўлена, што прыватная жыццё сапраўды была неабходная. Калі вы робіце гэта ўвесь час, людзі будуць лавіць на даволі хутка, і пачаць выкарыстоўваць грамадскія форумы па змаўчанні.

З самага пачатку грамадскага існавання вашага праекта, вы павінны падтрымліваць палітыку абсалютнай нецярпімасці да грубым або абразлівым паводзінамі ў форумах. Нулявой цярпімасці "не азначае, тэхнічных органаў як такіх. Вы не павінны выдаляць людзей з спісу рассылкі, калі яны полымя іншага абанента, або забраць iх учынення доступ, таму што яны зроблены прыніжальных каментары. (У тэорыі, Вы ў канчатковым выніку можа звяртацца да такіх дзеянняў, але толькі пасля выканання ўсіх іншых напрамкаў не атрымалася, якая, па вызначэнні, гэта не так у пачатку праекта.) Нулявы цярпімасці "проста азначае, ніколі не дазваляючы дрэннае паводзіны слайд неўзаметку. Напрыклад, калі хто-то паведамленні тэхнічнай каментар змешаных разам з прадузятасці атакі аб'яваў на некаторых іншых распрацоўнікаў у праекце, вельмі важна, каб ваш адказ адрас прадузятасці атакі аб'яў па-першае, у якасці асобнага пытання да сябе, і толькі потым пераходзіць да тэхнічнага ўтрымання.

Гэта, на жаль, вельмі лёгка, і занадта тыповая, для канструктыўнага абмеркавання запасці ў разбуральных войнаў полымя. Людзі будуць казаць рэчы, у электроннай пошце, што яны ніколі не сказаў бы тварам да асобе. Тэмамі абмеркавання толькі ўзмацняюць гэты эфект: у тэхнічных пытаннях, людзі часта адчуваю, што ёсць адзін правільны адказ на большасць пытанняў, і, што нязгоду з такой адказ можа быць растлумачана толькі невуцтва або глупства. Гэта недалёка ад выкліку тэхнічнае прапанову хто-то дурное выкліку чалавек сябе дурное. На самай справе, часта цяжка сказаць, дзе тэхнічныя абмеркавання лісце і характар ??прыступ пачынаецца, якая з'яўляецца адной з прычын рэзкага адказаў або пакарання не добрая ідэя. Замест гэтага, калі вы думаеце, вы бачыце гэта адбываецца, зрабіць паведамленне, што падкрэслівае важнасць захавання дружалюбных абмеркавання, не абвінавачваючы хто-небудзь з наўмысна атрутныя. Такія "Добры паліцэйскі" паведамленні маюць тэндэнцыю да няшчасных гучаць як выхавальніца дзіцячага сада лекцыі класа на добрае паводзіны:

Як высакапышнымі як такі гук адказы, яны маюць прыкметны ўплыў. Калі вы стала выклікаць дрэннае паводзіны, але не патрабуюць выбачэнняў або пацверджанне ад парушальніка, то вы пакідаеце людзей бясплатна, каб астыць і паказаць сваю лепшы бок ад сябе больш прыстойна наступны раз і яны будуць. Адзін з сакрэтаў робіць гэта паспяхова гэта ніколі не зрабіць мета-абмеркаванне асноўнай тэмы. Ён заўсёды павінен быць у бок, кароткае прадмову да асноўнай часткі вашага адказу. Пакажыце, дарэчы, што "мы не будзем рабіць тое, што шлях дзесьці тут", але затым перайсці да рэальных зместам, так што вы даяце людзям нешта на тэму, каб адказаць. Калі хто-то пратэстуе, што яны не заслугоўваюць вашага папрок, проста адмаўляюцца быць ўцягнутым у спрэчку пра яе. Альбо не адказваюць (калі вы думаеце, што яны проста выпуск пара і не патрабуюць адказу), або кажаце, што вы прабачце, калі вы занадта востра, і што гэта цяжка выявіць нюанс ў лісце, а затым вярнуцца да асноўнай тэмы. Ніколі, ніколі не настойваць на прызнанні, будзь то дзяржаўныя ці прыватныя, ад каго-тое, што яны паводзілі сябе непрыстойным чынам. Калі яны выбіраюць па ўласным жаданні з пасады выбачэнні, што гэта выдатна, але патрабуе, каб яны робяць гэта толькі выкліча абурэньне.

Агульная мэта заключаецца, каб зрабіць добрага тону разглядаць як адзін з "у групе" паводзін. Гэта дапамагае праекта, так як распрацоўнікі могуць быць выгнаныя (нават з праектаў, якія яны, як і вы хочаце падтрымаць) ад полымя вайны. Вы можаце нават не ведаць, што яны былі выгнаныя, хто-то можа хавацца на спіс рассылкі, бачым, што ён прымае тоўстую скуру, каб удзельнічаць у праекце, і прыняць рашэнне ў дачыненні ўцягнутыя на ўсіх. Захаванне дружалюбных форумах з'яўляецца доўгатэрміновай стратэгіяй выжывання, і гэта лягчэй зрабіць, калі праект яшчэ малая. Як толькі гэта частка культуры, вы не павінны быць адзіным чалавекам, яго папулярызацыі. Яна будзе падтрымлівацца ўсімі.

Адзін з лепшых спосабаў для садзейнічання прадуктыўнай развіцця суполак, каб атрымаць людзі, гледзячы на ??код адзін аднаго. Некаторыя тэхнічнай інфраструктуры і павінен быў зрабіць гэта эфектыўна, у прыватнасці, здзейсніць электроннай пошты павінен быць уключаны, гл раздзел "Commit электронную пошту" для больш падрабязнай інфармацыі. Эфект фіксацыі паведамленні ў тым, што кожны раз, калі хто-то фіксуе змены ў зыходны код, электронная пошта выходзіць паказаны часопіс паведамленняў і адрозненні для змены (гл. змяненняў, у раздзеле "Упраўленне версіямі слоўніка" ). кодэкса агляд Практыка разгляду здзейсніць электронную пошту па меры іх паступлення, шукае памылкі і магчымыя паляпшэння. ^{[ 11 ]}

Агляд кода служыць некалькім мэтам адначасова. Гэта найбольш відавочны прыклад калегіяльнага агляду ў свеце адкрытага зыходнага кода, так і непасрэдна спрыяе падтрыманню якасці праграмнага забеспячэння. Кожная памылка, судоў у частцы праграмнага забеспячэння, атрымаў там здзяйсняюцца і не выяўлена, таму, чым больш вочы глядзець здзяйсняе менш памылак будзе пастаўляцца. Але код аглядзе таксама служыць ўскосным мэты: ён пацвярджае, што для людзей, што яны робяць пытанні, таму што, відавочна, не спатрэбіцца час для разгляду здзейсніць калі не клапаціўся пра яго эфектыўнасці. Людзі свае лепшыя працы, калі яны ведаюць, што іншыя будуць марнаваць час на яго ацэнкі.

Водгукі павінны быць публічнымі. Нават у выпадках, калі я сядзеў у той жа фізічнай пакой з распрацоўшчыкамі, і адзін з нас зрабіў здзейсніць, мы клапоцімся не рабіць агляд вусна ў пакой, але каб адправіць яго ў спіс рассылкі замест развіцця. Кожны здабывае карысць, бачачы агляд здарыцца. Людзі ідуць каментары, а часам і знайсці недахопы ў ім, і нават калі яны не робяць, яна па-ранейшаму нагадвае ім, што агляд і чакалася, дзейнасць на рэгулярнай аснове, як мыццё посуду або траўніка.

У праекце Subversion, мы спачатку не зрабіць рэгулярнай практыку кода. Існаваў ніякай гарантыі, што кожны робіць будзе разгледжаны, хоць можна было б часам глядзець на змены, калі адзін быў асабліва зацікаўлены ў гэтай галіне кода. Памылкі ў паслізнуўся, якія сапраўды маглі б і павінны былі злоўленыя. Распрацоўшчык імя Грег Штэйн, які ведаў значэнне праверкі кода з мінулых работ, вырашылі, што ён збіраецца падаць прыклад шляхам аналізу кожнай лініі кожны робіць, якія ўвайшлі ў рэпазітар. Кожны робіць любы зроблена неўзабаве рушыла ўслед электроннай пошты да спісу распрацоўшчыкаў ад Грега, рассякаючы здзяйсняюць, аналіз магчымых праблем, а часам і хваліў разумны кавалак кода. Зараз, ён лавіў памылак і неоптимальных практыкі кадавання, якія інакш былі незаўважна, нават не быўшы заўважаным. Падкрэслена, ён ніколі не скардзіліся, што іх адзіны чалавек разглядзе кожнай фіксацыі, нават калі ён прыняў ладная колькасць свайго часу, але ён апяваць праверкі кода, калі ён быў шанец. Даволі хутка, іншыя людзі, уключаючы мяне, пачаў разгляд здзяйсняе рэгулярна таксама. Што наша матывацыя? Гэта было не тое, што Грег свядома сароміць нас у гэтым. Але ён даказаў, што пры разглядзе код каштоўнай спосаб правесці час, і што можна было б унесці максімальна ў праект па аналізе змяненняў аднаго як на напісанні новага кода. Аднойчы ён паказаў, што, стала чаканае паводзіны, да кропкі, дзе любы здзяйсненне гэтага не атрымаць рэакцыю выкліча коммиттер турбавацца, і нават задаць пытанне ў спіс Ці хто-небудзь меў магчымасці разгледзець яго яшчэ. Пазней, Грег атрымаў працу, якая не пакідала яго, як шмат часу для Subversion, і быў вымушаны спыніць рабіць рэгулярныя агляды. Але да таго часу, звычка была настолькі ўкаранілася для астатніх з нас, што здаецца, што яна ідзе з спрадвечных часоў.

Пачынайце рабіць водгукаў першых фіксацыі. Роду праблемы, якія лягчэй за ўсё злавіць на разглядзе адрозненняў з'яўляюцца уразлівасці бяспекі, уцечкі памяці, недастаткова каментары ці API дакументацыю, з па адной памылкі, які выклікае / выкліканага неадпаведнасці дысцыпліны, а таксама іншыя праблемы, якія патрабуюць мінімум навакольны кантэкст, каб пляма. Аднак, нават буйнамаштабныя такія пытанні, як адмова Анатацыя паўтаральных участкаў у адным месцы стала spottable пасля аднаго рабіў водгукаў рэгулярна, таму што памяць аб мінулых параўнанні паведамляе агляд цяперашні адрозненняў.

Не хвалюйцеся, што вы не маглі б знайсці што-небудзь пракаментаваць, ці што вы не ведаеце дастаткова аб кожнай вобласці кода. Там, як правіла, што-небудзь сказаць пра амаль кожнай фіксацыі; нават там, дзе вы не знойдзеце нічога, каб пытанне, вы можаце знайсці што-то пахваліць. Важна, каб даць зразумець кожнаму коммиттер, што яны робяць, гэта бачыў і разумеў. Вядома, праверкі кода не вызваляе праграмістаў адказнасць за агляд і тэст іх змены да здзяйснення; ніхто не павінен залежаць ад праверкі кода злавіць тое, што ён павінен быў злоўлены на сваю ўласную.

Калі вы адкрыццё існуючага праекта, які ўжо ёсць актыўныя распрацоўшчыкі прывыклі працаваць у асяроддзі з зачыненым зыходным кодам, пераканайцеся, што ўсе разумеюць, што вялікія змены станаўлення і пераканайцеся, што вы разумееце, як гэта будзе адчуваць ад іх пункту гледжання.

Паспрабуйце ўявіць сабе, як выглядае сітуацыя з імі: раней, увесь код і дызайн рашэнні былі прынятыя з групай іншых праграмістаў, якія ведалі, праграмнае забеспячэнне больш-менш аднолькава добра, якія атрымоўвалі жа ціск з таго ж кіравання, і хто ўсё ведаем, адзін аднаго, моцныя і слабыя бакі. Цяпер вы просіце іх, каб выставіць іх код праверкі выпадковых незнаёмцаў, хто будзе фармаваць меркаванні, заснаваныя толькі на код, без разумення таго, што бізнэс ціску, магчыма, вымушаныя пэўныя рашэнні. Гэтыя незнаёмцы будуць задаваць шмат пытанняў, пытанняў, якія выбіваюць існуючых распрацоўшчыкаў разумеючы, што ў дакументацыі яны скарэкціраваны так моцна за ўсё яшчэ застаюцца недастатковымі (гэта непазбежна). У давяршэнне да ўсяго, навічкі невядомыя, безаблічных асоб. Калі адзін з вашых распрацоўнікаў ужо адчувае сябе небяспечна аб сваіх навыкаў, уявіце сабе, як гэта будзе абвастрацца, калі навічкі адзначыць недахопы ў кодзе ён піша, і што яшчэ горш, зрабіць гэта на вачах у яго калегаў. Калі ў вас ёсць каманда дасканалых кодэры, гэта непазбежна ў самай справе, гэта, верагодна, здараецца з усімі з іх на першы погляд. Гэта не таму, што яны дрэнныя праграмісты, гэта проста, што любая праграма вышэй пэўнага памеру ўтрымлівае памылкі, і экспертнай ацэнкі будзе месца некаторыя з гэтых памылак (гл. раздзел пад назвай "Практыка паказная кодэкса агляд" раней у гэтай чале). У той жа час, навічкі самі па сабе не будзе прадметам шматлікіх экспертнай ацэнкі на першы, так як яны не могуць спрыяць код, пакуль яны больш знаёмыя з праектам. Для вашых распрацоўнікаў, ён можа адчуваць сябе, як і ўсе крытыкі ўваходныя, выходныя ніколі. Такім чынам, існуе небяспека аблогі менталітэт узяўшы сярод старых рукі.

Лепшы спосаб прадухіліць гэта, каб папярэдзіць кожнага аб тым, што ідзе, гэта растлумачыць, сказаць ім, што пачатковы дыскамфорт цалкам нармальна, і пераканаць іх, што гэта будзе лепш. Некаторыя з гэтых папярэджанняў павінны праводзіцца ў прыватным парадку, перш чым праект адчынены. Але вы таксама можаце знайсці карысным, каб нагадаць людзям пра грамадскасці спісы, што гэта новы шлях развіцця для праекта, і што гэта зойме некаторы час, каб прыстасавацца. Самае лепшае, што вы можаце зрабіць, гэта прывесці прыклад. Калі вы не бачыце вашы распрацоўшчыкі адказу досыць пачаткоўца пытанні, то проста кажу, каб яны адказалі больш не дапаможа. Яны не могуць мець добрае пачуццё, што ордэра адказ, а што няма яшчэ, ці гэта можа быць, што яны не маюць пачуццё для ўстанаўлення прыярытэтаў для кадавання працаваць супраць новага цяжару знешняй сувязі. Спосаб атрымаць іх для ўдзелу з'яўляецца ўдзел самастойна. Будзьце на агульнадаступных паштовых рассылак, і пераканайцеся, што адказаць на некаторыя пытанні ёсць. Калі ў вас няма вопыту на месцах пытанне, то відавочна рукі яго да распрацоўніку, які робіць і глядзець, каб пераканацца, што ён варта з адказам, або па крайняй меры адказ. Гэта, натуральна, будзе спакуса для даўні распрацоўшчыкаў ўпасьці ў прыватных гутарках, так гэта тое, што яны прызвычаіліся. Пераканайцеся, што вы падпісаныя на ўнутраныя спісы рассылання, на якім гэта можа адбыцца, так што вы можаце папрасіць, каб такія дыскусіі перанесці ў публічныя спісы адразу.

Ёсць і іншыя, больш доўгатэрміновыя праблемы з адкрыццём раней закрытых праектаў. кіраўнік 5, грошы даследуе спосабы для змешвання аплачваецца і неаплатны распрацоўшчыкі паспяхова, і ў частцы 9, ліцэнзіі, аўтарскія правы і патэнты абмяркоўвае неабходнасць прававога абачлівасці пры адкрыцці прыватнага коду, які можа ўтрымоўваць праграмнае забеспячэнне, напісанае ці "належаць" іншых бакоў.

Між тым, калі гэтая фраза была напісана і пасля яго публікацыі, Інтэрнэт-шырокая праблема спаму будзе, верагодна, падвоіцца ў сур'ёзнасці або, па крайняй меры, ён будзе адчуваць сябе такім чынам. Быў момант, не так даўно, калі можна было запусціць спіс рассылкі без прыняцця якіх-небудзь спам-прафілактычных мер на ўсіх. Выпадковыя вандроўных паведамленне будзе па-ранейшаму з'яўляюцца, але рэдка, каб ён быў толькі нізкім узроўнем раздражненне. Гэтая эпоха сышла назаўсёды. Сёння, спіс рассылкі, які не прымае меры па прадухіленні спаму хутка апускаецца ў непажаданай электроннай пошты, каб кропка unusability. Абарона ад спаму з'яўляецца абавязковым.

Разаб'ем спаму на дзве катэгорыі: прадухіленне спаму паведамленні ад з'яўлення на вашых спісаў рассылання, а таксама прадухіленне спісу рассылання ад крыніцы новых адрасоў электроннай пошты для камбайнаў спамераў. Першае з'яўляецца больш важным, таму мы разглядаем гэта ў першую чаргу.

Спіс абанентаў часта хочуць, каб пакласці пошту з спісу ў канкрэтных праектаў папкі, асобна ад іншых сваіх пошце. Іх чытання пошты праграмнае забеспячэнне можа зрабіць гэта аўтаматычна шляхам вывучэння паштовага загалоўкі. Загалоўкі палёў у верхняй частцы пошты, якія паказваюць адпраўнік, атрымальнік, тэма, дата, і розныя іншыя рэчы пра паведамленні. Некаторыя загалоўкі добра вядомыя і эфектыўна абавязковым:

Ад:...
Каму:...
Тэма:...
Дата:...

Іншыя з'яўляюцца неабавязковымі, хоць яшчэ зусім стандартныя. Напрыклад, электронныя лісты не з'яўляюцца строга абавязаны мець

Адказ на: sender@email.address.here

загалоўка, але большасць з іх, таму што гэта дае атрымальнікам бяспечны спосаб дасягнуць аўтара (гэта асабліва карысна, калі аўтар быў вымушаны адправіць з адрасы, чым той, да якога адказы павінны быць накіраваны).

Некаторыя паштовыя чытання праграмнае забеспячэнне прапануе просты ў выкарыстанні інтэрфейс для падачы лісты на аснове шаблонаў ў загалоўку. Гэта прыводзіць людзей прасіць, каб спіс рассылкі дадаць аўтаматычнага прэфікса для ўсіх суб'ектаў, таму яны могуць усталёўваць свае чытачам шукаць для гэтага прэфікса і аўтаматычна файл лісты ў патрэбную папку. Ідэя ў тым, што аўтару варта напісаць:

Тэма: Стварэнне 2,5 рэлізе.

але пошты будзе адлюстроўвацца ў спісе выгляду:

Тэма: [discuss@lists.example.org] унясенні 2,5 рэлізе.

Хоць вялікая частка праграмнага забеспячэння кіравання спісам прапануе магчымасць зрабіць гэта, я настойліва рэкамендую супраць ператварэння опцыі. Праблемы яна вырашае можа быць лёгка вырашана ў значна менш дакучлівай спосабамі, і выдаткі на харчаванне прасторы ў полі "Тэма" з'яўляецца занадта высокай. Дасведчаныя карыстальнікі спіс рассылкі звычайна праверкі суб'ектаў уваходнай пошты спісу дзень, каб вырашыць, што чытаць і / або адказаць. Предварение імя спісу да аб'екта, націснуць на правы бок Тэма з экрана, што робіць яго нябачным. Гэта хавае інфармацыю, што людзі залежаць ад вырашыць, што лісты, каб адкрыць, тым самым памяншаючы агульную функцыянальнасць спісу рассылання для ўсіх.

Замест munging загалоўку, навучыць карыстальнікаў выкарыстоўваць іншыя стандартныя загалоўкі, пачынаючы з у загаловак, які павінен сказаць, назва рассылкі:

Каму: <discuss@lists.example.org>

Любы паштовы кліент з магчымасцю фільтрацыі па тэме павінны быць у стане фільтра на такой жа лёгкасцю.

Ёсць некалькі іншых неабавязковых, але-стандартныя загалоўкі чаканых для складання спісаў рассылання. Фільтраванне па гэтым яшчэ больш надзейным, чым выкарыстанне "Каму" ці "Копія" загалоўкі, так як гэтыя загалоўкі дададзеныя да кожнай пасады па кіраванні спіс рассылкі само праграмнае забеспячэнне, некаторыя карыстальнікі могуць разлічваць на іх прысутнасць:

Спіс-Help: <mailto:discuss-help@lists.example.org>
Спіс-адпісацца: <mailto:discuss-unsubscribe@lists.example.org>
спіс з пасадамі: <mailto:discuss@lists.example.org>
Delivered-To: спіс рассылкі discuss@lists.example.org
Спіс рассылкі: кантакт discuss-help@lists.example.org; вядзенні ezmlm

Па большай частцы, яны гавораць самі за сябе. Глядзіце http://www.nisto.com/listspec/list-manager-intro.html для больш падрабязнага тлумачэння, ці, калі вам трэба сапраўды падрабязна, фармальнай спецыфікацыі, гл http://www.faqs.org/rfcs/rfc2369. HTML.

Заўважце, як гэтыя загалоўкі вынікае, што калі ў вас ёсць спіс рассылкі з імем "спіс", то ў Вас таксама ёсць адміністрацыйныя адрасы "спіс-Help" і "Спіс-адпісацца" даступныя. У дадатак да гэтых, гэта нармальна, каб "спіс-падпісацца", для злучэння, і "Спіс-ўладальніка", для дасягнення спіс адміністратараў. У залежнасці ад праграмнага забеспячэння для кіравання спісам вы выкарыстоўваеце гэтыя і / або розныя іншыя адміністрацыйныя адрасы могуць быць створаны; дакументацыя будзе атрымаць падрабязную інфармацыю. Звычайна поўнае тлумачэнне ўсіх гэтых спецыяльных адрасоў адпраўляецца кожнаму новаму карыстальніку як частка аўтаматызаванай "Сардэчна запрашаем пошты" на падпісцы. Вы самі, верагодна, атрымаць копію гэтага вітаем пошце. Калі ў вас няма, то папрасіць каго-небудзь для копіі, так што вы ведаеце, што карыстальнікі бачаць, калі яны далучыцца да спісу. Захоўвайце копіі зручны так што вы можаце адказаць на пытанні аб функцыях спіс рассылкі, або яшчэ лепш, пастаўце яго на вэб-старонцы недзе. Такім чынам, калі людзі губляюць сваю ўласную копію інструкцыі і пасля спытаць: "Як я магу адмовіцца ад гэтага спісу?", Вы можаце проста перадаць іх URL.

Некаторыя праграмы рассылкі прапануе опцыю дадання адпіску інструкцыі да ніжняй частцы кожнага паведамлення. Калі гэтая опцыя даступная, уключыце яго. Гэта выклікае толькі некалькі дадатковых радкоў у паведамленні, у бясшкодныя месцы, і яна можа захаваць вам шмат часу, за кошт скарачэння колькасці людзей, пошты ці горш, паштовы спіс!-Пытаюць, як адмовіцца ад падпіскі.

Раней, у раздзеле "Пазбягайце прыватных гутарках", я падкрэсліў важнасць пераканаўшыся абмеркавання знаходжанне ў грамадскіх форумах, і казалі пра тое, як актыўныя меры часам неабходныя для прадухілення гутарак з задняй у прыватныя электроннай пошты тэмы, акрамя таго, гэтая кіраўнік Аб стварэнні праекта камунікацыйнае праграмнае забеспячэнне, каб зрабіць так шмат працы для вас, як гэта магчыма. Таму, калі кіраванне рассылку праграмнае забеспячэнне прапануе спосаб аўтаматычна выклікаюць дыскусіі, каб застацца на спіс, вы павінны думаць, што паварот функцыю будзе відавочным выбарам.

Ну, не зусім. Існуе такая асаблівасць, але яна мае некалькі даволі сур'ёзных перашкод. Пытанне аб тым, выкарыстоўваць ці не выкарыстоўваць гэта адна з самых гарачых дэбатаў у спісе рассылання кіравання-праўда, не спрэчкі, якія, хутчэй за ўсё, каб у вячэрніх навінах у вашым горадзе, але яна можа ўспыхнуць час ад часу ў свабодных праграмных праектаў. Ніжэй я апішу функцыі, даць асноўныя довады абодвух бакоў, і зрабіць лепшай рэкамендацыяй я магу.

Функцыя сама па сабе вельмі простая: праграмнае забеспячэнне спісу рассылання можна, калі вы хочаце, аўтаматычна адказаць загаловак на кожны пост для перанакіравання адказаў на спіс рассылкі. Гэта значыць, незалежна ад таго, што адпраўнік змяшчае ў адказаць загаловак (або нават калі яны не ўключаюць у сябе адзін на ўсіх), да таго часу спіс абанентаў гл. паведамленне, загаловак будзе змяшчаць спіс адрасоў:

Адказ на: discuss@lists.example.org

На першы погляд, гэта здаецца добрай рэччу. Таму што практычна ўсе праграмнае забеспячэнне для паштовага чытанні звяртае ўвагу на адказ-у загаловак, цяпер, калі хто-небудзь у адказ на паведамленне, іх адказ будзе аўтаматычна імя ўвесь спіс, а не толькі для адпраўніка паведамлення час адказу. Вядома, адказчык можа ўручную змяняць, дзе ідзе паведамленне, але галоўнае, што па змаўчанні напрамкі адказаў у спіс. Гэта выдатны прыклад выкарыстання тэхналогіі заахвочваць супрацоўніцтва.

На жаль, Ёсць некаторыя недахопы. Першы вядомы як не можа знайсці дарогу назад Галоўная праблема: часам адпраўніку будзе пакласці іх "рэальны" адрас электроннай пошты ў адказ, да поля, таму што для той ці іншай прычыне яны адпраўляюць электронную пошту з іншага адрасы, чым дзе яны яго атрымліваюць. Людзі, якія заўсёды чытаць і адпраўляць з таго ж месца не маюць гэтай праблемы, і можаце быць здзіўлены, што ён наогул існуе. Але для тых, хто незвычайных канфігурацый электроннай пошце, або хто не можа кантраляваць тое, як з адрасам на іх лісты выглядае (магчыма, таму што яны пасылаюць на працу і не маюць ніякага ўплыву на ІТ-аддзел), выкарыстоўваючы для адказу можа быць толькі, як яны павінны гарантаваць, што адказы іх дасягнення. Калі такі чалавек паведамленняў у спіс рассылкі, што ён не падпісаўся на яго ўстаноўку для адказу становіцца істотнай інфармацыі. Калі спіс праграмнага забеспячэння перапісвае яго, ён ніколі не можаце ўбачыць адказы на свой пост.

Другі недахоп звязаны з чаканнямі, і на мой погляд, самы магутны аргумент супраць Адказ на munging. Большасць дасведчаных карыстальнікаў пошты прывыклі да двух асноўных метадаў адказу: адказ да ўсіх і адказаць да аўтару. Усё сучаснае праграмнае забеспячэнне чытання пошты мае асобныя клавішы для гэтых двух дзеянняў. Карыстальнікі ведаюць, што адказаць на ўсе (гэта значыць, у тым ліку спіс), яны павінны выбраць для адказу-ўсё, і адказаць у прыватным парадку аўтара, яны павінны выбраць для адказу-аўтара. Хаця вы хочаце, каб заахвочваць людзей, каб адказаць на спіс па меры магчымасці, Ёсць, безумоўна, абставіны, пры якіх прыватныя адказ адказвае прэрагатывай, напрыклад, яны хочуць сказаць што-то канфідэнцыйнай аўтара арыгінальнага паведамлення, то, што было б недарэчна на публічны спіс.

Зараз разгледзім, што адбываецца, калі спіс пераазначэнне арыгінальны адпраўніка для адказу. Адказчык хіты для адказу ключавыя аўтара, разлічваючы адправіць асабістае паведамленне Вярнуцца да аўтару. Таму што гэта чаканае паводзіны, ён не можа турбаваць паглядзець уважліва на адрас атрымальніка ў новае паведамленне. Ён складае яго асабістай, канфідэнцыйнай паведамленне, якое, магчыма, кажа якія зводзяць рэчаў пра каго-то ў спісе, і хіты адправіць ключ. Нечакана, праз некалькі хвілін яго паведамленне з'яўляецца на рассылку! Праўда, у тэорыі ён павінен быў ўважліва паглядзеў на поле атрымальніка, і не павінны лічыць нічога адказаць загаловак. Але аўтары амаль заўсёды ўстанаўліваецца для адказу на свае асабістыя адрасы (ці, хутчэй, да сваёй пошце праграмнага забеспячэння ўсталёўвае яго для іх), і шматлікія даўнія карыстальнікі электроннай пошты павінны чакаць, што. На самай справе, калі чалавек свядома наборы для адказу на некаторыя іншыя адрасы, такія як спіс, ён звычайна робіць пункту згадваючы аб гэтым у целе паведамлення, каб людзі не будуць здзіўлены тым, што адбываецца, калі яны адказваюць.

З-за магчымасці сур'ёзных наступстваў гэтага нечаканага паводзінаў, мае ўласныя перавагі для наладкі праграмнага забеспячэння кіравання спісам, каб ніколі не дакранацца да адказ-у загаловак. Гэта адзін выпадак, калі з выкарыстаннем тэхналогіі заахвочваць супрацоўніцтва мае, як мне здаецца, патэнцыйна небяспечных пабочных эфектаў. Аднак Ёсць таксама некаторыя магутныя аргументы іншага боку ў гэтым спрэчцы. Які б спосаб вы ні выбралі, вы будзеце часам атрымаць людзей, якія адпраўляюць у спіс пытаюцца, чаму вы не выбралі іншы шлях. Паколькі гэта не тое, што вы калі-небудзь захочаце ў якасці асноўнай тэмай абмеркавання ў вашым спісе, гэта можа быць добра мець гатовы адказ гатовы, з тых, што больш верагодна, каб спыніць абмеркаванне, чым заахвочваць яго. Пераканайцеся, што вы не настойваю, што ваша рашэнне, якой бы ні гэта, відавочна, адзіна правільны і разумны (нават калі вы думаеце, што гэта справа). Замест гэтага, адзначаюць, што гэта вельмі стары спрэчка, Ёсць добрыя аргументы абодвух бакоў, няма іншага выбару, збіраецца задаволіць усіх карыстачоў, і, такім чынам, вы толькі што зрабілі лепшае рашэнне, якое вы маглі. Ветліва просяць, што прадмет не быць перагледжаныя, калі хто-небудзь што-то сапраўды новае, каб сказаць, то заставацца ў баку ад патоку і спадзяюся, што ён памірае натуральнай смерцю.

Хтосьці можа прапанаваць галасавання выбраць тую ці іншую. Вы можаце зрабіць гэта, калі вы хочаце, але асабіста я не адчуваю, што падлік галовак здавальняючы рашэнне ў гэтым выпадку. Штраф для тых, хто здзіўлены паводзінамі настолькі вялікі (выпадкова адправіць яму асабістае пошце публічны спіс), і нязручнасці для ўсіх астатніх гэта даволі невялікае (часам таго, каб нагадаць хто-то рэагаваць на ўвесь спіс, а не толькі да вы), што гэта не ясна, што большасць, нават калі яны з'яўляюцца большасцю, павінны быць у стане забяспечыць меншасцяў на такую ??рызыку.

Я не разгледжаны ўсе аспекты гэтага пытання тут, толькі тыя, якія, здавалася першараднае значэнне. Для ўсебаковага абмеркавання, убачыць гэтыя дзве кананічныя дакументы, якія тыя людзі заўсёды спасылаюцца, калі яны з гэтай дыскусіі:

Нягледзячы на мяккі перавагі, названых вышэй, я не адчуваю, што ёсць "правільны" адказ на гэтае пытанне, і з задавальненнем прымаюць удзел у многіх спісах, якія набор для адказу. Самая важная рэч вы можаце зрабіць, гэта спыніцца на той ці іншы рана, і паспрабуйце не заблытацца ў дэбатах аб гэтым пасля гэтага.

Падрабязная тэхнічная інфармацыя аб стварэнні спісу рассылання архівавання з'яўляюцца спецыфічнымі для праграмнага забеспячэння, якое працуе спіс, і выходзяць за рамкі гэтай кнігі. Пры выбары і наладзе архіватара, разгледзець гэтыя якасці:

Вышэй, з'яўляецца толькі тэхнічным кантрольны спіс, каб дапамагчы вам ацаніць і ўсталяваць архіватар. Як людзі на самай справе выкарыстаць архіватара праекта перавага абмяркоўваецца ў наступных раздзелах, у прыватнасці раздзел пад назвай "Прыкметнае выкарыстанне архіваў".

Вось некаторыя адкрытым зыходным кодам для вядзення спісу кіравання і архівавання. Калі сайт, дзе вы размяшчае ваш праект ужо мае налады па змаўчанні, то вы ніколі не можаце прыняць рашэнне аб інструментам на ўсіх. Але калі вы павінны ўсталяваць яго самастойна, гэта толькі некаторыя магчымасці. Тыя, якія я на самай справе выкарыстоўваюцца Mailman, Ezmlm, MHonArc, і Hypermail, але гэта не значыць, іншыя не занадта добрая (і, вядома, Ёсць, верагодна, іншых інструментаў, якія я проста не здарылася, каб знайсці, таму не прымайце гэта як поўны спіс).

Рассылка праграмнае забеспячэнне для кіравання:

Архівы рассылкі праграмнае забеспячэнне:

Гэтая кніга не можа навучыць вас, як выкарыстоўваць сістэму кіравання версіямі, калі вы ніколі не выкарыстоўваў яго раней, але гэта было б немагчыма абмяркоўваць гэтую тэму без некалькіх ключавых тэрмінаў. Гэтыя тэрміны, якія выкарыстоўваюцца незалежна ад якой-небудзь канкрэтнай сістэмы кіравання версіямі: яны з'яўляюцца асноўнымі назоўнікаў і дзеясловаў сеткавым супрацоўніцтве, і будзе выкарыстоўвацца агульным ўсёй астатняй частцы гэтай кнігі. Нават калі б не было сістэм кантролю версій у свеце, праблемы змянення кіравання будзе заставацца, і гэтыя словы даюць нам мова для размовы аб тым, што праблема лаканічна.