From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4F4DA1389E2 for ; Tue, 30 Dec 2014 02:23:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E11EBE0990; Tue, 30 Dec 2014 02:23:03 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6A813E098E for ; Tue, 30 Dec 2014 02:23:03 +0000 (UTC) Received: from 127.0.0.1 (12.transminn.cz [37.157.195.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 5A31D340594 for ; Tue, 30 Dec 2014 02:23:00 +0000 (UTC) Message-ID: <54A20C7E.80807@gentoo.org> Date: Tue, 30 Dec 2014 02:22:54 +0000 From: hasufell 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 MIME-Version: 1.0 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Council meeting 2015-01-13: call for agenda items References: <201412271334.34252.dilfridge@gentoo.org> <549FECF3.2090101@gentoo.org> <54A1ACCD.6000907@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: d8fe94b3-cbdd-4a0c-bf77-8bf05a59ddb8 X-Archives-Hash: 40f092fea05c149e7974874adeb72516 Rich Freeman: > On Mon, Dec 29, 2014 at 2:34 PM, hasufell wrote: >> Anthony G. Basile: >>> >>> I'd like to add a discussion on glep 39. In particular, under >>> specifications we have: >>> >>> "It may have one or many leads, and the leads are selected by the >>> members of the project. This selection must occur at least once every 12 >>> months, and may occur at any time." >>> >> >> That requirement imposes a specific structure on projects. There are >> ways to have a functional project without any lead. >> >> So that phrase should be removed altogether. >> > > I think we need to step back and think about why we have projects. > The whole point of projects is to have something in-between the > Council and anything-goes. So, if you want to know whether doing xyz > is acceptable for Python modules, you can ask the Python project. If > you REALLY disagree you can then complain to the Council, but they're > probably going to just side with the Python project since that is the > whole reason for having a Python project. > > Well, since projects are inanimate concepts you can't actually ask > them questions - you need people to talk for them. So, if 3 people on > the Python project say one thing, and 3 others say something else, > then what IS the opinion of the Python project? To settle that we > have project leads. > No, you don't need a project lead. You can just say any member can speak for the whole project at any time. Whether that works or not, is a different thing, but it's a valid model. Decisions can be reached by whatever method you want, with or without a lead. What matters is that the project is _functional_ and _responsive_. How they do that should be up to the and should not be specified anywhere. > I think that some of what sparked this question is that some projects > are fairly non-responsive, and devs don't feel at liberty to make > commits to packages under the authority of that project. IMHO the > simplest solution here is to tell people to just announce their > changes and go ahead and make them if there are no objections. The > onus has to be on the person blocking change to prevent it, unless we > want to fossilize. Of course, anybody can always go to the Council > for help, but the point isn't to micromanage every little decision > anybody wants to make. > Yeah, that's your diplomatic approach, but it doesn't work.