Re: Modules



Hi everyone,

Let me see if I can respond to some of today's posts and try to recap my
personal take on what the foundation should look like.

I think the Gnome foundation should be a forum for discussions about where Gnome
is headed, and for deciding what will go into specific Gnome releases.  The
Gnome foundation also gets to decide which modules are part of Gnome.  The
foundation also helps promote Gnome, organizes technical conferences and
administers funds.  But the foundation has no control over specific modules,
except that it can decides that a module isn't part of Gnome or won't be part of
a Gnome release.

Gnome-hackers will continue to be a very important place where technical issues
get hashed out.

The Board of Directors of the foundation would be the one and only central place
where final decisions about the issues I listed above get made (roadmap, release
schedule, what's included, what's part of Gnome).  The Board can also speak on
behalf of Gnome.  So if you are, for example, Microsoft, and you'd like to port
IE to Gnome and you want Gnome IE to be the "official" Gnome Web browser then
the Board of the foundation would be the right group of people to talk to (and
they would have a good laugh).  The Board of Directors should fairly represent
the Gnome community and so there should be room there for the key contributors,
or representatives of key modules, some people who can speak on behalf of key
corporate partners, folks from different continents etc.  And the board of
directors should be accountable to the Gnome Community, which I would very
broadly construe to include all active Gnome hackers and other folks who are
making a personal commitment to Gnome (as opposed to folks who are just
contributing to Gnome because that's what they're being paid to do.  So if I'm,
say, a marketing guy at Eazel working on a PR campaign promoting Gnome, that
does not give me the right to vote).  All the members of the Gnome community
would get to vote on who's on the board of directors and there's a process
whereby the Gnome community can basically fire the board if it doesn't like the
job the board is doing.

Regional Gnome Foundations, let's say Gnome Foundation Asia, would be affiliated
with the Gnome Foundation: they might have a representative on the board of
directors, and they would coordinate with the Gnome foundation to set up
technical conferences or promote Gnome is their areas.    There might be
regional funding opportunities.  For example, maybe there's government funds in
Korea that end up going to Gnome developers there.

And so the current way in which we have a bunch of modules that are part of
Gnome CVS, and a few parts of Gnome (think: Sawfish, for example) that don't
live in Gnome.org, would continue to work pretty well: John Hall is obviously an
important part of the Gnome community and would have a vote.  So the issue of
which modules are part of Gnome would be orthogonal to who gets to vote.  All
the people who get to vote would be the 'members' of the foundation.  So there
would be no corporate members.  There might be folks with corporate
affiliations, or even maybe folks representing specific companies, on the board
of the foundation; but they would have been elected by the members of the
foundation.  And I still like the idea of a slate of board members proposed by a
nominating committee or the outgoing board.

Also, I like the way George summarized things.

Did I miss something important or propose something really stupid?

Bart

George wrote:

> On Fri, Jul 07, 2000 at 01:08:32PM -0400, Havoc Pennington wrote:
> >  - should a 100-lines-of-code applet really be given the same
> >    status as gnome-core?
>
> As long as being a "project" doesn't neccessairly bring any voting rights, it
> doesn't matter.  Any decision power should be with contributors, not with
> projects.  Then if someone writes a 100-lines-of-code applet, quite likely
> this does not have the same amount of serious contributors as gnome-core has.
>
> Plus I think that this is not such a huge problem.  I think what it means for
> a project to be a project of the gnome foundation would be that they are
> doing things in accordance with some guidelines (such as using gnome-libs,
> whatever...).  I think it's more of a stamp of approval by the gnome
> foundation.
>
> > (In general I would lean toward more central control than Debian has;
> > they are effectively paralyzed by democracy at times, and their
> > technical direction and social climate suffers in some ways as a
> > result.)
>
> I think Debian has more use for central direction then we do.  We have use
> for real central direction in the libraries and in the desktop, but not for
> all the projects.  There is no reason we need to release ALL the gnome
> projects at once, and we have never done that.  I think the current model of
> projects being autonomous almost completely is a good model.  Then the
> foundation works more as a "forum" of where gnome should be going, but it
> doesn't have to really make many decisions (because if you do make decisions,
> how are you going to enforce them:).  So I don't think any central "control"
> will work here.
>
> Also the more such control you give to the foundation the more contravertial
> the election process becomes, the more contraversial will be which packages
> are part of gnome.  We also don't want to scare of new projects and
> contributors by being a buerocratic controlling beast.  (Plus the term
> "central control" reminds me of the industrial policy in socialism, which
> didn't exactly work :)
>
> > Of course, this whole issue may become more clear if we clarify what role
> > a project actually plays in the organization, which is unclear to me
> > right now. If projects are purely an informal way to organize
> > technical stuff, and the membership list is what affects
> > decision-making, then it's probably fine to be really informal about
> > the list of projects.
>
> This would be my feeling.  It would make life much simpler.
>
> George
>
> --
> George <jirka@5z.com>
>    I wanna be sedated.  -- Ramones





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]