From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2161C138334 for ; Sat, 21 Sep 2019 13:54:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 23C6CE0956; Sat, 21 Sep 2019 13:54:53 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BDFB0E0955 for ; Sat, 21 Sep 2019 13:54:52 +0000 (UTC) Received: from [192.168.5.125] (pool-96-232-115-28.nycmny.fios.verizon.net [96.232.115.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id EF58134B46B; Sat, 21 Sep 2019 13:54:51 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 (1.0) Subject: Re: [gentoo-project] Re: [RFC] Undertakers: appeal policy From: Richard Yao X-Mailer: iPad Mail (16G77) In-Reply-To: <20190921105536.2764e1e6@symphony.aura-online.co.uk> Date: Sat, 21 Sep 2019 09:54:48 -0400 Cc: =?utf-8?Q?Micha=C5=82_G=C3=B3rny?= , undertakers , comrel Content-Transfer-Encoding: quoted-printable Message-Id: <8C6FAD3C-F48F-4B2D-98A5-0CD5CDEF1DF9@gentoo.org> References: <3aab702403d9a7e0bf7246f14a5130acd464ca45.camel@gentoo.org> <20190921105536.2764e1e6@symphony.aura-online.co.uk> To: gentoo-project@lists.gentoo.org X-Archives-Salt: 1e958567-1e37-47ab-9376-31ac8d47bb02 X-Archives-Hash: 90d7f34a7fc7490e90bbcb34f66f03b8 > On Sep 21, 2019, at 5:55 AM, James Le Cuirot wrote: >=20 > On Sat, 21 Sep 2019 09:01:54 +0200 > Micha=C5=82 G=C3=B3rny wrote: >=20 >> Hi, everyone. >>=20 >> Since we currently don't explicitly indicate the appeal procedure >> for Undertaker actions, I'd like to propose adding the following to our >> wiki page. >>=20 >> TL;DR: Potential retirements can be appealed <1 mo before execution (or >> post execution), with ComRel being the first appeal instance, >> and Council being the second. >>=20 >>=20 >> Full proposed policy, with rationale: >>=20 >> 1. Both pending and past retirements can be appealed to ComRel. >> The ComRel decision can be further appealed to the Council. >>=20 >> R: ComRel is a parent project for Undertakers, so it seems reasonable to >> make it the first appeal instance. >>=20 >>=20 >> 2. Pending retirements can be appealed no earlier than one month before >> planned execution date (i.e. no earlier than after receiving third- >> mail). >>=20 >> R: This is meant to prevent premature appeals while Undertakers would >> not retire the developer anyway (e.g. due to new activity). Undertakers >> recheck activity while sending third mail, so that's a good point to >> confirm that someone's retirement is still pending. >>=20 >>=20 >> 3. Throughout the appeal process, the pending retirement is suspended.=20= >> If the appeal occurs post retirement, the developer remains retired >> throughout the appeal process. The appeal process is finished if >> either: >>=20 >> a. the Council issues final decision, >>=20 >> b. the ComRel decision is not appealed further within 7 days, >>=20 >> c. both sides agree not to appeal further. >>=20 >> R: We obviously want to avoid ping-pong of retiring, then unretiring >> (then maybe retiring again). >>=20 >>=20 >> 4. The appeal process is meant to resolve disagreements between >> Undertakers and developers. It is not a replacement for communicating >> with Undertakers. >>=20 >> R: We don't want people to appeal everything without even trying to >> resolve it between us. For example, if we missed something, then you >> should tell us rather than calling for appeal. However, if we do >> disagree on whether something counts as sufficient activity, this is >> something you can appeal. >>=20 >>=20 >> 5. The appeal process resolves each case individually based on existing >> policies. While it may influence future policies, those need to be >> carried out via appropriate policy making channels. >>=20 >> R: In other words, appeals don't change policies silently. If a policy >> needs to be changed, it must follow proper channel with ml review. >>=20 >>=20 >> WDYT? >=20 > Thanks for noticing this gap and addressing it. Given recent events > though, we must also review the wording used in regular undertaker > correspondence and also the process, if necessary, to avoid things > getting to this point in the first place. I agree. Putting a process into place to provide order to things is a defini= te improvement. I am happy to see things moving in a constructive direction.= That said, I want to point out that our ability to move in a constructive di= rection after discussion is praiseworthy. I have recently had exposure to ce= rtain other areas of the OSS community where disagreements are not handled w= ell. I find our approach to things to be a breath of fresh air in comparison= . I will refrain from naming projects, but to avoid causing misconceptions, I= will say that I am not referring to any projects where I currently have mor= e than 3 commits. >=20 > --=20 > James Le Cuirot (chewi) > Gentoo Linux Developer