Programming Historian Governance

Lazy Consensus

The editorial board of The Programming Historian strives to arrive at decisions via a gradual, lazy consensus-like model. Under this governance approach, we do not hold formal votes. Rather, potential policy or work suggestions are welcomed on any one of our venues for team discussion. Members who have a specific interest in an issue (whether in approval or in dissent) are expected to make their voice heard on one of these venues. Sub-teams are empowered to make decisions on behalf of the project (with the exception of policy level changes, see below), but must do so in a sufficiently transparent way that if any team members object to a course of action, we will not move forward without addressing those objections. Silence on a given issue is treated as assent.

The Apache Community guidelines explain the goals behind this approach:

The key thing about lazy consensus is that it's easier for people to agree, by doing nothing, than it is to object, which requires an alternative to be proposed. This has two effects, firstly people are less likely to object for the sake of it and secondly it cuts down on the amount of unnecessary mail traffic and discussion.

Lazy consensus means we can avoid waiting for a community based decision before proceeding. However, it does require everyone who cares for the health of the project to watch what is happening, as it is happening. Objecting too far down the road will cause upset, but objecting (or asking for clarification of intent) early is likely to be greeted with relief that someone is watching and cares.

Although we seek to streamline discussion with this method, we recognize the importance of consensus building on foundational policy decisions. Because our project team is global, and volunteers their extra time to support The Programming Historian, we are mindful that enough time be allotted for all members to be able to read proposals and register their opinions if they choose. If there is some actionable item that will have a significant impact on editorial processes, such as adding new text to the editorial guidelines for example, then a formal deadline for feedback will be announced on all venues, and the issue tag policy will be added to the ticket. It is preferable that this deadline should be set to fall after the next editorial call, so that all team members have an opportunity to register their opinions in the venue of their choosing. If no members voice objections to the proposal before the deadline, then we'll proceed with work on the issue (at the point, we remove the policy tag from the issue). If it is clear that continued discussion is warranted, however, then we will hold off on implementation until we can achieve consensus.

Venues for discussion

• GitHub issues
• Monthly Skype calls
• Google Groups mailing list