List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Wed, Apr 7, 2010 at 8:23 AM, Ben de Groot <firstname.lastname@example.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.