From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 1 Nov 2004 14:56:31 +0300 From: =?koi8-r?B?5MXOydMg883J0s7P1w==?= To: ALT Devel discussion list Message-ID: <20041101115631.GA10686@mithraen_ws> Mail-Followup-To: =?koi8-r?B?5MXOydMg883J0s7P1w==?= , ALT Devel discussion list References: <20041027220143.GA23142@basalt.office.altlinux.org> <20041030180757.GA8898@altlinux.org> <20041030181914.GB26204@mithraen_ws> <200410310111.51060.cray@neural.ru> <20041031064529.GF18130@osdn.org.ua> <20041031170649.GB18969@mithraen_ws> <20041031180334.GR18130@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041031180334.GR18130@osdn.org.ua> Subject: [devel] Re: subteams? (was: I: Sisyphus-20041027 unmets) X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2004 10:52:49 -0000 Archived-At: List-Archive: List-Post: On Sun, Oct 31, 2004 at 08:03:34PM +0200, Michael Shigorin wrote: MS> Не претендую (тем паче только что посмотрев "Revolution OS" :) MS> К тому же подозреваю, что частично она решена. Решить её полностью, и задокументировать результат слабо? ;-) >> Такая tiger team должна: >> 1. обладать очень высокой квалификацией MS> Да. Но кое-кто тут в своё время и был замечен ровно за MS> высказыванием вида "уровень разработчиков в команде существенно MS> выше уровня разработчиков в мире" года два-три тому. Сие есть факт. Я бы сказал _много_ выше, ибо средний уровень разработчиков в мире, мягко скажем, низковат, и за сравнение "просто выше" и обидеться можно :) Но тут не относительные величины нужны а абсолютные. Человек либо может решить какие-то проблемы, либо нет. >> 2. иметь в своём составе хотя бы 1-2 "универсалов" (знающих >> "почти всё", и способных помочь остальным в интеграции) плюс >> специалистов в отдельных секторах (таких как языки >> программирования, отдельные платформы типа KDE/Gnome со всей их >> инфраструктурой, или kernel team). MS> Скорее да. MS> Ты упустил ещё одно качество (или включил в универсальность?) -- MS> кругозор по дистрибутивам. Бишь "а как это делается в ...", MS> что может способствовать стабилизации (вместо бурного роста) MS> отечественного велосипедостроения и улучшению стратегической MS> интероперабельности на разных уровнях, от конфигурации и опыта MS> до пакетов и их "гроздей" (последнее и для портирования спеков MS> довольно важно). Я это действительно упустил. Правда вообще-то это в первую очередь группы планирования развития дистрибутива. О существовании такой группы мне ничего не известно. >> 3. (ключевое) иметь очень жёсткую дисциплину и организованность >> действий. MS> Ты только не путай второе с первым. Вместо первого кажется более MS> полезным задокументированная методология и нечто вроде бОльших MS> полномочий (например, на NMU по оговоренному алгоритму -- см., MS> например, Debian Policy про дырки и критические баги). А дисциплина в проектах масштаба больше "полтора человека за одним ноутбуком в гараже" и может быть, IMHO, реализована исключительно написанием полиси на каждый чих и непрерывной их модификацией под текущие реалии. Насчёт NMU -- Блин-Ну-Когда-Же-Спеки-Будут-Лежать-В-CVS? >> Эдакий "мантейнерский спецназ". MS> Ну, в общем, да. Только формализованный. За счёт чего меньше MS> времени и сил должно уходить в каждом конкретном случае на MS> переливание из пустого в порожнее и больше -- на собственно дело. Разумеется. >> Проблемы: >> 1. чем выше квалификация, тем выше загруженность (читай тяжелее >> мотивировать, особенно на срочную работу) MS> Дело не столько в срочности, сколько в предсказуемости. MS> Например, что-то предвидится изменить в том же rpm-build-python MS> или initscripts. Люди, которые составляют такую команду, могут MS> выработать рекомендации по прохождению изменения, помогать MS> индивидуальным майнтейнерам, пакеты которых оно цепляет, MS> управлять желающими помочь, но имеющими ещё недостаточно опыта MS> для самостоятельного создания или портирования спеков (это к MS> слову о janitors / junior jobs и, пожалуй, студентах -- наверное, MS> и мне было бы интересно с чего-то _полезного_ начать, заодно MS> посмотрев на то, как какое-либо инфраструктурное изменение MS> проходит по _разным_ спекам и как на что влияет -- это же MS> разносторонний опыт!). MS> И это может быть та же пара недель, а не "на позавчера", да и MS> "час X" обычно вполне сдвигаем. Опять же, в этом случае у нас получается в центре команды как минимум один человек специальностей "Хакер" и "Менеджер", который периодами практически целиком выбывает из деятельности кроме управления/обучения/пинания остальных членов этой команды. Такую модель я вижу реализуемой только если ядро этой команды будет сидеть на зарплате. >> 2. организовать _чёткое_ взаимодействие между людьми не >> являющимися сотрудниками одной организации весьма сложно. MS> Ну почему, насколько могу судить -- в рамках того же lkml бывают MS> достаточно чёткие взаимодействия и без этого условия. Естественно это возможно. Естественно это часто встречается. Нам этого мало. Нам нужно чёткий способ воспроизводить некоторый уровень качества взаимодейства по первой необходимости. >> Соответственно основной вопрос -- как мотивировать? MS> Ну, когда-то можно поиграться и во что-то вроде slashdot ratings MS> ("этот человек знаменит тем, что ведёт NN пакетов, пишет NNN MS> полезных писем в рассылки в средний месяц и помог N пакаджерам с MS> их M пакетами"). MS> Но неохота на такие фантики размениваться. Угу. С другой стороны как раз для начинающих это, вместе с работой под руководством более опытного специалиста и может являться хорошим стимулом. Фактически при таких рейтингах ему проще будет в будущем трудоустроиться. MS> Посему остаётся банальная экономия времени при достижении MS> индивидуальных целей (ведь у каждого из нас они есть, и обсудить, MS> почему мы тратим время на Sisyphus -- было бы отдельно интересной MS> темой; но пусть для начала newsletter стартует). MS> Например, автору (инициатору) подобного изменения участие в MS> подобной team по своему направлению может экономить вполне MS> заметное время, которое иначе придётся потратить на рассеивание MS> непонимания и всё то же решение предвиденных и не очень, но MS> возникающих у коллег проблем. Понымаешь в чём фишка... Есть навыки, которые ближе уже к менеджерским чем программерским -- списаться с кем надо, кого-то пнуть по мыло, кого-то выловить в IM, на кого-то багу повесить. Это надо не только уметь (научиться этому легко), надо этим _хотеть_ заниматься. Опять же вопрос мотивации. Скажем несколько лет назад для меня проще было потратить пару дней на разбирании и правке чужого кода, чем пару часов на переписку с автором кода, который может решить проблему, возможно, за несколько минут. И никакие вопросы эффективности ни могли с этим справится. Дык вот такому человеку гораздо проще решать вопросы коммуникации если он входит в официальную team, у которой сейчас есть конкретная (общеизвестная) задача на текущий момент. Если кто-то из team напишет мне "нужно поправить такой-то пакет", я, естественно, скажу "Ok, как время будет". И положу в папочку "сделать в ближайшие дни". Если же, скажем, мне прийдёт письмо "эти 3 дня посвящены такому-то изменению в репозитории, и моё торможение будет задерживать весь процесс или вынуждать других делать моё дело", то обработка этой просьбы у меня ляжет в папочку "сделать срочно". MS> Возвращаясь к началу -- мерой, по которой можно судить об MS> удачности такого проекта, может быть то, будет ли получаться эта MS> самая экономия времени. Вообще говоря, она зависит от: MS> - количества изменений, требующих такого разбирательства, MS> в единицу времени; MS> - количества пакетов, задеваемых изменением; MS> - объёма нестандартных (и нескриптуемых) действий над спеками, MS> которые необходимы для изменения заданного пакета; MS> - времени, которое уходит на непродуктивные (социальные, MS> снимающие напряжённость etc) обсуждения результатов принятия MS> какого-либо изменения (особенно при задержках между изменением MS> базы и мигрированием пакетов); MS> - количества таких вот людей. MS> Как по мне -- так тот же проект "по питоньей части" был MS> достаточно грамотно организован (не путать с "идеально") и можно MS> попробовать это формализовать для использования в будущем. К сожалению я не наблюдал за процессами происходящими с питоном, потому как всё руки не доходят его изучить :) -- С уважением, Денис http://freesource.info