[gentoo-dev] Council meeting 19 April 2010

[gentoo-dev] Council meeting 19 April 2010

[Ulrich Mueller]

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.

Ulrich

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

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

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

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.

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

On 7 April 2010 17:00, Denis Dupeyron <calchan@gentoo.org> wrote:
> 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.


Gentoo Council project page <http://www.gentoo.org/proj/en/council/>:

"1.  Project Description
The elected Gentoo Council decides on global issues and policies that
affect multiple projects in Gentoo."

GLEP 39 also says "Global issues will be decided by an elected Gentoo council."

So all I'm asking is to do your job and make decisions on issues that
affect all of Gentoo. The issues I brought up are wider than a single
individual project.

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

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> So all I'm asking is to do your job and make decisions on issues that
> affect all of Gentoo. The issues I brought up are wider than a single
> individual project.

And almost 100% of the time this needs to run through a GLEP, which is
the case here. Then the council will do all the things you've pasted
from GLEP 39.

Denis.

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

On 7 April 2010 20:05, Denis Dupeyron <calchan@gentoo.org> wrote:
> On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> So all I'm asking is to do your job and make decisions on issues that
>> affect all of Gentoo. The issues I brought up are wider than a single
>> individual project.
>
> And almost 100% of the time this needs to run through a GLEP

Where is that policy documented?

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

Re: [gentoo-dev] Council meeting 19 April 2010

[Arun Raghavan]

Hi Ben,

On 7 April 2010 22:44, Ben de Groot <yngwin@gentoo.org> wrote:
[...]
> "1.  Project Description
> The elected Gentoo Council decides on global issues and policies that
> affect multiple projects in Gentoo."
>
> GLEP 39 also says "Global issues will be decided by an elected Gentoo council."
>
> So all I'm asking is to do your job and make decisions on issues that
> affect all of Gentoo. The issues I brought up are wider than a single
> individual project.

I don't understand what you expect the council to do in some of these
cases. Taking the website redesign or consolidation of documentation
as examples, do you want them to:

a) Decide that this should be done?
b) Call for volunteers? (they obviously cannot force anyone to do it)
c) Do it themselves?
d) What you probably mean that I fail to see

Regards,
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] Council meeting 19 April 2010

[Ben de Groot]

On 7 April 2010 23:02, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> I don't understand what you expect the council to do in some of these
> cases. Taking the website redesign or consolidation of documentation
> as examples, do you want them to:
>
> a) Decide that this should be done?
> b) Call for volunteers? (they obviously cannot force anyone to do it)
> c) Do it themselves?
> d) What you probably mean that I fail to see

Mostly, I want them to show leadership. I want the council to affirm
that these are important goals, to raise awareness of where our weak
areas are, and what needs to be done to improve things. And yes, I
want the council to call for volunteers, and where necessary to
recruit people who are able to help.

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

Re: [gentoo-dev] Council meeting 19 April 2010

[Richard Freeman]

On 04/07/2010 11:00 AM, Denis Dupeyron wrote:
>> 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.
>

To be honest, this doesn't even need a GLEP so much as a website or 
something.  If somebody consolidated all this stuff into a reasonable 
format, I bet that half the devs would pitch in and make their 
contributions.  The only thing that might warrant a GLEP is a policy 
decision that all development policies must be documented or linked from 
that site to be binding, or something like that.

I don't think that for the council to make a policy decision that there 
needs to be a GLEP.  Sure, it is the best way to make big changes, or 
changes that require some level of formality.  However, the council can 
still show leadership in affirming their agreement on issues even if it 
isn't a formal affair.  I'm sure every other town government in the 
Western World has taken a vote in support of their troops or something 
like that without going through the official lawmaking process and all 
that - it is just a gesture.

I don't have the time to create such a website although I would agree 
that it is sorely needed.  Hence, I will try to be careful in throwing 
around criticism - it is much easier to bring problems to the table than 
solutions...

Rich

Re: [gentoo-dev] Council meeting 19 April 2010

[Denis Dupeyron]

On Wed, Apr 7, 2010 at 4:30 PM, Richard Freeman <rich0@gentoo.org> wrote:
> Sure, it is the best way to make big changes

Why then use anything else than the best tool when you can use the
best tool? I didn't say that he should work on a GLEP though, but that
he should "feel free" to do so, which is different. That meant that if
he thought there was a point to it, was willing to do it, etc...

Just a note about this. The council could for example make the
decision to centralize all the documentation in a wiki, force the doc
team to use tools they haven't chosen or even take that responsibility
out of their hands. Basically step on their toes. Nice way to show
respect for all the hard work they've done for years. Or this could be
discussed on the relevant mailing-list(s) by everybody who feels
concerned, input from the whole community (including the doc team)
could be gathered, council members could chime in (I usually do),
dissenting opinions could be documented, a consensus could be reached
and then design decisions could be documented. See GLEP 1 for more
information on that work flow.

Gentoo has been driven by consensus since Daniel left, for better or
for worse. You might not like this way to work, but that's OK. I
didn't say I thought it was optimal either. All I know is I'm going by
the book, but it allows me to rewrite some pages when I don't like
them. The good news is that during the last meeting the council has
decided to initiate an overhaul of GLEP 39. I'm still gathering
material from various sources to start the discussions open to all
users and developers. At that point you'll have the opportunity to
suggest anything you think may improve the way the council works.

> However, the council can
> still show leadership in affirming their agreement on issues even if it
> isn't a formal affair.

We don't need a meeting for that. We can show leadership on the
mailing-lists everyday. What do you think I'm doing right now for
example? And by the way I don't believe that issuing a statement along
the lines of "Yep, we agree" shows any leadership at all.
Additionally, leadership is not about doing your job. You may want to
peruse the council meeting logs and summaries for examples of
leadership, and vote for real leaders next time if you think we suck.

> I'm sure every other town government in the Western
> World has taken a vote in support of their troops or something like that
> without going through the official lawmaking process and all that - it is
> just a gesture.

We've been down that road many times before, but let me say it again:
Gentoo is not a government, so any comparison to one is pointless.

> I don't have the time to create such a website although I would agree that
> it is sorely needed.  Hence, I will try to be careful in throwing around
> criticism - it is much easier to bring problems to the table than
> solutions...

Wise words, although constructive criticism is always welcome. In
order to be really constructive however, criticism needs among other
things to take into account goals, resources, history and rules.

Denis.

Re: [gentoo-dev] Council meeting 19 April 2010

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

On 04/07/2010 12:05 PM, Ulrich Mueller 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.
> 
> Ulrich
> 

Two things already discussed on this mailing list but I don't see a
definite consensus so taking for a spin through council.

1. Keywording bugs with a single arch:

http://archives.gentoo.org/gentoo-dev/msg_3f8603c9bc97b7b0bcf59782848c2650.xml

Options to vote in order:

After the maintainer has accepted that a package is good for stable (by
being the assignee or reporter).
a) The preferred way is to assign the bug to the single arch in question
b) The bug can be either assigned to the arch or the arch can be CCed
   and the maintainer is the assignee
c) The maintainer is the assignee and the arch is CCed

2. Bugzilla resolutions

http://archives.gentoo.org/gentoo-dev/msg_9cb8abe1d6608e4fb4e525833eea897b.xml

Vote on:
- Remove LATER and REMIND from resolutions
- Add LATER as a KEYWORD
- Add resolution OBSOLETE

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Council meeting 19 April 2010

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

On Wed, Apr 07, 2010 at 11:05:34AM +0200, Ulrich Mueller 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.

VALID_USE-
http://archives.gentoo.org/gentoo-dev/msg_b0e868626019f497eba47194c34e5421.xml

Historically, no PMS change has been glep'ified, but if the council 
wants PMS changes to start being glep'd I'd be willing to guinea pig 
this one- earliest I'd have the glep out the door is saturday also.

Few additional notes to the proposal-
1) few has offered up his time patch wise.
2) if he backs out, I'll throw in a gurantee of having it done prior 
to the next council meeting (realistically I can do it faster, I just 
have other fish I'd like to be frying).
3) dev feedback generally has been positive, exempting ciaran's views 
on it- please review those (if you'd like a summation I can provide 
one).
4) if there are questions re: use cycle breaking or other bits, feel 
free to ask prior please- council meeting times unfortunately right 
now intersect badly with my paying work so it's hard to be online to 
answer questions during the meeting (that said per the norm I'll try).
5) final reminder- part of the impetus of this is that if this is 
punted till EAPI5, it forces pkg_pretend as the interim use constraint 
checking- this has some nasty implications on the use cycle breaking 
intentions since it would require everyone to upgrade their ebuilds to 
EAPI5 if they've got use state constraints.  Basically screws things 
up a bit and requires a potentially pointless EAPI bump for the sake 
of trying to knock EAPI4 out the door now (regardless of how long it 
takes to stable portage for it) rather than adding a few weeks in.

Thanks-
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Council meeting 19 April 2010

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On Thu, 8 Apr 2010 05:02:25 -0700
Brian Harring <ferringb@gmail.com> wrote:
> 4) if there are questions re: use cycle breaking or other bits, feel 
> free to ask prior please- council meeting times unfortunately right 
> now intersect badly with my paying work so it's hard to be online to 
> answer questions during the meeting (that said per the norm I'll try).

Please detail your cycle breaking algorithm that works in such a way
that it's guaranteed not to toggle flags that will break a system, but
that does not require any changes to be made to ebuilds etc telling the
package manager what those flags are.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Council meeting 19 April 2010

[Patrick Lauer]

On 04/08/10 15:29, Ciaran McCreesh wrote:
> On Thu, 8 Apr 2010 05:02:25 -0700
> Brian Harring <ferringb@gmail.com> wrote:
>> 4) if there are questions re: use cycle breaking or other bits, feel 
>> free to ask prior please- council meeting times unfortunately right 
>> now intersect badly with my paying work so it's hard to be online to 
>> answer questions during the meeting (that said per the norm I'll try).
> 
> Please detail your cycle breaking algorithm that works in such a way
> that it's guaranteed not to toggle flags that will break a system, but
> that does not require any changes to be made to ebuilds etc telling the
> package manager what those flags are.
> 
That would violate the Entscheidungsproblem.

But why would you make the cycle breaking depend on an oracle? Once we
have the method in place we can find the two special cases and think of
ways to fix them. Abandoning the idea as a whole just because there may
be a corner case that isn't as easy appears quite silly to me.

Brian's proposal is the only one I've seen that is deterministic and
sane, so I think we should figure out if we can improve it instead of
giving up at the first bump in the road.

Re: [gentoo-dev] Council meeting 19 April 2010

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Thu, 08 Apr 2010 16:08:57 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > Please detail your cycle breaking algorithm that works in such a way
> > that it's guaranteed not to toggle flags that will break a system,
> > but that does not require any changes to be made to ebuilds etc
> > telling the package manager what those flags are.
> > 
> That would violate the Entscheidungsproblem.
> 
> But why would you make the cycle breaking depend on an oracle? Once we
> have the method in place we can find the two special cases and think
> of ways to fix them.

The problem is, the special cases where it goes horribly wrong aren't
rare. As soon as you start looking for cycles, you find flags like
'build', 'bootstrap' and 'acl'.

> Abandoning the idea as a whole just because there may be a corner
> case that isn't as easy appears quite silly to me.

I'm not after abandoning the idea. I'm after doing it properly, and
doing it properly starts by handling the problematic cases rather than
pretending they don't exist.

We've already seen repeatedly what goes wrong when you start with the
assumption "it'll probably work" and then pile on special exceptions
every time someone gets screwed over by something you didn't think of.
Why don't we go with "we'll only do it for things where we know it'll
work" instead this time?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Council meeting 19 April 2010

[Dror Levin]

On Wed, Apr 7, 2010 at 21:05, Denis Dupeyron <calchan@gentoo.org> wrote:
> On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> > So all I'm asking is to do your job and make decisions on issues that
> > affect all of Gentoo. The issues I brought up are wider than a single
> > individual project.
>
> And almost 100% of the time this needs to run through a GLEP, which is
> the case here. Then the council will do all the things you've pasted
> from GLEP 39

I thought the council was a body that should be capable of action, not
merely one that gives a stamp of approval for stuff other people do.
Was I wrong?

Reading all your manifestos from the elections shows you all had
things you wanted to do, things you wanted to change (git migration,
forming a group of experts to discuss technical issues, QA
propagation, just to name a few). Where did all that go to? If all the
council is currently able to do is get everybody involved in
bureaucracy (e.g. writing GLEPs for centralizing documentation instead
of putting a page full of links) just so it could meet once a month to
decide on bugzilla resolutions, then something is wrong.

All council members not only volunteered for that position, but also
had other people voting for them. Didn't you do that so you could have
a larger influence? So you could make Gentoo better? How do you plan
to achieve that if you just wait for other people to do it? I don't
see why there is such strong opposition by your side to actually do
something, after all, that's what you're there for.

As I've seen in the last few days, the common reaction to this is,
"Well, what do you want us to do? Force people to do stuff?". Why did
you want to be a council member if you have no idea how to accomplish
the things you wanted to do? How did you think you were going to
achieve all those things written in your manifesto? Being in the
council is a responsibility, and one which you took upon yourself
willingly. All we're now requesting is that you all stand up to that
responsibility and use your authority to make changes to how Gentoo
work, not point fingers and ask rhetorical questions.

Ben raised some very painful issues which hurt Gentoo daily but are
not being addressed for a long time. The way I see it, the council's
job is to lead Gentoo, and that includes things that individual
members may not find interesting. These are global issues which are
under the council's responsibility. Gentoo's best interest should be
in mind, not personal interests, and so the council should strive to
achieve all those things so that Gentoo may benefit from it. That's
what leadership is, and that's what your job is.

Let's take redesigning the homepage as an example. Our website has the
same design since at least 2002, and to users it looks dead. This is
seriously hurting Gentoo, and its inability to fix the situation has
become a laughing stock. Clearly, Gentoo as a whole suffers and it's
the council's responsibility to address this issue. Now, I'm not
saying that council members should sit around all day playing with
CSS, but this issue should be one of their top priorities. Maybe ask
for users to help, reward a volunteer to do it with funds from the
foundation, heck maybe even pay some company to do it, but just do
something, even though you may not think dealing with this is
interesting, but a response like "if you want it then work on it and
make it happen" is unacceptable.


Note that all that is said here is not pointed at any specific member
of the council, but at the council as a whole. I did not intend to
hurt anybody, but am genuinely concerned for Gentoo's well being.

Dror Levin

Re: [gentoo-dev] Council meeting 19 April 2010

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 3655 bytes --]

On 04/09/2010 05:51 PM, Dror Levin wrote:
> On Wed, Apr 7, 2010 at 21:05, Denis Dupeyron <calchan@gentoo.org> wrote:
>> On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>>> So all I'm asking is to do your job and make decisions on issues that
>>> affect all of Gentoo. The issues I brought up are wider than a single
>>> individual project.
>>
>> And almost 100% of the time this needs to run through a GLEP, which is
>> the case here. Then the council will do all the things you've pasted
>> from GLEP 39
> 
> I thought the council was a body that should be capable of action, not
> merely one that gives a stamp of approval for stuff other people do.
> Was I wrong?
> 

It's capable of action if the members want to take it.

> Reading all your manifestos from the elections shows you all had
> things you wanted to do, things you wanted to change (git migration,
> forming a group of experts to discuss technical issues, QA
> propagation, just to name a few). Where did all that go to? If all the
> council is currently able to do is get everybody involved in
> bureaucracy (e.g. writing GLEPs for centralizing documentation instead
> of putting a page full of links) just so it could meet once a month to
> decide on bugzilla resolutions, then something is wrong.
> 

Let's see my manifesto:
- EAPIs: council is not the blocker
- Meetings: there will be a web application most likely in GSoC

> All council members not only volunteered for that position, but also
> had other people voting for them. Didn't you do that so you could have
> a larger influence? So you could make Gentoo better? How do you plan
> to achieve that if you just wait for other people to do it? I don't
> see why there is such strong opposition by your side to actually do
> something, after all, that's what you're there for.
> 

I said in my manifesto that Gentoo is not my first priority so you get
what you vote for :)

> 
> Ben raised some very painful issues which hurt Gentoo daily but are
> not being addressed for a long time. The way I see it, the council's
> job is to lead Gentoo, and that includes things that individual
> members may not find interesting. These are global issues which are
> under the council's responsibility. Gentoo's best interest should be
> in mind, not personal interests, and so the council should strive to
> achieve all those things so that Gentoo may benefit from it. That's
> what leadership is, and that's what your job is.
>

Many of the points Ben raised are doable by any single developer who
wants to do the work. Just show up with the code/patches.

> 
> Let's take redesigning the homepage as an example. Our website has the
> same design since at least 2002, and to users it looks dead. This is
> seriously hurting Gentoo, and its inability to fix the situation has
> become a laughing stock. Clearly, Gentoo as a whole suffers and it's
> the council's responsibility to address this issue. Now, I'm not
> saying that council members should sit around all day playing with
> CSS, but this issue should be one of their top priorities. Maybe ask
> for users to help, reward a volunteer to do it with funds from the
> foundation, heck maybe even pay some company to do it, but just do
> something, even though you may not think dealing with this is
> interesting, but a response like "if you want it then work on it and
> make it happen" is unacceptable.
> 

Just petition the trustees to spend money on it. I guess Debian is dying
too then:
http://web.archive.org/web/20020124014701/http://www.debian.org/

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Council meeting 19 April 2010

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

I was asked on #gentoo-council to respond to this post so I will. It
should also be noted council members usually speak as individual members
instead of for the council as a whole.

On 04/07/2010 06:00 PM, Denis Dupeyron wrote:
> 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.
> 

This doesn't exclude council members themselves from working on such a
GLEP if they think it's needed.

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

Council can't assure it will happen, they can only encourage and work
towards such a goal.

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

As said Council is not needed. Recruiters as a project can handle
improving it just fine. I think I have pinged gentoo-core quite a few
times to try get new people in, would it make a difference if I pinged
as a council representative instead of as the Recruiting lead? Good news
is that I have two people in training nowadays.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] Council meeting 19 April 2010

[Brian Harring]

On Thu, Apr 8, 2010 at 5:02 AM, Brian Harring <ferringb@gmail.com> wrote:
>
> On Wed, Apr 07, 2010 at 11:05:34AM +0200, Ulrich Mueller 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.

Wrote it up as a glep-

http://dev.gentoo.org/~ferringb/gleps/required_use.html

Longer term, I'd like to see all EAPI related changed proposed as
Glep's so the discussion and logic for a feature is properly
documented, including alternatives and counter proposals to it.
Basically the same thing Python does with their Python Enhancement
Proposals (Peps, which is where Glep's came from).
Thanks,
~harring