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

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

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

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

Памятайце, што патэнцыял для відэльцы ідзе ў абодвух напрамках. BD можа відэльцам праекта так жа лёгка, як ніхто іншы, і некаторыя з іх час ад часу зрабілі, калі яны адчувалі, што кірунак яны хацелі б прыняць праект адрозніваецца ад, дзе большасць іншых распрацоўшчыкаў хацеў ісці. З-за forkability, не мае значэння, будзь добразычлівым дыктатар корань (правамі сістэмнага адміністратара) на галоўнай праекта сервераў ці няма. Людзі часам кажуць аб серверны элемент кіравання, як калі б гэта было асноўнай крыніцай улады ў праекце, але на самой справе гэта не мае значэння. Магчымасць дадаць ці выдаліць здзейсніць паролі людзей на адным пэўным сэрвэры ўплывае толькі копію праекта, які знаходзіцца на гэтым сэрверы. Доўгі злоўжыванне, што ўлада, будзь то BD ці хто-небудзь яшчэ, проста прывесці да развіцця пераходу на іншы сервер.

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

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

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

Непазбежна, некаторыя дэбаты проста не будзе кансенсусу. Калі ўсе іншыя сродкі парушэнні ў тупік не атрымалася, рашэнне, каб прагаласаваць. Але да галасавання можа быць прынята, павінна быць ясна, што выбар на галасаванні. Тут, зноў жа, нармальны працэс абмеркавання тэхнічных сумесяў шчаслівай выпадковасці з працэдурамі прыняцця рашэнняў праекта. Віды пытанняў якія прыходзяць на галасаванне часцяком патрабуецца комплекснае, шматграннае пытанняў. У любым такія складаныя абмеркавання, як правіла Ёсць адзін ці два чалавека гуляць ролю сумленнага пасярэдніка: размяшчэнне перыядычных рэзюмэ розныя аргументы і адсочваць, дзе асноўныя пункты разыходжанні (і пагаднення) ляжаць. Гэтыя рэзюмэ дапамагчы ўсім меру, які прагрэс быў дасягнуты, і нагадаць усім аб тым, што пытанні яшчэ трэба вырашыць. Тыя ж рэзюмэ можа служыць у якасці прататыпаў для галасавання ліст, павінны прагаласаваць стане неабходным. Калі сапраўды брокераў рабілі сваю працу добра, яны будуць мець магчымасць дакладна заклік прагаласаваць, калі прыйдзе час, і група будзе гатовая выкарыстаць галасаванне ліста на аснове іх рэзюмэ пытанняў. Брокеры самі па сабе могуць быць ўдзельнікі дыскусіі, гэта не з'яўляецца неабходным для іх заставацца над сутычкай, да тых часоў, як яны могуць зразумець і справядліва прадстаўляць думкі іншых, і не дапусціць іх партызанскіх настрояў прадухіліць іх абагульненне стану абмеркавання у нейтральнай моды.

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

Не забудзьцеся пазначыць сістэме галасавання, як Ёсць шмат розных відаў, і людзі могуць зрабіць няправільныя здагадкі пра тое, якія працэдуры выкарыстоўваюцца. Добры выбар у большасці выпадкаў з'яўляецца зацвярджэнне галасавання, пры якой кожны выбаршчык можа галасаваць за, як многія з выбараў на галасаванне, як яму падабаецца. Сцвярджэнне галасавання проста растлумачыць, і лічыць, і ў адрозненне ад некаторых іншых метадаў, а толькі ўключае ў сябе адзін тур галасавання. Глядзіце http://en.wikipedia.org/wiki/Voting_system # List_of_systems для больш падрабязнай інфармацыі аб галасаванні зацвярджэння і іншыя сістэмы галасавання, але паспрабуйце не патрапіць ў доўгую спрэчку, аб якім сістэма галасавання для выкарыстання (таму што, вядома, вы будзеце то знайсці сябе ў дыскусіі аб якім сістэма галасавання выкарыстоўваць вырашыць сістэма галасавання!). Адна з прычын зацвярджэння галасавання з'яўляецца добрым выбарам у тым, што гэта вельмі цяжка для любога аб'екта-гэта аб якасці справядлівай сістэме галасавання могуць быць.

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

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

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

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

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

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

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

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

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

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

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

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

Вы можаце бачыць, што людзі пішуць "-1", каб выказаць вета. Гэта выкарыстанне паходзіць ад Apache Software Foundation, якая добра структураваны галасавання і права вета працэс, апісаны ў http://www.apache.org/foundation/voting.html . Apache стандарты распаўсюджваюцца на іншыя праекты, і вы ўбачыце іх ўмоўныя абазначэнні, якія выкарыстоўваюцца ў рознай ступені ў многіх месцах у свеце адкрытага зыходнага кода. Тэхнічна, "-1" не заўсёды азначае фармальнае вета нават па Apache стандартам, але неафіцыйна, як правіла, разумеецца права вета або, па крайняй меры вельмі моцныя пярэчанні.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Некаторы час праз, яны зрабілі яшчэ адно аб'ява. Вось што ён сказаў, з указаннем прозвішчы і нумар версіі замененыя псеўданімамі:

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

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

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

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

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

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

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

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

Адправіць пошту раўніне толькі тэкст, а не HTML, RichText, або іншых фарматах, якія могуць быць непразрыстымі ў тэкст толькі для чытачоў пошце. Фарматаванне ліній, каля 72 слупкоў доўга. Не перавышае 80 калон, які стаў стандартам дэ-факта шырыня тэрмінала (гэта значыць, некаторыя людзі могуць выкарыстоўваць больш шырокі тэрміналаў, але ніхто не выкарыстоўвае вузкі адзін). Робячы свае лініі крыху менш чым 80 слупкоў, пакінуць месца для некалькіх узроўняў цытаванні знакаў, якія будуць дададзеныя ў "іншых адказаў, не прымушаючы rewrapping тэксту.

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

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

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

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

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

Зрабіце рэчы лёгка для вашых чытачоў. Там у тону інфармацыі, якія цыркулююць у любой актыўнай праект з адкрытым кодам, і чытачы не могуць быць павінны быць знаёмыя з большасцю ІТ-У самай справе, яны не заўсёды могуць быць як чакаецца, ведаеце, як пазнаёміцца. Усюды, дзе магчыма, вашы паведамленні павінны ўтрымліваць інфармацыю ў форме, найбольш зручнай для чытачоў. Калі вам давядзецца выдаткаваць дадатковыя дзве хвіліны, каб выкапаць URL для пэўнага струменя ў архівах спісаў рассылання, у мэтах эканоміі вашых чытачоў праца Паступаючы такім чынам, яно таго варта. Калі вам давядзецца выдаткаваць дадатковыя 5 або 10 хвілін з кароткім выкладам высноў дагэтуль комплекснай ніткі, з тым каб даць людзям кантэкст, у якім, каб зразумець ваша паведамленне, то зрабіць гэта. Падумайце аб гэтым так: больш паспяховым праектам, тым вышэй чытача да пісьменніку адносіны ў тым ці іншым форуме. Калі кожнае паведамленне вы робіце разглядаецца N людзей, то пры п падвышаецца ў каштоўнасці чалавечага марнаваць дадатковыя намаганні, каб выратаваць тых людзей час паднімаецца з ім. І як людзі бачыць Вас ўвядзення гэтага стандарту на сябе, яны будуць працаваць, каб адпавядаць яго ў сваіх паведамленнях. У выніку, у ідэале, павелічэнне глабальнай эфектыўнасці праекта: калі ёсць выбар паміж п людзі прыкладаюць намаганні і адзін чалавек робіць так, праект аддае перавагу апошняе.

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

Тое ж настрой сапраўды становіцца мацней, калі фармулёўцы менш рэзка:

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

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

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

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

А таксама:

Якая версія Slash вы карыстаецеся? Я не магу сказаць з вашага
зыходнае паведамленне.

Сапраўды, як жа вы будуеце Apache / mod_perl крыніца?

Спрабавалі Ці вы Apache 2.0 патч, які быў размешчаны на о
slashcode.com?

  Шэйн

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

Ці будуць усе чытачы рэагуюць станоўча на гэты стыль? Не абавязкова, гэта залежыць ад чалавека і кантэксту. Напрыклад, калі хтосьці толькі што апублікавалі прызнаючы, што яна зрабіла памылку (магчыма, яна піша памылка), і вы ведаеце, з мінулага досведу, што гэты чалавек, як правіла, крыху небяспечным, то ў той час як вы ўсё роўна можаце напісаць кампактны адказ, вы павінны пераканайцеся, што закваска яго з нейкай прызнанне яе пачуцці. Асноўная частка вашага адказу можа быць кароткім, engineer's вачэй аналіз сітуацыі, як кароткім, як вы хочаце. Але ў канцы, выйсці з яго з чым-то аб тым, што ваш сцісласць не павінны быць прынятыя як халоднасць. Напрыклад, калі вы толькі што пачкаў парады, як менавіта чалавек павінен выправіць памылку, то падпісваць з "Поспехі, тут> <ваш імя", каб паказаць, што вы хочаце іх добра і не вар'ят. Стратэгічна смайлік ці іншых emoticlue часта можа быць дастаткова, каб супакоіць суразмоўцы, таксама.

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

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

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

Давайце пачнем з рэчаў, якія не груба:

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

Блант, без усялякіх упрыгожванняў пытанняў, такіх, як пытанні Шэйн мне ў раней цытуе электроннай пошце, не грубіяніць небудзь. Пытанні, якія ў іншых умовах можа здацца халоднай, рытарычнае, і нават насмешлівы, часта прызначаны сур'ёзна, і ніякай ўтоенай парадку дня, акрамя атрымання інфармацыі як мага хутчэй. Вядомы тэхнічнай падтрымкі пытанне "Ці з'яўляецца ваш кампутар падключаны? з'яўляецца класічным прыкладам гэтага. Падтрымка чалавек сапраўды трэба ведаць, калі ваш кампутар падключаны да сеткі, і пасля першых некалькіх дзён на працу, атрымаў стаміліся ад прэфікса яе пытанне з ветлівай ўгаворы ("Я прашу прабачэння, я проста хачу задаць некалькі простых пытанні, каб выключыць некаторыя магчымасці. Некаторыя з іх могуць здацца даволі просты, але, мядзведзь са мной ..."). На дадзены момант, яна не важдацца з абіўка больш, яна проста пытаецца прама: гэта падключаны ці не? Эквівалентныя пытанні задаюцца ўвесь час на бясплатныя спісы рассылання праграмнага забеспячэння. Мэтай з'яўляецца не абражаць атрымальніка, але хутка выключыць найбольш відавочным (і, магчыма, найбольш распаўсюджаны) тлумачэнні. Атрымальнікі, якія разумеюць гэта і рэагаваць адпаведным чынам выйграць кропкі для прыняцця шырокім кругаглядам прагляд без запыту. Але атрымальнікі, якія хваравіта рэагаваць не павінны быць звернута спагнанне, альбо. Гэта проста сутыкненне культур, а не нічыёй віны. Растлумачце прыязна, што Ваш пытанне (або крытыка) не мелі схаваны сэнс, а проста хацеў атрымаць (ці перадачы) інфармацыі як мага больш эфектыўна, не больш таго.

Так што груба?

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

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

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

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

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

Ад: "Карл Фогель" <kfogel@whateverdomain.com>

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

Ад: "Цуд-Хакер" <wonderhacker@whateverdomain.com>

Там у вядомага мультфільма Пол Штайнер, ад 5 Ліпень 1993 г. пытанне аб Нью-Ёрку, які паказвае адну сабаку ўвайсці ў кампутарны тэрмінал, гледзячы ўніз і кажа іншы змоўніцку: "У Інтэрнэце ніхто не ведае, што ты сабака. " Гэты выгляд думкі, верагодна, ляжыць у аснове шматлікіх самовозвеличенных, азначала-да-быць-хіп онлайн людзей тоеснасці даць сябе, як быццам называць сябе "Цуда-Хакер" на самай справе прымушае людзей верыць адзін выдатны хакера. Але факт застаецца фактам: нават калі ніхто не ведае, што ты сабака, вы ўсё яшчэ сабака. Фантастычных ідэнтычнасць ніколі не ўражвае чытачоў. Замест гэтага, ён прымушае іх думаць, вы больш ў малюнак, чым рэчывы, або, што вы проста небяспечна. Выкарыстоўваць сваё сапраўднае імя для ўсіх узаемадзеянняў, або калі па якой-небудзь прычыне вам патрабуецца ананімнасць, то прыдумайце імя, што гучыць як цалкам нармальнае сапраўднае імя, і выкарыстоўвайце яго пастаянна.

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

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

УВАГА!

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

Дадзенае паведамленне ад Deloitte & Touche LLP. Deloitte &
Touche LLP з'яўляецца таварыствам з абмежаванай адказнасцю, зарэгістраванага ў Англіі
і Ўэльсе з зарэгістраванымі OC303675 нумар. Спіс імёнаў членаў
даступная для агляду ў Стонкаттер суда, 1 Стонкаттер
Street, London EC4A 4TR, Злучанае Каралеўства, асноўнае месца фірмы з
бізнес і юрыдычны адрас. Deloitte & Touche LLP з'яўляецца
упаўнаважаных і рэгулюецца Упраўленнем па фінансавых паслуг.

Гэта паведамленне і любыя ўкладання ўтрымліваюць інфармацыю, якая
канфідэнцыйнымі і могуць быць прывілеяваным. Гэта для выключнага выкарыстання
ад атрымальніка (ы). Калі вы не прызначаных
атрымальнік (і) Калі ласка, звярніце ўвагу, што любая форма раскрыцця інфармацыі, распаўсюджванне,
Капіраванне або выкарыстанне гэтага паведамлення або інфармацыю ў ім або ў
любыя ўкладання строга забаронена і можа быць незаконным. Калі вы
атрымалі гэтае паведамленьне па памылку, калі ласка, вярніце яго з
Назва "атрымалі па памылцы" на deloitte.co.uk IT.SECURITY.UK @ затым выдаліце
адрас электроннай пошты і знішчыць усе копіі яго.

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

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

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

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

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

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

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

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

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

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

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

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

У той час як гэта добра:

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

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

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

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

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

Прынцып, згодна з якім колькасць абмеркавання зваротна прапарцыйная складанасці тэма была вакол на працягу доўгага часу, і неафіцыйна называюць Bikeshed эфект. Вось тлумачэнне Poul-Henning Kamp аб ім, ад цяпер знакамітае паведамленне апублікавана на BSD распрацоўнікаў:

(Поўны тэкст яго пасаду вельмі шмат варта чытаць, таксама бачу. Дадатак C, чаму я павінен турбавацца аб колеры Bikeshed ці што? ; гл. таксама http://bikeshed.com .)

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

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

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

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

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

Так як жа вы спраўляецеся свяшчэнных войнаў?

Першы адказ, паспрабуйце ўсталяваць рэчы, каб яны не адбудзецца. Гэта не так безнадзейна, як здаецца:

Вы можаце прадбачыць некаторыя стандартныя свяшчэнных войнаў: яны, як правіла, каб прыдумаць больш моў праграмавання, ліцэнзій (гл. раздзел "GPL і ліцэнзіі сумяшчальнасці" у чале 9, ліцэнзіі, аўтарскія правы і патэнты ), для адказу munging (гл. раздзел называюць "Вялікай Адказ на дэбаты" ў раздзеле 3, тэхнічная інфраструктура ), і некалькі іншых тэм. Кожны праект звычайна мае святую вайну ці два усе свае ўласныя, а таксама, што даўні распрацоўнікам хутка азнаёміцца ??з. Метады прыпынку свяшчэнных войнаў, ці, па меншай меры абмяжоўвае іх пашкоджання, у значнай ступені аднолькавыя ўсюды. Нават калі вы ўпэўнены, бок права, спрабуюць знайсці спосаб, каб выказаць спачуванне і разуменне пункту іншая бок рашэнняў. Часта праблема ў свяшчэннай вайне, што, паколькі кожны бок мае убудаваную яго сцены як мага вышэй, і даў зразумець, што любое іншае меркаванне чыстай дурасці, акт здачы або змены розум становіцца псіхалагічна невыносна: гэта было б прызнанне не толькі памыліцца, але што яны былі вызначаныя і яшчэ не так. Тое, як вы можаце зрабіць гэта прызнанне прымальным для другога боку, каб выказаць некаторую нявызначанасць сабе-сапраўды, паказаўшы, што вы разумееце Аргументы, якія яны робяць, і знайсці іх па крайняй меры разумным, калі не канчаткова пераканаўчымі. Зрабіць жэст, які забяспечвае прастора для ўзаемнага жэст, і, як правіла сітуацыя палепшыцца. Вы не больш і не менш верагодна, каб атрымаць тэхнічны вынік вы хацелі, але па меншай меры, вы можаце пазбегнуць непатрэбнага ўрону залогу для маральнага праекта.

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

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

Дадатковыя гістарычная даведка аб свяшчэнных войнах, гл http://catb.org/ ~ ЭПР / жаргону / HTML / H / Свята-wars.html , і праца Дэні Коэн, які папулярызаваў тэрмін, http://www.ietf .org/rfc/ien/ien137.txt .

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

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

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

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

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

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

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

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

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

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

Ад: "Браян У. Фітцпатрык" <fitz@collab.net>
Каму: [... спіс атрымальнікаў апушчаны на ананімнасць ...]
Тэма: Ракавіна Subversion энергіі
Дата: Wed, 12 Лістапада 2003 23:37:47 -0600

У апошнія 25 дзён, 6 найбольш плакатаў [Dev | карыстачы] SVN спісе ёсць
былі:

    294 kfogel@collab.net
    236 "С. Майкл Pilato" <cmpilato@collab.net>
    220 "J. Random" <jrandom@problematic-poster.com>
    176 Бранка Cibej <brane@xbc.nu>
    130 Філіп Марцін <philip@codematters.co.uk>
    126 Бэн <sussman@collab.net> Колінз-Сассман

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

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

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

Subversion Dev @ з'яўляецца спіс рассылкі, каб спрыяць развіццю версія
сістэмы кіравання, а не сесіі групавой тэрапіі.

-Фиц, спрабуючы прабрацца праз тры дні SVN пошты, што ён дазволіў
 назапашваць

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

Стратэгія Фиц быў, у рэтраспектыве, па-майстэрску. Ён сабраў забойны колькасных даных, а затым распаўсюджваюць яе незаўважна, і адправіць яго першым некалькіх людзей, чыя падтрымка будзе ключавым у якіх-небудзь рэзкіх дзеянняў. Яны пагадзіліся, што якое-небудзь дзеянне было неабходна, і ў рэшце рэшт мы называлі J. Random па тэлефоне, апісаныя праблемы з ім непасрэдна, і папрасіў яго, каб проста спыніць рэгістрацыю. Ён ніколі не разумеў прычын, чаму, калі ён быў у стане зразумець, ён бы, напэўна, ажыццяўляюць адпаведныя рашэнні, у першую чаргу. Але ён пагадзіўся, каб спыніць праводкі, і спісы рассылання стала карыснай зноў. Адной з прычын гэтага стратэгія працавала, мабыць, ўтоеную пагрозу, што мы маглі б пачаць абмяжоўваць яго паведамленні па ўмерана праграмнага забеспячэння звычайна выкарыстоўваецца для прадухілення спаму (гл. раздзел пад назвай "абарона ад спаму" ў раздзеле 3, тэхнічная інфраструктура ). Але па гэтай прычыне мы былі ў стане мець такую ??магчымасць у рэзерве, што Фиц сабраў неабходную падтрымку з боку ключавых людзей у першую чаргу.

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

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

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

Падобна на тое, што вашыя Scanley індэксы сталі frobnicated. Для
unfrobnicate іх, выканайце наступныя дзеянні:

1. Выключыце сервер Scanley.
2. Выканаць "defrobnicate" праграму, якая пастаўляецца з Scanley.
3. Запуск сервера.

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

Падобна на тое, што вашыя Scanley індэксы сталі frobnicated. Мы
бачыў гэтую праблему яшчэ ў ліпені, і J. Random Паведамленні рашэнні ў
http://blahblahblah/blah. Ніжэй прыводзіцца больш поўнае апісанне
Як unfrobnicate вашыя індэксы, заснаваныя на інструкцыях J. Random 'S
але распаўсюджванне іх няшмат:

1. Выключыце сервер Scanley.
2. Стаць карыстальнікам сервера Scanley звычайна працуе як.
3. Як гэтага карыстальніка, запуск праграмы "defrobnicate" на індэксы.
4. Выканаць Scanley ўручную, каб убачыць, калі індэксы працаваць.
5. Перазагрузіце сервер.

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

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

 <a name="mylabel"> ...</> 

 <p id="mylabel"> ...</ P> 

 http://myproject.example.com/faq.html # MyLabel 

 <a name="mylabel"> </ A> 

 <a name="mylabel" title="#mylabel"> ...</> 

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

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

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

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

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

Вы цяпер гаворыце пра # linuxhelp

Тэма для # linuxhelp з'яўляецца Калі ласка, прачытайце
http://www.catb.org/ ~ ЭПР / FAQ / смарт-questions.html & &
http://www.tldp.org/docs.html # Howto Перш чым задаваць пытанні | Крыніца
Правілы на http://www.nerdfest.org/lh_rules.html | Звярніцеся
http://kerneltrap.org/node/view/799, перш чым прасіць аб абнаўленні да
2.6.x ядра | ПСП на чытанне магчыма: http://tinyurl.com/4s6mc ->
абнаўленне 2.6.8.1 або 1927/04/02 | хэш-алгарытму катастрофа: http://tinyurl.com/6w8rf
| Reiser4 з

З спісы рассылання, "рэкламнае прастора" з'яўляецца малюсенькі колонтитул дадаецца да кожнага паведамлення. Большасць праектаў пакласці падпіску / адпіску там інструкцыі, і, магчыма, паказальнік на галоўную старонку праекта або FAQ старонцы. Вы можаце падумаць, што хто падпісаўся на спіс будзе ведаць, дзе знайсці гэтыя рэчы, і яны, верагодна,-але значна больш людзей, чым проста абанентаў гэтыя паведамленні спісу рассылання. Заархіваваны паведамленне можа быць звязана з з многіх месцаў, больш таго, некаторыя пасады сталі настолькі шырока вядома, што яны ў канчатковым выніку мець больш чытачоў з спісу, чым на ім.

Фарматаванне можа мець вялікае значэнне. Напрыклад, у праекце Subversion, мы былі з абмежаваным поспехам выкарыстання памылка фільтрацыі методыцы, апісанай у раздзеле "папярэдняй фільтрацыі Bug Tracker" ў раздзеле 3, тэхнічная інфраструктура . Многія падробленыя паведамленні пра памылку па-ранейшаму пададзеных нявопытныя людзі, і кожны раз гэта здарылася, фільтрам павінны былі быць створаны ў дакладнасці так жа, як 500 чалавек перад ім. Аднойчы, пасля аднаго з нашых распрацоўшчыкаў, нарэшце, дабраўся да канца свайго вяроўкі і запалалі некаторых бедных карыстальнікаў, хто не чытаў прынцыпаў адсочвання праблем досыць дбайна, іншы распрацоўнік вырашыў, што гэта карціна сышла на досыць доўга. Ён прапанаваў, каб мы перафарматаваць перад адсочвання праблем старонцы, так што самая важная частка, судовы забарону, каб абмеркаваць памылку на спісы рассылання або IRC-каналы да падачы, будзе стаяць у вялізных, смелыя чырвонымі літарамі, на ярка-жоўтым фоне, па цэнтру прыкметна вышэй за ўсё астатняга на старонцы. Мы зрабілі гэта (вы можаце ўбачыць вынікі на http://subversion.tigris.org/project_issues.html ), і ў выніку было прыкметнае падзенне хуткасці фіктыўных заявак пытанні. Мы па-ранейшаму атрымліваць іх, вядома, мы заўсёды будзем, але хуткасць істотна запаволілася, як і колькасць карыстальнікаў павялічваецца. Вынік не толькі тое, што памылка базы даных змяшчае менш смецця, але тыя, хто адказвае на пытанне заявак знаходжання ў лепшым настроі, і, хутчэй за ўсё, застаюцца сяброўскімі, адказваючы на ??адно з цяпер рэдкіх фіктыўных заявак. Гэта паляпшае праекта выявы і псіхічнае здароўе сваіх добраахвотнікаў.

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

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

Іншы прыклад з праекту Subversion: мы спыніліся на з'езд "r12908" азначае "перагляд 12908 у сховішча кантролю версій." Малыя "г", код лёгка ўвесці, і таму што гэта палова вышыні лічбаў, ён робіць лёгка вядомы блок тэксту ў спалучэнні з лічбамі. Вядома, асядаючы на ??Канвенцыю не азначае, што ўсё будзе пачаць выкарыстоўваць яго паслядоўна адразу. Такім чынам, калі здзяйсняюць пошта прыходзіць з лог паведамлення накшталт гэтага: