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

[Danil Shein]

Добрый день!

Относительно наименования нового участника 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