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@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org