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

[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 резко падает и секретарю, 
рецензенту и самому кандидату становиться намного проще.

Предлагаю обсудить этот вопрос и по результатом обсуждения я подготовлю 
и пришлю в рассылку консолидированные предложения для изменения 
существующего регламента.


Антон