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

[Anton Farygin]

On 07.12.2023 14:49, Ivan A. Melnikov wrote:
 > 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, нужно решить две
 > независимых задачи:
 >
 > - Кандидат должен найти ментора и убедить его,
 >   что он правда чего-то хочет и готов что-то делать;

Задача поиска ментора должна быть решена до появления заявки

 >
 > - Секретарь должен убедиться, что выбранный
 >   nickname и сегнерированные ключи соответствуют
 >   формальным требованиям.

Это планируется автоматизировать, но несмотря на это может быть так, что 
лучше это поручить ментору.

Вообще отдельный этап работы с gitery был нужен для того, что бы 
убедиться что кандидат понимает что такое git и умеет им пользоваться.

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

Т.е. - mentor прямо на этапе 1 может убедиться, что кандидат знает git, 
что у него нормальные nickname и ключи и попросить сразу перевести на 
этап 2.0, в котором уже будет доступ к сборочнице.

Соответственно предполагаемые изменения для секретаря 
https://www.altlinux.org/Team/Join/Secretary будут звучать так:

1. По созданию бага в разделе «Development», продукте «Team accounts», 
на компонент «join»:

 1.   Ментор: Подтвердить наставничество
 2.   Ментор: Проверить SSH- и GPG-ключ кандидата, nickname и адрес
    пересылки почты.
 3.   Ментор: Убедиться что кандидат подтвердил знание инструментария git
 4.   Ментор: перевести кандидата на стадию 2.0, установив тему
    сообщения тикета в bugzilla в формат [2.0] join ник@


2. По положительному решению ментора о том, что кандидат готов начать 
вступление - секретарь:

 1. Создать email alias для кандидата (детали создания выясняются у
    текущего секретаря).
 2. Зарегистрировать SSH-ключ кандидата в gitery.alt
    <https://www.altlinux.org/Gitery.alt>.
 3. Ожидать решения ментора о готовности кандидата.
 4. Поместить очищенный GPG-ключ кандидата в пакет alt-gpgkeys.
 5. Отправить новую сборку пакета alt-gpgkeys в Сизиф.
 6. Установить новую сборку пакета alt-gpgkeys на сервер.
 7. Подписать кандидата на рассылку devel на .
 8. Зарегистрировать SSH-ключ кандидата в gyle.alt
    <https://www.altlinux.org/Gitery.alt> (без добавления в группу
    майнтейнеров).

Пункт 3 или нивелировать или на нём подписывать на devel