[devel] Re: subteams? (was: I: Sisyphus-20041027 unmets)

[Денис Смирнов]

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