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]
