Re: [devel] Предложение к изменению в регламент JOIN -> стадии развития мантейнера (сопровождающего)

[Evgeny Sinelnikov <sin@altlinux.org>]

Добрый вечер,

в целом, у предложенного сценария вступления в Team есть положительные
цели, но сам подход откровенно напоминает сегрегацию мейнтейнеров по
не вполне сформулированным, субъективным критериям.

Прежде всего, тут стоит отметить следующие противоречивые моменты с
точки зрения оценки кандидатов:
* техническая компетенция vs технические предпочтения отдельного члена
Team, который на последнем этапе играет роль рецензента;
* техническое доверие vs техническая предвзятость относительно
принимаемых претендентом технических решений.

Например, рассмотрим обновление пакета и смену схемы сборки.

С одной стороны у многих пакетов исторически сложился свой сценарий
сборки, с другой - этот сценарий может казаться не вполне удачным или
технически несовершенным. Как нужно поступать начинающему мейнтейнеру,
если он берётся обновлять такой пакет? Исправлять то, с чем, в свое
время кто-то не справился, или делать по аналогии с уже сложившимся
сценарием сборки? А, если исправлять, то как? Почему так, а не эдак,
если оба варианта равнозначны?

Тут ведь возникает вилка. Если этот пакет активно сопровождается, то
текущий участник ALT Linux Team, как бы, вправе и к нему нет никакий
претензний. А если пакет заброшен и его предлагается обновить, то у
рецензента возникает возможность предъявить к претенденту на такое
обновление совершенно другие требования.

Ещё один момент - это соответствие во многом "неписанных" требований,
которые могут быть предъявлены претенденту (кандидату в ALT Linux
Team), тем компетенциям, которым соответствуют или не соответствуют
уже существующие, активные члены команды (собственно, уже прошедшие в
ALT).

Во избежание двойного толкования требований предлагаю с первых шагов
вступления в Team предъявлять только такие требования и рекомендации,
которые закреплены в соответствующих документах:
- https://www.altlinux.org/Категория:Нормативные_документы

Такие же требования, которые ещё не закреплены в соответствующих
документах, как минимум, сразу оформлять в качестве Черновиков:
- https://www.altlinux.org/Категория:Черновики_нормативных_документов

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

Относительно фиксации вступления в команду на стадии 4.0 есть ещё
одна, уже не техническая тонкость. Утверждение "считать кандидата на
стадии 4.0 уже вступившим в команду" звучит, мягко говоря, достаточно
двусмысленно. Футболку ALT Linux Team тоже будем выдавать с припиской
"Стажёр" или "Junior"?

На самом деле тут стоит ведь исходить скорее из интереса и мотивации
вступающих в Team:
- Участие в развитии проекта Sisyphus;
- Сопровождение конкретных пакетов для бизнеса (например, от лица той
или иной заинтересованной компании, в том числе и Базальт СПО);
- ... ?

Если речь идёт о втором варианте, то я не вижу никаких препятствий для
введения промежуточной стадии, когда человек сам понимает, что участие
в ALT Linux Team для него, всего лишь рабочий момент. Но если речь
идёт о первом варианте, то совершенно не стоит предлагать ему
оскорбительную полумеру.

В любом случае, критерии оценки технической компетенции нужно
развивать для того, чтобы сохранять честность и убедительность. Как
для кандидатов, так и для действующих членов ALT Linux Team.



пт, 15 мар. 2024 г. в 17:16, Danil Shein <dshein@basealt.ru>:
>
> Добрый день!
>
> Относительно наименования нового участника ALT Linux Team на этапе 4.0:
>
> Выбор конкретного наименования, как мне кажется, не принципиален.
> Использование названия "junior maintainer" сильно лучше русскоязычных
> вариантов.
>
> Мне схема с использованием ACL в целом кажется вполне разумной, а
> главное технически реализуемой.
>
> Относительно документального сопровождения процесса JOIN:
>
> Мне лично, чтобы вспомнить что такое этап "4.0", потребовалось таки
> искать описание процедуры на вики.
> Более того, вступающему найти эту информацию сходу тоже не так-то просто
> ибо она расположена в статье про обязанности "секретаря" команды - нужно
> ещё догадаться где искать или спрашивать у ментора.
>
> Отсюда пара моментов для обсуждения:
>
> - Возможно имеет смысл дать какие-то говорящие названия этапам JOIN (да
> хоть отрицание/гнев/торг/депрессия/принятие - как раз 5 этапов)?
>
> Например:
> * 1.0 - Заявка
> * 2.0 - Регистрация
> * 3.0 - Подтверждение
> * 4.0 - Аттестация (Квалификация, Экзамен etc.)
> * 5.0 - Вступление
>
> - Обновить или добавить на вики описание процедуры JOIN в более понятном
> виде?
>
> 14.03.2024 21:16, Anton Farygin пишет:
> > Всем привет.
> >
> > Как многим из вас известно, у нас довольно тяжёлый для прохождения
> > регламент JOIN в ALT Linux Team, включающей в себя дополнительного
> > рецензента работы ментора.
> >
> > Решение о появлении  этапа контролёра понятно и было продиктовано
> > реальными случаями попадания в Team людей, не обладающих всем спектром
> > знаний для полноценной и качественной самостоятельной работой над
> > достаточно сложной и разнообразной пакетной базой репозитория.
> >
> > И в целом такое решение могло бы нормально работать, но у нас
> > появилось узкое место из-за отсутствия доверенных рецензентов, реально
> > качественно проверяющих кандидатов и при этом уделяющих процессу
> > взаимодействия с кандидатом достаточно много времени.
> >
> > Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать
> > что вступление в команду для полноценной самостоятельной работы из-за
> > отсутствия рецензента или их оперативности стало затягиваться уже не
> > на месяцы а на годы.
> >
> > Считаю это плохим фактором для дальнейшего роста нашей дружной команды
> > и хочу предложить сообществу к рассмотрению точечные изменения к этой
> > схеме.
> >
> > Изменения будут заключаться в формальном статусе кандидата на стадии
> > ожидания рецензента.
> >
> > Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но
> > имеющим некоторые ограничения в правах. А именно:
> >
> > - он может отправлять изменения только к тем пакетам, в ACL которых он
> > присутствует;
> >
> > - он может отправлять новые, приналежащие @nobody или @everybody
> > пакеты только после review и approve от прошедших стадию 4.2 ментейнеров;
> >
> > -  в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким
> > ментейнером лидером устанавливается тот, кто делал approve;
> >
> > -  может присутствовать в ACL только в качестве соучастника (не может
> > быть лидером и не может оставаться один);
> >
> > - не имеет права до окончания процедуры вступления становиться
> > ментором новым кандидатам;
> >
> > - не имеет права голоса в принятии технических решений (но естественно
> > может принимать участие в обсуждениях);
> >
> >
> > при этом ментор фактически завершает свою работу и в дальнейшем росте
> > такого ментейнера в команде становятся все участники.
> >
> > Для данной стадии предлагается выбрать соответствующее название и я
> > придумал несколько вариантов, которые предлагаю заодно обсудить в
> > данном треде:
> >
> > 1) Стажёр
> >
> > 2) Практикант
> >
> > 3) Подмастерье
> >
> > 4) Ученик
> >
> > 5) Junior (термин, привычный в IT области)
> >
> >
> > Мне лично из всех вариантов названия предлагаемой стадии нравится
> > больше junior maintainer, но возможно у кого-то будут и другие, более
> > интересные варианты.
> >
> >
> > Процесс перехода от стадии 4.0 на стадию 5.0 надо продумать, как
> > вариант можно рассмотреть решение по запросу секретаря на такой
> > переход от одного или нескольких из тех самых "доверенных"
> > ментейнеров, кому обычно секретарь JOIN поручает рецензирование.
> >
> > Но т.к. после предлагаемых изменений кандидат на стадии 4.0 становится
> > фактически полноценным участником Team, может собирать пакеты,
> > взаимодействовать по разным компонентам системы с другими участниками
> > команды, принимать участие в обсуждении и выработке технологических
> > решений - то острота завершения JOIN резко падает и секретарю,
> > рецензенту и самому кандидату становиться намного проще.
> >
> > Предлагаю обсудить этот вопрос и по результатом обсуждения я
> > подготовлю и пришлю в рассылку консолидированные предложения для
> > изменения существующего регламента.
> >
> >
> > Антон
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
> --
>
> *Данил Шеин / Danil Shein*
>
> dshein@altlinux.org
> dshein@basealt.ru
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)