diff --git a/.deploy/mirror-chores.service b/.deploy/mirror-chores.service index 99982c85..baa372ef 100644 --- a/.deploy/mirror-chores.service +++ b/.deploy/mirror-chores.service @@ -1,5 +1,5 @@ [Unit] -Description=Chores by Mirror +Description=Chores by Chore Wheel Documentation=https://github.com/zaratanDotWorld/mirror After=network.target diff --git a/.deploy/mirror-hearts.service b/.deploy/mirror-hearts.service index effe1054..39358af2 100644 --- a/.deploy/mirror-hearts.service +++ b/.deploy/mirror-hearts.service @@ -1,5 +1,5 @@ [Unit] -Description=Hearts by Mirror +Description=Hearts by Chore Wheel Documentation=https://github.com/zaratanDotWorld/mirror After=network.target diff --git a/.deploy/mirror-things.service b/.deploy/mirror-things.service index 256be16e..1c9e5bd8 100644 --- a/.deploy/mirror-things.service +++ b/.deploy/mirror-things.service @@ -1,5 +1,5 @@ [Unit] -Description=Things by Mirror +Description=Things by Chore Wheel Documentation=https://github.com/zaratanDotWorld/mirror After=network.target diff --git a/README.md b/README.md index 8e87efc1..2c901ccc 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# Mirror 🪞 +# Chore Wheel 🔆 [![CircleCI](https://dl.circleci.com/status-badge/img/gh/zaratanDotWorld/mirror/tree/master.svg?style=svg)](https://dl.circleci.com/status-badge/redirect/gh/zaratanDotWorld/mirror/tree/master) [![Documentation Status](https://readthedocs.org/projects/mirror/badge/?version=latest)](https://mirror.readthedocs.io/en/latest/?badge=latest) @@ -8,11 +8,11 @@ ### Overview: -Mirror is self-governance software for coliving, helping reshape the economics of housing. +Chore Wheel is self-governance software for coliving, helping reshape the economics of housing. -Developed in collaboration with social scientists and game designers, Mirror is a set of tools and processes which enable groups of individuals to easily and effectively share space, without reliance on expensive managers or tedious meetings. By lowering the cost of cooperation, Mirror helps to bring coliving into the mainstream, reducing both the price and environmental impact of housing. +Developed in collaboration with social scientists and game designers, Chore Wheel is a set of tools and processes which enable groups of individuals to easily and effectively share space, without reliance on expensive managers or tedious meetings. By lowering the cost of cooperation, Chore Wheel helps to bring coliving into the mainstream, reducing both the price and environmental impact of housing. -Mirror draws influence from the work of Elinor Ostrom, and is designed in reference to her [eight principles](https://en.wikipedia.org/wiki/Elinor_Ostrom#Design_principles_for_Common_Pool_Resource_(CPR)_institution): +Chore Wheel draws influence from the work of Elinor Ostrom, and is designed in reference to her [eight principles](https://en.wikipedia.org/wiki/Elinor_Ostrom#Design_principles_for_Common_Pool_Resource_(CPR)_institution): 1. Clearly defined the group boundaries (and effective exclusion of external un-entitled parties) and the contents of the common pool resource; 2. The appropriation and provision of common resources that are adapted to local conditions; diff --git a/docs/conf.py b/docs/conf.py index 83e82647..5664e892 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -2,8 +2,8 @@ # -- Project information -project = 'Mirror' -copyright = '2023, Daniel Kronovet' +project = 'Chore Wheel' +copyright = '2023, Kronosapiens Labs' author = 'Daniel Kronovet' release = '0.3' diff --git a/docs/development/architecture.rst b/docs/development/architecture.rst deleted file mode 100644 index 4997ec1c..00000000 --- a/docs/development/architecture.rst +++ /dev/null @@ -1,4 +0,0 @@ -Architecture -============ - -Coming soon diff --git a/docs/development/design-principles.rst b/docs/development/design-principles.rst new file mode 100644 index 00000000..bb61c807 --- /dev/null +++ b/docs/development/design-principles.rst @@ -0,0 +1,61 @@ +Design Principles +================= + +Three Institutional Layers + The overall design of Chore Wheel can be understood in terms of three layers, evoking the three layers described in Elinor Ostrom’s seminal *Governing the Commons*. + The first, or **constitutional layer**, involves the design of the modules themselves. + In this first layer, the design of the entire system and its implementation are up for discussion. + There are no constraints, as software can be changed in arbitrary ways. + The constitutional layer can be understood as governing the system from without by changing rules themselves. + + The second layer, the **political layer**, involves participants collaboratively setting explicit parameters that govern the behavior of the system. + An example would be choosing the frequency with which a certain chore is to be performed. + In the political layer, residents have control over the system’s behavior, but only within the constraints set by the constitutional layer. + We can think of this as governing the system from within. + + Third and finally, the **operational layer** involves residents individually interacting with the system given the constraints created by the constitutional and political layers. + In this third layer, residents complete and verify chores, vote on issues, and procure supplies. + + This three-layer design is meant to balance flexibility with simplicity – keeping daily interactions clear and straightforward, and providing residents with a structured means for shaping and controlling their environment, while still allowing for unstructured, open-ended changes to be made as needed. + +Cheap Information + A guiding motivation for Chore Wheel is the reduction of the cost of information. + As observed in *Governing the Commons*, the cost of information is inextricably linked to the design of the system itself. + A well-designed system, which makes high-quality information cheaply available, will lead to consistently higher-quality decisions and thus better outcomes. + Chore Wheel achieves this by placing an “event stream” at the center of every module. + Every action, ultimately an attempt to claim some house resource, creates an event. + This can then be interacted with by all residents, most simply in the form of an endorsement or a challenge. + +Permissionless by Default + A major design motif for Chore Wheel is “permissionless by default.” Whenever possible, synchronous voting should be avoided. + In practice, this means that most actions take the form of challenge-response. + In such a system, any resident can propose an action (e.g. such as making a purchase out of a shared account). + If there is no response to the proposal by other residents, the action will be allowed – and likely occur – after a set period of time. + This will be recorded as having passed with a vote of 1-0, representing implicit consent. + However, if other residents do not abstain, they may either oppose or support it with their own votes. + For major actions, a minimum number or percentage of votes in favor may be required, so as to encourage residents to “do their homework” and establish support prior to initiating the vote. + + This approach allows uncontroversial actions to go forward unimpeded (due to a lack of opposition), while allowing for controversial actions to be decided by vote. + This “lazy consensus” approach mimics the processes successfully practiced by groups such as the Apache Software Foundation and Wikipedia. + To both discourage initiating frivolous voting and encourage participation in out-of-band communication, residents who propose failed actions will receive a small penalty. + +Chat-based Interfaces + A second major design motif for Chore Wheel is an orientation around chat-based interfaces. + It is currently being developed as a set of Slack applications but is, in principle, portable to Discord, or any extensible chat platform. + The vision is for residents to interact with Chore Wheel via a series of chat bots, allowing governance interactions to occur seamlessly alongside other house communication. + Each module lives in a dedicated channel and interacts with residents via an events log, which is a series of messages providing information and interactivity. + To avoid spam in these channels, they will be read-only for residents. + However, residents may add comments and reactions to help keep them engaged with the channels without disrupting their utility. + Organizing all interactions as events in a log has positive knock-on effects for auditability and reliability, as any specific state can be reconstructed from the underlying event stream. + +Anonymity and Identity + One critical design consideration is the appropriate role and degree of anonymity. + What actions must be taken publicly and which can be private? No one should have to respond to anonymous criticism, yet publicly identifying oneself can be intimidating and thus disenfranchising. + Ultimately, we choose to require identity for *initial* actions (e.g. completing a chore, issuing a challenge, or making a purchase), but allowing all votes to be anonymous. + In this way, at least one person is always linked to any action but the majority of the inputs can be private. + +Subjective Inputs + Last but not least, Chore Wheel chooses to use only *subjective* inputs. + This means that explicit surveillance is not necessary, and communities using Chore Wheel can sidestep invasive measures practiced elsewhere such as mounting a camera behind the sink to see who leaves dirty dishes. + Such explicit information-gathering approaches create an uncomfortable environment, turn the home into a public sphere, and introduce a new class of measurement error. + The constrained physical environment allows for frequent eyeballs to perform the same monitoring function in a more pleasant, less invasive way, while also providing a few degrees of discretion (e.g. “wiggle room”). diff --git a/docs/index.rst b/docs/index.rst index c618180b..06fa0903 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -1,16 +1,16 @@ -Mirror +Chore Wheel ====== -**Mirror is pioneering software for co-living, running on Slack.** +**Chore Wheel is pioneering software for coliving, running on Slack.** -Created by **economists** and **game designers**, Mirror is a family of tools helping people share space: +Created by **economists** and **game designers**, Chore Wheel is a family of tools helping people share space: - :ref:`chores` for keeping it clean - :ref:`hearts` for mutual accountability - :ref:`things` for bulk purchasing - and more to come -Mirror is **open-source** and **privacy-preserving**. +Chore Wheel is **open-source** and **privacy-preserving**. It contains the latest thinking in **ethical technology**, with four core principles: - No managers or privileged roles @@ -53,4 +53,4 @@ Contents :maxdepth: 2 :caption: Development - development/architecture.rst + development/design-principles.rst diff --git a/docs/overview/getting-started.rst b/docs/overview/getting-started.rst index 41ff386e..932b9715 100644 --- a/docs/overview/getting-started.rst +++ b/docs/overview/getting-started.rst @@ -3,9 +3,9 @@ Getting Started =============== -Getting started with Mirror is quick and easy, and you can be up-and-running in twenty minutes. +Getting started with Chore Wheel is quick and easy, and you can be up-and-running in twenty minutes. -.. note:: +.. tip:: | It is recommended that everyone be physically present during the set-up process. | Perhaps over brunch? @@ -19,7 +19,7 @@ If the house doesn't have a Slack workspace, they should `create one `_. + While initially designed for large coliving houses, Chore Wheel works just as well helping groups of friends or even couples navigate shared space. -As housing costs continue to climb, the development of quality, affordable housing remains a continual challenge. -It is increasingly apparent that shared living situations – housing configurations where residents have private bedrooms but share common facilities like kitchens, bathrooms, and living rooms – are an important part of the solution. +Perhaps the greatest benefit of coliving is the avoidance of redundant infrastructure (e.g. one large kitchen, rather than three small ones), which lowers costs. +However, sharing common resources introduces new coordination challenges (e.g. “who does the dishes”). +Historically, such challenges have been overcome through informal norms (e.g. a “dish-zero” rule), deliberative decision-making processes (e.g. house meetings), or basic coordination mechanisms (e.g. white-board chore schedules). +Such solutions are unreliable, burdensome, and often too simplistic to meet the needs of a large and varied population. -Perhaps the greatest benefit afforded by shared living situations is the avoidance of redundant infrastructure (e.g. one large kitchen, rather than three small ones), which drive down costs. -However, the provisioning of common housing resources introduces new coordination challenges (e.g. “who does the dishes”). -Historically, such challenges have been overcome through informal norms (e.g. a “dish-zero” rule), deliberative decision-making processes (e.g. house meetings), or basic coordination mechanisms (e.g. an analog chore wheel). -But such solutions are unreliable, burdensome, and often too simplistic to meet the needs of a large and varied population. -As Oscar Wilde famously quipped, “the trouble with socialism is that it takes up too many evenings.” We can do better. +As Oscar Wilde famously quipped, “the trouble with socialism is that it takes up too many evenings.” **We can do better.** -Mirror is *poetic technology*: a suite of tools meant to support the healthy functioning of a shared living environment. +Chore Wheel is *poetic technology*: a family of tools meant to support the healthy functioning of a coliving environment, **by maximizing participation and minimizing potential abuses of power**. Drawing influences variously from cognitive science, computer science, electoral theory, economics, cybernetics, and game design, it functions with four top-level design goals: - No managers or privileged administrative roles @@ -24,89 +25,21 @@ Drawing influences variously from cognitive science, computer science, electoral - Humans for sensing and judgment, machines for bookkeeping - Continuously available, asynchronous processes -Although many of these principles can benefit social structures outside of shared living, we have intentionally chosen this setting for the specific advantages it provides. -For example, and by contrast, a government workplace would likely also benefit from simple and intuitive inputs. -But the work done there, being *linear* (i.e. novel, creative) in nature, makes leaderless organization deeply challenging. -In a residential environment, much of the work is *cyclical* – continuous, repetitious, and not meaningfully different between iterations – more naturally allowing for specialized solutions which deemphasize novel ideation and emphasize resource balancing and peer accountability. - -Further, unlike the highly distributed and anonymous settings of online communities, residential environments, by virtue of being shared physical spaces where participants spend a significant amount of their time, provide arguably the maximal number of opportunities for the informal, out-of-band communication essential for eliciting empathy and identification, and building relationships and friendships. -As such, we should *assume* the existence of a coherent social sphere, with the technical system merely providing measurement hooks into accountability and enforcement logic. -The aim, then, is the creation of an objective external representation that closely *mirrors* the subjective inner state (e.g. organic norms and culture) that we take as a given. - -Note that Mirror does not claim to capture all ideation, decision making, and deliberation necessary for a shared living environment. -Nor does its use preclude the need for ongoing investments in education and culture. -Rather, it takes its cue from the Pareto principle: a set of simple, general processes which, given a reasonably trained population, manages the most common 80% of scenarios, leaving the remaining 20% to be handled by locally-determined, informal processes. - -Design ------- - -Three Institutional Layers -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The overall design of Mirror can be understood in terms of three layers, evoking the three layers described in Elinor Ostrom’s seminal *Governing the Commons*. -The first, or **constitutional layer**, involves the design of the modules themselves. -In this first layer, the design of the entire system and its implementation are up for discussion. -There are no constraints, as software can be changed in arbitrary ways. -The constitutional layer can be understood as governing the system from without by changing rules themselves. - -The second layer, the **political layer**, involves participants collaboratively setting explicit parameters that govern the behavior of the system. -An example would be choosing the frequency with which a certain chore is to be performed. -In the political layer, residents have control over the system’s behavior, but only within the constraints set by the constitutional layer. -We can think of this as governing the system from within. +Although these design principles can be desirable in many settings, we see the coliving setting as having the **greatest potential for benefit**. +For example, and by contrast, a government workplace would likely also benefit from simple and intuitive inputs, making it easier for employees to meaningfully participate. +But the work done there, being *linear* (i.e. novel, creative) in nature, makes flat organization significantly riskier and more challenging. +In a housing environment, on the other hand, much of the work is *cyclical* (i.e. continuous, repetitious, not meaningfully different between iterations), allowing for new approaches which de-emphasize novel ideation and emphasize resource balancing and mutual accountability. -Third and finally, the **operational layer** involves residents individually interacting with the system given the constraints created by the constitutional and political layers. -In this third layer, residents complete and verify chores, vote on issues, and procure supplies. +Further, unlike the distributed and anonymous settings of online communities, coliving environments, being real physical spaces, provide many more opportunities for the informal, casual interactions necessary for building strong relationships. +As such, we can *assume* the existence of a coherent social sphere, with the software tools merely providing a structure for transparency and accountability. -This three-layer design is meant to balance flexibility with simplicity – keeping daily interactions clear and straightforward, and providing residents with a structured means for shaping and controlling their environment, while still allowing for unstructured, open-ended changes to be made as needed. +Note that Chore Wheel does not claim to capture all ideation, decision making, and deliberation occuring in a coliving environment. +Nor does its use reduce the need for ongoing investments in community-building. +Rather, it takes its cue from the Pareto principle: a set of simple, general tools which handles the most common 80% of scenarios, leaving the remaining 20% to be handled by separate, specialized processes. -Cheap Information -~~~~~~~~~~~~~~~~~ -A guiding motivation for Mirror is the reduction of the cost of information. -As observed in *Governing the Commons*, the cost of information is inextricably linked to the design of the system itself. -A well-designed system, which makes high-quality information cheaply available, will lead to consistently higher-quality decisions and thus better outcomes. -Mirror achieves this by placing an “event stream” at the center of every module. -Every action, ultimately an attempt to claim some house resource, creates an event. -This can then be interacted with by all residents, most simply in the form of an endorsement or a challenge. +By helping coliving communities handle their most common problems almost "by magic", Chore Wheel lets communities channel their time and energy towards more long-term, meaningful projects. -Permissionless by Default -~~~~~~~~~~~~~~~~~~~~~~~~~ - -A major design motif for Mirror is “permissionless by default.” Whenever possible, synchronous voting should be avoided. -In practice, this means that most actions take the form of challenge-response. -In such a system, any resident can propose an action (e.g. such as making a purchase out of a shared account). -If there is no response to the proposal by other residents, the action will be allowed – and likely occur – after a set period of time. -This will be recorded as having passed with a vote of 1-0, representing implicit consent. -However, if other residents do not abstain, they may either oppose or support it with their own votes. -For major actions, a minimum number or percentage of votes in favor may be required, so as to encourage residents to “do their homework” and establish support prior to initiating the vote. - -This approach allows uncontroversial actions to go forward unimpeded (due to a lack of opposition), while allowing for controversial actions to be decided by vote. -This “lazy consensus” approach mimics the processes successfully practiced by groups such as the Apache Software Foundation and Wikipedia. -To both discourage initiating frivolous voting and encourage participation in out-of-band communication, residents who propose failed actions will receive a small penalty. - -Chat-based Interface -~~~~~~~~~~~~~~~~~~~~ - -A second major design motif for Mirror is an orientation around chat-based interfaces. -It is currently being developed as a set of Slack applications but is, in principle, portable to Discord, or any extensible chat platform. -The vision is for residents to interact with Mirror via a series of chat bots, allowing governance interactions to occur seamlessly alongside other house communication. -Each module lives in a dedicated channel and interacts with residents via an events log, which is a series of messages providing information and interactivity. -To avoid spam in these channels, they will be read-only for residents. -However, residents may add comments and reactions to help keep them engaged with the channels without disrupting their utility. -Organizing all interactions as events in a log has positive knock-on effects for auditability and reliability, as any specific state can be reconstructed from the underlying event stream. - -Anonymity and Identity -~~~~~~~~~~~~~~~~~~~~~~ - -One critical design consideration is the appropriate role and degree of anonymity. -What actions must be taken publicly and which can be private? No one should have to respond to anonymous criticism, yet publicly identifying oneself can be intimidating and thus disenfranchising. -Ultimately, we choose to require identity for *initial* actions (e.g. completing a chore, issuing a challenge, or making a purchase), but allowing all votes to be anonymous. -In this way, at least one person is always linked to any action but the majority of the inputs can be private. - -Subjective Inputs -~~~~~~~~~~~~~~~~~ +.. note:: -Last but not least, Mirror chooses to use only *subjective* inputs. -This means that explicit surveillance is not necessary, and communities using Mirror can sidestep invasive measures practiced elsewhere such as mounting a camera behind the sink to see who leaves dirty dishes. -Such explicit information-gathering approaches create an uncomfortable environment, turn the home into a public sphere, and introduce a new class of measurement error. -The constrained physical environment allows for frequent eyeballs to perform the same monitoring function in a more pleasant, less invasive way, while also providing a few degrees of discretion (e.g. “wiggle room”). + You can read the original project whitepaper `here `_. diff --git a/docs/tools/chores.rst b/docs/tools/chores.rst index 2a5651ad..7e485253 100644 --- a/docs/tools/chores.rst +++ b/docs/tools/chores.rst @@ -15,13 +15,14 @@ Chores is designed with two goals in mind: first, to ensure an even distribution It is tempting to shy away from structure, and rely on spontaneous generosity. But spontaneous generosity never lasts, and a few people, usually women, end up doing most of the work. - Alternatives, like simple chore wheels or schedules, have their own drawbacks. + Alternatives, like physical chore wheels or schedules, have their own drawbacks. Cameras and cleaners have their place, but are expensive and can create a weird vibe. The core concept of Chores is, unsurprisingly, chores. Every house creates a list of chores that they need done. The key idea is that chores aren't done on a schedule, but rather "whenever necessary", as determined by the residents. Chores are worth points, and the amount of points a chore is worth goes up the longer the chore goes undone (in most cases, the longer it's been, the bigger the job gets). + **Everyone in the house needs to earn a certain number of points, about 100 per month.** **Over the course of the month, all the chores (collectively) gain about 100 points per person.** So, everyone does the chores they think are worth their time. @@ -32,10 +33,10 @@ The result is a continuous process of domestic renewal. Here is the key dynamic: everyone would rather do a chore for more points, but if they wait too long, they'll get scooped. So everyone independently make choices about what to do, and when, and how, based on the ever-changing situation on the ground. - | Doing chores bit-by-bit over several weeks? Have fun. - | Waiting until the last day? Good luck. - | Doing 3 hard chores for 30 points a pop? Go nuts. - | Doing 20 easy chores for 5 points each? Why not. + | Doing chores bit-by-bit over several weeks? *Have fun*. + | Waiting until the last day? *Good luck*. + | Doing 3 hard chores for 30 points a pop? *Go nuts*. + | Doing 20 easy chores for 5 points each? *Why not*. It all works. @@ -81,7 +82,7 @@ The Chores home page is the chores dashboard. On the home page, folks can see their current and owed points for the month, as well as how many people are "working" that day (i.e. not exempt and not on break). The app home is also the entryway into the basic functionality, described below: -``Claim a chore`` +:guilabel:`Claim a chore` When someone does a chore, they "claim" the points that chore is worth at that moment. The claim is then posted publicly, and other residents can verify that the claim was made honestly. A minimum of **two upvotes** are needed for the large claims (10+ points) to succeed, equivalent to having someone "sign off" on the chore. @@ -93,12 +94,12 @@ The app home is also the entryway into the basic functionality, described below: In the unlikely scenario that someone lies about doing a chore (or does an extremely poor job), the rest of the residents may negate the claim. A failed claim returns the points to the chore, allowing someone else to do the job properly. -``Take a break`` +:guilabel:`Take a break` The point of Chores is to help folks clean up their own messes, with more points (roughty) meaning more mess. When someone is out of town, they aren't making a mess, and so they shouldn't owe as many points. Anyone who goes out of town for at least **3 days** can take a break, and they'll owe less points for that month (also, there will be fewer points given to chores on the days that they're gone). -``Gift your points`` +:guilabel:`Gift your points` Not every useful piece of work around the house can be expressed as a recurring chore. Things happen randomly, and spontaneously, and it's valuable to be able to recognize those things. As mentioned above, the total amount of points per month is fixed, but there's no reason folks can't give away points that *they themselves have earned*. @@ -106,19 +107,19 @@ The app home is also the entryway into the basic functionality, described below: After someone has claimed a chore and gotten points, they can gift those points to someone else in recognition of a useful contribution that they've made. It's their choice who to gift and why and how much, since they're the one who earned those points in the first place. -``Edit chores list`` +:guilabel:`Edit chores list` Before anyone can claim a chore, the chore needs to be defined. Chores can be added, edited, or deleted. Chore edits start as proposals and go to the house for a vote. If the vote passes, the chore is created and begins accumulating points. - .. note:: + .. tip:: If 100% of the workspace votes yes for a proposal, it passes immediately. This is useful if folks ever want to gather in-person for a chore setup session, helping you get up-and-running quickly. -``Set chore priorities`` +:guilabel:`Set chore priorities` The **total amount** of points per month is fixed, at 100 points per resident. Those points are distributed continuously over the course of the month. In a 10-person house and a 30-day month, that works out to about **33 points per day** in total. That number can't be changed, as it ensures that chores are done over the entire course of the month. diff --git a/docs/tools/hearts.rst b/docs/tools/hearts.rst index fa797938..48d41079 100644 --- a/docs/tools/hearts.rst +++ b/docs/tools/hearts.rst @@ -46,7 +46,7 @@ The Hearts home page is the chores dashboard. On the home page, folks can see their current hearts. The app home is also the entryway into the basic functionality, described below: -``Resolve a dispute`` +:guilabel:`Resolve a dispute` The most dramatic way to lose a heart is by having another resident call you out for bad behavior, by issuing a **challenge** (similar to getting a "strike"). This, rightly, is an uncomfortable experience, but a necessary one, as the final step in the :ref:`conflict resolution ` process. If you couldn't be called out, or you couldn't call someone else out, then there would be no accountability: problematic behavior would continue until things reached a breaking point; not a situation anyone wants to be in. @@ -63,7 +63,7 @@ The app home is also the entryway into the basic functionality, described below: Anyone who issues a challenge stands to lose hearts themselves, if other residents feel they are out of line. Instead, challenges should come as no surprise, and represent a final step in a respectful process of disagreement. -``See current hearts`` +:guilabel:`See current hearts` Pull up a view showing everyone's hearts. Slash Commands diff --git a/docs/tools/things.rst b/docs/tools/things.rst index 3227c724..812586f3 100644 --- a/docs/tools/things.rst +++ b/docs/tools/things.rst @@ -30,7 +30,7 @@ Buys Basic Functionality ------------------- -``Buy a thing`` +:guilabel:`Buy a thing` Whenever someone notices that a supply is running low, they can propose that the house buy more. The "buy" is then posted publicly, and other residents can endorse or reject the proposal. A minimum of **one endorsement per $50** is needed for the buy to succeed, to prevent one person from unilaterally spending a large proportion of the house's funds. @@ -39,19 +39,19 @@ Basic Functionality Once a buy is resolved, it will be "fulfilled" (hand-wavy, to be sure) in some way, shape, or form. -``Buy special thing`` +:guilabel:`Buy special thing` From time to time, folks want to buy something which isnt "on the list". In that case, they can propose a "special buy" and provide more details on what they're thinking. Special buys have a longer voting window and require a higher number of upvotes to pass. -``Edit things list`` +:guilabel:`Edit things list` Before anyone can buy a thing, the thing needs to be defined. Things can be added, edited, or deleted. Thing edits start as proposals and go to the house for a vote. If the vote passes, the thing is created and can be bought. -``See bought things`` +:guilabel:`See bought things` Pull up a view showing ongoing and historical buys. Historical buys are aggregated by thing, making it easy to see spending trends. diff --git a/src/bolt/common.js b/src/bolt/common.js index 7d2a7acd..fbb2b131 100644 --- a/src/bolt/common.js +++ b/src/bolt/common.js @@ -11,7 +11,7 @@ exports.homeEndpoint = function (appName) { method: [ 'GET' ], handler: async (_, res) => { res.writeHead(200); - res.end(`Welcome to Mirror - ${appName}!`); + res.end(`Welcome to Chore Wheel - ${appName}!`); }, }; };