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

Сб Мар 16 04:47:39 MSK 2024

Доброго времени суток!

Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я 
как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару 
дней прочитал ещё раз и снова не понял. Переименовать кандидатов в 
джуниоров или что?

Потому что фактических изменений я особо не вижу. Разве что разрешение 
кандидатам собирать пакеты со своим ацл. Сейчас, я напомню, такие пакеты 
требуют одобрения любого участника тим, как и любые другие.

Давайте по пунктам:

> Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но 
> имеющим некоторые ограничения в правах. А именно:
На 3.5 уже по новым нормам человек уже подписан на devel@, что раньше 
считалось признаком прохождения джойн.
> - он может отправлять изменения только к тем пакетам, в ACL которых он 
> присутствует;
Не реализовано.
> - он может отправлять новые, приналежащие @nobody или @everybody 
> пакеты только после review и approve от прошедших стадию 4.2 ментейнеров;
И сейчас может.
> -  в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким 
> ментейнером лидером устанавливается тот, кто делал approve;
После джойна менторы будут переназначать пачки пакетов на подопечных. 
Нынешний вариант считаю лучше.
> -  может присутствовать в ACL только в качестве соучастника (не может 
> быть лидером и не может оставаться один);
Пустая формальность.
> - не имеет права до окончания процедуры вступления становиться 
> ментором новым кандидатам;
И сейчас не имеет. Ни ментором, ни рецензентом.

Хотя я слышал о ситуациях, когда в одном городе менторами становились 
люди, прошедшие джойн год назад или может даже меньше. Я точно сказать 
не могу, но меня тогда это потрясло, когда я только видел как человек 
еле закончил джойн и вот он уже учит кого-то следующего. Лучше бы 
поточнее сформулировать список предъявляемых к менторам и рецензентам 
требований.

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

Раз уж всё равно затронул тему, то неплохо было бы и определиться с 
понятием "качественно проверяющих". В частности требовать от кандидатов 
собрать что-то с shared libs, если он планирует заниматься питоном или 
собрать питон, если он собирается заниматься чем-то ещё - это странно. Я 
не говорю, что это плохо, знания лишними не бывают, но как минимум 
обоснование этому можно было бы где-нибудь прописать. Дескать каждый 
кандидат должен уметь то то и это.

> - не имеет права голоса в принятии технических решений (но естественно 
> может принимать участие в обсуждениях); 
И сейчас не имеет, но может обсуждать.

---

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

Поэтому формализуй не формализуй регламент джойна, этот опыт для каждого 
участника будет свой. Повторюсь: вы главное аналог ЕГЭ не вводите.

Спасибо за внимание!

P.S. На всякий случай.. Никого из соседнего города обижать или задевать 
не хотел.

15.03.2024 21:42, Evgeny Sinelnikov пишет:
> Добрый вечер,
>
> в целом, у предложенного сценария вступления в 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
>
>