Brief list of things I maintain, co-maintain or generally tinker with --
Fluxbox, the Vim packages and plugins, various shell tools and cron things,
the odd base package that I haven't managed to move into another herd yet, the
versionator eclass, SPARC and MIPS archs. I also started and wrote most of the
unofficial devmanual and the ebuild quiz.

The role I see for the council:

The current situation with the tree is far from perfect. Things get broken,
but then, things will always break. The problem is that most of these
breakages are avoidable. I see the council as a means to reducing these.
There're a few ways that stand out:

* Technical knowledge base -- there's no real authoritative source of answers
  to technical questions currently. The devmanual has some answers, but it
  lacks any official status, and, in the current situation, seems to lack any
  way of becoming official. There've been various posts to -core and -dev that
  outline various things, but again, they don't carry any clout with the kind
  of developer who is inclined to ignore anything which doesn't have a big
  shiny "OFFICIAL" stamp on it.

  Simply dishing out mandates isn't going to work, however. Whilst Daniel
  might have been able to push through the occasional issue based upon
  authority rather than technical decisions, this isn't going to work from a
  council. The rationale-based format I use in the devmanual illustrates how
  I'd like to see things done.

* Technical guidance -- for things that don't currently have a written up
  solution, some way of getting one is needed. As it stands, any kind of
  technical decision-making will be argued to death with silliness like "if it
  isn't already written up as official policy then it's not official policy".
  There needs to be some way of breaking this.

* Technical enforcement -- as it stands, some really really broken things can
  be put in the tree and left there for a very long time simply because
  there's no-one who can step in and say "this needs to be fixed or removed".
  Similarly, there needs to be an end to the way a very small number of
  developers repeatedly and deliberately violate keywording policy, ignore
  repoman and generally screw over everyone who has to tidy up after them.
  Right now maybe half of the work done by arch teams is fixing up things that
  wouldn't've been broken had basic policy been followed.

What I don't want is a council that goes around interfering unnecessarily. The
current development process isn't broken, it's just not as smooth as it could
be. There's no need to change lots, but there is a need to apply some
lubricant here and there... Metaphorically, of course.

Similarly, I don't think Gentoo needs a super-strong roadmap as such, or at
least not one that's determined by the council. Sure, the occasional prod in a
particular direction could help, but nothing more.

I'm also not in favour of a council that's in cahoots with any of the other
high profile Gentoo groups. I think it's important that the council can and
occasionally will disagree with the Foundation -- we have a chance to get away
from the old Cabal style organisation, and we should use it.

I guess I should also comment on the non-Linux debate... In principle I like
the idea of ports to non-Linux. However, this kind of thing is *not* trivial,
and needs a lot of work to be done correctly. I'm not against non-Linux things
being moved into the main tree, *if* it is done only once all the technical
issues and problems have been properly ironed out in overlay. The way *bsd is
being handled is good. The way macos was initially handled must not be
repeated, and I'd hope that the council would step in very quickly if the same
mistakes were made again.

There's been this strange notion floating around that Gentoo should be about
giving commit access to as many people as possible and encouraging people to
spread ricer propaganda. I think this is a terrible idea. Screwing up a commit
can break all kinds of things and waste huge amounts of other developers'
time.  The last thing we want is a repeat of the 'mkdir in global scope'
fiasco.  Gentoo is *not* about inclusiveness, nor is it about giving
recognition and approval to every single project and person under the sun. A
degree of elitism is necessary and appropriate if we want to maintain any kind
of standard.

Finally, on the subject of PR. We have all kinds of brilliant products and
services that no-one else can provide. We should be selling ourselves to the
public based upon these. We should not be advertising things we are not
delivering and can not deliver. We should not be advertising based upon things
we are not. Frankly I find it disappointing that some people think so little
of what we do have that they consider it necessary to base our PR upon
anything else.