From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: Date: Sat, 16 Mar 2024 10:59:01 +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:59:02 -0000 Archived-At: List-Archive: List-Post: 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, если он планирует заниматься > питоном или собрать питон, если он собирается заниматься чем-то ещё - > это странно. Я не говорю, что это плохо, знания лишними не бывают, но > как минимум обоснование этому можно было бы где-нибудь прописать. > Дескать каждый кандидат должен уметь то то и это. Конечно, и одна из задач, которую должна решить предлагаемая схема - это сделать так, что бы кандидат мог отвечать только за часть репозитория, в которой он силён. > >> - не имеет права голоса в принятии технических решений (но >> естественно может принимать участие в обсуждениях); > И сейчас не имеет, но может обсуждать. > А у нас сейчас нет вообще формального голосования. Этот пункт, скорее, написан на будущее.