[devel] JOIN - выдавать кандидату гитовницу на 2 этапе T/J/S

[Nikolai Kostrigin]

07.12.2023 14:49, Ivan A. Melnikov пишет:
> On Wed, Dec 06, 2023 at 12:31:16PM +0300, Nikolai Kostrigin wrote:
>> Всем привет!
>>
>> Я писал о нижеследующем ранее [1], но из-за неудачного оформления темы
>> письмо утонуло.
>>
>> После изменений порядка подписки на devel@, я бы посягнул и на первые 2
>> пункта T/J/S , т.к. без гитовницы для проверки наработок кандидатов
>> приходится "шарахаться по разным углам" (gitlab, github, архивы в
>> мессенжерах).
>>
>> Вместо:
>>
>> Пункт 1. По созданию бага в разделе «Development», продукте «Team accounts»,
>> на компонент «join»:
>>
>> 1. Убедиться, что кандидат имеет активного ментора.
>> 2. Проверить SSH- и GPG-ключ кандидата, nickname и адрес пересылки почты.
>> 3. Ожидать решения ментора о готовности кандидата.
>>
>> Пункт 2. По положительному решению ментора о том, что кандидат готов начать
>> вступление:
>>
>> 1. Создать email alias для кандидата (детали создания выясняются у текущего
>> секретаря).
>> 2. Зарегистрировать SSH-ключ кандидата в gitery.alt.
>> 3. Ожидать решения ментора о готовности кандидата.
>>
>> Сделать:
>>
>> Пункт 1. По созданию бага в разделе «Development», продукте «Team accounts»,
>> на компонент «join»:
>>
>> 1. Убедиться, что кандидат имеет активного ментора. ( == Ожидать решения
>> ментора о готовности кандидата.)
>>
>> Пункт 2. По положительному решению ментора о том, что кандидат готов начать
>> вступление:
>> 1. Проверить SSH- и GPG-ключ кандидата, nickname и адрес пересылки почты.
>> 2. Создать email alias для кандидата (детали создания выясняются у текущего
>> секретаря).
>> 3. Зарегистрировать SSH-ключ кандидата в gitery.alt.
>> 4. Ожидать решения ментора о готовности кандидата.
> 
> Мне кажется, такая переделка не имеет большого смысла.
> Прежде чем переходить к T/J/S 2.0, нужно решить две
> независимых задачи:
> 
> - Кандидат должен найти ментора и убедить его,
>    что он правда чего-то хочет и готов что-то делать;

В подавляющем большинстве случаев это уже состоялось заранее (почта, 
общение на канале, кулуары конференций, трудоустройство).
Я не смог вспомнить ни одной заявки с 19 года, наверное, когда кандидат 
регистрировал бы багу на join не имея договоренности с ментором; 
поправьте, если ошибаюсь.
Т.е. в предлагаемой переделке подтверждение ментором готовности в  п.1 
(перевод на 2.0) уже означает, что с приложенными ключами и псевдонимом 
можно делать все предусмотренные п.2 операции. Если секретарь 
обнаруживает несоответствие заявка зацикливается на 2.1
> 
> - Секретарь должен убедиться, что выбранный
>    nickname и сегнерированные ключи соответствуют
>    формальным требованиям.

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

При оформлении коммитов и changelog в spec-файлах мы просим кандидатов 
указывать почту @altlinux.org (как правило, после того, как в первом 
git-репозитории пакета видим там другую почту и  nickname вместо имени).
Многим не очевидно, что нужно использовать алиас сразу, т.к. этой почты 
у них еще "как бы нет". Т.е. работа с настройкой git есть, а почты 
мэнтейнера - нет. Так пусть она будет сразу. И с гитовницей впридачу.


> Думаю, вполне можно переводить на 2.0 и до
> формального перехода на 1.3, если ментор
> сам проверил ключи а переход на 1.3 почему-то
> затягивается.


> 

-- 
Best regards,
Nikolai Kostrigin