Drupal - Governance

Discussion

Source: http://www.osbr.ca/ojs/index.php/osbr/article/view/890/860

Key Recommendations

Angela Byron:

"Focus on the people, not the product. A team that enjoys working with one another will naturally be more productive. Take a "mental health" check of the people on your team. Is there animosity brewing between two or more groups that could be solved by them working more closely together? Is decision-making in the hands of a single individual, hampering the feeling of ownership by other, capable people? Resolving these kinds of issues should take precedence over anything else.

Eliminate barriers for those who want to make improvements. Where not absolutely necessary for security or legal reasons, fight red tape in all of its forms. Remember that a frustrated person is often best poised to lead revolutionizing changes for the better as they have the motivation. Get the road blocks out of their way and empower them to get to work.

Fight the stagnation of perfectionism by encouraging collaboration. Put processes in place that help prevent perfectionists from getting trapped in their own heads, and get them working with others instead. Not only does collaboration help achieve a more robust solution, it can be used as a mentoring tool to help raise the collective IQ of your entire organization."

=Peer Review

Angela Byron:

"In the Drupal project, as in most open source projects, improvements to the software may be contributed by anyone, but they are only added to the core software after the changes are peer reviewed. Aside from the rather obvious benefits that this process has on the quality of the contributions, the effect this peer review requirement has on the community is three-fold:

1. It actively fosters an environment of mentorship. Experienced contributors are highly motivated to help newer contributors to understand more complex areas of the software because it directly benefits them to do so. As they gain experience, new users become better equipped to help in the review.

2. It helps keep the overall community's IQ level high, as members are constantly exposed to areas of the software they may not have seen before. This naturally occurs because often the easiest way for a contributor to get their changes reviewed is to review someone else's in exchange. It also actively works to prevent less desirable and community-damaging personality traits from manifesting themselves. After all, people won't get the peer reviews they require to accomplish their goals by being arrogant, insulting, and demeaning towards others.

3. It is extremely helpful to document in as many mediums as possible (text, audio, video, interactive classes, etc.) the options available to people who want to help, and what methods they can employ to be most effective. The sooner a frustrated user realizes that there is only a collective “we" where each contributes whatever they can to make the project better, the sooner the transformation into contributor can take place. Users then learn to channel their frustration into an effective force for change."

The Problem of Perfectionism

Angela Byron:

"The natural problem-solving methodology for perfectionists tends to be withdrawal from the community and working quietly in isolation until they believe they've achieved something that is immune to criticism. This brings with it a whole host of problems, including:

1. Perfectionists never truly believe that their work is immune to criticism, because they can always find something that can be improved. In practice, their work can get permanently trapped in "analysis paralysis" and never see the light of day.

2. In the rare cases where the perfectionist feels that the ultimate, “immune to criticism” state is achieved, they can develop a deep emotional attachment to their contribution. This can lead to the perfectionist growing irrationally defensive, and rejecting or dismissing useful critique from their peers.

3. Working in isolation eliminates transparency, and removes the ability for other contributors to help. In a worst-case scenario, the larger community has already developed a solution to a problem in parallel by the time the perfectionist is finished, leading the perfectionist to extreme frustration, particularly if coupled with a deep attachment to their own solution.

4. Working offline until perfection is achieved naturally leads to fewer interactions with the larger open source community. These interactions are absolutely key to a contributor establishing their own expertise and personality within the community, which in turn directly impacts how well they are received by others. These interactions are also key to helping others understand the proposed solution so that they may provide reviews in the future.

It is vital to establish a strong culture of “release early, release often” where people are encouraged to throw solutions against the wall and find out what sticks. This results in increased visibility for individual contributors and a lack of attachment to any one solution so that the best possible solution is found.

Fighting perfectionism does not equate to compromising in quality. Perfectionists can still contribute improvements that are up to their enormously high standards, and the project still benefits. The key difference that separates healthy perfectionist contributors from unhealthy ones is the participation in a collaborative problem-solving process, rather than an introverted one. The community's processes should reward those who do the former, while encouraging those who do the latter to change their approach." (http://www.osbr.ca/ojs/index.php/osbr/article/view/890/860)