DRAFT: Governance for Demodam

Goals of Demodam

  • Showcase. Demodam shows working digital services that municipalities (and possibly other governmental organisations) can re-use.
  • Collaborate. On Demodam we learn how we collaborate in the Common Ground ecosystem. This happens both at a systems level (how do components interact?) and at a human level (how do we work together?).
  • Improve. Set standards together: when do we say a component is ready for production?
  • Innovate. By offering a stable and rich software environment, it becomes easier to develop new digital services.

Demodam principles

  • Our community is welcoming and respectful as mentioned in our CODEOFCONDUCT.md. As a community we want to make it easy for new members of the community to take part, regardless of background and level of knowledge.
  • We are Transparent and accessible. Changes to the Demodam organization, Demodam code repositories, and Demodam-related activities (e.g. level, involvement, etc.) are done in public.
  • Ideas and contributions are accepted according to their merit and alignment with project objectives, scope, and design principles.
  • Demodam is open source.

Through codebase stewardship the Foundation for Public Code supports the governance of Demodam, the steering team, and its community.

Join Demodam!

So, convinced already, are you? Excellent. Please join us! Find out how you can join and contribute.

Demodam core team

The Demodam steering team oversees the overall direction of Demodam. Any active member of the community can request to become a core team member by asking the core team. The core team will vote on it (simple majority). The core team strives to be a team in which several perspectives (knowledge, type of organizations) are represented.

If core team members cannot reach consensus informally, the question at hand will be forwarded to the core team meeting.

Joint responsibilities

  • Maintaining the mission, vision, values, strategy, roadmap, branding and scope of the project

    • Collecting planned features and presenting them in a unified view
    • Manage the Demodam brand

  • Community and governance matters

    • Control rights to Demodam assets such as source repositories
    • Make codebase level decisions
    • Refine the governance as needed
    • Control access to Demodam assets such as hosting and project calendars
    • Handling code of conduct violations
    • Oversee licensing and intellectual property changes

  • Conflict resolution

    • Serve as an escalation level for the action groups
    • Resolve escalated project decisions when a sub-team responsible is blocked
    • Resolve issues in development or conflicts between contributors

  • Technical matters

    • Set and decide technical constraints and standards for the Demodam environment
    • Provide technical direction for the codebase
    • Maintain a technical roadmap, an architecture and coding principles
    • Manage and plan releases
    • Overseeing the resolution and disclosure of security issues

Team members

The current core team members are:

Way of working

The core team meets regularly. Their agenda includes review of the technical roadmap and issues that are at an impasse. The intention of the agenda is not to review or approve all patches. This is mainly being done through the process described in CONTRIBUTING.md. Meetings and their agenda will be announced on the mailing list and on Slack. The action items and agenda's of the core team can be found on the core team project board.

No individual or organization will employ a simple majority of the core team.

Action teams

The Demodam codebase forms action teams to solve specific tasks. These can make day-to-day decisions to move things forward, but cannot overrule decisions made by the core team. Each working or action group must be represented in the core team by at least one person. If a group cannot resolve an issue with consensus in the group, any participant of the group can raise the issue to the core team.

Decision making process

The default decision making process is lazy-consensus. This means that any decision is considered supported by the team making it as long as no one objects. Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will.

When a consensus cannot be found a team member can call for a majority vote on a decision. Every team member has 1 vote, but each organization can be represented by only 1 team member in a vote regardless of how many members from their organization there are on the team.

Many of the day-to-day project maintenance tasks can be done by a lazy consensus model. But the following items must be called to vote:

  • Adding a team member (simple majority)
  • Removing a team member (simple majority)
  • Changing the governance rules for non-trivial changes (this document) (simple majority)
  • Licensing and intellectual property changes (including new logos, wordmarks) (simple majority)
  • Adding, archiving, or removing sub-projects (simple majority)

Votes related to these items need to be communicated to the core team and put on the agenda upfront with enough time prior to the meeting where the voting takes place. All decisions shall be documented in a version control system.

Code of Conduct

Demodam's Code of Conduct is explained in CODEOFCONDUCT.md.

If the possible violation involves a team member that member will be recused from voting on the issue.