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

[Grigory Ustinov]

07.08.2024 14:14, Anton Farygin пишет:
> Тему приобрела новый поворот.
> Есть потребность в создании команд, которые непосредствено не будут 
> заниматься сборкой пакетов - а именно дизайнеров, документаторов и 
> переводчиков (с редакторами).
Я вижу это так:

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

Было бы интересно узнать другие мнения.

>
>
> Предлагаю возобновить это обсуждение и довести до логического 
> завершения - внесения изменений в регламенты.
>
> On 14.03.2024 21:16, Anton Farygin wrote:
>> Всем привет.
>>
>> Как многим из вас известно, у нас довольно тяжёлый для прохождения 
>> регламент 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
>
>
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel