public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Denis Dupeyron <calchan@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Council meeting 19 April 2010
Date: Wed, 7 Apr 2010 09:00:15 -0600	[thread overview]
Message-ID: <n2r7c612fc61004070800k1355c793g753cb94c2bbd3c5c@mail.gmail.com> (raw)
In-Reply-To: <v2ie117dbb91004070723rcd695995q3eb244779732b548@mail.gmail.com>

On Wed, Apr 7, 2010 at 8:23 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> 1. reconsider metadata changepolicies proposal
> ==============================================
[...]
> Can council please decide to honor
> the wish from developers to implement this?

The council will be glad to vote on a GLEP when ready. From GLEP 1,
GLEPs are the "primary mechanisms for proposing significant new
features, for collecting community input on an issue, and for
documenting the design decisions". So use them.

Also, you might want to check the log and summary of the last meeting
to find out why the council may end up voting no to such a GLEP.

> 2. website redesign
> ===================
[...]
> Can council assure that a team will be assembled that can
> effectively tackle this issue?

You want the council to aim their collective gun at volunteer
developers and force them to assemble in a team and work on something
they might not want to work on?

In other words, if you want it then work on it and make it happen.
This is and has always been the Gentoo way.

> 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?

The only way to solve this is to address these issues where they are.
That means joining the recruiters team and helping them with that.
Another thing you might want to do is properly mentor recruits.
Because one reason recruiting takes so long, and thus why there is a
backlog, is (to put is simply) that mentors suck at mentoring.

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

In case you haven't noticed there was a recent change of devrel lead.
This means it is urgent to wait for the results of the change. Because
you never know, it might just be that the change of lead was intended
to solve such things at a perceived devrel ineffectiveness.

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

This is an interesting idea which I believe I have seen discussed on
irc at some point. Feel free to work on a GLEP to address that.

Before we go any further, let me make the following PA announcement:

 1 - If you want to improve a project or subproject the best (and
often only) thing to do is to join it.

 2 - The council isn't a super-nanny metaproject with enough magical
powers to solve each and every of your oh-so-annoying problems. We do
have magic wands but you don't want to see them.

Denis.



  reply	other threads:[~2010-04-07 15:00 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
2010-04-07 15:00   ` Denis Dupeyron [this message]
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=n2r7c612fc61004070800k1355c793g753cb94c2bbd3c5c@mail.gmail.com \
    --to=calchan@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