From: Evgeny Sinelnikov <sin@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] Предложение к изменению в регламент JOIN -> стадии развития мантейнера (сопровождающего)
Date: Fri, 15 Mar 2024 22:42:04 +0400
Message-ID: <CAK42-GoXdkdiBJhnMGFt3Uk7iJPp8aYycGYVEqtfCp2BYMBOiw@mail.gmail.com> (raw)
In-Reply-To: <97c9a109-c863-40cc-8763-72d49d67f591@basealt.ru>
Добрый вечер,
в целом, у предложенного сценария вступления в 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)
next prev parent reply other threads:[~2024-03-15 18:42 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 18:16 Anton Farygin
2024-03-15 13:16 ` Danil Shein
2024-03-15 18:42 ` Evgeny Sinelnikov [this message]
2024-03-16 1:47 ` Grigory Ustinov
2024-03-16 7:59 ` Anton Farygin
2024-03-16 8:27 ` Aleksey Novodvorsky
2024-03-16 8:38 ` Denis Medvedev
2024-03-16 9:28 ` [devel] Голосования в Team Anton Farygin
2024-03-16 9:39 ` Denis Medvedev
2024-03-16 11:09 ` Grigory Ustinov
2024-03-16 9:26 ` [devel] голосования " Anton Farygin
2024-03-19 11:55 ` Andrey Savchenko
2024-03-20 5:56 ` [devel] Предложение к изменению в регламент JOIN -> стадии развития мантейнера (сопровождающего) Andrey Savchenko
2024-03-20 7:28 ` Sergey Bolshakov
2024-03-20 7:49 ` Anton Farygin
2024-03-20 8:03 ` Anton Farygin
2024-03-20 8:04 ` Anton Farygin
2024-03-20 8:07 ` Andrey Savchenko
2024-03-20 8:12 ` Anton Farygin
2024-03-20 14:56 ` Vitaly Lipatov
2024-03-16 7:48 ` Anton Farygin
2024-03-16 10:43 ` Dmitry V. Levin
2024-03-17 7:22 ` Alexey V. Vissarionov
2024-03-18 11:58 ` Anton Farygin
2024-03-18 11:14 ` Anton Farygin
2024-03-20 4:39 ` Andrey Savchenko
2024-03-20 7:46 ` Anton Farygin
2024-03-20 7:57 ` Andrey Savchenko
2024-03-20 8:08 ` Anton Farygin
2024-03-20 8:13 ` Yuri Sedunov
2024-03-20 8:14 ` Anton Farygin
2024-03-20 8:15 ` Anton Farygin
2024-03-20 8:24 ` Yuri Sedunov
2024-03-20 8:26 ` Anton Farygin
2024-03-20 15:19 ` [devel] мнение кандидата Anton Farygin
2024-03-20 8:25 ` [devel] Предложение к изменению в регламент JOIN -> стадии развития мантейнера (сопровождающего) Denis Medvedev
2024-03-20 5:51 ` Andrey Savchenko
2024-03-20 7:13 ` Anton Farygin
2024-03-20 18:18 ` Alexey V. Vissarionov
2024-04-17 17:41 ` Alexey Shabalin
2024-03-20 15:13 ` Vitaly Lipatov
2024-08-07 11:14 ` Anton Farygin
2024-08-07 13:14 ` Grigory Ustinov
2024-08-07 15:21 ` Alexey Shabalin
2024-08-08 5:23 ` Anton Farygin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK42-GoXdkdiBJhnMGFt3Uk7iJPp8aYycGYVEqtfCp2BYMBOiw@mail.gmail.com \
--to=sin@altlinux.org \
--cc=devel@lists.altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git