I have spent some time writing a foundation for Open Config Developer Guidelines. At the moment this is a very early draft summary of my own experience, gained through years as a software developer. A lessons learned if you will. I do hope for more people helping me on this mission
Why are developer guidelines necessary? At first it may seem as a smart-ass/dictator thing to do, trying to write people on their nose. This is far from the truth.
First, coding is a team effort. Developer guidelines are the pride and identity of the team, explaining their philosophy for collaboration and getting things done.
Second, the power lies in hands of the team, free for developers to adopt their own styles and change these guidelines together, as a team. There is no such thing as “dictatorship” in this regard, tyranny and arrogance pretending to be a democracy will turn people off.
The purpose of developer guidelines is to encourage the team to maintain a certain level of consistency and quality throughout all aspects of the project. Having different ways and opinions of achieving similar things cause confusion, inconsistency, and in the end, segregation within the team. This must be avoided, the team cannot afford loosing focus and good contributors in frustration and agony.
Do notice the emphasis on “guidelines” here, there will always be exceptions to every rule. Developers are expected to be thoughtful enough to care and take appropriate action (within reasonable boundaries) when these do not apply, maybe providing notice to the team of anomaly or ambiguity.
Individuals should not be afraid their opinions. But sometimes this cause strong philosophical disagreement to occur within the team. When this happens, the team accomplish consensus through voting. Individuals are expected to show good judgement resolving such conflicts, providing relevant justificating arguments from their point of view. If the conflict is resolved favoring a change of direction, individuals +1 voting for the proposal are expected to help making the change a reality.
The satisfaction of creativity is an energising motivator not to be underestimated. The team should feel proud of their creations, not frustrated by overly-constrainting rules.