Skip to content

Latest commit

 

History

History
89 lines (64 loc) · 6.58 KB

GOVERNANCE.md

File metadata and controls

89 lines (64 loc) · 6.58 KB
Raw

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 CODE_OF_CONDUCT.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 steering team

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

If steering team members cannot reach consensus informally, the question at hand will be forwarded to the steering 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 / working 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 steering team members are:

Way of working

The steering 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 steering team can be found on the steering team project board.

No individual or organization will employ a simple majority of the steering 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 steering team. Each working or action group must be represented in the steering group 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 steering 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 steering 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 CODE_OF_CONDUCT.md.

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