public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ben de Groot <yngwin@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Council meeting 19 April 2010
Date: Wed, 7 Apr 2010 16:23:42 +0200	[thread overview]
Message-ID: <v2ie117dbb91004070723rcd695995q3eb244779732b548@mail.gmail.com> (raw)
In-Reply-To: <19388.19166.779165.480708@a1i15.kph.uni-mainz.de>

On 7 April 2010 11:05, Ulrich Mueller <ulm@gentoo.org> wrote:
> Next monthly council meeting will be at 19 April 2010, 18:00 UTC
> in #gentoo-council.
>
> If you have any topics you want us to discuss or even vote about,
> simply followup to this message.

1. reconsider metadata changepolicies proposal
==============================================

The fact is there is a spectrum from ebuild maintainers' side about
how desirable it is for non-maintainers to step in, ranging from
"don't touch this ever" to "please do touch this". There may be very
valid reasons for this (in some cases intimate knowledge of the
package may be required, for example, or on the opposite side someone
might not have the time or motivation to do much about that specific
package) that have little to do with territoriality. While there is a
need for basic policies to be made more explicit, it is also obvious
that there is no good "one policy fits all" approach. The metadata
changepolicies proposal beautifully captured this spectrum and has
wide support from developers. While this information isn't directly
useful to users, the argument that it "would bloat the file for no
good reason" is false, because there are very good reasons: to
facilitate cooperation between devs as well as a better overall
quality of the tree. This benefits users, so I'm quite sure they don't
mind we use metadata.xml for that. Can council please decide to honor
the wish from developers to implement this?


2. website redesign
===================

This is a recurring theme in discussions about Gentoo's shortcomings.
While there have been some minor improvements in recent years, the
resign project itself failed miserably, but is still as needed as
ever. We should have one elegant design that will be consistently
applied to all official Gentoo websites. A look at znurt.org should
convince anyone of what can be done. Also our frontpage needs to be
more focussed on communicating the things users and new visitors are
looking for. Can council assure that a team will be assembled that can
effectively tackle this issue?


3. manpower and recruitment issues
==================================

Another recurring theme is the lack of manpower in certain areas, the
recruitment bottleneck and the quizzes. There are some initiatives but
more decisive leadership is needed. Can council decide to actively
pursue solutions for these structural problems?


4. devrel ineffectiveness
=========================

What can be done to assure that conflicts are addressed in a timely
and effective manner by DevRel? What can be done to remove poisonous
people from Gentoo and its communication channels more decisively and
effectively? The fact that many people indicate they do not want to
become a developer for this exact reason, should be cause for concern.
Can council make a statement that they share these concerns and are
actively looking to address them?


5. centralize developer documentation
=====================================

Currently the documentation a developer needs to effectively write
ebuilds and maintain packages is scattered all over the place. We have
the (incomplete) devmanual, the developer handbook, various guides and
policies in individual projects, the GLEPs, council decisions, and a
legacy of unwritten rules or poorly documented policies. It would be
very helpful to centralize all that information, and work on properly
documenting our policies. At the very least there should be one page
that funtions as a portal to all existing relevant information. Even
better would be to have as much of that relevant information as
possible consolidated into one place, so that everyone knows where to
go to look that up. Can council decide to see this implemented?

Thanks,
-- 
Ben de Groot
Gentoo Qt project lead developer
Gentoo Wiki project lead



  reply	other threads:[~2010-04-07 14:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-07  9:05 [gentoo-dev] Council meeting 19 April 2010 Ulrich Mueller
2010-04-07 14:23 ` Ben de Groot [this message]
2010-04-07 15:00   ` Denis Dupeyron
2010-04-07 17:14     ` Ben de Groot
2010-04-07 18:05       ` Denis Dupeyron
2010-04-07 18:22         ` Ben de Groot
2010-04-09 14:51         ` Dror Levin
2010-04-10 13:47           ` Petteri Räty
2010-04-07 21:02       ` Arun Raghavan
2010-04-07 21:45         ` Ben de Groot
2010-04-07 22:30     ` Richard Freeman
2010-04-08  1:27       ` Denis Dupeyron
2010-04-10 15:36     ` Petteri Räty
2010-04-08 11:41 ` Petteri Räty
2010-04-08 12:02 ` Brian Harring
2010-04-08 13:29   ` Ciaran McCreesh
2010-04-08 14:08     ` Patrick Lauer
2010-04-08 14:14       ` Ciaran McCreesh
2010-04-11  2:51   ` Brian Harring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=v2ie117dbb91004070723rcd695995q3eb244779732b548@mail.gmail.com \
    --to=yngwin@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox