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

[Anton Farygin <rider@basealt.ru>]

On 16.03.2024 04:47, Grigory Ustinov wrote:
> Доброго времени суток!
>
> Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я 
> как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару 
> дней прочитал ещё раз и снова не понял. Переименовать кандидатов в 
> джуниоров или что?

вместо "топик-стартер" можно использовать Антон или Rider. Я не обижусь.

Основная цель - дать спокойно работать над своими пакетами без 
необходимости делать дополнительное review для тех, кто не хочет или не 
может идти на следующую стадию.


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

Верно..


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

Сейчас им должен доверять секретарь, т.к. по текущему регламенту именно 
он назначает рецензента.

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

Я помню, что  было так, что после сборки трёх _однотипных_ python 
пакетов ментор считал кандидата готовым к _самостоятельной_ полноценной 
работе в Team, что естественно никак не соответствует тому, с чем в 
реальности придётся столкнуться ментейнеру при работе над пакетной базой 
Sisyphus.


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

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


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