From owner-freebsd-policy Wed Dec 1 13:57:26 1999 Delivered-To: freebsd-policy@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 0) id F2DA315024; Wed, 1 Dec 1999 13:57:20 -0800 (PST) From: FreeBSD Core Team Subject: Core policy statement 19991201 To: freebsd-policy@freebsd.org Cc: cvs-committers@freebsd.org Message-Id: <19991201215720.F2DA315024@hub.freebsd.org> Date: Wed, 1 Dec 1999 13:57:20 -0800 (PST) Sender: owner-freebsd-policy@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Core has been criticized for many things: a lack of leadership, ambiguity or inequity in its policy decisions, being unapproachable. As a distributed governing body of 16 it can be time consuming to reach decisions, and once they are made, ratifying a concise, clear description of our policies takes even longer. We know that our communication style of the past, often a failure to communicate at all, is unacceptable. We ask for your patience as we work to improve the situation. Hopefully this message, clarifying our policies on peer review and how they pertain to Matt Dillon's request for 'normalized' commit authority, is a step in that direction. Trust and respect are the cornerstones of any relationship. The punitive action taken by Core against Matt came in response to a breach of trust, not a loss of respect. Regardless of our attempts to convey this fact up to now, we have yet to see a commitment from Matt to regain our trust. Technically, he has not violated the 'review before commit' provision for his commit access, but this is only a small portion of his relationship to the project. It is understandable for an individual to lose respect for an authority that acts to control him. It is understandable for a developer with large ideas and copious amounts of free time to become frustrated with what he sees as an impediment to his progress. But none of these extenuating circumstances excuse the behavior of *any developer* who attempts to undermine the reputation of the Project or openly refute the authority of its governing body in our public mailing lists. Matt calls for respect from Core. Our respect for him never left. To rebuild Core's *trust* in Matt, however, he must demonstrate that he respects the structure and the rules that govern this project even when he may not personally agree with them. These rules, including the rules governing the content of our public mailing lists which Matt has violated, have been published and agreed to by all committers. Working to strengthen the project, abiding by the guidelines of the project, and being a team player is the path to regaining our trust. Matt has requested that Core lift the extra restrictions on his commit authority. In an environment of rebuilt trust, that request would make sense or be unnecessary as the restrictions would have been lifted by Core long ago. Unfortunately, rather than actively seek to reestablish such trust, Matt has chosen to become more and more strident in his demands that Core trust him again. Firing blistering tirades at the Core team in public is not a constructive way to regain our trust, and it pollutes the collaborative environment the developers of this project demand. Core patiently waits for Matt to stop acting in a manner which only brings results contrary to his own desires, but each outburst makes any reasonable opportunity to jump in with a compromise solution recede further into the distance. The restriction on Matt's commit authority is designed to counter one particular area of lost trust. We trust all committers to use common sense in their relationship with the project, respect other developers, and also to know when their changes warrant a review. There has always been an "unwritten rule" that changes with significant impact to FreeBSD, or in complex, central infrastructure areas (VM, VFS, etc.) require review. This policy is designed to maintain the high code quality of FreeBSD. In order to limit the restriction this "rule" imposes on progress, it is left to the developer's discretion to decide when it applies. Core *trusts* that developers will act in good faith to honor the rule, err on the side of review if ever in doubt, and revert any change in the case of a dispute. Matt Dillon violated that trust and it resulted in the revocation of his commit status. Our current policy is designed to allow Matt to work within the project while he restores that trust. As always, Core welcomes constructive commentary on how to better the project. On many occasions we have received and implemented suggestions from our user community. However, personal attacks or derisive arguments on our public lists will not be accepted from *anyone*. This is the only way we can ensure a healthy environment for collaboration in the FreeBSD community. - The core team This is the moderated mailing list freebsd-policy. The list contains policy statements from the FreeBSD Core Team. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-policy" in the body of the message