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 8219D139085 for ; Thu, 19 Jan 2017 21:40:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C0D1A234108; Thu, 19 Jan 2017 21:40:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 811BC23409A for ; Thu, 19 Jan 2017 21:40:17 +0000 (UTC) Received: from katipo2.lan (unknown [IPv6:2406:e001:1:d01:de0e:a1ff:fea1:6ec4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id C6A383413B7 for ; Thu, 19 Jan 2017 21:40:15 +0000 (UTC) Date: Fri, 20 Jan 2017 10:39:49 +1300 From: Kent Fredric To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] RFC: GLEP - Require Projects to report to Council Monthly Message-ID: <20170120103356.2e704bd7@katipo2.lan> In-Reply-To: References: Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/OUAovYl8U2E+D2XF5So9/MH"; protocol="application/pgp-signature" X-Archives-Salt: dafe8451-78d0-47e0-bebc-28e7d21d20df X-Archives-Hash: a5dd679bec30d2bc0596000b2423f5dc --Sig_/OUAovYl8U2E+D2XF5So9/MH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 19 Jan 2017 13:45:39 -0500 "William L. Thomson Jr." wrote: > I think that should be expanded as a require for a project. If a project = is=20 > formed, it should be required to report on a monthly basis to the council= . It=20 > does not have to meet monthly I think this starts out with a wrong priority.=20 The framing here is that this structure is a stick to keep everyone in line, and that the beatings shall continue to drive up morale.=20 Where I think the priority needs to focus on *facilitating* progress, by cr= eating systems that *empower* and *enable* clearer communication, like making sure= that the donkey has somewhere to sleep at night and has plenty of water so it ca= n actually do its job the next day, instead of hoping a stick or carrot can be a magic= al solution. As such, a mandatory scheme that requires projects to report back to an aut= hority is distasteful. I'd rather a more informal structure, where somebody is appointed the task = of polling the different projects and asking them questions like:=20 - Is there anything the project needs - Are there any changes you're doing now or in the future that would be use= ful for people to know about ( including other members of the project ) And I would take more concern if given projects couldn't be reached for com= mentary. If a project can be reached for commentary, but has nothing specific to rep= ort back, then that should be fine. If a project doesn't need to declare a need for anything from other project= s, or doesn't care to inform other projects what its doing, that should be fin= e. There would naturally be some conceptual overlaps here with the GLEP 42 gen= too news system, and some overlap with the Gentoo newsletter, and so anything t= hat falls into either of those would be good examples of things to mention, and ear-tag as such. ( Which may potentially facilitate those groups ) As an adjunct, it might also be useful to have some sort of active "status = board" for different projects that can be edited by anyone easily and can easily b= e displayed in bulk, and not have any real requirements on its frequency of change. For example, to an extent IRC /topic's are used in a limited fashion for th= is sometimes. But it needs a little more space than whatever that limit is. But it doesn't ( and shouldn't ) need a full blank web page, and should ide= ally be no larger than a moderate but concise git commit message. So probably somewhere less painful to deal with than a wiki would be nice. But this status board can help inform the person doing the polling and others in a slightly more immediate fashion, not bound by clock cycles, but by necessity. And for groups who want to bother to sit down and have meetings, brief outcomes from those meetings could be part of that status board, perhaps with longer contents in links. --Sig_/OUAovYl8U2E+D2XF5So9/MH Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAliBMjQACgkQ6FQySxNm qCDPPw/8C/YGsawrPMp85sFaay26Z6bJet2dtfjTm5ngfoxPsEuohlprNZdR6JUi I9jFSBu5VfyMBGvDFGPlCYj85kzHR3jrs4jqIABfoqDFxgRPpFvWAZWX33mub+hA nt0c1ltK4ExOQ2yK4VmlAyt0GKB0DWJHqPMykrLcfRPD9vKHpWEXtnUzfVUCP55U 30hVHto7N4g+wIUDSPrSTgc87W81syHfjJz8Rj0nlLrGw+etTmS09eM8v7Vikay5 hipZxgBXIGsEqHJUhvGWIquHzDReDNC+BB+bEw207qMUBNVbRveCg1OsOTSzcDtG kEEU13tswBlADPAvpaCF9tfdS3Z1YlnhTWA07SVckU1Vgw8y3wx3xSW7cfPNuy5n 13M8eOorEAl13rVlQD1KqJ1QJKInwYQpLnrumeF5IKXnq89utvJEjdampfa8PsfC iPWpu5gPhTWl6VCzafE1ND2b6sD56/jhmSWl7PDMZ8FcOe+7wIIVQwdmapqZ+ukq dBzTvMZzsI46dWCwxQpwajbNq9ngGLHXLV9PF/k6/3XPwmIq5fy72nhd/M7E2nWm +rk97FfVVxPTaxZgGOMBnvUirMV/DdcGE4Kbp/u1z1fPT76qr79qW1v8sPYEIOqH pK8g4BdRfH1eufSj2CfAZfHKbCJYSgzouxxAZjvPpNq/mU10lok= =G6PA -----END PGP SIGNATURE----- --Sig_/OUAovYl8U2E+D2XF5So9/MH--