Skip to content

Latest commit

 

History

History
59 lines (45 loc) · 2.86 KB

GOVERNANCE.md

File metadata and controls

59 lines (45 loc) · 2.86 KB

This is all hypothetical and subject to change. This document is only really relevant if Zokka gets enough adoption to actually require a governance structure.

In light of Zokka's tightly scoped technical goals as well as the current state of Elm's community, Zokka's social dynamics will look different from Elm's.

In particular Elm's community is:

  • Stable: the number of Elm veterans in the community outnumbers the number of new Elm developers.
  • Relatively consistent when it comes to opinions about what Elm code should look like:

And as a reminder Zokka does not intend (at least not until 2025) to do feature development on the Elm language itself or any expansionary feature development on the Elm compiler.

This mean that Zokka does not really need a visionary at its helm or large amounts of time and energy spent on groundbreaking features. What Zokka needs instead foremost is a low, but consistent, amount of attention to accept PRs and bug reports from the community. Secondarily, as time allows, Zokka will slowly grind through bugs that have no PRs.

The absence of a need for radical design or commitment and instead a focus on a consistent source of low amounts of energy makes Zokka a good fit for committee leadership rather than individual leadership.

As such Zokka hopes to

  • Maintain at least five active members of the zelm and zelm-explorations GitHub organizations who have push/merge permissions across the repositories managed by those organizations. Potentially more than five, but ideally remaining at some odd number to allow for tie breaks in the (hopefully rare) case of controversial decisions.
  • Regularly rotate out any inactive members (people who do not feel they can engage more than once a week) for active members.

These are hopes not commitments. But I do consider them valid barometers of whether Zokka has a project has succeeded.

Because Zokka does not intend (at least not until 2025) to do feature development on the Elm language itself, Zokka makes a different set of social trade-offs compared to Elm itself.

Concretely, Zokka hopes to achieve timely (< 1 week) responses to issues and PRs that fit within Zokka's mission scope, i.e. bug fixes to foundational packages or to the compiler. These should be fixes with very few or no questions of design and no changes to any APIs.

Note that responses do not necessarily mean that issues will be fixed or PRs will be merged. Again, because of how tightly scoped Zokka's technical mission is, it is likely that many issues and PRs will lie outside what Zokka intends to address at least until 2025. Even if the issue or PR lies within Zokka's scope, it may either be tricky to fit or to merge in.

However, even if you don't get your issue fixed or merged into a Zokka repository, Zokka gives you the tools through custom repositories and package overrides to do a lot of this on your own!