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

Anton Farygin rider на basealt.ru
Пн Мар 18 14:14:17 MSK 2024


On 16.03.2024 13:43, Dmitry V. Levin wrote:
> On Thu, Mar 14, 2024 at 09:16:05PM +0300, Anton Farygin wrote:
> [...]
>> Предлагаю считать кандидата на стадии 4.0 уже вступившим в команду, но
>> имеющим некоторые ограничения в правах. А именно:
>>
>> - он может отправлять изменения только к тем пакетам, в ACL которых он
>> присутствует;
>>
>> - он может отправлять новые, приналежащие @nobody или @everybody пакеты
>> только после review и approve от прошедших стадию 4.2 ментейнеров;
>>
>> -  в ACL новых (или принадлежащих @nobody) пакетов, отправляемых таким
>> ментейнером лидером устанавливается тот, кто делал approve;
> По сути речь идёт о том, что мы как team уже готовы доверить новым
> кандидатам, а что - ещё не готовы.  Это предложение, по видимому, неявно
> постулирует, что мы готовы доверять новым кандидатам отдельные пакеты, но
> не готовы сразу доверить любой пакет с открытым acl, а захочет ли и сможет
> ли кандидат добиться такого доверия - это вопрос индивидуальный.

Да, спасибо. Всё верно.

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

>
>> -  может присутствовать в ACL только в качестве соучастника (не может
>> быть лидером и не может оставаться один);
> Не очевидно, какая могла бы быть польза в этом ограничении.

Это вытекает из того, что в ACL пакета лидером будет вставать тот, кто 
сделал review пакета кандидата.

Цель простая - пока кандидат не станет полноценным ментейнером за его 
пакеты должен вмести с ним отвечать какой-то ментор.

>
>> при этом ментор фактически завершает свою работу и в дальнейшем росте
>> такого ментейнера в команде становятся все участники.
> Мне кажется, упразднение ментора на этой стадии не будет полезно.  Хотя
> сейчас, насколько я вижу, это уже фактически происходит, не считаю это
> хорошей практикой.  Если сейчас ментор зачастую спихивает менторство на
> конкретного рецензента, то в предложенной схеме менторство будет
> перекладываться на всю team, что, скорее всего, дополнительно затруднит
> интеграцию кандидатов, поскольку в team сейчас фактически не видно никаких
> механизмов интеграции кандидатов.
Да, согласен. Но я хотел в этом избежать ментор-лок ситуаций, когда 
кандидат завязан на одного ментора фактически или не выполняющего 
менторских обязанностей или выполняющего их плохо.
>
>> Для данной стадии предлагается выбрать соответствующее название и я
> В принципе, если консенсуса по названию не будет, то не в названии дело,
> хотя название было бы, наверное, удобнее нынешних номеров.
А тебе какой вариант больше понравился ?



Подробная информация о списке рассылки Devel