Mailinglist Archive: opensuse-project (67 mails)

[Michael Loeffler <michl@xxxxxxxxxx>]

Hi, 
On Thursday 12 July 2007 23:19, Christian Boltz wrote:
> Hello,
--snip--
> OK, now to the board.
>
> > I'd like it to be clearer what the board can and cannot decide.
> >
> > It says the chairman has veto-power, I guess that means he can
> > *reject* proposals. How about in a situation where, say, someone
> > proposes to include some pre-alpha package management system late in
> > development phase. Would the chairman's veto-power empower him to
> > *force* proposals through?
>
> "with veto power over any decision" probably means he can override any
> _decision_, which could also mean to force proposals through.
>
> I understand that the chairperson should have some veto power, but I'd
> like to soften it so that he can't become a "dictator" ;-)
> Proposal: At least one of the other board members needs to agree with
> the veto.

The chairman with veto power is a kind of fuse for Novell to avoid that 
somehow the project goes into totally different ways than Novell is 
interested in. But no one can be interested that the chairman becomes a kind 
of dictator or uses his power to often. If that's the case the community will 
run away anyway. And this is well understood by Novell as well. 

Michael 

> > What kind of transparency would there be for the board?
> >
> > Say, it's decided to include some extremely harmful pre-alpha package
> > management system late in development phase, would it be public who
> > voted for and against on the board? Or perhaps just the numbers (3
> > yays, 2 nays, for example)
>
> Good question.
>
> Public votes have the advantage that you know who you need to call
> names, but they also have the disadvantage that everybody will call a
> specific board member names in case of problematic decisions...
>
> I'm not sure what is better here. (In other words: I prefer public votes
> unless I'm elected as a board member ;-))
>
> Opinions?
> BTW: How do the boards of other open source projects handle this?
>
> > Perhaps we could add something like: "The board decides on the
> > general direction of the project/distro. But not on day to day
> > technical decisions."
>
> Hmm, the existing text more or less contains this information
> ("shouldn't direct or control development").
> Do you think this is unclear?
>
> > > Novell appoints the initial members of the board with participation
> > > of the community.
> >
> > This is of course the very tricky part. It would be nice if a
> > procedure could be specified. And does "initial" mean that Novell
> > won't appoint the next board? For how long are board members elected
> > anyway? 2 years? 5 years?
>
> Yes, this should be clarified.
>
> IMHO the board members should be elected for max. 2 years, maybe 1 year
> is better.
> Or do something between: elect half the board every year, so that people
> stay there for 2 years, but some new people can come in every year.
>
> > Perhaps a few substitutes should be appointed initially also - so we
> > don't have strange decisions in case someone is hit by a bus and
> > needs to be replaced.
>
> I hope that we never need a substitute for such a reasen ;-)  but we can
> still have some.
> Related question: Should the substitutes only become active if someone
> is permanently unavailable or also if he is on vacation for some
> days/weeks?
>
>
> Another question: With 5 persons in the board, we have probably "only"
> 2 persons from outside Novell in the board. Do we need more? [1]
>
> I know this is also a controversial question: with more persons, you get
> more ideas and knownledge in - but you also make discussions and
> decisions slower if everybody has a differrent opinion.
>
> Opinions?
>
> > Generally it's looking very good. And I think it's a very good
> > initiative.
>
> ACK.
>
>
> Regards,
>
> Christian Boltz
>
> [1] based on the weak feedback here, there are two possibilities
>     a) there aren't many people interested in the guidlines and/or the
>        board, so we won't find more than two anyways
>     b) the proposed guidelines are accepted as is by nearly everybody,
>        so no feedback is needed
>     ;-))

-- 
Michael Löffler, Product Management
SUSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nuremberg
SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx