Jim Jagielski wrote:
IMO, the need for "Independent committers" is based on the
following wants and needs:
1. Reduce the influence that any single entity has over
the codebase and/or its direction.
2. Reduce the risk that, if a single entity suddenly drops
its "support" for a codebase, that development does not
immediately whither away and die.
3. Provide some sort of assurance that the committers are
personally invested in the codebase, independent of their
employment.
4. The health of a community is proportional to its diversity.
5. Reduce the risk associated when corporate drivers do not
align with community drivers (corporate entity wants A
but community wants B).
All of this makes sense. I think we should refine the meaning of
independent committer as others have suggested, going beyond just
looking at which company is the employer. The "day job" principle
that Matt suggested is one aspect. Others are the amount of
personal commitment (which I think is observable), and willingness
to put community drivers ahead of the corporate line when these
are not in sync (your point 5). This last one could be hard to
calibrate without knowing what goes on in private corporate
discussions, but I think people show by their actions how much
weight they give to community views and input when some topic is
up for discussion. The mentors should have a good sense of how
well the corporate committers follow these principles.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]