Candidate Q&A - List of Questions

[Daniel Stone]

On Wed, Feb 16, 2011 at 04:27:28PM +0100, Luc Verhaegen wrote:
> On Wed, Feb 16, 2011 at 03:22:26PM +0000, Daniel Stone wrote:
> > On Wed, Feb 16, 2011 at 04:11:26PM +0100, Luc Verhaegen wrote:
> > > Do you really find it normal that exactly this is being pushed for?
> > > 
> > > Stuart Kreitman (the new treasurer) only received those financial 
> > > records that Keith Packard (the old treasurer) had kept for the previous 
> > > 5 years or so, a few weeks ago. Why did no-one flag this before? And 
> > > what will happen if more members of the same company will be on the 
> > > board?
> > 
> > Since you seem to be accusing me to be part of some kind of conspiracy
> > (harming X.Org by electing more Intel employees to withhold financial
> > records?), at least have the decency to be specific about what you're
> > accusing me of.
> 
> Ok.
> 
> Feel free to describe, in your own words, what possible reason could you 
> have to ask for suggesting to change this in the bylaws?

It was in response to a question asked to the candidates about that
exact same part of the bylaws.  There are two Intel candidates running,
plus one already on the board, and I believe all three would make good
board members.

The no-more-than-two rule was instituted when the Foundation began, to
avoid not only the Consortium's problem whereby companies would use the
management/oversight arm to strongarm their code in, but to avoid even
the very perception of that.  Remember that XFree86's most prominent
scaremonger against X.Org was that it was 'vendor-dominated', and not a
true community project: merit was allegedly derived from your employer,
not from your code.

We've long passed that point though.  Seven years later, we've
demonstrated a viable technical community which can not only handle the
load of maintaining the X stack, but is also able to engage in robust
technical debate.

In 2004, the problem was that submissions arrived as megapatches which
were little understood beyond their authors.  Now, with easily
reviewable microcommits, we're able to evaluate every submission on its
merits, in public.  This has led to a drastic improvement in quality of
code, and to a number of submissions being held off until everyone is
satisfied that they're in good state to be merged.

Not only that, but this has happened _completely independently_ of the
Foundation.  The Foundation makes sure X.Org doesn't fall down a well,
keeps the infrastructure running, organises conferences, and only steps
in when something is serious enough to warrant Board intervention.  Even
then, the Board tends to spend quite a while evaluating whether it
should even step in.

So, I don't think those concerns are relevant anymore.  And that would
be fine, but for the the Foundation's current problem: finding enough
people to even run for the Board.  This year's election is not the
first where the nomination period has had to be extended because we've
had more Board vacancies than candidates.  I fail to see how this isn't
a serious problem.  I thus fail to see the continued usefulness of a
rule which a) does not solve the problem it was brought in to solve, as
it is now irrelevant, and b) indeed actually harms the Foundation by
unnecessarily limiting candidates for the Board, when even without this
rule we don't always have enough candidates to have an election!

> Apart from triggering a reaction from me of course.

Well, either I wanted to raise a legitimate question -- no, not even
raise, more expand upon a question someone else raised -- to the
candidates to improve the Foundation, or I was desperately hoping to
get a reaction from you to kick off yet another staggeringly pointless
argument.  Funnily enough, it was actually the former.

I'm not going to entertain any more insane conspiracy theories on public
lists: it's a waste of everyone's time to read this crap.  If you want
to continue this, feel free to do it in private mail.

Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://foundation.x.org/archives/members/attachments/20110216/729322cf/attachment-0001.pgp>