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

[Michael Shigorin]

On Sun, Oct 31, 2004 at 08:06:49PM +0300, Денис Смирнов wrote:
>  MS> В общем, господа team, что думаете по поводу более явного
>  MS> выделения в оной team таких вот "родов войск"?
> Думаю что если ты сможешь решить эту задачу неэкономическими
> методами, то станешь в один ряд со Столлманом, Рэймондом и
> Линусом.

Не претендую (тем паче только что посмотрев "Revolution OS" :)
К тому же подозреваю, что частично она решена.

> Такая tiger team должна:
> 1. обладать очень высокой квалификацией

Да.  Но кое-кто тут в своё время и был замечен ровно за
высказыванием вида "уровень разработчиков в команде существенно
выше уровня разработчиков в мире" года два-три тому.

> 2. иметь в своём составе хотя бы 1-2 "универсалов" (знающих
> "почти всё", и способных помочь остальным в интеграции) плюс
> специалистов в отдельных секторах (таких как языки
> программирования, отдельные платформы типа KDE/Gnome со всей их
> инфраструктурой, или kernel team).

Скорее да.

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

> 3. (ключевое) иметь очень жёсткую дисциплину и организованность
> действий.

Ты только не путай второе с первым.  Вместо первого кажется более
полезным задокументированная методология и нечто вроде бОльших
полномочий (например, на NMU по оговоренному алгоритму -- см.,
например, Debian Policy про дырки и критические баги).

> Эдакий "мантейнерский спецназ".

Ну, в общем, да.  Только формализованный.  За счёт чего меньше
времени и сил должно уходить в каждом конкретном случае на
переливание из пустого в порожнее и больше -- на собственно дело.

> Проблемы:
> 1. чем выше квалификация, тем выше загруженность (читай тяжелее
> мотивировать, особенно на срочную работу)

Дело не столько в срочности, сколько в предсказуемости.

Например, что-то предвидится изменить в том же rpm-build-python
или initscripts.  Люди, которые составляют такую команду, могут
выработать рекомендации по прохождению изменения, помогать
индивидуальным майнтейнерам, пакеты которых оно цепляет,
управлять желающими помочь, но имеющими ещё недостаточно опыта
для самостоятельного создания или портирования спеков (это к
слову о janitors / junior jobs и, пожалуй, студентах -- наверное,
и мне было бы интересно с чего-то _полезного_ начать, заодно
посмотрев на то, как какое-либо инфраструктурное изменение
проходит по _разным_ спекам и как на что влияет -- это же
разносторонний опыт!).

И это может быть та же пара недель, а не "на позавчера", да и
"час X" обычно вполне сдвигаем.

> 2. организовать _чёткое_ взаимодействие между людьми не
> являющимися сотрудниками одной организации весьма сложно.

Ну почему, насколько могу судить -- в рамках того же lkml бывают
достаточно чёткие взаимодействия и без этого условия.

> Соответственно основной вопрос -- как мотивировать?

Ну, когда-то можно поиграться и во что-то вроде slashdot ratings
("этот человек знаменит тем, что ведёт NN пакетов, пишет NNN
полезных писем в рассылки в средний месяц и помог N пакаджерам с
их M пакетами").

Но неохота на такие фантики размениваться.

Посему остаётся банальная экономия времени при достижении
индивидуальных целей (ведь у каждого из нас они есть, и обсудить,
почему мы тратим время на Sisyphus -- было бы отдельно интересной
темой; но пусть для начала newsletter стартует).

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

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

Возвращаясь к началу -- мерой, по которой можно судить об
удачности такого проекта, может быть то, будет ли получаться эта
самая экономия времени.  Вообще говоря, она зависит от:

- количества изменений, требующих такого разбирательства,
  в единицу времени;
- количества пакетов, задеваемых изменением;
- объёма нестандартных (и нескриптуемых) действий над спеками,
  которые необходимы для изменения заданного пакета;
- времени, которое уходит на непродуктивные (социальные,
  снимающие напряжённость etc) обсуждения результатов принятия
  какого-либо изменения (особенно при задержках между изменением
  базы и мигрированием пакетов);
- количества таких вот людей.

Как по мне -- так тот же проект "по питоньей части" был
достаточно грамотно организован (не путать с "идеально") и можно
попробовать это формализовать для использования в будущем.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следущая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : http://lists.altlinux.ru/pipermail/devel/attachments/20041031/c4b11ad1/attachment-0001.bin