From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: Date: Sat, 16 Mar 2024 10:48:27 +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: Anton Farygin Organization: BaseALT 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 07:48:28 -0000 Archived-At: List-Archive: List-Post: 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 открыт для редактирования всеми, кто хочет принять в этом участие. Или ты предлагаешь взвалить эту задачу на меня, как на инициатора данного треда ?