Simplified README, reference to modpol.net
This commit is contained in:
parent
06e7bb9d2d
commit
56adaba7d6
37
README.md
37
README.md
@ -1,26 +1,12 @@
|
||||
# Modpol for Minetest
|
||||
|
||||

|
||||
|
||||
Modpol, short for "modular politics," enables diverse governance processes on multi-user platforms. It offers a library with which users can choose, modify, and create modules that add specific governance functionalities.
|
||||
|
||||
This implementation is a mod for [Minetest](https://minetest.net), a free/open-source voxel game. It is designed to be adapted to other multi-user platforms that also employ Lua as an extension language.
|
||||
|
||||
## How to use it
|
||||
|
||||
Modpol is built around groups called *orgs*. At the base is an org with all users in it, called `Root` by default. *Modules* enable people to do things within orgs, such as decide on membership, grant powers to the org, and much more. To get started in Minetest:
|
||||
|
||||
* Type the command `/mp`
|
||||
* Select the org `Root`
|
||||
* Choose one of its modules to make new orgs and craft their behavior
|
||||
|
||||

|
||||
|
||||
Modules can be nested in each other, so one module can rely on another module to accomplish a process. Users might use a module to unilaterally carry out actions in the game, or the module might require a group decision to do so. Users can also change the modules available to users of a given org. There are currently two ways of doing this:
|
||||
|
||||
* Admins can remove modules from the list of modules loaded in `modpol_core/api.lua` and `modpol_minetest/api.lua`. This will make those modules no longer available to any user.
|
||||
* Players can change the modules available in a given org from within the program using the `Change modules` module. Removed modules can be re-added in any org by using `Change modules` again.
|
||||
|
||||
Modpol should give you the ability to do whatever kind of politics you want with your modules. If there is something you would like to do that is not available, [develop a module for it](https://gitlab.com/medlabboulder/modpol/-/wikis/Module-Writing-Guide) (or ask us for help!).
|
||||
|
||||
**Learn more at [modpol.net](https://modpol.net).**
|
||||
|
||||
## Installation in Minetest
|
||||
|
||||
@ -55,23 +41,6 @@ In the interpreter, for a list of global functions and tables, use `modpol.menu(
|
||||
The persistent storage method may be chosen in `modpol.lua`. If available, Modpol uses Minetest's built-in StorageRef system for Minetest 5.*. If that is not available, or in CLI mode, data will be stored in a data directory at `modpol_core/data/`. This will contain a log file and serialized program data files.
|
||||
|
||||
|
||||
## Design philosophy
|
||||
|
||||
Modpol seeks to implement a theoretical framework called "[modular politics](https://metagov.org/modpol)," which proposes these design goals:
|
||||
|
||||
* *Modularity*: Platform operators and community members should have the ability to construct systems by creating, importing, and arranging composable parts together as a coherent whole.
|
||||
* *Expressiveness*: The governance layer should be able to implement as wide a range of processes as possible.
|
||||
* *Portability*: Governance tools developed for one platform should be portable to another platform for reuse and adaptation.
|
||||
* *Interoperability*: Governance systems operating on different platforms and protocols should have the ability to interact with each other, sharing data and influencing each other's processes.
|
||||
|
||||
Additionally, Modpol seeks to counteract the tendency for "[implicit feudalism](https://ntnsndr.in/ImplicitFeudalism)," according to which rigid, top-down power structures are the norm in online spaces. To this end, some design patterns include:
|
||||
|
||||
* *Groups, not roles*: While most platforms assign powers through particular permissions given to individuals, in Modpol, power lies in groups (which Modpol calls "orgs").
|
||||
* *Consent, not oligarchy*: Rather than assuming that decisions will be made by a few power-holders, the software assumes that consent by all affected users is the norm.
|
||||
* *Inheritance, not blank slates*: When a new group is formed, it inherits the patterns of what preceded it, rather than imagining that it is starting from scratch.
|
||||
|
||||
It is certainly possible to use Modpol to replicate practices of implicit feudalism, such as all-powerful admins, but doing so requires extra work to overcome these defaults.
|
||||
|
||||
## Documentation
|
||||
|
||||
Various guides are available at the [GitLab wiki](https://gitlab.com/medlabboulder/modpol/-/wikis/home).
|
||||
|
Loading…
x
Reference in New Issue
Block a user