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

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

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


Антон

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

[Danil Shein]

Добрый день!

Относительно наименования нового участника ALT Linux Team на этапе 4.0:

Выбор конкретного наименования, как мне кажется, не принципиален. 
Использование названия "junior maintainer" сильно лучше русскоязычных 
вариантов.

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

Относительно документального сопровождения процесса JOIN:

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

Отсюда пара моментов для обсуждения:

- Возможно имеет смысл дать какие-то говорящие названия этапам JOIN (да 
хоть отрицание/гнев/торг/депрессия/принятие - как раз 5 этапов)?

Например:
* 1.0 - Заявка
* 2.0 - Регистрация
* 3.0 - Подтверждение
* 4.0 - Аттестация (Квалификация, Экзамен etc.)
* 5.0 - Вступление

- Обновить или добавить на вики описание процедуры JOIN в более понятном 
виде?

14.03.2024 21:16, 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 резко падает и секретарю, 
> рецензенту и самому кандидату становиться намного проще.
>
> Предлагаю обсудить этот вопрос и по результатом обсуждения я 
> подготовлю и пришлю в рассылку консолидированные предложения для 
> изменения существующего регламента.
>
>
> Антон
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
-- 

*Данил Шеин / Danil Shein*

dshein@altlinux.org
dshein@basealt.ru

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

[Evgeny Sinelnikov]

Добрый вечер,

в целом, у предложенного сценария вступления в Team есть положительные
цели, но сам подход откровенно напоминает сегрегацию мейнтейнеров по
не вполне сформулированным, субъективным критериям.

Прежде всего, тут стоит отметить следующие противоречивые моменты с
точки зрения оценки кандидатов:
* техническая компетенция vs технические предпочтения отдельного члена
Team, который на последнем этапе играет роль рецензента;
* техническое доверие vs техническая предвзятость относительно
принимаемых претендентом технических решений.

Например, рассмотрим обновление пакета и смену схемы сборки.

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

Тут ведь возникает вилка. Если этот пакет активно сопровождается, то
текущий участник ALT Linux Team, как бы, вправе и к нему нет никакий
претензний. А если пакет заброшен и его предлагается обновить, то у
рецензента возникает возможность предъявить к претенденту на такое
обновление совершенно другие требования.

Ещё один момент - это соответствие во многом "неписанных" требований,
которые могут быть предъявлены претенденту (кандидату в ALT Linux
Team), тем компетенциям, которым соответствуют или не соответствуют
уже существующие, активные члены команды (собственно, уже прошедшие в
ALT).

Во избежание двойного толкования требований предлагаю с первых шагов
вступления в Team предъявлять только такие требования и рекомендации,
которые закреплены в соответствующих документах:
- https://www.altlinux.org/Категория:Нормативные_документы

Такие же требования, которые ещё не закреплены в соответствующих
документах, как минимум, сразу оформлять в качестве Черновиков:
- https://www.altlinux.org/Категория:Черновики_нормативных_документов

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

Относительно фиксации вступления в команду на стадии 4.0 есть ещё
одна, уже не техническая тонкость. Утверждение "считать кандидата на
стадии 4.0 уже вступившим в команду" звучит, мягко говоря, достаточно
двусмысленно. Футболку ALT Linux Team тоже будем выдавать с припиской
"Стажёр" или "Junior"?

На самом деле тут стоит ведь исходить скорее из интереса и мотивации
вступающих в Team:
- Участие в развитии проекта Sisyphus;
- Сопровождение конкретных пакетов для бизнеса (например, от лица той
или иной заинтересованной компании, в том числе и Базальт СПО);
- ... ?

Если речь идёт о втором варианте, то я не вижу никаких препятствий для
введения промежуточной стадии, когда человек сам понимает, что участие
в ALT Linux Team для него, всего лишь рабочий момент. Но если речь
идёт о первом варианте, то совершенно не стоит предлагать ему
оскорбительную полумеру.

В любом случае, критерии оценки технической компетенции нужно
развивать для того, чтобы сохранять честность и убедительность. Как
для кандидатов, так и для действующих членов ALT Linux Team.



пт, 15 мар. 2024 г. в 17:16, Danil Shein <dshein@basealt.ru>:
>
> Добрый день!
>
> Относительно наименования нового участника ALT Linux Team на этапе 4.0:
>
> Выбор конкретного наименования, как мне кажется, не принципиален.
> Использование названия "junior maintainer" сильно лучше русскоязычных
> вариантов.
>
> Мне схема с использованием ACL в целом кажется вполне разумной, а
> главное технически реализуемой.
>
> Относительно документального сопровождения процесса JOIN:
>
> Мне лично, чтобы вспомнить что такое этап "4.0", потребовалось таки
> искать описание процедуры на вики.
> Более того, вступающему найти эту информацию сходу тоже не так-то просто
> ибо она расположена в статье про обязанности "секретаря" команды - нужно
> ещё догадаться где искать или спрашивать у ментора.
>
> Отсюда пара моментов для обсуждения:
>
> - Возможно имеет смысл дать какие-то говорящие названия этапам JOIN (да
> хоть отрицание/гнев/торг/депрессия/принятие - как раз 5 этапов)?
>
> Например:
> * 1.0 - Заявка
> * 2.0 - Регистрация
> * 3.0 - Подтверждение
> * 4.0 - Аттестация (Квалификация, Экзамен etc.)
> * 5.0 - Вступление
>
> - Обновить или добавить на вики описание процедуры JOIN в более понятном
> виде?
>
> 14.03.2024 21:16, 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 резко падает и секретарю,
> > рецензенту и самому кандидату становиться намного проще.
> >
> > Предлагаю обсудить этот вопрос и по результатом обсуждения я
> > подготовлю и пришлю в рассылку консолидированные предложения для
> > изменения существующего регламента.
> >
> >
> > Антон
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
> --
>
> *Данил Шеин / Danil Shein*
>
> dshein@altlinux.org
> dshein@basealt.ru
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel



-- 
Sin (Sinelnikov Evgeny)

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

[Grigory Ustinov]

Доброго времени суток!

Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я 
как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару 
дней прочитал ещё раз и снова не понял. Переименовать кандидатов в 
джуниоров или что?

Потому что фактических изменений я особо не вижу. Разве что разрешение 
кандидатам собирать пакеты со своим ацл. Сейчас, я напомню, такие пакеты 
требуют одобрения любого участника тим, как и любые другие.

Давайте по пунктам:

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

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

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

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

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

---

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

Поэтому формализуй не формализуй регламент джойна, этот опыт для каждого 
участника будет свой. Повторюсь: вы главное аналог ЕГЭ не вводите.

Спасибо за внимание!

P.S. На всякий случай.. Никого из соседнего города обижать или задевать 
не хотел.

15.03.2024 21:42, Evgeny Sinelnikov пишет:
> Добрый вечер,
>
> в целом, у предложенного сценария вступления в Team есть положительные
> цели, но сам подход откровенно напоминает сегрегацию мейнтейнеров по
> не вполне сформулированным, субъективным критериям.
>
> Прежде всего, тут стоит отметить следующие противоречивые моменты с
> точки зрения оценки кандидатов:
> * техническая компетенция vs технические предпочтения отдельного члена
> Team, который на последнем этапе играет роль рецензента;
> * техническое доверие vs техническая предвзятость относительно
> принимаемых претендентом технических решений.
>
> Например, рассмотрим обновление пакета и смену схемы сборки.
>
> С одной стороны у многих пакетов исторически сложился свой сценарий
> сборки, с другой - этот сценарий может казаться не вполне удачным или
> технически несовершенным. Как нужно поступать начинающему мейнтейнеру,
> если он берётся обновлять такой пакет? Исправлять то, с чем, в свое
> время кто-то не справился, или делать по аналогии с уже сложившимся
> сценарием сборки? А, если исправлять, то как? Почему так, а не эдак,
> если оба варианта равнозначны?
>
> Тут ведь возникает вилка. Если этот пакет активно сопровождается, то
> текущий участник ALT Linux Team, как бы, вправе и к нему нет никакий
> претензний. А если пакет заброшен и его предлагается обновить, то у
> рецензента возникает возможность предъявить к претенденту на такое
> обновление совершенно другие требования.
>
> Ещё один момент - это соответствие во многом "неписанных" требований,
> которые могут быть предъявлены претенденту (кандидату в ALT Linux
> Team), тем компетенциям, которым соответствуют или не соответствуют
> уже существующие, активные члены команды (собственно, уже прошедшие в
> ALT).
>
> Во избежание двойного толкования требований предлагаю с первых шагов
> вступления в Team предъявлять только такие требования и рекомендации,
> которые закреплены в соответствующих документах:
> - https://www.altlinux.org/Категория:Нормативные_документы
>
> Такие же требования, которые ещё не закреплены в соответствующих
> документах, как минимум, сразу оформлять в качестве Черновиков:
> - https://www.altlinux.org/Категория:Черновики_нормативных_документов
>
> Рассчитываю, что новичкам это даст понять, что им есть что опереться в
> отстаивании своих технических решений. А также даст нам самим
> возможность отделить сложившиеся за годы предпочтения от требований,
> которым мы все вместе следуем, даже если они ещё не реализованы.
> ____________________________
>
> Относительно фиксации вступления в команду на стадии 4.0 есть ещё
> одна, уже не техническая тонкость. Утверждение "считать кандидата на
> стадии 4.0 уже вступившим в команду" звучит, мягко говоря, достаточно
> двусмысленно. Футболку ALT Linux Team тоже будем выдавать с припиской
> "Стажёр" или "Junior"?
>
> На самом деле тут стоит ведь исходить скорее из интереса и мотивации
> вступающих в Team:
> - Участие в развитии проекта Sisyphus;
> - Сопровождение конкретных пакетов для бизнеса (например, от лица той
> или иной заинтересованной компании, в том числе и Базальт СПО);
> - ... ?
>
> Если речь идёт о втором варианте, то я не вижу никаких препятствий для
> введения промежуточной стадии, когда человек сам понимает, что участие
> в ALT Linux Team для него, всего лишь рабочий момент. Но если речь
> идёт о первом варианте, то совершенно не стоит предлагать ему
> оскорбительную полумеру.
>
> В любом случае, критерии оценки технической компетенции нужно
> развивать для того, чтобы сохранять честность и убедительность. Как
> для кандидатов, так и для действующих членов ALT Linux Team.
>
>
>
> пт, 15 мар. 2024 г. в 17:16, Danil Shein <dshein@basealt.ru>:
>> Добрый день!
>>
>> Относительно наименования нового участника ALT Linux Team на этапе 4.0:
>>
>> Выбор конкретного наименования, как мне кажется, не принципиален.
>> Использование названия "junior maintainer" сильно лучше русскоязычных
>> вариантов.
>>
>> Мне схема с использованием ACL в целом кажется вполне разумной, а
>> главное технически реализуемой.
>>
>> Относительно документального сопровождения процесса JOIN:
>>
>> Мне лично, чтобы вспомнить что такое этап "4.0", потребовалось таки
>> искать описание процедуры на вики.
>> Более того, вступающему найти эту информацию сходу тоже не так-то просто
>> ибо она расположена в статье про обязанности "секретаря" команды - нужно
>> ещё догадаться где искать или спрашивать у ментора.
>>
>> Отсюда пара моментов для обсуждения:
>>
>> - Возможно имеет смысл дать какие-то говорящие названия этапам JOIN (да
>> хоть отрицание/гнев/торг/депрессия/принятие - как раз 5 этапов)?
>>
>> Например:
>> * 1.0 - Заявка
>> * 2.0 - Регистрация
>> * 3.0 - Подтверждение
>> * 4.0 - Аттестация (Квалификация, Экзамен etc.)
>> * 5.0 - Вступление
>>
>> - Обновить или добавить на вики описание процедуры JOIN в более понятном
>> виде?
>>
>> 14.03.2024 21:16, 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 резко падает и секретарю,
>>> рецензенту и самому кандидату становиться намного проще.
>>>
>>> Предлагаю обсудить этот вопрос и по результатом обсуждения я
>>> подготовлю и пришлю в рассылку консолидированные предложения для
>>> изменения существующего регламента.
>>>
>>>
>>> Антон
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel@lists.altlinux.org
>>> https://lists.altlinux.org/mailman/listinfo/devel
>> --
>>
>> *Данил Шеин / Danil Shein*
>>
>> dshein@altlinux.org
>> dshein@basealt.ru
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>
>

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

[Anton Farygin]

On 15.03.2024 21:42, Evgeny Sinelnikov wrote:
> Добрый вечер,
>
> в целом, у предложенного сценария вступления в Team есть положительные
> цели, но сам подход откровенно напоминает сегрегацию мейнтейнеров по
> не вполне сформулированным, субъективным критериям.
>
> Прежде всего, тут стоит отметить следующие противоречивые моменты с
> точки зрения оценки кандидатов:
> * техническая компетенция vs технические предпочтения отдельного члена
> Team, который на последнем этапе играет роль рецензента;
> * техническое доверие vs техническая предвзятость относительно
> принимаемых претендентом технических решений.
>
> Например, рассмотрим обновление пакета и смену схемы сборки.
>
> С одной стороны у многих пакетов исторически сложился свой сценарий
> сборки, с другой - этот сценарий может казаться не вполне удачным или
> технически несовершенным. Как нужно поступать начинающему мейнтейнеру,
> если он берётся обновлять такой пакет? Исправлять то, с чем, в свое
> время кто-то не справился, или делать по аналогии с уже сложившимся
> сценарием сборки? А, если исправлять, то как? Почему так, а не эдак,
> если оба варианта равнозначны?
>
> Тут ведь возникает вилка. Если этот пакет активно сопровождается, то
> текущий участник ALT Linux Team, как бы, вправе и к нему нет никакий
> претензний. А если пакет заброшен и его предлагается обновить, то у
> рецензента возникает возможность предъявить к претенденту на такое
> обновление совершенно другие требования.
>
> Ещё один момент - это соответствие во многом "неписанных" требований,
> которые могут быть предъявлены претенденту (кандидату в ALT Linux
> Team), тем компетенциям, которым соответствуют или не соответствуют
> уже существующие, активные члены команды (собственно, уже прошедшие в
> ALT).
>
> Во избежание двойного толкования требований предлагаю с первых шагов
> вступления в Team предъявлять только такие требования и рекомендации,
> которые закреплены в соответствующих документах:
> - https://www.altlinux.org/Категория:Нормативные_документы
>
> Такие же требования, которые ещё не закреплены в соответствующих
> документах, как минимум, сразу оформлять в качестве Черновиков:
> - https://www.altlinux.org/Категория:Черновики_нормативных_документов

Отличный план. Но у нас нет работающей хорошей схемы принятия Policy и 
начать, наверное, надо с этого.

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


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

Да, конечно надо приводить в порядок инструкции и политики. Но моё 
предложение заключалось не в этом.


> ____________________________
>
> Относительно фиксации вступления в команду на стадии 4.0 есть ещё
> одна, уже не техническая тонкость. Утверждение "считать кандидата на
> стадии 4.0 уже вступившим в команду" звучит, мягко говоря, достаточно
> двусмысленно. Футболку ALT Linux Team тоже будем выдавать с припиской
> "Стажёр" или "Junior"?

Без приписки.

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

Пример - переводчики, разработчики документации, тестировщики и дизайнеры.

>
> На самом деле тут стоит ведь исходить скорее из интереса и мотивации
> вступающих в Team:
> - Участие в развитии проекта Sisyphus;
> - Сопровождение конкретных пакетов для бизнеса (например, от лица той
> или иной заинтересованной компании, в том числе и Базальт СПО);
> - ... ?
>
> Если речь идёт о втором варианте, то я не вижу никаких препятствий для
> введения промежуточной стадии, когда человек сам понимает, что участие
> в ALT Linux Team для него, всего лишь рабочий момент. Но если речь
> идёт о первом варианте, то совершенно не стоит предлагать ему
> оскорбительную полумеру.

Она совершенно никого не оскорбляет. Я знаю кандидатов, которые вступают 
в тим ради сборки одного пакета. Вероятно им вообще никогда не 
понадобиться уметь собирать пакеты, например, написанные на python.


>
> В любом случае, критерии оценки технической компетенции нужно
> развивать для того, чтобы сохранять честность и убедительность. Как
> для кандидатов, так и для действующих членов ALT Linux Team.

Я только за - www.altlinux.org открыт для редактирования всеми, кто 
хочет принять в этом участие.

Или ты предлагаешь взвалить эту задачу на меня, как на инициатора 
данного треда ?

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

[Anton Farygin]

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, если он планирует заниматься 
> питоном или собрать питон, если он собирается заниматься чем-то ещё - 
> это странно. Я не говорю, что это плохо, знания лишними не бывают, но 
> как минимум обоснование этому можно было бы где-нибудь прописать. 
> Дескать каждый кандидат должен уметь то то и это.

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


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

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

[Aleksey Novodvorsky]

сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
>
> On 16.03.2024 04:47, Grigory Ustinov wrote:

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

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

Rgrds, Алексей

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

[Denis Medvedev]

On Sat, 16 Mar 2024 11:27:23 +0300
Aleksey Novodvorsky <aen@basealt.ru> wrote:

> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
> >
> > On 16.03.2024 04:47, Grigory Ustinov wrote:
> 
> > >> - не имеет права голоса в принятии технических решений (но
> > >> естественно может принимать участие в обсуждениях);
> > > И сейчас не имеет, но может обсуждать.
> > >
> > А у нас сейчас нет вообще формального голосования. Этот пункт,
> > скорее, написан на будущее.
> 
> При  всех возможных проблемах с голосованием, которые мы наблюдаем,
> например, у коллег из Debian,
> это будущее хорошо бы приблизить. Есть предложения?


Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим пакетом
ставить апрувы/дисапрувы. При наличии апрува от ревьюера и ментора таск
проходит - кандидат считается в тиме. Остальные могут голосовать путем
апрува/дисапрува этого таска с комментариями.

Re: [devel] голосования в Team

[Anton Farygin]

On 16.03.2024 11:27, Aleksey Novodvorsky wrote:
> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
>> On 16.03.2024 04:47, Grigory Ustinov wrote:
>>>> - не имеет права голоса в принятии технических решений (но
>>>> естественно может принимать участие в обсуждениях);
>>> И сейчас не имеет, но может обсуждать.
>>>
>> А у нас сейчас нет вообще формального голосования. Этот пункт, скорее,
>> написан на будущее.
> При  всех возможных проблемах с голосованием, которые мы наблюдаем,
> например, у коллег из Debian,
> это будущее хорошо бы приблизить. Есть предложения?
>
Я уже достаточно давно думаю над этим, как раз наблюдая проблемы с 
голосованием у коллег.

Если бы были предложения по реализации, то я уже их давно бы озвучил. 
Нет, к сожалению пока предложений нет.

Может быть у кого-то есть идеи ?

Re: [devel] Голосования в Team

[Anton Farygin]

On 16.03.2024 11:38, Denis Medvedev wrote:
> On Sat, 16 Mar 2024 11:27:23 +0300
> Aleksey Novodvorsky <aen@basealt.ru> wrote:
>
>> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
>>> On 16.03.2024 04:47, Grigory Ustinov wrote:
>>>>> - не имеет права голоса в принятии технических решений (но
>>>>> естественно может принимать участие в обсуждениях);
>>>> И сейчас не имеет, но может обсуждать.
>>>>
>>> А у нас сейчас нет вообще формального голосования. Этот пункт,
>>> скорее, написан на будущее.
>> При  всех возможных проблемах с голосованием, которые мы наблюдаем,
>> например, у коллег из Debian,
>> это будущее хорошо бы приблизить. Есть предложения?
>
> Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим пакетом
> ставить апрувы/дисапрувы. При наличии апрува от ревьюера и ментора таск
> проходит - кандидат считается в тиме. Остальные могут голосовать путем
> апрува/дисапрува этого таска с комментариями.

Денис, нет - речь не про голосования за вступление, речь про голосования 
для принятия решений, и не только технических.

Re: [devel] Голосования в Team

[Denis Medvedev]

On Sat, 16 Mar 2024 12:28:00 +0300
Anton Farygin <rider@basealt.ru> wrote:

> On 16.03.2024 11:38, Denis Medvedev wrote:
> > On Sat, 16 Mar 2024 11:27:23 +0300
> > Aleksey Novodvorsky <aen@basealt.ru> wrote:
> >
> >> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
> >>> On 16.03.2024 04:47, Grigory Ustinov wrote:
> >>>>> - не имеет права голоса в принятии технических решений (но
> >>>>> естественно может принимать участие в обсуждениях);
> >>>> И сейчас не имеет, но может обсуждать.
> >>>>
> >>> А у нас сейчас нет вообще формального голосования. Этот пункт,
> >>> скорее, написан на будущее.
> >> При  всех возможных проблемах с голосованием, которые мы наблюдаем,
> >> например, у коллег из Debian,
> >> это будущее хорошо бы приблизить. Есть предложения?
> >
> > Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим
> > пакетом ставить апрувы/дисапрувы. При наличии апрува от ревьюера и
> > ментора таск проходит - кандидат считается в тиме. Остальные могут
> > голосовать путем апрува/дисапрува этого таска с комментариями.
> 
> Денис, нет - речь не про голосования за вступление, речь про
> голосования для принятия решений, и не только технических.
В принципе можно так же - апрувы/дисапрувы на пакет специального вида
(с содержимым, касающимся вопроса о котором идет голосование).
Но тайное голосование при этом невозможно.

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

[Dmitry V. Levin]

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 только в качестве соучастника (не может 
> быть лидером и не может оставаться один);

Не очевидно, какая могла бы быть польза в этом ограничении.

> при этом ментор фактически завершает свою работу и в дальнейшем росте 
> такого ментейнера в команде становятся все участники.

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

> Для данной стадии предлагается выбрать соответствующее название и я 

В принципе, если консенсуса по названию не будет, то не в названии дело,
хотя название было бы, наверное, удобнее нынешних номеров.


-- 
ldv

Re: [devel] Голосования в Team

[Grigory Ustinov]

16.03.2024 12:39, Denis Medvedev пишет:
> On Sat, 16 Mar 2024 12:28:00 +0300
> Anton Farygin <rider@basealt.ru> wrote:
>
>> On 16.03.2024 11:38, Denis Medvedev wrote:
>>> On Sat, 16 Mar 2024 11:27:23 +0300
>>> Aleksey Novodvorsky <aen@basealt.ru> wrote:
>>>
>>>> сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
>>>>> On 16.03.2024 04:47, Grigory Ustinov wrote:
>>>>>>> - не имеет права голоса в принятии технических решений (но
>>>>>>> естественно может принимать участие в обсуждениях);
>>>>>> И сейчас не имеет, но может обсуждать.
>>>>>>
>>>>> А у нас сейчас нет вообще формального голосования. Этот пункт,
>>>>> скорее, написан на будущее.
>>>> При  всех возможных проблемах с голосованием, которые мы наблюдаем,
>>>> например, у коллег из Debian,
>>>> это будущее хорошо бы приблизить. Есть предложения?
>>> Создавать пакет в сизиф "join-<кандидат ник>" и на таске с этим
>>> пакетом ставить апрувы/дисапрувы. При наличии апрува от ревьюера и
>>> ментора таск проходит - кандидат считается в тиме. Остальные могут
>>> голосовать путем апрува/дисапрува этого таска с комментариями.
>> Денис, нет - речь не про голосования за вступление, речь про
>> голосования для принятия решений, и не только технических.
> В принципе можно так же - апрувы/дисапрувы на пакет специального вида
> (с содержимым, касающимся вопроса о котором идет голосование).
> Но тайное голосование при этом невозможно.
Я не знаток кода сборочницы, но логически кажется несложным добавить 
новый режим таска, что-то вроде --vote, в котором ники можно было бы 
закрывать плюсиками, минусиками, да хоть звёздочками.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2024-03-16 12:43:41 +0200, Dmitry V. Levin wrote:

 >> Для данной стадии предлагается выбрать соответствующее название
 > В принципе, если консенсуса по названию не будет, то не в названии
 > дело, хотя название было бы, наверное, удобнее нынешних номеров.

Вижу три уровня: кандидат, стажер, участник.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Anton Farygin]

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

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

[Anton Farygin]

On 17.03.2024 10:22, Alexey V. Vissarionov wrote:
> Good ${greeting_time}!
>
> On 2024-03-16 12:43:41 +0200, Dmitry V. Levin wrote:
>
>   >> Для данной стадии предлагается выбрать соответствующее название
>   > В принципе, если консенсуса по названию не будет, то не в названии
>   > дело, хотя название было бы, наверное, удобнее нынешних номеров.
>
> Вижу три уровня: кандидат, стажер, участник.

Ну или в английском варианте:

Candidate, Intern and Participant

Вместо последнего можно (и лучше) использовать уже привычный 
сопровождающий / maintainer

Мне такой вариант нравится.

Re: [devel] голосования в Team

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 6508 bytes --]

On Sat, 16 Mar 2024 12:34:03 +0300 Aleksey Novodvorsky wrote:
> сб, 16 мар. 2024 г., 12:26 Anton Farygin <rider@basealt.ru>:
> 
> > On 16.03.2024 11:27, Aleksey Novodvorsky wrote:
> > > сб, 16 мар. 2024 г. в 10:59, Anton Farygin <rider@basealt.ru>:
> > >> On 16.03.2024 04:47, Grigory Ustinov wrote:
> > >>>> - не имеет права голоса в принятии технических решений (но
> > >>>> естественно может принимать участие в обсуждениях);
> > >>> И сейчас не имеет, но может обсуждать.
> > >>>
> > >> А у нас сейчас нет вообще формального голосования. Этот пункт, скорее,
> > >> написан на будущее.
> > > При  всех возможных проблемах с голосованием, которые мы наблюдаем,
> > > например, у коллег из Debian,
> > > это будущее хорошо бы приблизить. Есть предложения?
> > >
> > Я уже достаточно давно думаю над этим, как раз наблюдая проблемы с
> > голосованием у коллег.
> >
> > Если бы были предложения по реализации, то я уже их давно бы озвучил.
> > Нет, к сожалению пока предложений нет.
> >
> > Может быть у кого-то есть идеи ?
> >
> 
> У нас сейчас нет активных членов тим из числа Debian developers. Но есть из
> Gentoo.
> 2bircoph : как устроено голосование в Gentoo? Технически и организационно.

Организационно есть два уровня принятия решений.

1) Большинство технических вопросов (и некоторые организационные)
решает Совет (Council), состоящий из 7 разработчиков. Они
избираются сроком на год без ограничения числа сроков всеми
действующими разработчиками. Все голоса равноправны.

Совет заседает раз в месяц по повестке, открытой заранее на devel
любым из разработчиков.

2) Выборы в Совет, в Foundation (юрлицо, отвечающее за финансовые
вопросы) и голосование по некоторым фундаментальным вопросам
проводятся общим голосованием разработчиков.

Технически:

1) Совет заседает и голосует открыто (irc канал + публикация
логов), решения принимаются простым большинством от полного состава
(4+ голосов за).

2) Общее голосование ведётся методом Шульца[1] и относится
к классу методов Кондорсета[2]. (В Debian используется похожий
способ.)

Суть метода в том, что каждый избиратель все возможные варианты
выбора ранжирует в порядке своих предпочтений, при этом допускается
равноранговое ранжирование, например:

B
C E
D
_r
A F

Если побеждает _r, то делается повторное обсуждение, возможное
рассмотрение новых вариантов и голосование на оставшиеся позищии
(_r и ниже). Грубо говоря, это псевдокандидат "против всех".
Повторное голосование, если до него дошло, делается уже без этого
псевдокандидата.

Достоинство такого подхода в том, что мнение голосующего
учитывается наиболее точно. Например, в списке предпочтений на
примере выше B наиболее предпочтительный вариант, тогда голос
участника будет учтён в выборе между, например, C и D, поскольку
C и E предпочтительней D.

Голосование осуществляется тайно, путём размещения голосов в $HOME
на инфраструктурной машине (аналог нашего basealt) в виде
текстовых файлов по примеру выше. Затем софт забирает в назначенное
время эти голоса (обычно голосование 2 недели идёт) и методом
Шульца считает победителей (например, состав нового Совета).

Каждому голосующему высылается уникальный ID по которому можно
проверить анонимизированные данные голосования.

Как любое здоровое сообщество, Gentoo публикует код своих
инфраструктурных наработок. Поэтому софт для голосования свободен
и опубликован:
- votify для проверки корректности, сбора и подсчёта голосов, вместе
с другими инструментами[3];
- votrify: инструмент для удобной проверки корректности учёта
голосов[4].

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

[1] https://en.wikipedia.org/wiki/Schulze_method
[2] https://en.wikipedia.org/wiki/Condorcet_method
[3] https://gitweb.gentoo.org/proj/elections.git/tree/
[4] https://github.com/projg2/votrify

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3445 bytes --]

On Sat, 16 Mar 2024 12:43:41 +0200 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 не сильно поможет.
Мы хотим в Сизифе качественный код, удовлетворяющий опеределённому
уровню, а не тяп-ляп — собралось, значит и так сойдёт.

Вот пример кода, который был бы в Сизифе, если бы предложенное
правило работало:

mv mdcat*.1* mdcat.1
xz mdcat.1

Вместо:
BuildRequires: asciidoctor gem-asciidoctor

Просто для понимания: вместо генерации документации из asciidoctor,
её сырой исходник был переименован в man-страницу. И ментор это
пропустил.

Часть пакетов вообще собиралась с undefined symbol в логах.
Сборочница такое бы не пропустила, но ментор решил, что кандидат
готов собирать пакеты в Сизиф.

Debuginfo не создавался, лицензии были неверно указаны и прочие
подобные ошибки — всё это будет в Сизифе, если разрешить не
прошедшим рецензирование кандидатам самим собирать пакеты в Сизиф.

ACL тут не поможет, потому что ACL не повысит качество кода. Нужно
повышать качество работы менторов, чтоб рецензентам не приходилось
доучивать кандидатов.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]

On Thu, 14 Mar 2024 21:16:05 +0300 Anton Farygin wrote:
> Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать 
> что вступление в команду для полноценной самостоятельной работы из-за 
> отсутствия рецензента или их оперативности стало затягиваться уже не на 
> месяцы а на годы.

По своему опыту могу сказать, что и в других дистрибутивах средний
срок приёма нового разработчика несколько месяцев – год. Бывают
исключения в обе стороны: может быть быстрое (недели) там, где,
например, кандидат по факту уже годы рядом с командой, просто
результаты его работы коммитили другие (патчи, пулл реквесты).
Может быть и годы там, где кандидат сам надолго исчезает или плохо
учится.

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

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

По моему пониманию, топик-стартер хочет очень простой вещи: убрать
преграду в виде рецензентов для возможности оперативного
пропихивания большого количества пусть не вполне подготовленных, но
лояльных и послушных мейнтенеров. А дальше можно брать числом,
заодно регламент по голосованию пригодится. Мягкий райдерский
захват Team. Начало.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Anton Farygin]

On 20.03.2024 08:51, Andrey Savchenko wrote:
> On Thu, 14 Mar 2024 21:16:05 +0300 Anton Farygin wrote:
>> Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать
>> что вступление в команду для полноценной самостоятельной работы из-за
>> отсутствия рецензента или их оперативности стало затягиваться уже не на
>> месяцы а на годы.
> По своему опыту могу сказать, что и в других дистрибутивах средний
> срок приёма нового разработчика несколько месяцев – год. Бывают
> исключения в обе стороны: может быть быстрое (недели) там, где,
> например, кандидат по факту уже годы рядом с командой, просто
> результаты его работы коммитили другие (патчи, пулл реквесты).
> Может быть и годы там, где кандидат сам надолго исчезает или плохо
> учится.

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

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

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

>
> У нас, в общем-то причины долгих задержек те же: или кандидат сам
> на полгода исчезает, или ментор спустя рукава на его работу
> смотрим. Притом оба фактора могут быть одновременно. Вот
> и возникают задержки и пытаться их решить бюрократизацией работы —
> глупо. Задержек станет только больше, просто механизмы будут
> другими.

Ну или рецензент плохо выполняет работу ментора.

Сейчас, например, на стадии 4.0 висит в ожидании рецензента:

https://bugzilla.altlinux.org/buglist.cgi?quicksearch=JOIN%204.0&list_id=90709

А на стадии 4.2:
https://bugzilla.altlinux.org/buglist.cgi?quicksearch=JOIN%204.2&list_id=90710


Можно походить по задачам и посмотреть где и из-за кого что не двигается.

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

[Sergey Bolshakov]

>>>>> "Andrey" == Andrey Savchenko <bircoph-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

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

 > По моему пониманию, топик-стартер хочет очень простой вещи: убрать
 > преграду в виде рецензентов для возможности оперативного
 > пропихивания большого количества пусть не вполне подготовленных, но
 > лояльных и послушных мейнтенеров. А дальше можно брать числом,
 > заодно регламент по голосованию пригодится. Мягкий райдерский
 > захват Team. Начало.

Возьмите и меня в этот прекрасный мир с розовыми поняшами, позязя.

-- 

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

[Anton Farygin]

On 20.03.2024 07:39, Andrey Savchenko wrote:
> ACL тут не поможет, потому что ACL не повысит качество кода. Нужно
> повышать качество работы менторов, чтоб рецензентам не приходилось
> доучивать кандидатов.

Да, согласен. Но вот беда в том, что таких качественных менторов 
практически нет. Точнее не практически, а совсем нет.

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

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

[Anton Farygin]

On 20.03.2024 08:56, Andrey Savchenko wrote:
> On Sat, 16 Mar 2024 04:47:39 +0300 Grigory Ustinov wrote:
>> Доброго времени суток!
>>
>> Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я
>> как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару
>> дней прочитал ещё раз и снова не понял. Переименовать кандидатов в
>> джуниоров или что?
> По моему пониманию, топик-стартер хочет очень простой вещи: убрать
> преграду в виде рецензентов для возможности оперативного
> пропихивания большого количества пусть не вполне подготовленных, но
> лояльных и послушных мейнтенеров. А дальше можно брать числом,
> заодно регламент по голосованию пригодится. Мягкий райдерский
> захват Team. Начало.
>
Хорошие у тебя наркотики, но нет - топик стартер хочет развития а не 
стагнации команды.

Сейчас рецензенты откровенно закончились.

Тот же Автор сообщения, на которое отвечает топик-стартер откровенно 
забил на рецензирование и максимально, сколько мог затягивал процесс, 
постоянно кормя завтраками топик-стартера.

А термин Райдерский захват мне понравился, спасибо.

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

On Wed, 20 Mar 2024 10:46:34 +0300 Anton Farygin wrote:
> On 20.03.2024 07:39, Andrey Savchenko wrote:
> > ACL тут не поможет, потому что ACL не повысит качество кода. Нужно
> > повышать качество работы менторов, чтоб рецензентам не приходилось
> > доучивать кандидатов.
> 
> Да, согласен. Но вот беда в том, что таких качественных менторов 
> практически нет. Точнее не практически, а совсем нет.
> 
> В случае использования предложенной мной схемы мы получим частично 
> доверенных стажёров, которые спокойно могут заниматься развитием 
> пакетной базы репозитория в части тех пакетов, в ACL которых они стоят.

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

Не нужно так делать.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Anton Farygin]

On 20.03.2024 10:54, Aleksey Novodvorsky wrote:
>
>     стагнации команды.
>
>
> Это важный вопрос, но развития не будет с потерей качества, будет 
> деградация.

Потеря качества идёт на количестве пакетов у активных сопровождающих.

Можно качественно сопровождать очень маленькое количество пакетов .

( что нам прекрасно демонстирует Андрей Савченко в своих пакетах: 
https://packages.altlinux.org/ru/sisyphus/maintainers/bircoph/ имея 
всего одну повешенную ошибку на 7 собранных им пакетов )

А можно с меньшим качеством сопровождать сопровождать более 500 пакетов 
(пример Андрея Черепанова):

https://packages.altlinux.org/ru/sisyphus/maintainers/cas/srpms

у которого просто руки не доходят до того, что бы качественно разобрать 
531 ошибку на его пакетах в Sisyphus:

https://packages.altlinux.org/ru/sisyphus/maintainers/cas/bugs?product=Sisyphus

Примерно такая же картина у всех загруженных ментейнеров. У меня, 
например, TODO лист расписан примерно на пару месяцев вперёд _активной 
работы_.

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

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

[Anton Farygin]

On 20.03.2024 11:02, Aleksey Novodvorsky wrote:
> Но не лучше ли сосредоточиться сейчас на подготовке к бранчеванием, а 
> не обвинять друг друга? 

А я никого ни в чём не обвиняю - это не обвинение, а просто констатация 
фактов.

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

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3657 bytes --]

On Wed, 20 Mar 2024 10:49:33 +0300 Anton Farygin wrote:
> On 20.03.2024 08:56, Andrey Savchenko wrote:
> > On Sat, 16 Mar 2024 04:47:39 +0300 Grigory Ustinov wrote:
> >> Доброго времени суток!
> >>
> >> Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я
> >> как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару
> >> дней прочитал ещё раз и снова не понял. Переименовать кандидатов в
> >> джуниоров или что?
> > По моему пониманию, топик-стартер хочет очень простой вещи: убрать
> > преграду в виде рецензентов для возможности оперативного
> > пропихивания большого количества пусть не вполне подготовленных, но
> > лояльных и послушных мейнтенеров. А дальше можно брать числом,
> > заодно регламент по голосованию пригодится. Мягкий райдерский
> > захват Team. Начало.
> >
> Хорошие у тебя наркотики, но нет - топик стартер хочет развития а не 
> стагнации команды.
> 
> Сейчас рецензенты откровенно закончились.
> 
> Тот же Автор сообщения, на которое отвечает топик-стартер откровенно 
> забил на рецензирование и максимально, сколько мог затягивал процесс, 
> постоянно кормя завтраками топик-стартера.

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

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

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

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

[Anton Farygin]

On 20.03.2024 10:57, Andrey Savchenko wrote:
> On Wed, 20 Mar 2024 10:46:34 +0300 Anton Farygin wrote:
>> On 20.03.2024 07:39, Andrey Savchenko wrote:
>>> ACL тут не поможет, потому что ACL не повысит качество кода. Нужно
>>> повышать качество работы менторов, чтоб рецензентам не приходилось
>>> доучивать кандидатов.
>> Да, согласен. Но вот беда в том, что таких качественных менторов
>> практически нет. Точнее не практически, а совсем нет.
>>
>> В случае использования предложенной мной схемы мы получим частично
>> доверенных стажёров, которые спокойно могут заниматься развитием
>> пакетной базы репозитория в части тех пакетов, в ACL которых они стоят.
> К сожалению, "под развитием пакетной базы" подразумевается
> "откровенная халтура лучше, чем ничего", да ACL немного ограничит
> масштаб бедствия, но от снижения качества репозитория не спасёт.
>
> Не нужно так делать.
>
Я, как мне кажется, хорошо ответил на этот вопрос в соседнем письме.

А именно - халтура заметно растёт от количества задач (пакетов), а 
вопрос качества можно решать итерационно.

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

Наверное можно попробовать выбрать статистику по отправленным пакетам 
людей, не прошедших JOIN, но сходу непонятно как отличить на том же 
packages.altlinux.org одних от других.

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

[Anton Farygin]

On 20.03.2024 11:07, Andrey Savchenko wrote:
> И вот сейчас на рецензента пошли нападки по всем возможным каналам
> и ресурсам просто за то, что он по-человечески отнёсся к исходной
> ситуации и не прогнулся под последовавший нажим.

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

И да, действительно думаю что хорошая практика отшивать на 3.0 при 
некачественной работе ментора.

Но вот ведь в чём дело - качественных менторов примерно так же мало как 
и рецензентов.

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

[Yuri Sedunov]

В Ср, 20/03/2024 в 11:08 +0300, Anton Farygin пишет:
> On 20.03.2024 10:57, Andrey Savchenko wrote:
> > 
> 
> А именно - халтура заметно растёт от количества задач (пакетов), а 
> вопрос качества можно решать итерационно.
> 

А пошел бы ты ... пакеты собирать.

-- 
Yuri N. Sedunov

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

[Anton Farygin]

On 20.03.2024 11:13, Yuri Sedunov wrote:
> В Ср, 20/03/2024 в 11:08 +0300, Anton Farygin пишет:
>> On 20.03.2024 10:57, Andrey Savchenko wrote:
>> А именно - халтура заметно растёт от количества задач (пакетов), а
>> вопрос качества можно решать итерационно.
>>
> А пошел бы ты ... пакеты собирать.
>
Действительно, чем команду растить - иди пакеты собирай. Отличный план.

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

[Anton Farygin]

On 20.03.2024 11:14, Anton Farygin wrote:
> On 20.03.2024 11:13, Yuri Sedunov wrote:
>> В Ср, 20/03/2024 в 11:08 +0300, Anton Farygin пишет:
>>> On 20.03.2024 10:57, Andrey Savchenko wrote:
>>> А именно - халтура заметно растёт от количества задач (пакетов), а
>>> вопрос качества можно решать итерационно.
>>>
>> А пошел бы ты ... пакеты собирать.
>>
> Действительно, чем команду растить - иди пакеты собирай. Отличный план.

https://packages.altlinux.org/ru/sisyphus/maintainers/aris/bugs?product=Sisyphus

Кстати, по тебе статистика точно такая же как и по остальным активным 
сборщикам пакетов.

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

[Yuri Sedunov]

В Ср, 20/03/2024 в 11:14 +0300, Anton Farygin пишет:
> On 20.03.2024 11:13, Yuri Sedunov wrote:
> > В Ср, 20/03/2024 в 11:08 +0300, Anton Farygin пишет:
> > > On 20.03.2024 10:57, Andrey Savchenko wrote:
> > > А именно - халтура заметно растёт от количества задач (пакетов),
> > > а
> > > вопрос качества можно решать итерационно.
> > > 
> > А пошел бы ты ... пакеты собирать.
> > 
> Действительно, чем команду растить - иди пакеты собирай. Отличный
> план.
> 

А ты попробуй и пакеты собирать, и команду растить, желательно молча,
ну как я :)

-- 
Yuri N. Sedunov

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

[Denis Medvedev]

On Wed, 20 Mar 2024 10:57:17 +0300
Andrey Savchenko <bircoph@altlinux.org> wrote:

> On Wed, 20 Mar 2024 10:46:34 +0300 Anton Farygin wrote:
> > On 20.03.2024 07:39, Andrey Savchenko wrote:
> > > ACL тут не поможет, потому что ACL не повысит качество кода. Нужно
> > > повышать качество работы менторов, чтоб рецензентам не приходилось
> > > доучивать кандидатов.
> > 
> > Да, согласен. Но вот беда в том, что таких качественных менторов 
> > практически нет. Точнее не практически, а совсем нет.
> > 
> > В случае использования предложенной мной схемы мы получим частично 
> > доверенных стажёров, которые спокойно могут заниматься развитием 
> > пакетной базы репозитория в части тех пакетов, в ACL которых они
> > стоят.
> 
> К сожалению, "под развитием пакетной базы" подразумевается
> "откровенная халтура лучше, чем ничего", да ACL немного ограничит
А помнится, был такой бранч - Daedalus.
Мне кажется, что сейчас требования от Сизифа качества сильно выросли.
И сейчас уже нет "площадки молодняка", на которой можно было резвиться.
Ведь сизиф всегда был нестабилен и разломы его были обычны. На них
учились новички. И, кстати, более опытные могли поэкспериментировать
немножко.

> масштаб бедствия, но от снижения качества репозитория не спасёт.
А нужно ли качество этому репозиторию? Может качество нужно бранчам?
> 
> Не нужно так делать.
> 
> Best regards,
> Andrew Savchenko



-- 

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

[Anton Farygin]

On 20.03.2024 11:24, Yuri Sedunov wrote:
> В Ср, 20/03/2024 в 11:14 +0300, Anton Farygin пишет:
>> On 20.03.2024 11:13, Yuri Sedunov wrote:
>>> В Ср, 20/03/2024 в 11:08 +0300, Anton Farygin пишет:
>>>> On 20.03.2024 10:57, Andrey Savchenko wrote:
>>>> А именно - халтура заметно растёт от количества задач (пакетов),
>>>> а
>>>> вопрос качества можно решать итерационно.
>>>>
>>> А пошел бы ты ... пакеты собирать.
>>>
>> Действительно, чем команду растить - иди пакеты собирай. Отличный
>> план.
>>
> А ты попробуй и пакеты собирать, и команду растить, желательно молча,
> ну как я :)

Многих вырастил ?

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

[Vitaly Lipatov]

Anton Farygin писал(а) 20.3.24 10:49:
...
> Сейчас рецензенты откровенно закончились.
Они не закончились. Просто к ним предъявляют ещё больше неформальных 
требований. Меня вот например не взяли даже при том, что я априори 
согласился на все условия.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

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

[Vitaly Lipatov]

Anton Farygin писал(а) 14.3.24 21:16:
> Всем привет.
> 
> Как многим из вас известно, у нас довольно тяжёлый для прохождения 
> регламент JOIN в ALT Linux Team, включающей в себя дополнительного 
> рецензента работы ментора.
> 
> Решение о появлении  этапа контролёра понятно и было продиктовано 
> реальными случаями попадания в Team людей, не обладающих всем спектром 
> знаний для полноценной и качественной самостоятельной работой над 
> достаточно сложной и разнообразной пакетной базой репозитория.
> 
> И в целом такое решение могло бы нормально работать, но у нас появилось 
> узкое место из-за отсутствия доверенных рецензентов, реально 
> качественно проверяющих кандидатов и при этом уделяющих процессу 
> взаимодействия с кандидатом достаточно много времени.
> 
> Из опыта эксплуатации действующего сейчас регламента JOIN могу сказать 
> что вступление в команду для полноценной самостоятельной работы из-за 
> отсутствия рецензента или их оперативности стало затягиваться уже не на 
> месяцы а на годы.
...
Со своей стороны добавлю, что существуют классические пути передачи 
секретов мастерства у средневековых ремесленников.
Ремесленники объединялись в цеха. В цехе работал мастер, подмастерье и 
ученик. Ещё имелся старшина цеха.
У нас почему-то стремление к тому, чтобы внезапно после прохождения 
экзамена ученик без реального опыта становился мастером (членом Тим).
Возможно, что большу́ю часть возникшей проблемы можно решить через 
создание отношений мастер - помастерье. В отличие от ментора, который в 
силу своих возможностей и способностей поглядывает на то, что делает его 
подопечный, и иногда даёт советы, подмастерье выполняет работу мастера, 
то есть приносит пользу/облегчение в повседневных делах, взамен получая 
опыт реальной работы.
И в какой-то момент подмастерье может начать претендовать на то, чтобы и 
самому быть мастером. И это действительно срок, может быть и год.
А сейчас у нас какие-то конкуренции за независимость, суды о признании 
дееспособности, неформализованные требования. И если говорить о 
сообществе — ноль участия сообщества в принятии новых членов. А 
наверное, их и стоит спрашивать, хотят ли они видеть нового коллегу в 
своём составе или его пакеты им не сдались.

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

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] мнение кандидата

[Anton Farygin]

Антон, спасибо.

On 20.03.2024 16:39, Anton Palgunov wrote:
> Хороший тред.
>
> Я бы предложил, также высказаться самим кандидатам, какие есть 
> проблемы, как им кажется с их стороны. Так как в этот процесс 
> вовлечены обе стороны. Я сам [3.6], и я не чувствую себя ущемленным, 
> на практике пакеты можно доставить в сизиф и без join вообще, через 
> текущих участников. И я тот который пропадает, на пару месяцев, так 
> как Тима это хобби, а не работа для меня.
>
> Я бы подсветил 2 проблемы, по мотивации и продвижению с моей стороны:
> 1. Секретаря нужно больше одного - дольше всего было ожидание проверки 
> и добавления ключей, около месяца дважды в моём случае, я видимо очень 
> неудачно переходил по времени, а то и вовсе автоматизацию рутинных 
> процессов, ещё в руководстве (дописал свою ошибку в руководство в wiki)
> 2. Стандартизация подходов - переделок мелких по началу было очень 
> много чисто по стилю даже, так как нет понимания, как надо.
>
> Текущий процесс, вполне себе адекватный и не сложный, но нацелен 
> фокусом на ментора, как источник скрытых знаний, что в реальности и не 
> даёт быстро дойти до момента, "я уже собираю пакеты, требуется только 
> Approve от ментора или кого либо в команде". Но проблемы, как понимаю 
> - закончить этот процесс то есть 4+, у меня пока опыта там нет.
>
> С моей стороны. Ментор - это хорошо и помогает. Но я, на начальном 
> этапе, не в обиду своему ментору, пробовал пропихнуть пакеты и через 
> других людей, уже в Team сначала случайно, потом специально (Rider не 
> знает, но один пакет проверил мой и он в сизифе). И каждый раз это 
> были новые открытия относительно всех руководств, которые есть в wiki 
> и от ментора, а так же есть проблема, что не факт, что использование, 
> как пример другого спека из репозитория 
> https://github.com/altlinux/specs, пропустят дальше, сегодня.
>
> Поддерживаю Евгения, что отлично было бы, чтобы в команде договорились 
> о приемлемых рамках:
> > Ещё один момент - это соответствие во многом "неписанных" требований,
> которые могут быть предъявлены претенденту (кандидату в ALT Linux
> Team), тем компетенциям, которым соответствуют или не соответствуют
> уже существующие, активные члены команды (собственно, уже прошедшие в
> ALT).
>
> По таким рамкам можно было бы написать/дописать linter для пакетов и 
> применять его для всех. Возможно в целом данные правила и рекомендации 
> стоит писать, как правила линтера, как для spec, так и для gear в 
> целом применяя для всех, тем самым содержа их в актуальном состоянии. 
> Больше автоматизации данного процесса, разгружает ментора проверять 
> spec на простые ошибки, которые может допускать кандидат, тем самым 
> фокус смещается на решение реальных проблем с пакетами, а не связанных 
> с стилизацией и подходами.
>
> --- немного тематического оффтопа про вступление ---
>
> Ещё хотелось бы узнать, какие инструменты вспомогательные можно и 
> нужно использовать и какие вообще есть, особенно для обновления, какие 
> подходы для разных языков. Узнать это можно только в общении. Так как 
> наверняка у ментейнеров со стажем есть не один набор скриптов, 
> упрощающих жизнь себе. Но из публичных wiki и легко доступных есть 
> только etersoft-build-utils, наверняка есть и другие, о которых 
> упоминали в багах. Например конвертации github2spec - удобная тулза и 
> в целом шаблонизатор с 0 под языки, только нужно прочищать 
> rpmcs другой тулой, чтобы соответствовал каким либо нормам.
>
> PS. Пять копеек про Daedalus и в целом дать Полигон и мотивацию на 
> попробовать для любопытствующих, не вступая в Team, а после, чем могут 
> пользоваться всем, подключив целевой пакет себе на машину, аналогично 
> Fedora Copr. Вариант собрать самому себе - не работает, без 
> возможности поделиться со всеми. Себе я и без spec собрать могу, 
> просто с сорцов и пользоваться. А полигон такой, чтобы сделать для 
> других, но не вступая в Team, даёт мотивацию готовить spec. А оттуда 
> можно в сизиф брать хорошие варианты, через процесс review. Когда 
> собрали один-два пакета и даже готовы только их и поддерживать.
>
> PS2: По наименованию - "Кандидат" нормально и сегодня звучит, вы же 
> его и используете сейчас в переписке большинство.

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

[Alexey V. Vissarionov]

Good ${greeting_time}!

On 2024-03-20 10:13:13 +0300, Anton Farygin wrote:

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

Не ограничения, а строго наоборот - дополнительные возможности
после определенных достижений.

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

А считать кандидатов и стажеров какими-то недомейнтейнерами -
проявление какой-то тяжелой формы умственной недостаточности,
вызывающей сомнения, может ли такой человек быть мейнтейнером
(пока прям такое вроде никто не озвучивал, ну вот и не надо).


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

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

[Alexey Shabalin]

ср, 20 мар. 2024 г. в 21:18, Alexey V. Vissarionov <gremlin@altlinux.org>:
>
> Good ${greeting_time}!
>
> On 2024-03-20 10:13:13 +0300, Anton Farygin wrote:
>
>  > В моём предложении не идёт речь об ускорении прохождения
>  > кандидатов. Скорее наоборот - я за легализацию статуса
>  > стажёра, когда кандидат может выполнять много действий в
>  > репозитории, но имеет определённые ограничения.
>
> Не ограничения, а строго наоборот - дополнительные возможности
> после определенных достижений.
>
> Когда я чуть выше по треду предложил схему "кандидат, стажер,
> мейнтейнер", мне, похоже, надо было явно указать, что это три
> последовательных этапа, по мере прохождения которых участнику
> становятся доступны новые возможности самостоятельной работы.
>
> А считать кандидатов и стажеров какими-то недомейнтейнерами -
> проявление какой-то тяжелой формы умственной недостаточности,
> вызывающей сомнения, может ли такой человек быть мейнтейнером
> (пока прям такое вроде никто не озвучивал, ну вот и не надо).


Есть еще один момент.
О какой ALT Linux Team мы говорим?
О разработчиках( команда разработчиков - так говорит наша wiki) ? то
да, нужно проходить join, иметь ssh/gpg ключи.
Но в последнее время появилось еще множество Team вокруг нас. Полезных Team.
Писатели документации, тестировщики и т.д. ALT Gnome Team и др.
Участие в написании документации на wiki - join проходить не нужно,
ssh/gpg ключи не нужны.
Репорт о багах в bugzillа, на форуме - тоже ничего не нужно.
Но этих людей тоже хотелось бы "посчитать" в Team :)
И единая система аутентификации для всех наших сервисов нам бы тут
тоже пригодилась :)

-- 
Alexey Shabalin

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

[Anton Farygin]

Тему приобрела новый поворот.
Есть потребность в создании команд, которые непосредствено не будут 
заниматься сборкой пакетов - а именно дизайнеров, документаторов и 
переводчиков (с редакторами).

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

On 14.03.2024 21:16, Anton Farygin wrote:
> Всем привет.
>
> Как многим из вас известно, у нас довольно тяжёлый для прохождения 
> регламент 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 резко падает и секретарю, 
> рецензенту и самому кандидату становиться намного проще.
>
> Предлагаю обсудить этот вопрос и по результатом обсуждения я 
> подготовлю и пришлю в рассылку консолидированные предложения для 
> изменения существующего регламента.
>
>
> Антон
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Grigory Ustinov]

07.08.2024 14:14, Anton Farygin пишет:
> Тему приобрела новый поворот.
> Есть потребность в создании команд, которые непосредствено не будут 
> заниматься сборкой пакетов - а именно дизайнеров, документаторов и 
> переводчиков (с редакторами).
Я вижу это так:

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

Было бы интересно узнать другие мнения.

>
>
> Предлагаю возобновить это обсуждение и довести до логического 
> завершения - внесения изменений в регламенты.
>
> On 14.03.2024 21:16, Anton Farygin wrote:
>> Всем привет.
>>
>> Как многим из вас известно, у нас довольно тяжёлый для прохождения 
>> регламент 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 резко падает и 
>> секретарю, рецензенту и самому кандидату становиться намного проще.
>>
>> Предлагаю обсудить этот вопрос и по результатом обсуждения я 
>> подготовлю и пришлю в рассылку консолидированные предложения для 
>> изменения существующего регламента.
>>
>>
>> Антон
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

[Alexey Shabalin]

ср, 7 авг. 2024 г. в 14:14, Anton Farygin <rider@basealt.ru>:
>
> Тему приобрела новый поворот.
> Есть потребность в создании команд, которые непосредствено не будут
> заниматься сборкой пакетов - а именно дизайнеров, документаторов и
> переводчиков (с редакторами).
>
> Предлагаю возобновить это обсуждение и довести до логического завершения
> - внесения изменений в регламенты.

Давайте тогда сначал определимся с определением Join и что это
дает/как выглядит технически.
Судя по https://www.altlinux.org/Join это дает и и предоставляется
только три пункта:
* SSH-доступ к git.alt
* Возможность выкладывать пакеты в репозитории ALT
* Подписку на список рассылки devel
Даже значок на грудь или футболку не обещают :)
Получается документаторам и дизайнерам возможно не нужен ни один из
представленных пунктов, т.е. Join не нужен.
А может нужен только доступ к рассылке devel, что бы обсудить важную тему.

А вот если планируется предоставлять новые сервисы(генератор
документации, например), где требуются эти новые группы пользователей
и новые права, то да, нужно определиться сейчас
* о процедуре создания групп (групп по интересам Special Interest Group (SIG))
* о правилах приема в эти группы
* о создании новых и ревизии сущестующих ресурсов/сервисов (git,
bugzilla, wiki, и т.п.)
* о предоставляемых правах доступа на ресурсы/сервис для этих групп
(матрица доступа)

Тогда становится понятна потребность в сервисе аутентификации,
хранении на нем групп пользователей, с учетом что сервисы будут
использовать его.

Join из общего, превращается в join в конкретную группу (разработчики,
дизайнеры и т.п.) со своей символикой и ресурсами.
Сложнее становится, когда ресурсы разных групп пересекаются или
используются совместно. Не хотелось бы сдавать несколько экзаменов в
разные группы :)

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

[Anton Farygin]

On 07.08.2024 18:21, Alexey Shabalin wrote:
> ср, 7 авг. 2024 г. в 14:14, Anton Farygin <rider@basealt.ru>:
>> Тему приобрела новый поворот.
>> Есть потребность в создании команд, которые непосредствено не будут
>> заниматься сборкой пакетов - а именно дизайнеров, документаторов и
>> переводчиков (с редакторами).
>>
>> Предлагаю возобновить это обсуждение и довести до логического завершения
>> - внесения изменений в регламенты.
> Давайте тогда сначал определимся с определением Join и что это
> дает/как выглядит технически.
> Судя по https://www.altlinux.org/Join это дает и и предоставляется
> только три пункта:
> * SSH-доступ к git.alt
> * Возможность выкладывать пакеты в репозитории ALT
> * Подписку на список рассылки devel
> Даже значок на грудь или футболку не обещают :)
На самом деле нет. Сам факт того, что ты являешься участником ALT Linux 
Team значит довольно много.
> Получается документаторам и дизайнерам возможно не нужен ни один из
> представленных пунктов, т.е. Join не нужен.
> А может нужен только доступ к рассылке devel, что бы обсудить важную тему.
Да, нужна возможность нормально общаться в команде, email @altlinux.org 
и аккаунты в разных системах. В том числе на каком-то командном сервере 
git (и это не git.altlinux.org в текущем его виде)
>
> А вот если планируется предоставлять новые сервисы(генератор
> документации, например), где требуются эти новые группы пользователей
> и новые права, то да, нужно определиться сейчас
> * о процедуре создания групп (групп по интересам Special Interest Group (SIG))
> * о правилах приема в эти группы
> * о создании новых и ревизии сущестующих ресурсов/сервисов (git,
> bugzilla, wiki, и т.п.)
> * о предоставляемых правах доступа на ресурсы/сервис для этих групп
> (матрица доступа)
>
> Тогда становится понятна потребность в сервисе аутентификации,
> хранении на нем групп пользователей, с учетом что сервисы будут
> использовать его.
Конечно. Нужна будет база данных пользователей, с возможностью вводить 
разные группы.
>
> Join из общего, превращается в join в конкретную группу (разработчики,
> дизайнеры и т.п.) со своей символикой и ресурсами.
> Сложнее становится, когда ресурсы разных групп пересекаются или
> используются совместно. Не хотелось бы сдавать несколько экзаменов в
> разные группы :)

Но все, кто прошёл JOIN в какую-то определённую группу - должны при этом 
быть подписаны на общую рассылку devel@ и фактически являться 
участниками команды разработки ALT Linux Team (в широком смысле этого слова)