From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.1 Message-ID: Date: Sat, 16 Mar 2024 04:47:39 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: ru To: devel@lists.altlinux.org References: <97c9a109-c863-40cc-8763-72d49d67f591@basealt.ru> From: Grigory Ustinov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0J/RgNC10LTQu9C+0LbQtdC90LjQtSDQuiDQuNC30Lw=?= =?utf-8?b?0LXQvdC10L3QuNGOINCyINGA0LXQs9C70LDQvNC10L3RgiBKT0lOIC0+INGB?= =?utf-8?b?0YLQsNC00LjQuCDRgNCw0LfQstC40YLQuNGPINC80LDQvdGC0LXQudC90LU=?= =?utf-8?b?0YDQsCAo0YHQvtC/0YDQvtCy0L7QttC00LDRjtGJ0LXQs9C+KQ==?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2024 01:47:47 -0000 Archived-At: List-Archive: List-Post: Доброго времени суток! Вы главное ЕАЭ (Единый Альтовый Экзамен) не вводите. Честно сказать я как прочитал, сразу не понял, чего хочет топик-стартер, а спустя пару дней прочитал ещё раз и снова не понял. Переименовать кандидатов в джуниоров или что? Потому что фактических изменений я особо не вижу. Разве что разрешение кандидатам собирать пакеты со своим ацл. Сейчас, я напомню, такие пакеты требуют одобрения любого участника тим, как и любые другие. Давайте по пунктам: > Предлагаю считать кандидата на стадии 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 : >> Добрый день! >> >> Относительно наименования нового участника 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 > >