Bisq Wiki - User contributions [en]

Monero Explorer Operator

2020-09-07T07:45:32Z

Cbeams: Update team name to monero-explorer-operators

This article documents the '''Monero Explorer Operator''' [[Roles|role]].

__TOC__

== Issue ==
https://github.com/bisq-network/roles/issues/109

== Team ==
[https://github.com/orgs/bisq-network/teams/monero-explorer-operators/members @bisq-network/monero-explorer-operators]

== Duties ==
* Run an instance of the [https://github.com/moneroexamples/onion-monero-blockchain-explorer Onion Monero Blockchain Explorer]
* Make your Monero Explorer instance available over HTTPS clearnet and Tor V3 HS onion, enable HSTS and DNSSEC
* Update the [https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/user/Preferences.java#L130 Bisq code] to contain the FQDN clearnet hostname and Tor V3 HS onion of your Monero Explorer

== Rights ==
* Claim $100/month compensation

== Bonding ==
* Post 20,000 BSQ bond for Explorer Operator

[[Category:Roles]]
[[Category:Operator]]

Donation Address Owner

2020-06-16T08:41:47Z

Cbeams: Link to @bisq-network/donation-address-owners team

The '''donation address owner''' (sometimes referred to as the "burning man") controls the BTC address where BTC trade fees and funds from time-locked payout transactions are sent.

Please see [[Arbitration|arbitration]] for more details on how this role works with other elements of Bisq's decentralized dispute resolution process.

__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/80 BTC donation address owner #80]

== Team ==
* https://github.com/orgs/bisq-network/teams/donation-address-owners/

== Duties ==
* Periodically buy BSQ with BTC that has collected in the donation address wallet
** Announce these periodic trading sessions in the [https://github.com/bisq-network/roles/issues/80 role issue] a few days in advance
* Burn the purchased BSQ

== Rights ==
* Ownership of the Bisq donation address

== Bonding ==
[https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L70 Bond Link]
50 * [[DOA_PARAM|DOA PARAM.BONDED_ROLE_FACTOR]]

[[Category:Roles]]

Arbitration

2020-06-16T08:31:17Z

Cbeams: Rename Donation Address {Holder=>Owner}

'''Arbitration''' refers to the last stage of the dispute resolution process—it's what takes place in case trader chat and [[Mediation|mediation]] fail to resolve a dispute.

This page first covers the arbitration process itself, in a practical sense, so that users can be made aware of what to expect when trading. Then it covers the process in more detail, including its motivations, how all the components work together, and how the process is expected to develop in the future.

== Process ==

Bisq's arbitration process is a thoroughly decentralized approach to handling disputes between 2 strangers on the internet: one in which no user needs to trust a third party with authority over their funds, but one in which a user can still expect good conduct to be rewarded and bad conduct to be penalized.

Arbitration is only available when:

* one or both traders reject a [[Mediation|mediator’s]] suggested payout
* the time-locked transaction is published

A ''time-locked transaction'' is signed (but not published) at the beginning of the trade process. Its purpose is to allow time for traders and mediators to work out a payout using the funds in the 2-of-2 multisig escrow, and to eliminate the [[#Avoiding_Fraud|possibility of fraud]] in case they can't.

Requesting arbitration publishes this time-locked transaction, sending all funds in the multisig escrow (i.e., those of both trading peers) to the Bisq "donation address" (which is owned by the [[Donation Address Owner]], a bonded role approved by DAO voting). This transaction can only be published 10 days after the deposit transaction is confirmed (for altcoin trades) and 20 days after the deposit transaction is confirmed (for fiat trades), which means arbitration is only available after this time has passed.

The ''donation address'' is where disputed bitcoin funds are collected. The [[Donation Address Owner]] uses the BTC that collects in this wallet to buy BSQ and burn it. This reduces BSQ supply, allowing for a corresponding amount of new BSQ to be issued to account for the BTC payouts made to traders as part of arbitration. As a result, BSQ supply is largely unaffected.

This dynamic essentially makes bitcoin deposits confiscatable, enabling a sort of mutually assured destruction to drive dispute resolution on Bisq without trusted third parties.

'''In plain language, here's how the process works for traders:'''

# If you’re dissatisfied with the mediator’s suggestion and think you are entitled to a better outcome, request arbitration when it's available (doing so publishes the time-locked transaction and sends funds to the donation address).
# Collaborate with an arbitrator to clarify the details of your case.
# If the arbitrator agrees you are owed BTC, they will pay it to you.

Takeaway: if you are owed BTC after a dispute, you'll get it from an arbitrator, '''just like before''' with [[Arbitrator#Arbitrator_versus_Legacy_Arbitrator|legacy arbitration]] when arbitrators had a third key in 2-of-3 multisignature escrows. Only difference is the BTC payout won't be coming from the trade's multisig escrow.

== Process, In Detail ==

To better understand arbitration, we need to first understand the new trade protocol, and how it improves upon the old trade protocol.

=== Old Trade Protocol ===

The previous model with 2-of-3 multisig deposit transactions (where an arbitrator was the 3rd key holder, and makes the payout to one of the traders in dispute cases) carried a significant risk: if the arbitrator was malicious (or was hacked), he could have taken all offers with a sockpuppet trader and made the payouts right back to his own sockpuppet.

This risk made it impossible to scale dispute resolution and find more arbitrators—we were limited to filling the role with a tiny number of Bisq contributors who could be 100% trusted to not be malicious and who had a good enough background in computer security to make getting hacked highly unlikely.

This element was the single most problematic element in Bisq’s old trade protocol, but since there weren’t any better solutions, we used it for as long as we had to.

=== New Trade Protocol ===

The new trade protocol, launched in Bisq v1.2, eliminates the risks described above to a large extent by separating functions and involving the DAO. It significantly improves censorship-resistance, security, and scalability of dispute resolution on Bisq.

[[File:Ntp-v12.png|thumb|right|Dispute resolution for new trade protocol (v1.2+).]]

The basic change is that it uses a 2-of-2 multisig in the deposit transaction with only the traders’ keys.

On the happy path, the traders each sign the payout tx once the fiat or altcoin is transferred.

If anything goes wrong, there are 3 stages to resolve the issue:

# The traders can have a direct chat where they can try to find a solution to their problem.
# If that does not succeed either trader can open a mediation ticket and request help from a mediator. Mediators play a role similar to that of arbitrators in the old model, except they don’t have a 3rd key. They only can make a ''suggestion'' for the payout distribution, which either trader is free to accept or reject. If both traders accept, they create and sign the payout tx and the trade is completed. If either trader rejects, the dispute goes to stage 3. This escalation can only take place after a certain time period has passed. For altcoins, this period is 10 days, and for fiat it’s 20 days.
# An arbitrator will investigate the case, just like a mediator would, and decide how a payout should be distributed. The arbitrator role currently has 2 parts: supreme mediator and refund agent (this is where the term ''refund agent'' comes from, but ''arbitrator'' is a better term for the role, as we will soon see). The supreme mediator part of the role is similar in function to that of a regular mediator (i.e., investigate a dispute)—'''but the refund agent part of the role is new and intended to be temporary'''. The refund agent reimburses traders BTC for disputed trades without requiring them to undergo the complex and time-consuming process of making a reimbursement request in the DAO. The ultimate goal, however, is to make such extreme dispute cases so ''rare'' that requiring users to request reimbursement from the DAO on their own becomes feasible (e.g., by reducing bugs, UX improvements, increasing security deposits, etc). But we’re not there yet, so for now, an arbitrator simply decides on a payout ''and'' funds this payout from their own pocket, and later makes a reimbursement request to the DAO to be reimbursed for their reimbursement to the user. To avoid [[#Avoiding_Fraud|potential fraud]], and to keep the DAO from losing money in each arbitration case, we use the [[#Donation_Address|donation address]] to receive the funds from the trade via the time-locked payout tx.

=== Time-Locked Payout Transaction ===
Under the new protocol, traders create a time-locked payout tx where all the locked up funds (trade amount + both security deposits) are sent to the Bisq donation address. This is defined in the DAO as a default parameter and can be changed (by voting) to any BTC address. Right now, this address is controlled by the burning man who makes sure that the BTC collected will be brought into the BSQ market, but the donation address could also be owned by anyone else (e.g., another project Bisq wants to support, such as the Tor project).

If a trade is not completed in 10 days (for altcoins) or 20 days (for fiat), either of the 2 traders have a chance (after mediation) to publish the time-locked payout tx where all deposit funds are sent to the donation address, requiring the aggrieved trader to request arbitration so they can receive a payout. With the preliminary solution we use now, the trader gets a payout from an arbitrator directly, '''but the eventual goal is that the arbitrator makes a suggestion which the DAO uses as a basis for voting on the reimbursement request made by the trader(s)'''.

=== Avoiding Fraud ===

The time-locked payout tx is essential to avoid fraud. A trader could make a self-trade and then claim that his “peer” has not paid. Without the time-locked payout tx, he could go through the dispute process, make a reimbursement request, and receive BSQ for the equivalent “lost” funds in BTC. After that he could make the payout to himself from the trade, since he controls both “traders”—thereby scamming the DAO with the trade amount.

To avoid this scheme, we require that locked up funds in the 2-of-2 multisig deposit tx are spent before opening an arbitration ticket. The funds are sent to the donation address so that fraud scheme is not possible anymore.

=== Donation Address ===

As mentioned already, the donation address can be any address to which DAO stakeholders want to send disputed deposit funds. This address is also used for receiving BTC trade fees. But since refund cases are not rare enough, and not enough Bisq traders use BSQ yet, we cannot afford to donate the funds that collect in the donation address just yet—so we use the burning man to bring those BTC into the BSQ ecosystem.

=== Donation Address Owner ===

The burning man (i.e., donation address owner) is a trusted and bonded role. He needs to make a proposal to the DAO to take on this role, and he is only allowed to carry out the duties of the role once stakeholders accept his request ''and'' he locks up a 50,000 BSQ bond.

The burning man controls the BTC address where BTC trade fees and funds from time-locked payout transactions are sent. He does periodic trading sessions where he buys BSQ with the BTC that has collected in his wallet, and then burns the purchased BSQ. The burning decreases the supply of BSQ, and is equivalent in effect to traders burning BSQ trade fees. For arbitration cases, this burning results in a zero sum outcome for the DAO economy (ignoring price volatility): BSQ ''issued'' to refund the arbitrator for his BTC payout to aggrieved traders is equal to the BSQ ''burned'' by the burning man.

Let’s make a simple example to clarify:

* Two traders are engaged in a 1 BTC trade, with 0.1 BTC each locked in a security deposit
* 1.2 BTC is locked in the 2-of-2 multisig deposit tx (ignoring miner fees)
* Assume BSQ/BTC is trading at 0.0001 (for easy calculations)

After the required time passes, and the mediation process is closed, one of the traders opens an arbitration case. By doing so, the 1.2 BTC is sent to the donation address (controlled by the burning man). This transaction was signed by both traders at the time the offer was taken, but was time-locked so it was invalid until the required time had passed. The arbitrator investigates the case and makes a 1.2 BTC payout to the winning trader. He pays this sum from his personal wallet (pre-financing). To reduce volatility risk, the arbitrator also sells 12,000 BSQ from his own pocket to receive 1.2 BTC. So now he’s not missing any BTC, but he is missing 12,000 BSQ.

On the other side, the burning man buys 12,000 BSQ with the 1.2 BTC he received from the deposit funds of the trade. Upon buying those BSQ, he burns those BSQ, reducing BSQ supply by 12,000 BSQ.

The arbitrator then makes a reimbursement request of 12,000 BSQ to settle his pre-financing. When approved, the DAO issues 12,000 BSQ to the arbitrator. But since the burning man already burned 12,000 BSQ from the 1.2 BTC he received from the trade’s deposit funds, '''there is no net effect on the DAO economy'''. And the aggrieved trader receives the BTC he is owed just like he would have in the old model—the only difference is that he needs to wait until the time-lock period is over so he can open an arbitration case.

The arbitrator on takes a high risk by pre-financing the reimbursement. To mitigate this we made an arrangement for the burning man to prioritize offers from the arbitrator to lower his exposure. See [https://github.com/bisq-network/proposals/issues/171 this proposal] for details.

=== Why We Cannot Merge These Roles ===

The separation of those roles is essential to keep the system flexible, censorship-resistant, and scalable.

'''Keep in mind that the current dual role of arbitrators (i.e., supreme mediator and refund agent) is not the ultimate goal'''. The refund agent part of the role should be delegated to traders once the trade process is improved to a level where such cases rarely happen. How to keep the burden for traders low, and how to compensate them for this extra work—these items are still up for discussion (e.g. the trader could get a slight bonus if he does the reimbursement himself). A preferred option is to keep trader-submitted reimbursement requests optional and still offer arbitrator-funded reimbursements for a fee. The role could even be split, such that a market of refund agents develops where each agent offers their pre-financing services at different prices. But before getting into any of these discussions, we need to reduce bugs and improve UX.

The role of the burning man could also disappear when we have very few dispute cases, and once trade fees in BTC do not add up to a large amount. We could use the donation address to support critical infrastructure we use like Tor. Or we could use it to fund Bisq projects like the mobile wallet. Yet another idea is to rotate the funds coming in to this address among core contributors so a part of their earnings can come directly as BTC. There are many possibilities for how we could use these funds—but if we merged the burning man role with the arbitrator role, we would lose this flexibility.

The risks of the 2 roles are very different. An arbitrator does not present any severe risk to the DAO, actually, he ''takes on'' a lot of risk. The burning man, on the other hand, is a trusted role and there is an open problem that a malicious burning man could make many trades, go to the arbitrator, get payouts, and then run away with the funds he received from the donation address. The high bond is a partial protection, but ultimately, this is a trusted role and only highly trusted Bisq contributors can take it on. This is an open, known problem, and there are several ideas about how to mitigate it. But keep in mind that a single person can play this role even if there are 100,000 trades a day. So scalability is not an issue with the burning man, but we cannot say the same about the arbitrator. With more traders, there will be more cases, and we might need more arbitrators. Furthermore, with more regional expansion, we will need arbitrators with particular language skills. When arbitrators and burning man are not combined into one role, we can add arbitrators to support this growth without posing high risk to the Bisq network. If we merged both roles, we would not be able to do this. There is a risk arbitrators expose to the DAO: they could fake their reporting, but this is likely solvable (traders can provide evidence).

Another important aspect is that arbitrator reimbursement is not automated. DAO stakeholders have ultimate power. Sure, they would probably lose an arbitrator if they don’t reimburse him fairly, and it might be hard to find new arbitrators after unfair behaviour from DAO stakeholders. But it is highly important that stakeholders be able to exercise absolute power.

Another consideration: if the process to reimburse arbitrators were automated, the result would probably involve legal risks that we want to avoid. The role would then adopt elements of a custodial function, and that would likely trigger regulatory issues.

=== FAQ ===

'''What are the conditions that lead to a payout, for example, a dispute between Bob and Alice that is not resolved by normal mediation and gets escalated to arbitration?'''

After the time-lock period (10 days for altcoins and 20 days for fiat), and after mediation is completed, either trader can open an arbitration ticket. Doing so publishes the time-locked payout transaction.

'''How are Bob and Alice's BTC funds paid out to the Bisq donation address?'''

The time-locked payout transaction is created and signed in the take-offer process and stored by both traders. The trade protocol requires this transaction to be in place before a trade is started.

'''How is the arbitrator responsible for deciding what the payout distribution should be? Are facts and circumstances of the case taken into account? And how is this similar to legacy arbitration?'''

In terms of determining what a payout should be, an arbitrator's role is the same as that of a mediator. They'll ask you for any additional information they need to determine the facts and circumstances of the case. The only practical difference between arbitration and legacy arbitration is that arbitrators use their own funds to pay trader(s) instead of funds from the trading escrow.

'''How, upon deciding a payout, does an arbitrator pay the BTC to Bob and Alice?'''

Arbitrators need to have enough BTC to cover potential payouts—it's a requirement for anyone seeking to hold the role. An arbitration case can only be closed once an arbitrator makes a payout. Then, at the end of the DAO cycle, they'll get reimbursed with BSQ (which they can then sell for BTC).

'''How does the arbitrator issue a reimbursement request for an amount of BSQ equivalent to the amount of BTC paid out-of-pocket to settle disputes?'''

This process is a work in progress. Currently we try to reduce volatility and exposure risk by converting pre-financed BTC to BSQ as fast as possible. Once it is BSQ there is no longer any volatility risk, and the arbitrator simply sums up all pre-financed BSQ and requests reimbursement. The public result of an arbitrator's work is a reimbursement request to the Bisq DAO.

'''How does the DAO issue this BSQ to reimburse arbitrators?'''

A reimbursement request is technically the same as a compensation request. DAO stakeholders vote on an arbitrator's request. The arbitrator needs to provide solid reporting to make their request transparent to the DAO. Currently there is some trust involved, since it cannot be proven that the arbitrator is not adding fake cases. This may be solvable by collecting data from traders, but this requires more thought.

'''Doesn't this dispute resolution mechanism incentivize Bisq to have more trades go to arbitration, since disputed BTC funds are used to buy BSQ, reduce BSQ supply, and thereby benefit BSQ holders?'''

No, because arbitration does not reduce BSQ supply. Although BSQ supply is reduced by the burning man, arbitrators are reimbursed with newly-issued BSQ after they've done BTC payouts to traders, so ultimately there is no net impact on BSQ supply. Actually, arbitrators must charge for their time and risk, so the net result of having more arbitration cases is negative for BSQ holders.

Also consider that arbitration cases are bad for user experience, and each case required mediation and other support resources, all of which also cost the DAO. ''Reducing'' arbitration cases is absolutely in the DAO's best interest.

'''How does an arbitrator create offers to buy BTC with their newly-issued BSQ?

The arbitrator sells BSQ for BTC from the burning man as soon he has done the payout. In this way, we reduce volatility risk. Essentially, this allows the arbitrator to borrow BSQ from the DAO, which they'll then get back through a reimbursement request.

'''How does the burning man take offers from the arbitrator using BTC funds from the donation address?'''

The arbitrator has makes his onion address known so the burning man can see which offers are from him. The trade event is announced on the burning man's [https://github.com/bisq-network/roles/issues/80 role issue], and the arbitrator needs to make sure they're online at that time with competitive offers.

'''How does the donation address owner burn the BSQ they buy?'''

Burning is done inside the Bisq software on <code>DAO</code> > <code>Proof-of-Burn</code>. A proof is created, and all details are documented on reports posted on the [https://github.com/bisq-network/roles/issues/80 role issue].

'''Why not simply combine the burning man and arbitrator roles?'''

[[#Why_We_Cannot_Merge_These_Roles|See longer explanation above]]. In short: to stay flexible, to be able to implement the target vision (reimbursement done by traders themselves), to avoid legal risks, to keep the arbitrator role scalable, and to address the trust/security issue with the current burning man model.

[[Category:Processes]]

Support Team

2020-06-16T08:30:32Z

Cbeams: Rename Donation Address {Holder=>Owner}

The Support Team is responsible for providing excellent [[user support|support]] for Bisq users. This includes:

* Handling individual support cases, including [[mediation]] and [[refunds]]
* Maintaining the Bisq [[Docs|docs website]]
* Maintaining support-related articles here on the Bisq [[wiki]].

__TOC__

== Roles ==

* [[Support Team Lead]]
* L1/L2 [[Support Agent]]
* [[Mediator]]
* [[Arbitrator]]
* [[Refund Agent]]
* [[Donation Address Owner]] (aka "Burning Man")
* [[Wiki Editor]]
* [[Fee Reimbursement Agent]]

== Resources ==

=== GitHub Team ===

[https://github.com/orgs/bisq-network/teams/support @bisq-network/support]

=== GitHub Repositories ===

* https://github.com/bisq-network/support
* https://github.com/bisq-network/bisq-docs
* https://github.com/bisq-network/wiki

=== Keybase chat ===

* [[Keybase]] <code>#support</code> channel (public, for providing user support)
* Keybase <code>bisq.support</code> subteam (private, for Support Team contributors)

[[Category:Teams]]

Donation Address Owner

2020-06-16T08:30:04Z

Cbeams:

The '''donation address owner''' (sometimes referred to as the "burning man") controls the BTC address where BTC trade fees and funds from time-locked payout transactions are sent.

Please see [[Arbitration|arbitration]] for more details on how this role works with other elements of Bisq's decentralized dispute resolution process.

__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/80 BTC donation address owner #80]

== Team ==
* TBD

== Duties ==
* Periodically buy BSQ with BTC that has collected in the donation address wallet
** Announce these periodic trading sessions in the [https://github.com/bisq-network/roles/issues/80 role issue] a few days in advance
* Burn the purchased BSQ

== Rights ==
* Ownership of the Bisq donation address

== Bonding ==
[https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L70 Bond Link]
50 * [[DOA_PARAM|DOA PARAM.BONDED_ROLE_FACTOR]]

[[Category:Roles]]

Donation Address Owner

2020-06-16T08:29:45Z

Cbeams: Cbeams moved page Donation Address Holder to Donation Address Owner: Rename s/Holder/Owner/ for consistency

The '''donation address holder''' (sometimes referred to as the "burning man") controls the BTC address where BTC trade fees and funds from time-locked payout transactions are sent.

Please see [[Arbitration|arbitration]] for more details on how this role works with other elements of Bisq's decentralized dispute resolution process.

__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/80 BTC donation address owner #80]

== Team ==
* TBD

== Duties ==
* Periodically buy BSQ with BTC that has collected in the donation address wallet
** Announce these periodic trading sessions in the [https://github.com/bisq-network/roles/issues/80 role issue] a few days in advance
* Burn the purchased BSQ

== Rights ==
* Ownership of the Bisq donation address

== Bonding ==
[https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L70 Bond Link]
50 * [[DOA_PARAM|DOA PARAM.BONDED_ROLE_FACTOR]]

[[Category:Roles]]

Donation Address Holder

2020-06-16T08:29:45Z

Cbeams: Cbeams moved page Donation Address Holder to Donation Address Owner: Rename s/Holder/Owner/ for consistency

#REDIRECT [[Donation Address Owner]]

Support Agent

2020-06-08T08:00:58Z

Cbeams: Remove unwanted Agent category

__TOC__

==Requirements==

What makes a great support agent?

* You're a Bisq user. You understand how to use it well enough to help others.
* You can be available for 10 hours or more per week to handle support cases.
* You're familiar with the existing [[Docs]] and [[Knowledge Base]] articles.

If you're interested in becoming a support agent, see the [[#Internship]] section below.

==Infrastructure==

Includes all of [[Support Team#Infrastructure]], plus the following:

=== Coverage calendar ===

The coverage calendar tracks shifts for each support agent, with the goal of achieving 24/7 coverage.

* [https://calendar.google.com/calendar/embed?src=u4eea6bffk10b76l2cmb86eqqc%40group.calendar.google.com&ctz=Europe%2FVienna Public HTML]
* [https://calendar.google.com/calendar/ical/u4eea6bffk10b76l2cmb86eqqc%40group.calendar.google.com/public/basic.ics iCal File]
* [https://calendar.google.com/calendar?cid=dTRlZWE2YmZmazEwYjc2bDJjbWI4NmVxcWNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ Google Calendar] (login required)

===Case tracking board===
* https://github.com/bisq-network/support/projects/2

===GitHub team===
* [https://github.com/orgs/bisq-network/teams/support-agents @bisq-network/support-agents] (includes l1, l2 and intern subteams)

===Role issue===
* [https://github.com/bisq-network/roles/issues/64 L1 Support Agent #64]

==Duties==

===Handle support cases===

===Keep the coverage calendar up to date===

===Submit regular cycle reports===

==Rights==

* Writer access to the <code>bisq.support</code> Keybase subteam
* [https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level Triage] access to [[Support Team#Repositories]]
* Edit access to the [[#Coverage Calendar]]

==Policies==

===Time to response===

If you are on duty, it's your job to respond as promptly as possible to incoming user requests. The goal is to respond to all support inquiries in the <code>#support</code> channel within 1 hour of being asked and preferably much faster. This initial response need not actually ''resolve'' the user's issue, it is merely letting the user know that you've heard their question and that you'll be their primary support agent for this case.

===Sensitive user data===

Often support agents will need to ask users to share their logs with you or specific information about their offer or trade, such as trade ID, trade amounts, etc. This data should not be shared in any public channel and should be destroyed one month after the case is closed. Note that any such information that shared in the <code>bisq.support</code> subteam is automatically destroyed after 30 days.

==Processes==

===Internship===

Prospective support agents are asked to go through an internship process that lasts one DAO cycle (approximately one month). During this period, you'll perform the [[#Duties|duties]] of a support agent, but your contributions won't be eligible for compensation. This gives you a chance to get to know the ropes and for all parties involved to determine whether a support agent role is a good fit for you.

# Indicate in the <code>#support</code> channel that you're interested in interning as a Support Agent.
#* Say a bit about yourself and why you're interested in doing this work
#* Mention what days and times you'll be available to do this work
# The [[Support Team Lead]] will then:
#* Add you to the [https://github.com/orgs/bisq-network/teams/intern-support-agents @bisq-network/intern-support-agents] team
#* Add your requested shifts to the support coverage calendar
#* Announce your internship:
#** with a message to the larger [https://github.com/orgs/bisq-network/teams/support @bisq-network/support] team
#** with a message in the <code>#support</code> channel
# After one full cycle of interning
#* Submit a [[Proposals|proposal]] to be added to the [https://github.com/orgs/bisq-network/teams/l1-support-agents @bisq-network/l1-support-agents] team
#* If your proposal is approved, the support team lead will promote you as per the process below.

===Using the coverage calendar===

===Case tracking===

===Escalation===

===Reporting===

===Compensation===

[[Category:Roles]]

Stakeholder

2020-06-08T08:00:44Z

Cbeams: Remove unwanted Agent category

A ''stakeholder'' is an owner of [[BSQ]] and therefore capable of participating in Bisq DAO [[governance]].

[[Category:Roles]]

Mediator

2020-06-08T08:00:21Z

Cbeams: Remove unwanted Agent category

This article documents the ''Mediator'' [[Roles|role]].

A [[Mediator]] is a support role, his goal is to resolve a dispute between to parties efficiently, that is, without needing to reach the [[Refund Agent]]. A Mediator can only propose, the payout will only be made if both parties agree on the same outcome.

== Issue ==
* [https://github.com/bisq-network/roles/issues/83 Mediator #83]

== Team ==
* [https://github.com/orgs/bisq-network/teams/mediators @bisq-network/mediators]

== Duties ==

''TODO: transcribe / adapt this section to the dedicated [[Mediation]] process article, such that it can be consumed by both mediators and users alike. This section will remain, but should consist of a shorter list of bullet points linking to the [[Mediation]] article, being available on Keybase, mentioning what to do with updating / creating bug issues.''

* Handle support tickets
* Being available on Keybase.
* When bugs occur, create detailed issues on Github.

For more thorough details please consult [[Mediation]]

== Rights ==

* Writer access to the <code>bisq.support</code> Keybase subteam
* Compensation request rights per case solved

== Bonding ==

[https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L68 Bond Link]
10 * [[DOA_PARAM|DOA PARAM.BONDED_ROLE_FACTOR]]

[[Category:Roles]]

Fee Reimbursement Agent

2020-06-08T08:00:05Z

Cbeams: Remove unwanted Agent category

This article documents the ''Fee Reimbursement Agent'' [[role]].

A [[Fee Reimbursement Agent]] Refunds traders who have lost fees on a given trade.(reimbursements are made with btc)
They must provide a screenshot and details of the trade they wish to be reimbursed from.
__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/76 Fee Reimbursement Agent #76]
== Team ==

* [https://github.com/orgs/bisq-network/teams/fee-reimbursement-agents @bisq-network/fee-reimbursement-agents]

== Duties ==
* assign them to yourself manually to every fee reimbursement issue.
* add them to the lost fee reimbursement board.
* Examine every Github proposal, verify that the taker and maker fee address are mentioned in the issue. then move to "ready" [https://github.com/bisq-network/support/projects/1 Lost fee reimbursements]
* When starting to process an individual issue, move it to "In progress". Then open the terminal.
* Make a clone of the support repository.
* Enter ./helpers/automate.sh
* Add issue number, verify the information is correct.
* Follow the next steps and publish. move issue to "staged"
* Now make the reimbursement and close issue.

== Rights ==


== Bonding ==


[[Category:Roles]]

Arbitrator

2020-06-08T07:59:43Z

Cbeams: Remove unwanted Agent category

An '''arbitrator''' resolves disputes that could not be resolved by traders on their own or with a [[Mediator|mediator]]'s help.

Arbitrators investigate disputes, just like mediators. But unlike mediators, whose suggestions encourage traders to make payouts from their own escrowed funds, an arbitrator's findings lead to a payout from the arbitrator themselves.

__TOC__

== Role Notes ==

=== Arbitrator's Role in Dispute Resolution ===

Currently, the arbitrator makes BTC payouts to aggrieved traders out of their own pocket and gets refunded by the Bisq DAO (hence the term ''refund agent'' used sometimes). But this arrangement is meant to be temporary, intended as a convenience so that traders can avoid making a reimbursement request to the DAO on their own. As software bugs are reduced and UX is improved, arbitrators will cease to make payouts, and instead, their findings will serve as a basis for the Bisq DAO to issue payouts directly to aggrieved traders.

The arbitrator role is one element of Bisq's decentralized dispute resolution process. Please see more details at [[Arbitration|arbitration]].

=== Arbitrator versus Legacy Arbitrator ===

Although arbitrators have been a component of dispute resolution on Bisq since its early days, the v1.2 update wholly changed the nature of the role.

Before the update, trade funds were secured in a 2-of-3 multisig escrow, in which arbitrators held the third key. They would evaluate disputes and then sign funds to traders as they saw fit. Since these arbitrators (which we now refer to as ''legacy arbitrators'') had some element of control over users' funds, those who filled the role had to be ''very'' highly trusted.

The v1.2 update enabled trade funds to be secured in a 2-of-2 multisig escrow, in which arbitrators have '''no involvement'''. Mediators handle most disputes, but if an arbitrator does get involved, payouts either come from the arbitrator's own pocket or from the Bisq DAO. Arbitrators are still trusted to conduct their role with integrity and consistency, but this is a wholly different kind of trust, one that is unrelated to the handling of users' funds, and thus one that doesn't even require a bond.

== Issue ==
[https://github.com/bisq-network/roles/issues/93 Refund Agent #93]

== Team ==
[https://github.com/orgs/bisq-network/teams/refund-agents @bisq-network/refund-agents]

== Duties ==
* Investigate trader disputes and determine how payout should be made (must respond to traders within 5 days)
* Do payouts to traders as appropriate with BTC
* Request BSQ reimbursement from the Bisq DAO

== Rights ==
* Write access to the <code>bisq.support</code> Keybase subteam

== Bonding ==
[https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L69 Bond Link]
200 * [[DOA_PARAM|DAO PARAM.BONDED_ROLE_FACTOR]]
[[Category:Roles]]

YouTube Admin

2020-06-08T07:55:44Z

Cbeams: Remove unwanted Admin category

This article documents the ''YouTube Admin'' [[role]].

__TOC__

== Issue ==

* [https://github.com/bisq-network/roles/issues/56 YouTube Admin #56]
== Team ==

===github===
* [https://github.com/orgs/bisq-network/teams/youtube-admins @bisq-network/youtube-admins]
===wiki===

== Duties ==

This role is responsible for managing the [https://www.youtube.com/channel/UCDrHtlIlYfdRx4Gr-MV8NrA Bisq YouTube channel] where folks can follow demo videos, talks, interviews, etc.
== Rights ==

* "Manager" rights over Channel

== Bonding ==

[https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L48 Bond Link]
10 * [[DOA_PARAM|DOA PARAM.BONDED_ROLE_FACTOR]]
[[Category:Roles]]

Support Team Lead

2020-06-08T07:55:03Z

Cbeams: Remove unwanted Admin and TeamsLeader categories

This article documents the ''Support Team Lead'' [[role]].

__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/102 Support Team Lead #102]

== Team ==
===github===
* [https://github.com/orgs/bisq-network/teams/team-leads Team Leads team]
* [https://github.com/orgs/bisq-network/teams/support Support Team]
===wiki===
* [[Support_Team|Support Team]]

== Duties ==

* Review Team's [[Compensation]] requests as per Process.

== Rights ==


== Bonding ==
N/A

[[Category:Roles]]

Roles Maintainer

2020-06-08T07:54:39Z

Cbeams: Remove unwanted Admin category

This article documents the ''Roles Maintainer'' [[role]].

Roles Maintainers are the contributors responsible for the system of roles described throughout the rest of this document.

__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/28 Roles Maintainer #28]

== Team ==
===github===
* [https://github.com/orgs/bisq-network/teams/roles-maintainers Roles Maintainer]
===wiki===
* [[Roles_Maintainer|Roles Maintainer]]

== Duties ==
* Follow and enforce the [[Roles | roles Processes]].
* Report monthly on the Roles Maintainer Issue.
* Document changes to roles Processes.
* Communicate in the #roles [Keybase] channel.

== Rights ==
* Write access to the [https://github.com/bisq-network/roles bisq-network/roles] repository.

== Bonding ==
N/A

[[Category:Roles]]

[[Category:Maintainer]]

Roles

2020-06-08T07:53:21Z

Cbeams: Reverted edits by HunterNyan (talk) to last revision by Cbeams

This article is a stub pending the transcription of https://docs.bisq.network/roles.html here to the wiki. See https://github.com/bisq-network/roles/issues for the canonical list of all current roles and see [[:Category:Roles|Category:Roles]] for a list of all roles documented here on the wiki.

__TOC__

== Documentation ==

Each role should be documented as a wiki article using using the template below.

<nowiki>
This article documents the ''<Role Name>'' [[role]].

__TOC__

== Issue ==


== Team ==


== Duties ==


== Rights ==


== Bonding ==


[[Category:Roles]]
</nowiki>

[[Category:DAO]]
[[Category:Processes]]
[[Category:Stubs]]

Donation Address Owner

2020-06-08T07:49:54Z

Cbeams: Remove unwanted Admin category

Compensation Maintainer

2020-06-08T07:47:54Z

Cbeams:

This article documents the ''Compensation Maintainer'' [[role]].

__TOC__

== Issue ==
* [https://github.com/bisq-network/roles/issues/102 Support Team Lead #102]

== Team ==
===github===
* [https://github.com/orgs/bisq-network/teams/compensation-maintainers Compensation Maintainer]
===wiki===
* [[Compensation_Maintainer|Compensation Maintainer]]

== Duties ==
* Lead the operation of the [[Compensation]] Process.

== Rights ==

* Repo Access: https://github.com/bisq-network/compensation/

== Bonding ==
N/A

[[Category:Roles]]
[[Category:Maintainer]]

DOA PARAM

2020-05-18T07:30:07Z

Cbeams: Cbeams moved page DOA PARAM to DAO PARAM: Fix typo in article name s/DOA/DAO/

#REDIRECT [[DAO PARAM]]

Compensation

2020-05-06T07:43:19Z

Cbeams: Re-do MwithM's latest edit after undoing HunterNyan's earlier change

__TOC__

== Processes by role ==

=== Compensation Maintainer ===

==== Announce BSQ-USD exchange rate ====

Compensation requests [https://github.com/bisq-network/compensation/issues/519 should use a 90-day volume weighted average] to calculate a value for BSQ and mitigate its volatility. At the end of a Bisq DAO Cycle and beginning of a new one, the Compensation Maintainer should create a pinned issue with the title: <code>BSQ rate for Cycle X is Y.YY USD per 1 BSQ</code> and a screenshot of DAO Dashboard to announce the rates for the ongoing cycle.

==== Announce request submission deadline ====

To give time for team leads to discuss and review Compensation Requests, requests need to be <code>Ready for review</code> one week prior to the end of current cycle's proposal phase. [[File:Compensation_board.png|400px|right|thumb|Compensation board]]The date and reminders will be announced at [https://github.com/orgs/bisq-network/teams/dao/discussions/ @bisq-network/dao], the [https://github.com/orgs/bisq-network/projects/5 Compensation board] and [https://calendar.google.com/calendar/embed?src=adfiuiokq9jtac8t9keomc00b0%40group.calendar.google.com&ctz=Europe%2FMadrid Events Calendar]

==== Triage incoming requests ====

The Compensation Maintainer watches the [https://github.com/bisq-network/compensation/issues compensation repository] and proceeds to triage:

Incoming issues are classified as <code>Work in progress</code> if they have <code>[WIP]</code> at the beginning of the title or as <code>In Review</code> if they don't. Compensation Maintainer assigns 'In review' issues to corresponding team leads after looking at the content of the request. When in doubt, Compensation Maintainer should ask in the issue which team leaders are the appropriate for the issue.

The Compensation Maintainer should transition reviewed requests with DAO proposals transaction ID submitted to <code>Proposal Submitted</code> column.

Triage is controlled from the Compensation board, drag-and-dropping issues and using "add cards" to triage incoming issues, and directly from the issues, using the "projects" section in the right sidebar.

==== Archive previous cycle requests at the end of the proposal phase ====

At the completion of the current cycle's proposal phase, the Compensation Maintainer should [https://help.github.com/en/github/managing-your-work-on-github/archiving-cards-on-a-project-board archive] all issues in the <code>Done</code> column from the previous phase.

The reason for waiting to archive these issues is so that contributors can easily see how many requests were made in the last phase, to quickly find their own prior request, and to to easily review which ones were accepted and rejected. We archive them at the end of the proposal phase in order to keep the board clean and make room for requests in the current phase to populate the <code>Done</code> column.

==== Close current cycle requests after the vote reveal phase ====

When the reveal vote phase is complete, the Compensation Maintainer should take the following steps:

# Label each compensation request issue as <code>was:accepted</code> or <code>was:rejected</code> according to the vote result
# Close the issue with a comment that reads "Closing as accepted" or "Closing as rejected".

Once closed, the issues will automatically transition to the <code>Done</code> column of the board where they remain for reference until they are archived at the end of the next cycle's proposal phase (as per the section above).

=== Contributor ===

==== Create your compensation request issue ====

If you wish to request compensation for the current [[Glossary#DAO Cycle|cycle]], you should [https://docs.bisq.network/compensation.html#submit-your-compensation-request create a compensation request issue] no later than '''one week prior''' to the end of the current cycle's proposal phase. This is in order to allow time for review by your [[Team Lead]]. Reminders about this deadline are sent every cycle to the [https://github.com/bisq-network/teams/dao @bisq-network/dao] team, so you should make sure you are watching discussions for that team.

WIP (Work in Progress) compensation requests may be submitted with a <code>[WIP]</code> prefix in the title, e.g. <code>[WIP] For Cycle 10</code>. Such WIP requests are assumed not to be ready for review until the WIP prefix is removed. This allows you a convenient way to incrementally add content to a compensation request throughout the course of a cycle without triggering a review prematurely. To indicate that a WIP compensation request is now ready for review, remove the <code>[WIP]</code> prefix from the compensation request issue and add a comment stating ''"This request is ready for review"''. Any compensation request submitted without a WIP prefix will be assumed to be ready for review.

==== Incorporate review feedback for your request ====

When your team lead or other stakeholders review your compensation request, they will provide any feedback or requests for changes in the form of a comment on your request issue. Please respond to it promptly. When there is no further feedback, your team lead will add a comment asking you to submit this compensation request as a DAO proposal. The instructions how to do so are in the next section.

==== Submit your request as a DAO proposal ====

Follow the instructions on how to [https://docs.bisq.network/compensation.html#file-your-compensation-request-in-the-dao file your compensation request as a DAO proposal]. When complete, add a comment to your proposal issue that includes the transaction ID of your proposal.

=== Team Lead ===

==== Review team member requests ====

When a team lead is assigned to a compensation request issue, they should promptly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as a appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should add a comment asking the contributor to submit their proposal to DAO and to post the resulting TXID in a comment.

=== Stakeholder ===

==== Review contributor requests ====
Remember that just as stakeholders may vote on any DAO proposal, stakeholders may review any contributor's compensation request. To do so, simply add your review feedback in the form of a comment, and react to the compensation request issue with a thumbs-up, thumbs-down or confused face emoji as appropriate. Note that with the exception of team leads, there is no obligation to perform these reviews, and in general you should only review compensation requests that you are knowledgeable about.

[[Category:Processes]]

Compensation

2020-05-06T07:37:15Z

Cbeams: Undo revision 1175 by HunterNyan (talk)

__TOC__

== Processes by role ==

=== Compensation Maintainer ===

==== Announce BSQ-USD exchange rate ====

Since proposal [https://github.com/bisq-network/compensation/issues/114 #114], compensation requests should use a 90 day average to calculate value for BSQ and mitigate its volatility. At the end of a Bisq DAO Cycle and beginning of a new one, Compensation Maintainer should create a pinned issue with the title: <code>BSQ rate for Cycle X is Y.YY USD per 1 BSQ</code> and a screenshot of DAO Dashboard to announce the rates for the ongoing cycle.

==== Announce request submission deadline ====

To give time for team leads to discuss and review Compensation Requests, requests need to be <code>Ready for review</code> one week prior to the end of current cycle's proposal phase. [[File:Compensation_board.png|400px|right|thumb|Compensation board]]The date and reminders will be announced at [https://github.com/orgs/bisq-network/teams/dao/discussions/ @bisq-network/dao], the [https://github.com/orgs/bisq-network/projects/5 Compensation board] and [https://calendar.google.com/calendar/embed?src=adfiuiokq9jtac8t9keomc00b0%40group.calendar.google.com&ctz=Europe%2FMadrid Events Calendar]

==== Triage incoming requests ====

The Compensation Maintainer watches the [https://github.com/bisq-network/compensation/issues compensation repository] and proceeds to triage:

Incoming issues are classified as <code>Work in progress</code> if they have <code>[WIP]</code> at the beginning of the title or as <code>In Review</code> if they don't. Compensation Maintainer assigns 'In review' issues to corresponding team leads after looking at the content of the request. When in doubt, Compensation Maintainer should ask in the issue which team leaders are the appropriate for the issue.

The Compensation Maintainer should transition reviewed requests with DAO proposals transaction ID submitted to <code>Proposal Submitted</code> column.

Triage is controlled from the Compensation board, drag-and-dropping issues and using "add cards" to triage incoming issues, and directly from the issues, using the "projects" section in the right sidebar.

==== Archive previous cycle requests at the end of the proposal phase ====

At the completion of the current cycle's proposal phase, the Compensation Maintainer should [https://help.github.com/en/github/managing-your-work-on-github/archiving-cards-on-a-project-board archive] all issues in the <code>Done</code> column from the previous phase.

The reason for waiting to archive these issues is so that contributors can easily see how many requests were made in the last phase, to quickly find their own prior request, and to to easily review which ones were accepted and rejected. We archive them at the end of the proposal phase in order to keep the board clean and make room for requests in the current phase to populate the <code>Done</code> column.

==== Close current cycle requests after the vote reveal phase ====

When the reveal vote phase is complete, the Compensation Maintainer should take the following steps:

# Label each compensation request issue as <code>was:accepted</code> or <code>was:rejected</code> according to the vote result
# Close the issue with a comment that reads "Closing as accepted" or "Closing as rejected".

Once closed, the issues will automatically transition to the <code>Done</code> column of the board where they remain for reference until they are archived at the end of the next cycle's proposal phase (as per the section above).

=== Contributor ===

==== Create your compensation request issue ====

If you wish to request compensation for the current [[Glossary#DAO Cycle|cycle]], you should [https://docs.bisq.network/compensation.html#submit-your-compensation-request create a compensation request issue] no later than '''one week prior''' to the end of the current cycle's proposal phase. This is in order to allow time for review by your [[Team Lead]]. Reminders about this deadline are sent every cycle to the [https://github.com/bisq-network/teams/dao @bisq-network/dao] team, so you should make sure you are watching discussions for that team.

WIP (Work in Progress) compensation requests may be submitted with a <code>[WIP]</code> prefix in the title, e.g. <code>[WIP] For Cycle 10</code>. Such WIP requests are assumed not to be ready for review until the WIP prefix is removed. This allows you a convenient way to incrementally add content to a compensation request throughout the course of a cycle without triggering a review prematurely. To indicate that a WIP compensation request is now ready for review, remove the <code>[WIP]</code> prefix from the compensation request issue and add a comment stating ''"This request is ready for review"''. Any compensation request submitted without a WIP prefix will be assumed to be ready for review.

==== Incorporate review feedback for your request ====

When your team lead or other stakeholders review your compensation request, they will provide any feedback or requests for changes in the form of a comment on your request issue. Please respond to it promptly. When there is no further feedback, your team lead will add a comment asking you to submit this compensation request as a DAO proposal. The instructions how to do so are in the next section.

==== Submit your request as a DAO proposal ====

Follow the instructions on how to [https://docs.bisq.network/compensation.html#file-your-compensation-request-in-the-dao file your compensation request as a DAO proposal]. When complete, add a comment to your proposal issue that includes the transaction ID of your proposal.

=== Team Lead ===

==== Review team member requests ====

When a team lead is assigned to a compensation request issue, they should promptly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as a appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should add a comment asking the contributor to submit their proposal to DAO and to post the resulting TXID in a comment.

=== Stakeholder ===

==== Review contributor requests ====
Remember that just as stakeholders may vote on any DAO proposal, stakeholders may review any contributor's compensation request. To do so, simply add your review feedback in the form of a comment, and react to the compensation request issue with a thumbs-up, thumbs-down or confused face emoji as appropriate. Note that with the exception of team leads, there is no obligation to perform these reviews, and in general you should only review compensation requests that you are knowledgeable about.

[[Category:Processes]]

Compensation

2020-05-06T07:36:23Z

Cbeams: Undo revision 1213 by Cbeams (talk)

'''Compensation'''  The process in which Contributors can be compensated for their work via the DAO.

__TOC__

=Introduction=

* To incentivize further development & operation of Bisq

=Infrastructure=

==GitHub==
* Write Permissions to issues for [https://github.com/bisq-network/compensation/issues compensation repository].

=Roles=

==[[Admin Team]]== 
===[[Compensation Maintainer]]=== 
* Managing the Compensation Requests

==[[BSQ Explorer Team]]==
==[[Dev Team]]==
==[[Growth Team]]==
==[[Ops Team]]==
==[[Support Team]]==
===All Contributors===
* Submit Compensation Requests
===All Team Leads===
* Approve / Review their Team's requests

=Process=
==Step 0==

=== [[Compensation Maintainer]] ===
==== Announce BSQ-USD exchange rate ====
Since proposal [https://github.com/bisq-network/compensation/issues/114 #114], compensation requests should use a 90-day average to calculate a value for BSQ and mitigate its volatility.
At the end of a Bisq DAO Cycle and beginning of a new one, The [[Compensation Maintainer]] should create a pinned issue with the title: <code>BSQ rate for Cycle X is Y.YY USD per 1 BSQ</code> and a screenshot of DAO Dashboard to announce the rates for the ongoing cycle.

==== Announce request submission deadline ====
To give time for team leads to discuss and review Compensation Requests, requests need to be <code>Ready for review</code> one week prior to the end of current cycle's proposal phase. [[File:Compensation_board.png|400px|right|thumb|Compensation board]]The date and reminders will be announced at [https://github.com/orgs/bisq-network/teams/dao/discussions/ @bisq-network/dao], the [https://github.com/orgs/bisq-network/projects/5 Compensation board] and [https://calendar.google.com/calendar/embed?src=adfiuiokq9jtac8t9keomc00b0%40group.calendar.google.com&ctz=Europe%2FMadrid Events Calendar]

==Step 1==


=== Contributor ===
==== Create your compensation request issue ====

If you wish to request compensation for the current [[Glossary#DAO Cycle|cycle]], you should [https://docs.bisq.network/compensation.html#submit-your-compensation-request create a compensation request issue] no later than '''one week prior''' to the end of the current cycle's proposal phase. This is in order to allow time for review by your [[Team Lead]]. Reminders about this deadline are sent every cycle to the [https://github.com/bisq-network/teams/dao @bisq-network/dao] team, so you should make sure you are watching discussions for that team.

WIP (Work in Progress) compensation requests may be submitted with a <code>[WIP]</code> prefix in the title, e.g. <code>[WIP] For Cycle 10</code>. Such WIP requests are assumed not to be ready for review until the WIP prefix is removed. This allows you a convenient way to incrementally add content to a compensation request throughout the course of a cycle without triggering a review prematurely. To indicate that a WIP compensation request is now ready for review, remove the <code>[WIP]</code> prefix from the compensation request issue and add a comment stating ''"This request is ready for review"''. Any compensation request submitted without a WIP prefix will be assumed to be ready for review.

=== Compensation Maintainer ===
==== Triage incoming requests ====

The [[Compensation Maintainer]] watches the [https://github.com/bisq-network/compensation/issues compensation repository] and proceeds to triage:

Incoming issues are classified as <code>Work in progress</code> if they have <code>[WIP]</code> at the beginning of the title or as <code>In Review</code> if they don't. Compensation Maintainer assigns 'In review' issues to the corresponding team leads after looking at the content of the request. When in doubt, Compensation Maintainer should ask in the issue which team leaders are appropriate for the issue.

The Compensation Maintainer should transition reviewed requests with DAO proposals transaction ID submitted to <code>Proposal Submitted</code> column.

Triage is controlled from the Compensation board, drag-and-dropping issues and using "add cards" to triage incoming issues, and directly from the issues, using the "projects" section in the right sidebar.

==Step 2==

=== Team Lead ===
==== Review team member requests ====

When a team lead is assigned to a compensation request issue, they should promptly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should add a comment asking the contributor to submit their proposal to DAO and to post the resulting TXID in a comment.

=== [[Stakeholder]] ===
==== Review contributor requests ====
Remember that just as stakeholders may vote on any DAO proposal, stakeholders may review any contributor's compensation request. To do so, simply add your review feedback in the form of a comment, and react to the compensation request issue with a thumbs-up, thumbs-down or confused face emoji as appropriate. Note that with the exception of team leads, there is no obligation to perform these reviews, and in general you should only review compensation requests that you are knowledgeable about.

=== Contributor ===
==== Incorporate review feedback for your request ====

When your team lead or other stakeholders review your compensation request, they will provide any feedback or requests for changes in the form of a comment on your request issue. Please respond to it promptly.
When there is no further feedback, your team lead will add a comment asking you to submit this compensation request as a DAO proposal. You may now Procedure to Step 3

==Step 3==
=== Contributor ===
==== Submit your request as a DAO proposal ====

Follow the instructions on how to [https://docs.bisq.network/compensation.html#file-your-compensation-request-in-the-dao file your compensation request as a DAO proposal]. When complete, add a comment to your proposal issue that includes the transaction ID of your proposal.

==Step 4==
=== Compensation Maintainer ===
==== Archive previous cycle requests at the end of the proposal phase ====

At the completion of the current cycle's proposal phase, the Compensation Maintainer should [https://help.github.com/en/github/managing-your-work-on-github/archiving-cards-on-a-project-board archive] all issues in the <code>Done</code> column from the previous phase.

The reason for waiting to archive these issues is so that contributors can easily see how many requests were made in the last phase, to quickly find their own prior request, and to to easily review which ones were accepted and rejected. We archive them at the end of the proposal phase in order to keep the board clean and make room for requests in the current phase to populate the <code>Done</code> column.

==== Close current cycle requests after the vote reveal phase ====
When the reveal vote phase is complete, the Compensation Maintainer should take the following steps:

# Label each compensation request issue as <code>was:accepted</code> or <code>was:rejected</code> according to the vote result
# Close the issue with a comment that reads "Closing as accepted" or "Closing as rejected".

Once closed, the issues will automatically transition to the <code>Done</code> column of the board where they remain for reference until they are archived at the end of the next cycle's proposal phase (as per the section above).

=Evaluation=



=Guidelines=


[[Category:Process]]

Compensation

2020-05-06T07:33:26Z

Cbeams: Reverted edits by Cbeams (talk) to last revision by MwithM

'''Compensation'''  The process in which Contributors can be compensated for their work via the DAO.

__TOC__

=Introduction=

* To incentivize further development & operation of Bisq

=Infrastructure=

==GitHub==
* Write Permissions to issues for [https://github.com/bisq-network/compensation/issues compensation repository].

=Roles=

==[[Admin Team]]== 
===[[Compensation Maintainer]]=== 
* Managing the Compensation Requests

==[[BSQ Explorer Team]]==
==[[Dev Team]]==
==[[Growth Team]]==
==[[Ops Team]]==
==[[Support Team]]==
===All Contributors===
* Submit Compensation Requests
===All Team Leads===
* Approve / Review their Team's requests

=Process=
==Step 0==

=== [[Compensation Maintainer]] ===
==== Announce BSQ-USD exchange rate ====
Compensation requests should use a 90-day volume weighted average[https://bisq.wiki/index.php?title=Compensation&action=submit#References 1] to calculate a value for BSQ and mitigate its volatility.
At the end of a Bisq DAO Cycle and beginning of a new one, the [[Compensation Maintainer]] should create a pinned issue with the title: <code>BSQ rate for Cycle X is Y.YY USD per 1 BSQ</code> and a screenshot of DAO Dashboard to announce the rates for the ongoing cycle.

==== Announce request submission deadline ====
To give time for team leads to discuss and review Compensation Requests, requests need to be <code>Ready for review</code> one week prior to the end of current cycle's proposal phase. [[File:Compensation_board.png|400px|right|thumb|Compensation board]]The date and reminders will be announced at [https://github.com/orgs/bisq-network/teams/dao/discussions/ @bisq-network/dao], the [https://github.com/orgs/bisq-network/projects/5 Compensation board] and [https://calendar.google.com/calendar/embed?src=adfiuiokq9jtac8t9keomc00b0%40group.calendar.google.com&ctz=Europe%2FMadrid Events Calendar]

==Step 1==


=== Contributor ===
==== Create your compensation request issue ====

If you wish to request compensation for the current [[Glossary#DAO Cycle|cycle]], you should [https://docs.bisq.network/compensation.html#submit-your-compensation-request create a compensation request issue] no later than '''one week prior''' to the end of the current cycle's proposal phase. This is in order to allow time for review by your [[Team Lead]]. Reminders about this deadline are sent every cycle to the [https://github.com/bisq-network/teams/dao @bisq-network/dao] team, so you should make sure you are watching discussions for that team.

WIP (Work in Progress) compensation requests may be submitted with a <code>[WIP]</code> prefix in the title, e.g. <code>[WIP] For Cycle 10</code>. Such WIP requests are assumed not to be ready for review until the WIP prefix is removed. This allows you a convenient way to incrementally add content to a compensation request throughout the course of a cycle without triggering a review prematurely. To indicate that a WIP compensation request is now ready for review, remove the <code>[WIP]</code> prefix from the compensation request issue and add a comment stating ''"This request is ready for review"''. Any compensation request submitted without a WIP prefix will be assumed to be ready for review.

=== Compensation Maintainer ===
==== Triage incoming requests ====

The [[Compensation Maintainer]] watches the [https://github.com/bisq-network/compensation/issues compensation repository] and proceeds to triage:

Incoming issues are classified as <code>Work in progress</code> if they have <code>[WIP]</code> at the beginning of the title or as <code>In Review</code> if they don't. Compensation Maintainer assigns 'In review' issues to the corresponding team leads after looking at the content of the request. When in doubt, Compensation Maintainer should ask in the issue which team leaders are appropriate for the issue.

The Compensation Maintainer should transition reviewed requests with DAO proposals transaction ID submitted to <code>Proposal Submitted</code> column.

Triage is controlled from the Compensation board, drag-and-dropping issues and using "add cards" to triage incoming issues, and directly from the issues, using the "projects" section in the right sidebar.

==Step 2==

=== Team Lead ===
==== Review team member requests ====

When a team lead is assigned to a compensation request issue, they should promptly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should add a comment asking the contributor to submit their proposal to DAO and to post the resulting TXID in a comment.

=== [[Stakeholder]] ===
==== Review contributor requests ====
Remember that just as stakeholders may vote on any DAO proposal, stakeholders may review any contributor's compensation request. To do so, simply add your review feedback in the form of a comment, and react to the compensation request issue with a thumbs-up, thumbs-down or confused face emoji as appropriate. Note that with the exception of team leads, there is no obligation to perform these reviews, and in general you should only review compensation requests that you are knowledgeable about.

=== Contributor ===
==== Incorporate review feedback for your request ====

When your team lead or other stakeholders review your compensation request, they will provide any feedback or requests for changes in the form of a comment on your request issue. Please respond to it promptly.
When there is no further feedback, your team lead will add a comment asking you to submit this compensation request as a DAO proposal. You may now Procedure to Step 3

==Step 3==
=== Contributor ===
==== Submit your request as a DAO proposal ====

Follow the instructions on how to [https://docs.bisq.network/compensation.html#file-your-compensation-request-in-the-dao file your compensation request as a DAO proposal]. When complete, add a comment to your proposal issue that includes the transaction ID of your proposal.

==Step 4==
=== Compensation Maintainer ===
==== Archive previous cycle requests at the end of the proposal phase ====

At the completion of the current cycle's proposal phase, the Compensation Maintainer should [https://help.github.com/en/github/managing-your-work-on-github/archiving-cards-on-a-project-board archive] all issues in the <code>Done</code> column from the previous phase.

The reason for waiting to archive these issues is so that contributors can easily see how many requests were made in the last phase, to quickly find their own prior request, and to to easily review which ones were accepted and rejected. We archive them at the end of the proposal phase in order to keep the board clean and make room for requests in the current phase to populate the <code>Done</code> column.

==== Close current cycle requests after the vote reveal phase ====
When the reveal vote phase is complete, the Compensation Maintainer should take the following steps:

# Label each compensation request issue as <code>was:accepted</code> or <code>was:rejected</code> according to the vote result
# Close the issue with a comment that reads "Closing as accepted" or "Closing as rejected".

Once closed, the issues will automatically transition to the <code>Done</code> column of the board where they remain for reference until they are archived at the end of the next cycle's proposal phase (as per the section above).

=Evaluation=



=Guidelines=


=References=
1. https://github.com/bisq-network/compensation/issues/519

[[Category:Process]]

Compensation

2020-05-06T07:33:12Z

Cbeams: Reverted edits by MwithM (talk) to last revision by HunterNyan

Project management

2020-04-29T12:23:12Z

Cbeams: /* Review */ Add note about revising the bi-weekly call requirement

This article documents the project management process used within the Bisq DAO.

== Purpose ==

The purpose of the project management process is to ensure we:

* work on what's most important,
* finish what we start,
* stay within our budget, and
* don't spread ourselves too thin.

== Philosophy ==

=== Most work is project work ===

Many efforts under the Bisq DAO require multiple tasks to be carried out by multiple contributors, possibly across multiple [[:Category:Teams|teams]] and a span of time. Such efforts are best managed as ''projects'' having a beginning and an end, with clear criteria for delivery and a strong owner who takes responsibility for its success.

=== Identifying candidate projects ===

Good examples of candidate projects include:

* Adding a new feature or making a major enhancement to the Bisq client
* Introducing a new process within the Bisq DAO or significantly changing an existing one

Non-examples include:

* Typo fixes
* Minor enhancements and bug fixes
* Carrying out the regular duties of a given [[Roles|role]]

It is ultimately a judgement call whether a given effort should be managed as a project. Here are a few rules of thumb:

* Does it require multiple tasks? It's probably a project.
* Does it require people other than yourself to take action? It's probably a project.
* Does it require documentation and/or promotion to make sure people know about it? It's probably a project.

Work that starts out as a single task may evolve to become a project, and that's fine. But by thinking ahead a little, we can often identify projects up front and better manage them as a result.

=== Good project management scales ===

A primary goal of the project management process is to help the DAO scale. We want many contributors collaborating on many efforts in parallel with minimal management. To achieve this, the process must have a bottom-up aspect in which any contributor can propose a project and any stakeholder can participate in approving it, and it must also have a top-down aspect for allocating budget to the most important projects. The approach laid out here is designed to strike that balance.

== Roles and teams ==

=== Project owner ===

A project owner:

* is responsible for the delivery of a given project
* is usually the same contributor that proposes the project
* attends review meetings and reports on the project(s) they are responsible for

=== Stakeholders and users ===

DAO [[stakeholder|stakeholders]] and Bisq users are responsible for providing approval feedback on project proposals.


=== Project management committee ===

The [https://github.com/orgs/bisq-network/teams/pmc @bisq-network/pmc] is responsible for the overall project management process, including:

* triaging new project proposals
* accepting or rejecting proposals per stakeholder approval
* leading project review calls

=== Team leads ===

[https://github.com/orgs/bisq-network/teams/team-leads @bisq-network/team-leads] are responsible for prioritizing accepted projects by allocating budget to them.

=== Contributors ===

Contributors are responsible for performing the tasks necessary to deliver a project.

== Resources ==

=== Projects repository ===

Projects are managed as GitHub Issues at https://github.com/bisq-network/projects/issues. The [https://github.com/bisq-network/projects/blob/master/.github/ISSUE_TEMPLATE/project-proposal.md issue template] there defines what a well-formed project proposal should include.

=== Project boards ===

An approved project may have its own dedicated project board at https://github.com/orgs/bisq-network/projects for the purpose of tracking individual tasks. Otherwise, tasks may be tracked as simple checkboxes in the project issue description or by whatever means the project owner sees fit (e.g. an external kanban board); in general, however, it is preferred that everything is managed within GitHub Issues.

=== Master projects board ===

The master projects board is available at https://github.com/orgs/bisq-network/projects/3 and provides an overview of all projects and their status.

== Process ==

=== Overview ===

Anyone may '''propose''' a project so long as they are prepared to ''own'' it. Each new proposal goes through '''triage''' and, if ''well-formed'', moves on to stakeholder '''approval''' where it is ''accepted'' or ''rejected'' on its merits. An accepted project is allocated '''budget''' according to its priority and is subject to regular '''review''' until the project is '''closed''' as ''delivered'' or ''aborted''.

=== Proposal ===

To create a well-formed project proposal:

# Create a [https://github.com/bisq-network/projects/issues/new/choose new issue in the projects repository]
# Choose the <code>Project proposal</code> issue template
# Adhere to the format of the template and fill out its content according to the instructions within

New project proposal issues are automatically labeled as <code>a:proposal</code> and <code>needs:triage</code>.

=== Triage ===

A member of the project management committee will add each new project proposal to the <code>Backlog</code> column of the master projects board and assess whether it is well-formed according to the issue template.

If a proposal is well-formed, the triager will:
* remove the <code>needs:triage</code> label,
* add the <code>needs:approval</code> label and
* add a corresponding comment.

If a proposal is not well-formed, the triager will:
* add the <code>needs:info</code> label and a comment asking the submitter to provide the missing information, or
* add the <code>was:invalid</code> label and close the issue immediately with a corresponding comment.

=== Approval ===

Like any DAO [[proposals|proposal]], anyone may add comments providing feedback on a project proposal and may react to the proposal issue description with thumbs-up, thumbs-down or confused face emoji to indicate whether they believe the project should be approved. The goal is to arrive at a [https://en.wikipedia.org/wiki/Rough_consensus rough consensus] whether to approve the project. Taking a project proposal through formal stakeholder [[voting]] should be avoided unless there is significant unresolved contention.

Once consensus has been achieved, a member of the project management committee will:

* remove the <code>a:proposal</code> and <code>needs:approval</code> labels
* add the <code>has:approval</code> or <code>was:rejected</code> label as appropriate
* add a comment indicating the status change
* close the issue if rejected

=== Budgeting ===

Acceptance of a project is distinct from allocating budget to it. Acceptance indicates that a project is worth doing; allocating budget indicates that a project ''has priority.'' Team leads are responsible for reviewing accepted projects and adding the <code>has:budget</code> label when budget has been allocated.

=== Work ===

==== Starting work ====

Work may be started at any time on a project, even prior to approval and budgeting, but contributors should have no expectation of cooperation or compensation until the project has both.

In any case, when work starts, the project owner should move the project to the <code>In progress</code> column of the master projects board and add a corresponding comment.

If work is being resumed after a period of inactivity, the project owner should also remove any labels such as <code>is:blocked</code> or <code>is:stalled</code>.

==== Stopping work ====

When work stops for an extended period the project owner should move the project issue to the <code>Backlog</code> column with a corresponding comment. If the project is blocked in some way, the <code>is:blocked</code> label should be applied. If work has stalled due to inactivity, the <code>is:stalled</code> label should be applied.

==== Requesting help ====

If a project cannot progress because a certain skill set is not available within the current team of contributors, the project owner should add the <code>needs:help</code> label with a corresponding comment that explains what kind of help is needed.

=== Review ===

'''''UPDATE:''' These bi-weekly calls may not be the way to go. We might end up doing things more asynchronously through issue comments and perhaps a once-a-month project review call. See https://github.com/bisq-network/proposals/issues/182#issuecomment-621167017 for ongoing discussion.''

Approved projects are subject to a bi-weekly (once every two weeks) review call in which each project owner provides a brief summary of their project, including whether it is on or off track, blocked for any reason, at risk of exceeding its scope or budget, etc. See the [[events calendar]] for details.

=== Closure ===

==== Closing as delivered ====

Projects that meet their criteria for delivery will be closed with the <code>was:delivered</code> label and a corresponding comment.

==== Closing as aborted ====

Projects may be aborted prior to delivery for a variety of reasons, including abandonment by project owner, consensus that the effort is no longer worth pursuing, exceeding allocated budget, being blocked by external factors, and so forth. Such projects will be closed with the <code>was:aborted</code> label and a corresponding comment.

==== Closing as deferred ====

Projects that are blocked or stalled for an extended period of time may be closed with the <code>was:deferred</code> label and a corresponding comment. Deferral is appropriate if the project is something that we'd still like to do, but see no near-term path to actually working on. A deferred project may be reopened when it becomes feasible to work on it, but any prior budget allocation should be assumed invalid.

==== Closing as superseded ====

Projects may be closed with the <code>was:superseded</code> label when another project becomes a more appropriate vehicle for getting the same or similar work done. When closing, a comment should be added providing a link to the superseding project.

=== Compensation ===

Ideally, compensation should be requested after a project has been closed, but this is not always practical. A contributor may request compensation for work on a given project prior to that project's closure assuming that the work in question has itself been meaningfully delivered. For example, if a [[Growth Team]] project involves creating and publishing an instructional video, the video creator may request compensation for their work assuming the video has been published and promoted to its intended audience even if the larger growth project is still in progress.

[[Category:Processes]]

Manual payout

2020-04-08T07:28:31Z

Cbeams: /* 1. Get private keys */ Add missing </code> tag

== Warning ==

In this process you copy and paste your private keys from the Bisq software into a web browser. As a precaution it is advised you remove all of your funds from this wallet before starting this procedure.

== Precautions ==

This method is only necessary in extreme occasions where one of the traders may not be available. Therefore it is important to make sure that the person who constructs the transaction does not defraud the other signers.

== What you need ==

This document uses open source tools (other than Bisq) to create, sign and broadcast transactions of funds locked in multisig transactions.
To spend out of a multisig, two things are needed:
* A redeem script.
* Enough private keys to meet the minimum multisig threshold. Use the string in <code>priv WIF=</code> instead of <code>priv HEX=</code>.

Bisq does not provide the Redeem Script for the multisig, but we can recreate it with all the public keys involved in the multisig.

Tools you need:
* Bisq software
* [http://explorerzydxu5ecjrkwceayqybizmpjjznk5izmitf2modhcusuqlid.onion Blockstream's block explorer]
* [http://4zpinp6gdkjfplhk.onion Coinbin web wallet]
* [https://www.torproject.org/ Tor browser]

== 1. Get private keys ==

To access your Bisq wallet private key
# Press <code>Ctrl + j</code>, <code>alt +j</code> or <code>cmd + j</code>.
# Check <code>Include private keys</code> and click <code>COPY TO CLIPBOARD</code>.
# Copy, paste and save that information in a <code>bisqWallet.txt</code> file.

== 2. Get multisig public keys ==

Each trader involved can get their public keys and the other trader's public keys in their trade JSON contract.
<ol type="a">
<li>Find your trade under <code>PORTFOLIO</code>.</li>
<li>Click the <code>i</code> icon next to the trade ID, and at the bottom click <code>VIEW CONTRACT IN JSON FORMAT</code>. At the end, you see the Buyer and Seller public keys:</li>
</ol>
<nowiki>
BuyerMultiSigPubKeyHex: <hex value>
SellerMultiSigPubKeyHex: <hex value></nowiki>

'''About the legacy protocol'''

If resolving a trade with the old (legacy) protocol that involved a 2-of-3 multisig, a third public key belonging to the arbitrator is necessary. The arbitrator can get this public key by following the steps above and search in their own <code>bisqWallet.txt</code> file for it. They can find it by looking for the public key for their Arbitrator address. It is the one in the line with <code>context=ARBITRATOR</code>.

An alternative way to get the arbitrator's public key is to look for it in the blockchain. This can be done if at least one of the traders paid the trading fees in BTC.

By tracking the BTC trading fee you can find the cluster of other trades that arbitrator was involved in. Then you need to find to Payout transactions - spending from a 2-of-3 multisig. In these transactions will be able to find three revealed public keys for each trade. The one that is present in both trades is the arbitrator's.

== 3. Get payout addresses ==

At the end of the JSON contract file you can also find the intended payout address for each trader:
<nowiki>
makerPayoutAddressString: <address value>
takerPayoutAddressString: <address value></nowiki>

== 4. Recreating Redeem script ==

For all the web interactions use the Tor browser.
<ol type="a">
<li>Go to the [http://4zpinp6gdkjfplhk.onion Coinbin web wallet]:</li>
<li>At the top click <code>New</code> and from the dropdown menu choose <code>MultiSig Address</code></li>
<li>Paste the three public keys in the following order:</li>
*Arbitrator
*BuyerMultiSigPubKeyHex
*SellerMultiSigPubKeyHex
<li>Click <code>submit</code> to see an address and a Redeem Script. Make sure the address matches the multisig address for the trade. If not, try to change the order of the public keys.</li>
<li>Copy and save the Redeem Script.</li>
</ol>

== 5. Creating transaction ==
<ol type="a">
<li>Again, click <code>New</code> at the top, but this time choose <code>Transaction</code> from the dropdown menu.</li>
<li>Paste the Redeem Script in the text field at the top and click <code>Load</code>. It should take a few seconds and then return the value locked in the multisig.</li>
<li>For the first input fill in an address from <code>makerPayoutAddressString</code> and the respective trade amount.</li>
<li>Add a new output by clicking the <code>+</code> sign next to the <code>amount</code> field. For this second output paste the address that belongs to <code>takerPayoutAddressString</code> and the respective trade amount.</li>
<li>Click <code>submit</code> to obtain an encoded transaction string.</li>
<li>Copy and save the transaction.</li>
</ol>

== 6. Verify transaction ==

Click <code>Verify</code> at the top and paste the encoded string obtained from the step 5.e. Verify it all is correct before moving to the next step.

== 7. Sign transaction ==
<ol type="a">
<li>Click <code>Sign</code> at the top of the page and paste your WIF private key obtained in step 1.b in the <code>Private key</code> text field and the encoded transaction in the text field below. To find the private key, search your <code>bisqWallet.txt</code> file for the value of the <code>BuyerMultiSigPubKeyHex</code> (or <code>SellerMultiSigPubKeyHex</code> if you are the seller), obtained in step 2.b. The private key beginning with <code>priv WIF=</code> is written after the search result. Ensure that the pasted private key is only the part after the <code>priv WIF=</code>.</li>
<li>Click <code>Submit</code> to get a new encoded transaction string. </li>
<li>Copy and save it and share it with the other parties of the multisig so they can sign and broadcast it.</li>
</ol>

== 8. Second signature and broadcast ==
<ol type="a">
<li>The second signer clicks <code>Verify</code> at the top of the Coinbin website and pastes the encoded string the previous signer shared with you. If you are ok with it, click <code>Sign</code> at the top of the page and paste your WIF private key from step 1 on the <code>Private key</code> text field and the encoded transaction shared with you in the text field below.</li>
<li></li>
<li>Click <code>Submit</code> to get a new encoded transaction string.</li>
<li>Copy and save it.</li>
</ol>
==9. Verify transaction before broadcasting==
<ol type="a">
<li>Confirm everything is correct and click <code>Broadcast</code> at the top of the page.</li>
<li> After you have signed the transaction paste the encoded transaction string and click <code>Submit</code>.</li>
<li> When complete, delete the <code>bisqWallet.txt</code> file created in step 1.c.</li>
</ol>

Manual payout

2020-04-06T06:56:47Z

Cbeams: Polish <nowiki> blocks

__NOTOC__== Warning ==

In this process you copy and paste your private keys from the Bisq software into a web browser. As a precaution it is advised you remove all of your funds from this wallet before starting this procedure.

== Precautions ==

This method is only necessary in extreme occasions where one of the traders may not be available. Therefore it is important to make sure that the person who constructs the transaction does not defraud the other signers.

== What you need ==

This document uses open source tools (other than Bisq) to create, sign and broadcast transactions of funds locked in multisig transactions.
To spend out of a multisig, two things are needed:
* A redeem script.
* Enough private keys to meet the minimum multisig threshold. Use the string in <code>priv WIF=</code> instead of <code>priv HEX=</code>.

Bisq does not provide the Redeem Script for the multisig, but we can recreate it with all the public keys involved in the multisig.

Tools you need:
* Bisq software
* [http://explorerzydxu5ecjrkwceayqybizmpjjznk5izmitf2modhcusuqlid.onion Blockstream's block explorer]
* [http://4zpinp6gdkjfplhk.onion Coinbin web wallet]
* [https://www.torproject.org/ Tor browser]

== 1. Get private keys ==
<ol type="a">
<li>To access your Bisq wallet's private key press <code>Ctrl + j</code>, <code>alt +j</code> or <code>cmd + j</code>.</li>
<li>Check <code>Include private keys</code> and click <code>COPY TO CLIPBOARD</code>.</li>
<li>Copy, paste and save that information in a <code>bisqWallet.txt</code> file.</li>
</ol>

== 2. Get multisig public keys ==

Each trader involved can get their public keys and the other trader's public keys in their trade JSON contract.
<ol type="a">
<li>Find your trade under <code>PORTFOLIO</code>.</li>
<li>Click the <code>i</code> icon next to the trade ID, and at the bottom click <code>VIEW CONTRACT IN JSON FORMAT</code>. At the end, you see the Buyer and Seller public keys:</li>
</ol>
<nowiki>
BuyerMultiSigPubKeyHex: <hex value>
SellerMultiSigPubKeyHex: <hex value></nowiki>

'''About the legacy protocol'''

If resolving a trade with the old (legacy) protocol that involved a 2-of-3 multisig, a third public key belonging to the arbitrator is necessary. The arbitrator can get this public key by following the steps above and search in their own <code>bisqWallet.txt</code> file for it. They can find it by looking for the public key for their Arbitrator address. It is the one in the line with <code>context=ARBITRATOR</code>.

An alternative way to get the arbitrator's public key is to look for it in the blockchain. This can be done if at least one of the traders paid the trading fees in BTC.

By tracking the BTC trading fee you can find the cluster of other trades that arbitrator was involved in. Then you need to find to Payout transactions - spending from a 2-of-3 multisig. In these transactions will be able to find three revealed public keys for each trade. The one that is present in both trades is the arbitrator's.

== 3. Get payout addresses ==

At the end of the JSON contract file you can also find the intended payout address for each trader:
<nowiki>
makerPayoutAddressString: <address value>
takerPayoutAddressString: <address value></nowiki>

== 4. Recreating Redeem script ==

For all the web interactions use the Tor browser.
<ol type="a">
<li>Go to the [http://4zpinp6gdkjfplhk.onion Coinbin web wallet]:</li>
<li>At the top click <code>New</code> and from the dropdown menu choose <code>MultiSig Address</code></li>
<li>Paste the three public keys in the following order:</li>
*Arbitrator
*BuyerMultiSigPubKeyHex
*SellerMultiSigPubKeyHex
<li>Click <code>submit</code> to see an address and a Redeem Script. Make sure the address matches the multisig address for the trade. If not, try to change the order of the public keys.</li>
<li>Copy and save the Redeem Script.</li>
</ol>

== 5. Creating transaction ==
<ol type="a">
<li>Again, click <code>New</code> at the top, but this time choose <code>Transaction</code> from the dropdown menu.</li>
<li>Paste the Redeem Script in the text field at the top and click <code>Load</code>. It should take a few seconds and then return the value locked in the multisig.</li>
<li>For the first input fill in an address from <code>makerPayoutAddressString</code> and the respective trade amount.</li>
<li>Add a new output by clicking the <code>+</code> sign next to the <code>amount</code> field. For this second output paste the address that belongs to <code>takerPayoutAddressString</code> and the respective trade amount.</li>
<li>Click <code>submit</code> to obtain an encoded transaction string.</li>
<li>Copy and save the transaction.</li>
</ol>

== 6. Verify transaction ==

Click <code>Verify</code> at the top and paste the encoded string obtained from the step 5.e. Verify it all is correct before moving to the next step.

== 7. Sign transaction ==
<ol type="a">
<li>Click <code>Sign</code> at the top of the page and paste your WIF private key obtained in step 1.b in the <code>Private key</code> text field and the encoded transaction in the text field below. To find the private key, search your <code>bisqWallet.txt</code> file for the value of the <code>BuyerMultiSigPubKeyHex</code> (or <code>SellerMultiSigPubKeyHex</code> if you are the seller), obtained in step 2.b. The private key beginning with <code>priv WIF=</code> is written after the search result. Ensure that the pasted private key is only the part after the <code>priv WIF=</code>.</li>
<li>Click <code>Submit</code> to get a new encoded transaction string. </li>
<li>Copy and save it and share it with the other parties of the multisig so they can sign and broadcast it.</li>
</ol>

== 8. Second signature and broadcast ==
<ol type="a">
<li>The second signer clicks <code>Verify</code> at the top of the Coinbin website and pastes the encoded string the previous signer shared with you. If you are ok with it, click <code>Sign</code> at the top of the page and paste your WIF private key from step 1 on the <code>Private key</code> text field and the encoded transaction shared with you in the text field below.</li>
<li></li>
<li>Click <code>Submit</code> to get a new encoded transaction string.</li>
<li>Copy and save it.</li>
</ol>
==9. Verify transaction before broadcasting==
<ol type="a">
<li>Confirm everything is correct and click <code>Broadcast</code> at the top of the page.</li>
<li> After you have signed the transaction paste the encoded transaction string and click <code>Submit</code>.</li>
<li> When complete, delete the <code>bisqWallet.txt</code> file created in step 1.c.</li>
</ol>

Manual payout

2020-04-06T06:49:35Z

Cbeams: Fix typo

__NOTOC__== Warning ==

In this process you copy and paste your private keys from the Bisq software into a web browser. As a precaution it is advised you remove all of your funds from this wallet before starting this procedure.

== Precautions ==

This method is only necessary in extreme occasions where one of the traders may not be available. Therefore it is important to make sure that the person who constructs the transaction does not defraud the other signers.

== What you need ==

This document uses open source tools (other than Bisq) to create, sign and broadcast transactions of funds locked in multisig transactions.
To spend out of a multisig, two things are needed:
* A redeem script.
* Enough private keys to meet the minimum multisig threshold. Use the string in <code>priv WIF=</code> instead of <code>priv HEX=</code>.

Bisq does not provide the Redeem Script for the multisig, but we can recreate it with all the public keys involved in the multisig.

Tools you need:
* Bisq software
* [http://explorerzydxu5ecjrkwceayqybizmpjjznk5izmitf2modhcusuqlid.onion Blockstream's block explorer]
* [http://4zpinp6gdkjfplhk.onion Coinbin web wallet]
* [https://www.torproject.org/ Tor browser]

== 1. Get private keys ==
<ol type="a">
<li>To access your Bisq wallet's private key press <code>Ctrl + j</code>, <code>alt +j</code> or <code>cmd + j</code>.</li>
<li>Check <code>Include private keys</code> and click <code>COPY TO CLIPBOARD</code>.</li>
<li>Copy, paste and save that information in a <code>bisqWallet.txt</code> file.</li>
</ol>

== 2. Get multisig public keys ==

Each trader involved can get their public keys and the other trader's public keys in their trade JSON contract.
<ol type="a">
<li>Find your trade under <code>PORTFOLIO</code>.</li>
<li>Click the <code>i</code> icon next to the trade ID, and at the bottom click <code>VIEW CONTRACT IN JSON FORMAT</code>. At the end, you see the Buyer and Seller public keys:</li>
</ol>
<nowiki>
BuyerMultiSigPubKeyHex:
SellerMultiSigPubKeyHex:
</nowiki>

'''About the legacy protocol'''

If resolving a trade with the old (legacy) protocol that involved a 2-of-3 multisig, a third public key belonging to the arbitrator is necessary. The arbitrator can get this public key by following the steps above and search in their own <code>bisqWallet.txt</code> file for it. They can find it by looking for the public key for their Arbitrator address. It is the one in the line with <code>context=ARBITRATOR</code>.

An alternative way to get the arbitrator's public key is to look for it in the blockchain. This can be done if at least one of the traders paid the trading fees in BTC.

By tracking the BTC trading fee you can find the cluster of other trades that arbitrator was involved in. Then you need to find to Payout transactions - spending from a 2-of-3 multisig. In these transactions will be able to find three revealed public keys for each trade. The one that is present in both trades is the arbitrator's.

== 3. Get payout addresses ==

At the end of the JSON contract file you can also find the intended payout address for each trader:
<nowiki>
makerPayoutAddressString:
takerPayoutAddressString:</nowiki>

== 4. Recreating Redeem script ==

For all the web interactions use the Tor browser.
<ol type="a">
<li>Go to the [http://4zpinp6gdkjfplhk.onion Coinbin web wallet]:</li>
<li>At the top click <code>New</code> and from the dropdown menu choose <code>MultiSig Address</code></li>
<li>Paste the three public keys in the following order:</li>
*Arbitrator
*BuyerMultiSigPubKeyHex
*SellerMultiSigPubKeyHex
<li>Click <code>submit</code> to see an address and a Redeem Script. Make sure the address matches the multisig address for the trade. If not, try to change the order of the public keys.</li>
<li>Copy and save the Redeem Script.</li>
</ol>

== 5. Creating transaction ==
<ol type="a">
<li>Again, click <code>New</code> at the top, but this time choose <code>Transaction</code> from the dropdown menu.</li>
<li>Paste the Redeem Script in the text field at the top and click <code>Load</code>. It should take a few seconds and then return the value locked in the multisig.</li>
<li>For the first input fill in an address from <code>makerPayoutAddressString</code> and the respective trade amount.</li>
<li>Add a new output by clicking the <code>+</code> sign next to the <code>amount</code> field. For this second output paste the address that belongs to <code>takerPayoutAddressString</code> and the respective trade amount.</li>
<li>Click <code>submit</code> to obtain an encoded transaction string.</li>
<li>Copy and save the transaction.</li>
</ol>

== 6. Verify transaction ==

Click <code>Verify</code> at the top and paste the encoded string obtained from the step 5.e. Verify it all is correct before moving to the next step.

== 7. Sign transaction ==
<ol type="a">
<li>Click <code>Sign</code> at the top of the page and paste your WIF private key obtained in step 1.b in the <code>Private key</code> text field and the encoded transaction in the text field below. To find the private key, search your <code>bisqWallet.txt</code> file for the value of the <code>BuyerMultiSigPubKeyHex</code> (or <code>SellerMultiSigPubKeyHex</code> if you are the seller), obtained in step 2.b. The private key beginning with <code>priv WIF=</code> is written after the search result. Ensure that the pasted private key is only the part after the <code>priv WIF=</code>.</li>
<li>Click <code>Submit</code> to get a new encoded transaction string. </li>
<li>Copy and save it and share it with the other parties of the multisig so they can sign and broadcast it.</li>
</ol>

== 8. Second signature and broadcast ==
<ol type="a">
<li>The second signer clicks <code>Verify</code> at the top of the Coinbin website and pastes the encoded string the previous signer shared with you. If you are ok with it, click <code>Sign</code> at the top of the page and paste your WIF private key from step 1 on the <code>Private key</code> text field and the encoded transaction shared with you in the text field below.</li>
<li></li>
<li>Click <code>Submit</code> to get a new encoded transaction string.</li>
<li>Copy and save it.</li>
</ol>
==9. Verify transaction before broadcasting==
<ol type="a">
<li>Confirm everything is correct and click <code>Broadcast</code> at the top of the page.</li>
<li> After you have signed the transaction paste the encoded transaction string and click <code>Submit</code>.</li>
<li> When complete, delete the <code>bisqWallet.txt</code> file created in step 1.c.</li>
</ol>

Compensation

2020-03-12T13:59:34Z

Cbeams: /* Review team member requests */ Fix typo

__TOC__

== Processes by role ==

=== Compensation Maintainer ===

==== Announce BSQ-USD exchange rate ====

Since proposal [https://github.com/bisq-network/compensation/issues/114 #114], compensation requests should use a 90 day average mean to calculate value for BSQ and mitigate its volatility. At the end of a Bisq DAO Cycle and beginning of a new one, Compensation Maintainer should create a pinned issue with the title: <code>BSQ rate for Cycle X is Y.YY USD per 1 BSQ</code> and a screenshot of DAO Dashboard to announce the rates for the ongoing cycle.

==== Announce request submission deadline ====

To give time for team leads to discuss and review Compensation Requests, requests need to be <code>Ready for review</code> one week prior to the end of current cycle's proposal phase. [[File:Compensation_board.png|400px|right|thumb|Compensation board]]The date and reminders will be announced at [https://github.com/orgs/bisq-network/teams/dao/discussions/ @bisq-network/dao], the [https://github.com/orgs/bisq-network/projects/5 Compensation board] and [https://calendar.google.com/calendar/embed?src=adfiuiokq9jtac8t9keomc00b0%40group.calendar.google.com&ctz=Europe%2FMadrid Events Calendar]

==== Triage incoming requests ====

The Compensation Maintainer watches the [https://github.com/bisq-network/compensation/issues compensation repository] and proceeds to triage:

Incoming issues are classified as <code>Work in progress</code> if they have <code>[WIP]</code> at the beginning of the title or as <code>In Review</code> if they don't. Compensation Maintainer assigns 'In review' issues to corresponding team leads after looking at the content of the request. When in doubt, Compensation Maintainer should ask in the issue which team leaders are the appropriate for the issue.

The Compensation Maintainer should transition reviewed requests with DAO proposals transaction ID submitted to <code>Proposal Submitted</code> column.

Triage is controlled from the Compensation board, drag-and-dropping issues and using "add cards" to triage incoming issues, and directly from the issues, using the "projects" section in the right sidebar.

==== Archive previous cycle requests at the end of the proposal phase ====

At the completion of the current cycle's proposal phase, the Compensation Maintainer should [https://help.github.com/en/github/managing-your-work-on-github/archiving-cards-on-a-project-board archive] all issues in the <code>Done</code> column from the previous phase.

The reason for waiting to archive these issues is so that contributors can easily see how many requests were made in the last phase, to quickly find their own prior request, and to to easily review which ones were accepted and rejected. We archive them at the end of the proposal phase in order to keep the board clean and make room for requests in the current phase to populate the <code>Done</code> column.

==== Close current cycle requests after the vote reveal phase ====

When the reveal vote phase is complete, the Compensation Maintainer should take the following steps:

# Label each compensation request issue as <code>was:accepted</code> or <code>was:rejected</code> according to the vote result
# Close the issue with a comment that reads "Closing as accepted" or "Closing as rejected".

Once closed, the issues will automatically transition to the <code>Done</code> column of the board where they remain for reference until they are archived at the end of the next cycle's proposal phase (as per the section above).

=== Contributor ===

==== Create your compensation request issue ====

If you wish to request compensation for the current [[Glossary#DAO Cycle|cycle]], you should [https://docs.bisq.network/compensation.html#submit-your-compensation-request create a compensation request issue] no later than '''one week prior''' to the end of the current cycle's proposal phase. This is in order to allow time for review by your [[Team Lead]]. Reminders about this deadline are sent every cycle to the [https://github.com/bisq-network/teams/dao @bisq-network/dao] team, so you should make sure you are watching discussions for that team.

WIP (Work in Progress) compensation requests may be submitted with a <code>[WIP]</code> prefix in the title, e.g. <code>[WIP] For Cycle 10</code>. Such WIP requests are assumed not to be ready for review until the WIP prefix is removed. This allows you a convenient way to incrementally add content to a compensation request throughout the course of a cycle without triggering a review prematurely. To indicate that a WIP compensation request is now ready for review, remove the <code>[WIP]</code> prefix from the compensation request issue and add a comment stating ''"This request is ready for review"''. Any compensation request submitted without a WIP prefix will be assumed to be ready for review.

==== Incorporate review feedback for your request ====

When your team lead or other stakeholders review your compensation request, they will provide any feedback or requests for changes in the form of a comment on your request issue. Please respond to it promptly. When there is no further feedback, your team lead will add a comment asking you to submit this compensation request as a DAO proposal. The instructions how to do so are in the next section.

==== Submit your request as a DAO proposal ====

Follow the instructions on how to [https://docs.bisq.network/compensation.html#file-your-compensation-request-in-the-dao file your compensation request as a DAO proposal]. When complete, add a comment to your proposal issue that includes the transaction ID of your proposal.

=== Team Lead ===

==== Review team member requests ====

When a team lead is assigned to a compensation request issue, they should promptly review it with regard to whether the work meets the definition of delivered, and whether it fits within the team budget. The team lead should add feedback and comments as a appropriate, and assign the contributor to the issue to indicate that they are expected to respond to the review.

When the review process is complete, i.e. all team lead feedback has been addressed, the team lead should add a comment asking the contributor to submit their proposal to DAO and to post the resulting TXID in a comment.

=== Stakeholder ===

==== Review contributor requests ====
Remember that just as stakeholders may vote on any DAO proposal, stakeholders may review any contributor's compensation request. To do so, simply add your review feedback in the form of a comment, and react to the compensation request issue with a thumbs-up, thumbs-down or confused face emoji as appropriate. Note that with the exception of team leads, there is no obligation to perform these reviews, and in general you should only review compensation requests that you are knowledgeable about.

[[Category:Processes]]

Wiki Operator

2020-03-10T08:18:09Z

Cbeams:

This article documents the ''Wiki Operator'' [[Roles|role]].

__TOC__

== Issue ==
https://github.com/bisq-network/roles/issues/92

== Team ==
[https://github.com/orgs/bisq-network/teams/wiki-operators/members @bisq-network/wiki-operators]

== Duties ==
* Owning and renewing the bisq.wiki domain name
* Administering bisq.wiki DNS records
* Operating and administering the Mediawiki instance at bisq.wiki, including:
** Adding and maintaining plugins
** Daily Backups
*** Full MySQL database dump
*** Full filesystem archive of webroot
*** Off-site mirror of backup
* Triaging incoming issues to the bisq-network/wiki repository

== Rights ==
* Admin access to the bisq-network/wiki repository

== Bonding ==
Required but specifics are TBD.

[[Category:Roles]]
[[Category:Operator]]

Wiki Operator

2020-03-10T08:17:42Z

Cbeams: Remove from :Category:Stubs

This article documents the _Wiki Operator_ [[Roles|role]].

__TOC__

== Issue ==
https://github.com/bisq-network/roles/issues/92

== Team ==
[https://github.com/orgs/bisq-network/teams/wiki-operators/members @bisq-network/wiki-operators]

== Duties ==
* Owning and renewing the bisq.wiki domain name
* Administering bisq.wiki DNS records
* Operating and administering the Mediawiki instance at bisq.wiki, including:
** Adding and maintaining plugins
** Daily Backups
*** Full MySQL database dump
*** Full filesystem archive of webroot
*** Off-site mirror of backup
* Triaging incoming issues to the bisq-network/wiki repository

== Rights ==
* Admin access to the bisq-network/wiki repository

== Bonding ==
Required but specifics are TBD.

[[Category:Roles]]
[[Category:Operator]]

Support Team

2020-03-09T13:46:54Z

Cbeams: Add Wiki Editor to the list of roles under the support team

The Support Team is responsible for providing excellent [[user support|support]] for Bisq users. This includes:

* Handling individual support cases, including [[mediation]] and [[refunds]]
* Maintaining the Bisq [[Docs|docs website]]
* Maintaining support-related articles here on the Bisq [[wiki]].

__TOC__

== Roles ==

* [[Support Team Lead]]
* L1/L2 [[Support Agent]]
* [[Mediator]]
* [[Arbitrator]]
* [[Refund Agent]]
* [[Donation Address Owner]] (aka Burning Man)
* [[Wiki Editor]]

== Resources ==

=== GitHub Team ===

[https://github.com/orgs/bisq-network/teams/support @bisq-network/support]

=== GitHub Repositories ===

* https://github.com/bisq-network/support
* https://github.com/bisq-network/bisq-docs
* https://github.com/bisq-network/wiki

=== Keybase chat ===

* [[Keybase]] <code>#support</code> channel (public, for providing user support)
* Keybase <code>bisq.support</code> subteam (private, for Support Team contributors)

[[Category:Teams]]

Project management

2020-03-06T15:59:19Z

Cbeams: Use correct MediaWiki literal syntax

This article documents the project management process used within the Bisq DAO.

== Purpose ==

The purpose of the project management process is to ensure we:

* work on what's most important,
* finish what we start,
* stay within our budget, and
* don't spread ourselves too thin.

== Philosophy ==

=== Most work is project work ===

Many efforts under the Bisq DAO require multiple tasks to be carried out by multiple contributors, possibly across multiple [[:Category:Teams|teams]] and a span of time. Such efforts are best managed as ''projects'' having a beginning and an end, with clear criteria for delivery and a strong owner who takes responsibility for its success.

=== Identifying candidate projects ===

Good examples of candidate projects include:

* Adding a new feature or making a major enhancement to the Bisq client
* Introducing a new process within the Bisq DAO or significantly changing an existing one

Non-examples include:

* Typo fixes
* Minor enhancements and bug fixes
* Carrying out the regular duties of a given [[Roles|role]]

It is ultimately a judgement call whether a given effort should be managed as a project. Here are a few rules of thumb:

* Does it require multiple tasks? It's probably a project.
* Does it require people other than yourself to take action? It's probably a project.
* Does it require documentation and/or promotion to make sure people know about it? It's probably a project.

Work that starts out as a single task may evolve to become a project, and that's fine. But by thinking ahead a little, we can often identify projects up front and better manage them as a result.

=== Good project management scales ===

A primary goal of the project management process is to help the DAO scale. We want many contributors collaborating on many efforts in parallel with minimal management. To achieve this, the process must have a bottom-up aspect in which any contributor can propose a project and any stakeholder can participate in approving it, and it must also have a top-down aspect for allocating budget to the most important projects. The approach laid out here is designed to strike that balance.

== Roles and teams ==

=== Project owner ===

A project owner:

* is responsible for the delivery of a given project
* is usually the same contributor that proposes the project
* attends review meetings and reports on the project(s) they are responsible for

=== Stakeholders and users ===

DAO [[stakeholder|stakeholders]] and Bisq users are responsible for providing approval feedback on project proposals.


=== Project management committee ===

The [https://github.com/orgs/bisq-network/teams/pmc @bisq-network/pmc] is responsible for the overall project management process, including:

* triaging new project proposals
* accepting or rejecting proposals per stakeholder approval
* leading project review calls

=== Team leads ===

[https://github.com/orgs/bisq-network/teams/team-leads @bisq-network/team-leads] are responsible for prioritizing accepted projects by allocating budget to them.

=== Contributors ===

Contributors are responsible for performing the tasks necessary to deliver a project.

== Resources ==

=== Projects repository ===

Projects are managed as GitHub Issues at https://github.com/bisq-network/projects/issues. The [https://github.com/bisq-network/projects/blob/master/.github/ISSUE_TEMPLATE/project-proposal.md issue template] there defines what a well-formed project proposal should include.

=== Project boards ===

An approved project may have its own dedicated project board at https://github.com/orgs/bisq-network/projects for the purpose of tracking individual tasks. Otherwise, tasks may be tracked as simple checkboxes in the project issue description or by whatever means the project owner sees fit (e.g. an external kanban board); in general, however, it is preferred that everything is managed within GitHub Issues.

=== Master projects board ===

The master projects board is available at https://github.com/orgs/bisq-network/projects/3 and provides an overview of all projects and their status.

== Process ==

=== Overview ===

Anyone may '''propose''' a project so long as they are prepared to ''own'' it. Each new proposal goes through '''triage''' and, if ''well-formed'', moves on to stakeholder '''approval''' where it is ''accepted'' or ''rejected'' on its merits. An accepted project is allocated '''budget''' according to its priority and is subject to regular '''review''' until the project is '''closed''' as ''delivered'' or ''aborted''.

=== Proposal ===

To create a well-formed project proposal:

# Create a [https://github.com/bisq-network/projects/issues/new/choose new issue in the projects repository]
# Choose the <code>Project proposal</code> issue template
# Adhere to the format of the template and fill out its content according to the instructions within

New project proposal issues are automatically labeled as <code>a:proposal</code> and <code>needs:triage</code>.

=== Triage ===

A member of the project management committee will add each new project proposal to the <code>Backlog</code> column of the master projects board and assess whether it is well-formed according to the issue template.

If a proposal is well-formed, the triager will:
* remove the <code>needs:triage</code> label,
* add the <code>needs:approval</code> label and
* add a corresponding comment.

If a proposal is not well-formed, the triager will:
* add the <code>needs:info</code> label and a comment asking the submitter to provide the missing information, or
* add the <code>was:invalid</code> label and close the issue immediately with a corresponding comment.

=== Approval ===

Like any DAO [[proposals|proposal]], anyone may add comments providing feedback on a project proposal and may react to the proposal issue description with thumbs-up, thumbs-down or confused face emoji to indicate whether they believe the project should be approved. The goal is to arrive at a [https://en.wikipedia.org/wiki/Rough_consensus rough consensus] whether to approve the project. Taking a project proposal through formal stakeholder [[voting]] should be avoided unless there is significant unresolved contention.

Once consensus has been achieved, a member of the project management committee will:

* remove the <code>a:proposal</code> and <code>needs:approval</code> labels
* add the <code>has:approval</code> or <code>was:rejected</code> label as appropriate
* add a comment indicating the status change
* close the issue if rejected

=== Budgeting ===

Acceptance of a project is distinct from allocating budget to it. Acceptance indicates that a project is worth doing; allocating budget indicates that a project ''has priority.'' Team leads are responsible for reviewing accepted projects and adding the <code>has:budget</code> label when budget has been allocated.

=== Work ===

==== Starting work ====

Work may be started at any time on a project, even prior to approval and budgeting, but contributors should have no expectation of cooperation or compensation until the project has both.

In any case, when work starts, the project owner should move to project to the <code>In progress</code> column of the master projects board and add a corresponding comment.

If work is being resumed after a period of inactivity, the project owner should also remove any labels such as <code>is:blocked</code> or <code>is:stalled</code>.

==== Stopping work ====

When work stops for an extended period the project owner should move the project issue to the <code>Backlog</code> column with a corresponding comment. If the project is blocked in some way, the <code>is:blocked</code> label should be applied. If work has stalled due to inactivity, the <code>is:stalled</code> label should be applied.

==== Requesting help ====

If a project cannot progress because a certain skill set is not available within the current team of contributors, the project owner should add the <code>needs:help</code> label with a corresponding comment that explains what kind of help is needed.

=== Review ===

Approved projects are subject to a bi-weekly (once every two weeks) review call in which each project owner provides a brief summary of their project, including whether it is on or off track, blocked for any reason, at risk of exceeding its scope or budget, etc. See the [[events calendar]] for details.

=== Closure ===

==== Closing as delivered ====

Projects that meet their criteria for delivery will be closed with the <code>was:delivered</code> label and a corresponding comment.

==== Closing as aborted ====

Projects may be aborted prior to delivery for a variety of reasons, including abandonment by project owner, consensus that the effort is no longer worth pursuing, exceeding allocated budget, being blocked by external factors, and so forth. Such projects will be closed with the <code>was:aborted</code> label and a corresponding comment.

==== Closing as deferred ====

Projects that are blocked or stalled for an extended period of time may be closed with the <code>was:deferred</code> label and a corresponding comment. Deferral is appropriate if the project is something that we'd still like to do, but see no near-term path to actually working on. A deferred project may be reopened when it becomes feasible to work on it, but any prior budget allocation should be assumed invalid.

==== Closing as superseded ====

Projects may be closed with the <code>was:superseded</code> label when another project becomes a more appropriate vehicle for getting the same or similar work done. When closing, a comment should be added providing a link to the superseding project.

=== Compensation ===

Ideally, compensation should be requested after a project has been closed, but this is not always practical. A contributor may request compensation for work on a given project prior to that project's closure assuming that the work in question has itself been meaningfully delivered. For example, if a [[Growth Team]] project involves creating and publishing an instructional video, the video creator may request compensation for their work assuming the video has been published and promoted to its intended audience even if the larger growth project is still in progress.

[[Category:Processes]]

Project management

2020-03-06T15:56:37Z

Cbeams: Use correct MediaWiki link syntax

This article documents the project management process used within the Bisq DAO.

== Purpose ==

The purpose of the project management process is to ensure we:

* work on what's most important,
* finish what we start,
* stay within our budget, and
* don't spread ourselves too thin.

== Philosophy ==

=== Most work is project work ===

Many efforts under the Bisq DAO require multiple tasks to be carried out by multiple contributors, possibly across multiple [[:Category:Teams|teams]] and a span of time. Such efforts are best managed as ''projects'' having a beginning and an end, with clear criteria for delivery and a strong owner who takes responsibility for its success.

=== Identifying candidate projects ===

Good examples of candidate projects include:

* Adding a new feature or making a major enhancement to the Bisq client
* Introducing a new process within the Bisq DAO or significantly changing an existing one

Non-examples include:

* Typo fixes
* Minor enhancements and bug fixes
* Carrying out the regular duties of a given [[Roles|role]]

It is ultimately a judgement call whether a given effort should be managed as a project. Here are a few rules of thumb:

* Does it require multiple tasks? It's probably a project.
* Does it require people other than yourself to take action? It's probably a project.
* Does it require documentation and/or promotion to make sure people know about it? It's probably a project.

Work that starts out as a single task may evolve to become a project, and that's fine. But by thinking ahead a little, we can often identify projects up front and better manage them as a result.

=== Good project management scales ===

A primary goal of the project management process is to help the DAO scale. We want many contributors collaborating on many efforts in parallel with minimal management. To achieve this, the process must have a bottom-up aspect in which any contributor can propose a project and any stakeholder can participate in approving it, and it must also have a top-down aspect for allocating budget to the most important projects. The approach laid out here is designed to strike that balance.

== Roles and teams ==

=== Project owner ===

A project owner:

* is responsible for the delivery of a given project
* is usually the same contributor that proposes the project
* attends review meetings and reports on the project(s) they are responsible for

=== Stakeholders and users ===

DAO [[stakeholder|stakeholders]] and Bisq users are responsible for providing approval feedback on project proposals.


=== Project management committee ===

The [https://github.com/orgs/bisq-network/teams/pmc @bisq-network/pmc] is responsible for the overall project management process, including:

* triaging new project proposals
* accepting or rejecting proposals per stakeholder approval
* leading project review calls

=== Team leads ===

[https://github.com/orgs/bisq-network/teams/team-leads @bisq-network/team-leads] are responsible for prioritizing accepted projects by allocating budget to them.

=== Contributors ===

Contributors are responsible for performing the tasks necessary to deliver a project.

== Resources ==

=== Projects repository ===

Projects are managed as GitHub Issues at https://github.com/bisq-network/projects/issues. The [https://github.com/bisq-network/projects/blob/master/.github/ISSUE_TEMPLATE/project-proposal.md issue template] there defines what a well-formed project proposal should include.

=== Project boards ===

An approved project may have its own dedicated project board at https://github.com/orgs/bisq-network/projects for the purpose of tracking individual tasks. Otherwise, tasks may be tracked as simple checkboxes in the project issue description or by whatever means the project owner sees fit (e.g. an external kanban board); in general, however, it is preferred that everything is managed within GitHub Issues.

=== Master projects board ===

The master projects board is available at https://github.com/orgs/bisq-network/projects/3 and provides an overview of all projects and their status.

== Process ==

=== Overview ===

Anyone may '''propose''' a project so long as they are prepared to ''own'' it. Each new proposal goes through '''triage''' and, if ''well-formed'', moves on to stakeholder '''approval''' where it is ''accepted'' or ''rejected'' on its merits. An accepted project is allocated '''budget''' according to its priority and is subject to regular '''review''' until the project is '''closed''' as ''delivered'' or ''aborted''.

=== Proposal ===

To create a well-formed project proposal:

# Create a [https://github.com/bisq-network/projects/issues/new/choose new issue in the projects repository]
# Choose the `Project proposal` issue template
# Adhere to the format of the template and fill out its content according to the instructions within

New project proposal issues are automatically labeled as <code>a:proposal</code> and <code>needs:triage</code>.

=== Triage ===

A member of the project management committee will add each new project proposal to the <code>Backlog</code> column of the master projects board and assess whether it is well-formed according to the issue template.

If a proposal is well-formed, the triager will:
* remove the <code>needs:triage</code> label,
* add the <code>needs:approval</code> label and
* add a corresponding comment.

If a proposal is not well-formed, the triager will:
* add the <code>needs:info</code> label and a comment asking the submitter to provide the missing information, or
* add the <code>was:invalid</code> label and close the issue immediately with a corresponding comment.

=== Approval ===

Like any DAO [[proposals|proposal]], anyone may add comments providing feedback on a project proposal and may react to the proposal issue description with thumbs-up, thumbs-down or confused face emoji to indicate whether they believe the project should be approved. The goal is to arrive at a [https://en.wikipedia.org/wiki/Rough_consensus rough consensus] whether to approve the project. Taking a project proposal through formal stakeholder [[voting]] should be avoided unless there is significant unresolved contention.

Once consensus has been achieved, a member of the project management committee will:

* remove the <code>a:proposal</code> and <code>needs:approval</code> labels
* add the <code>has:approval</code> or <code>was:rejected</code> label as appropriate
* add a comment indicating the status change
* close the issue if rejected

=== Budgeting ===

Acceptance of a project is distinct from allocating budget to it. Acceptance indicates that a project is worth doing; allocating budget indicates that a project ''has priority.'' Team leads are responsible for reviewing accepted projects and adding the <code>has:budget</code> label when budget has been allocated.

=== Work ===

==== Starting work ====

Work may be started at any time on a project, even prior to approval and budgeting, but contributors should have no expectation of cooperation or compensation until the project has both.

In any case, when work starts, the project owner should move to project to the <code>In progress</code> column of the master projects board and add a corresponding comment.

If work is being resumed after a period of inactivity, the project owner should also remove any labels such as <code>is:blocked</code> or <code>is:stalled</code>.

==== Stopping work ====

When work stops for an extended period the project owner should move the project issue to the <code>Backlog</code> column with a corresponding comment. If the project is blocked in some way, the <code>is:blocked</code> label should be applied. If work has stalled due to inactivity, the <code>is:stalled</code> label should be applied.

==== Requesting help ====

If a project cannot progress because a certain skill set is not available within the current team of contributors, the project owner should add the <code>needs:help</code> label with a corresponding comment that explains what kind of help is needed.

=== Review ===

Approved projects are subject to a bi-weekly (once every two weeks) review call in which each project owner provides a brief summary of their project, including whether it is on or off track, blocked for any reason, at risk of exceeding its scope or budget, etc. See the [[events calendar]] for details.

=== Closure ===

==== Closing as delivered ====

Projects that meet their criteria for delivery will be closed with the <code>was:delivered</code> label and a corresponding comment.

==== Closing as aborted ====

Projects may be aborted prior to delivery for a variety of reasons, including abandonment by project owner, consensus that the effort is no longer worth pursuing, exceeding allocated budget, being blocked by external factors, and so forth. Such projects will be closed with the <code>was:aborted</code> label and a corresponding comment.

==== Closing as deferred ====

Projects that are blocked or stalled for an extended period of time may be closed with the <code>was:deferred</code> label and a corresponding comment. Deferral is appropriate if the project is something that we'd still like to do, but see no near-term path to actually working on. A deferred project may be reopened when it becomes feasible to work on it, but any prior budget allocation should be assumed invalid.

==== Closing as superseded ====

Projects may be closed with the <code>was:superseded</code> label when another project becomes a more appropriate vehicle for getting the same or similar work done. When closing, a comment should be added providing a link to the superseding project.

=== Compensation ===

Ideally, compensation should be requested after a project has been closed, but this is not always practical. A contributor may request compensation for work on a given project prior to that project's closure assuming that the work in question has itself been meaningfully delivered. For example, if a [[Growth Team]] project involves creating and publishing an instructional video, the video creator may request compensation for their work assuming the video has been published and promoted to its intended audience even if the larger growth project is still in progress.

[[Category:Processes]]

Project management

2020-03-06T15:55:55Z

Cbeams: Use correct MediaWiki link syntax

This article documents the project management process used within the Bisq DAO.

== Purpose ==

The purpose of the project management process is to ensure we:

* work on what's most important,
* finish what we start,
* stay within our budget, and
* don't spread ourselves too thin.

== Philosophy ==

=== Most work is project work ===

Many efforts under the Bisq DAO require multiple tasks to be carried out by multiple contributors, possibly across multiple [[:Category:Teams|teams]] and a span of time. Such efforts are best managed as ''projects'' having a beginning and an end, with clear criteria for delivery and a strong owner who takes responsibility for its success.

=== Identifying candidate projects ===

Good examples of candidate projects include:

* Adding a new feature or making a major enhancement to the Bisq client
* Introducing a new process within the Bisq DAO or significantly changing an existing one

Non-examples include:

* Typo fixes
* Minor enhancements and bug fixes
* Carrying out the regular duties of a given [[Roles|role]]

It is ultimately a judgement call whether a given effort should be managed as a project. Here are a few rules of thumb:

* Does it require multiple tasks? It's probably a project.
* Does it require people other than yourself to take action? It's probably a project.
* Does it require documentation and/or promotion to make sure people know about it? It's probably a project.

Work that starts out as a single task may evolve to become a project, and that's fine. But by thinking ahead a little, we can often identify projects up front and better manage them as a result.

=== Good project management scales ===

A primary goal of the project management process is to help the DAO scale. We want many contributors collaborating on many efforts in parallel with minimal management. To achieve this, the process must have a bottom-up aspect in which any contributor can propose a project and any stakeholder can participate in approving it, and it must also have a top-down aspect for allocating budget to the most important projects. The approach laid out here is designed to strike that balance.

== Roles and teams ==

=== Project owner ===

A project owner:

* is responsible for the delivery of a given project
* is usually the same contributor that proposes the project
* attends review meetings and reports on the project(s) they are responsible for

=== Stakeholders and users ===

DAO [[stakeholder|stakeholders]] and Bisq users are responsible for providing approval feedback on project proposals.


=== Project management committee ===

The [https://github.com/orgs/bisq-network/teams/pmc @bisq-network/pmc] is responsible for the overall project management process, including:

* triaging new project proposals
* accepting or rejecting proposals per stakeholder approval
* leading project review calls

=== Team leads ===

[https://github.com/orgs/bisq-network/teams/team-leads @bisq-network/team-leads] are responsible for prioritizing accepted projects by allocating budget to them.

=== Contributors ===

Contributors are responsible for performing the tasks necessary to deliver a project.

== Resources ==

=== Projects repository ===

Projects are managed as GitHub Issues at https://github.com/bisq-network/projects/issues. The [https://github.com/bisq-network/projects/blob/master/.github/ISSUE_TEMPLATE/project-proposal.md issue template] there defines what a well-formed project proposal should include.

=== Project boards ===

An approved project may have its own dedicated project board at https://github.com/orgs/bisq-network/projects for the purpose of tracking individual tasks. Otherwise, tasks may be tracked as simple checkboxes in the project issue description or by whatever means the project owner sees fit (e.g. an external kanban board); in general, however, it is preferred that everything is managed within GitHub Issues.

=== Master projects board ===

The master projects board is available at https://github.com/orgs/bisq-network/projects/3 and provides an overview of all projects and their status.

== Process ==

=== Overview ===

Anyone may '''propose''' a project so long as they are prepared to ''own'' it. Each new proposal goes through '''triage''' and, if ''well-formed'', moves on to stakeholder '''approval''' where it is ''accepted'' or ''rejected'' on its merits. An accepted project is allocated '''budget''' according to its priority and is subject to regular '''review''' until the project is '''closed''' as ''delivered'' or ''aborted''.

=== Proposal ===

To create a well-formed project proposal:

# Create a [new issue in the projects repository](https://github.com/bisq-network/projects/issues/new/choose)
# Choose the `Project proposal` issue template
# Adhere to the format of the template and fill out its content according to the instructions within

New project proposal issues are automatically labeled as <code>a:proposal</code> and <code>needs:triage</code>.

=== Triage ===

A member of the project management committee will add each new project proposal to the <code>Backlog</code> column of the master projects board and assess whether it is well-formed according to the issue template.

If a proposal is well-formed, the triager will:
* remove the <code>needs:triage</code> label,
* add the <code>needs:approval</code> label and
* add a corresponding comment.

If a proposal is not well-formed, the triager will:
* add the <code>needs:info</code> label and a comment asking the submitter to provide the missing information, or
* add the <code>was:invalid</code> label and close the issue immediately with a corresponding comment.

=== Approval ===

Like any DAO [[proposals|proposal]], anyone may add comments providing feedback on a project proposal and may react to the proposal issue description with thumbs-up, thumbs-down or confused face emoji to indicate whether they believe the project should be approved. The goal is to arrive at a [https://en.wikipedia.org/wiki/Rough_consensus rough consensus] whether to approve the project. Taking a project proposal through formal stakeholder [[voting]] should be avoided unless there is significant unresolved contention.

Once consensus has been achieved, a member of the project management committee will:

* remove the <code>a:proposal</code> and <code>needs:approval</code> labels
* add the <code>has:approval</code> or <code>was:rejected</code> label as appropriate
* add a comment indicating the status change
* close the issue if rejected

=== Budgeting ===

Acceptance of a project is distinct from allocating budget to it. Acceptance indicates that a project is worth doing; allocating budget indicates that a project ''has priority.'' Team leads are responsible for reviewing accepted projects and adding the <code>has:budget</code> label when budget has been allocated.

=== Work ===

==== Starting work ====

Work may be started at any time on a project, even prior to approval and budgeting, but contributors should have no expectation of cooperation or compensation until the project has both.

In any case, when work starts, the project owner should move to project to the <code>In progress</code> column of the master projects board and add a corresponding comment.

If work is being resumed after a period of inactivity, the project owner should also remove any labels such as <code>is:blocked</code> or <code>is:stalled</code>.

==== Stopping work ====

When work stops for an extended period the project owner should move the project issue to the <code>Backlog</code> column with a corresponding comment. If the project is blocked in some way, the <code>is:blocked</code> label should be applied. If work has stalled due to inactivity, the <code>is:stalled</code> label should be applied.

==== Requesting help ====

If a project cannot progress because a certain skill set is not available within the current team of contributors, the project owner should add the <code>needs:help</code> label with a corresponding comment that explains what kind of help is needed.

=== Review ===

Approved projects are subject to a bi-weekly (once every two weeks) review call in which each project owner provides a brief summary of their project, including whether it is on or off track, blocked for any reason, at risk of exceeding its scope or budget, etc. See the [[events calendar]] for details.

=== Closure ===

==== Closing as delivered ====

Projects that meet their criteria for delivery will be closed with the <code>was:delivered</code> label and a corresponding comment.

==== Closing as aborted ====

Projects may be aborted prior to delivery for a variety of reasons, including abandonment by project owner, consensus that the effort is no longer worth pursuing, exceeding allocated budget, being blocked by external factors, and so forth. Such projects will be closed with the <code>was:aborted</code> label and a corresponding comment.

==== Closing as deferred ====

Projects that are blocked or stalled for an extended period of time may be closed with the <code>was:deferred</code> label and a corresponding comment. Deferral is appropriate if the project is something that we'd still like to do, but see no near-term path to actually working on. A deferred project may be reopened when it becomes feasible to work on it, but any prior budget allocation should be assumed invalid.

==== Closing as superseded ====

Projects may be closed with the <code>was:superseded</code> label when another project becomes a more appropriate vehicle for getting the same or similar work done. When closing, a comment should be added providing a link to the superseding project.

=== Compensation ===

Ideally, compensation should be requested after a project has been closed, but this is not always practical. A contributor may request compensation for work on a given project prior to that project's closure assuming that the work in question has itself been meaningfully delivered. For example, if a [[Growth Team]] project involves creating and publishing an instructional video, the video creator may request compensation for their work assuming the video has been published and promoted to its intended audience even if the larger growth project is still in progress.

[[Category:Processes]]

Project management

2020-03-06T15:54:51Z

Cbeams: Link to new project proposal issue template

This article documents the project management process used within the Bisq DAO.

== Purpose ==

The purpose of the project management process is to ensure we:

* work on what's most important,
* finish what we start,
* stay within our budget, and
* don't spread ourselves too thin.

== Philosophy ==

=== Most work is project work ===

Many efforts under the Bisq DAO require multiple tasks to be carried out by multiple contributors, possibly across multiple [[:Category:Teams|teams]] and a span of time. Such efforts are best managed as ''projects'' having a beginning and an end, with clear criteria for delivery and a strong owner who takes responsibility for its success.

=== Identifying candidate projects ===

Good examples of candidate projects include:

* Adding a new feature or making a major enhancement to the Bisq client
* Introducing a new process within the Bisq DAO or significantly changing an existing one

Non-examples include:

* Typo fixes
* Minor enhancements and bug fixes
* Carrying out the regular duties of a given [[Roles|role]]

It is ultimately a judgement call whether a given effort should be managed as a project. Here are a few rules of thumb:

* Does it require multiple tasks? It's probably a project.
* Does it require people other than yourself to take action? It's probably a project.
* Does it require documentation and/or promotion to make sure people know about it? It's probably a project.

Work that starts out as a single task may evolve to become a project, and that's fine. But by thinking ahead a little, we can often identify projects up front and better manage them as a result.

=== Good project management scales ===

A primary goal of the project management process is to help the DAO scale. We want many contributors collaborating on many efforts in parallel with minimal management. To achieve this, the process must have a bottom-up aspect in which any contributor can propose a project and any stakeholder can participate in approving it, and it must also have a top-down aspect for allocating budget to the most important projects. The approach laid out here is designed to strike that balance.

== Roles and teams ==

=== Project owner ===

A project owner:

* is responsible for the delivery of a given project
* is usually the same contributor that proposes the project
* attends review meetings and reports on the project(s) they are responsible for

=== Stakeholders and users ===

DAO [[stakeholder|stakeholders]] and Bisq users are responsible for providing approval feedback on project proposals.


=== Project management committee ===

The [https://github.com/orgs/bisq-network/teams/pmc @bisq-network/pmc] is responsible for the overall project management process, including:

* triaging new project proposals
* accepting or rejecting proposals per stakeholder approval
* leading project review calls

=== Team leads ===

[https://github.com/orgs/bisq-network/teams/team-leads @bisq-network/team-leads] are responsible for prioritizing accepted projects by allocating budget to them.

=== Contributors ===

Contributors are responsible for performing the tasks necessary to deliver a project.

== Resources ==

=== Projects repository ===

Projects are managed as GitHub Issues at https://github.com/bisq-network/projects/issues. The [issue template](https://github.com/bisq-network/projects/blob/master/.github/ISSUE_TEMPLATE/project-proposal.md) there defines what a well-formed project proposal should include.

=== Project boards ===

An approved project may have its own dedicated project board at https://github.com/orgs/bisq-network/projects for the purpose of tracking individual tasks. Otherwise, tasks may be tracked as simple checkboxes in the project issue description or by whatever means the project owner sees fit (e.g. an external kanban board); in general, however, it is preferred that everything is managed within GitHub Issues.

=== Master projects board ===

The master projects board is available at https://github.com/orgs/bisq-network/projects/3 and provides an overview of all projects and their status.

== Process ==

=== Overview ===

Anyone may '''propose''' a project so long as they are prepared to ''own'' it. Each new proposal goes through '''triage''' and, if ''well-formed'', moves on to stakeholder '''approval''' where it is ''accepted'' or ''rejected'' on its merits. An accepted project is allocated '''budget''' according to its priority and is subject to regular '''review''' until the project is '''closed''' as ''delivered'' or ''aborted''.

=== Proposal ===

To create a well-formed project proposal:

# Create a [new issue in the projects repository](https://github.com/bisq-network/projects/issues/new/choose)
# Choose the `Project proposal` issue template
# Adhere to the format of the template and fill out its content according to the instructions within

New project proposal issues are automatically labeled as <code>a:proposal</code> and <code>needs:triage</code>.

=== Triage ===

A member of the project management committee will add each new project proposal to the <code>Backlog</code> column of the master projects board and assess whether it is well-formed according to the issue template.

If a proposal is well-formed, the triager will:
* remove the <code>needs:triage</code> label,
* add the <code>needs:approval</code> label and
* add a corresponding comment.

If a proposal is not well-formed, the triager will:
* add the <code>needs:info</code> label and a comment asking the submitter to provide the missing information, or
* add the <code>was:invalid</code> label and close the issue immediately with a corresponding comment.

=== Approval ===

Like any DAO [[proposals|proposal]], anyone may add comments providing feedback on a project proposal and may react to the proposal issue description with thumbs-up, thumbs-down or confused face emoji to indicate whether they believe the project should be approved. The goal is to arrive at a [https://en.wikipedia.org/wiki/Rough_consensus rough consensus] whether to approve the project. Taking a project proposal through formal stakeholder [[voting]] should be avoided unless there is significant unresolved contention.

Once consensus has been achieved, a member of the project management committee will:

* remove the <code>a:proposal</code> and <code>needs:approval</code> labels
* add the <code>has:approval</code> or <code>was:rejected</code> label as appropriate
* add a comment indicating the status change
* close the issue if rejected

=== Budgeting ===

Acceptance of a project is distinct from allocating budget to it. Acceptance indicates that a project is worth doing; allocating budget indicates that a project ''has priority.'' Team leads are responsible for reviewing accepted projects and adding the <code>has:budget</code> label when budget has been allocated.

=== Work ===

==== Starting work ====

Work may be started at any time on a project, even prior to approval and budgeting, but contributors should have no expectation of cooperation or compensation until the project has both.

In any case, when work starts, the project owner should move to project to the <code>In progress</code> column of the master projects board and add a corresponding comment.

If work is being resumed after a period of inactivity, the project owner should also remove any labels such as <code>is:blocked</code> or <code>is:stalled</code>.

==== Stopping work ====

When work stops for an extended period the project owner should move the project issue to the <code>Backlog</code> column with a corresponding comment. If the project is blocked in some way, the <code>is:blocked</code> label should be applied. If work has stalled due to inactivity, the <code>is:stalled</code> label should be applied.

==== Requesting help ====

If a project cannot progress because a certain skill set is not available within the current team of contributors, the project owner should add the <code>needs:help</code> label with a corresponding comment that explains what kind of help is needed.

=== Review ===

Approved projects are subject to a bi-weekly (once every two weeks) review call in which each project owner provides a brief summary of their project, including whether it is on or off track, blocked for any reason, at risk of exceeding its scope or budget, etc. See the [[events calendar]] for details.

=== Closure ===

==== Closing as delivered ====

Projects that meet their criteria for delivery will be closed with the <code>was:delivered</code> label and a corresponding comment.

==== Closing as aborted ====

Projects may be aborted prior to delivery for a variety of reasons, including abandonment by project owner, consensus that the effort is no longer worth pursuing, exceeding allocated budget, being blocked by external factors, and so forth. Such projects will be closed with the <code>was:aborted</code> label and a corresponding comment.

==== Closing as deferred ====

Projects that are blocked or stalled for an extended period of time may be closed with the <code>was:deferred</code> label and a corresponding comment. Deferral is appropriate if the project is something that we'd still like to do, but see no near-term path to actually working on. A deferred project may be reopened when it becomes feasible to work on it, but any prior budget allocation should be assumed invalid.

==== Closing as superseded ====

Projects may be closed with the <code>was:superseded</code> label when another project becomes a more appropriate vehicle for getting the same or similar work done. When closing, a comment should be added providing a link to the superseding project.

=== Compensation ===

Ideally, compensation should be requested after a project has been closed, but this is not always practical. A contributor may request compensation for work on a given project prior to that project's closure assuming that the work in question has itself been meaningfully delivered. For example, if a [[Growth Team]] project involves creating and publishing an instructional video, the video creator may request compensation for their work assuming the video has been published and promoted to its intended audience even if the larger growth project is still in progress.

[[Category:Processes]]

Mediator

2020-03-06T14:18:38Z

Cbeams: Link to newly-renamed Roles article

This article documents the ''Mediator'' [[Roles|role]].

== Issue ==

https://github.com/bisq-network/roles/issues/83

== Team ==

[https://github.com/orgs/bisq-network/teams/mediators @bisq-network/mediators]

== Duties ==

''TODO: transcribe / adapt this section to the dedicated [[Mediation]] process article, such that it can be consumed by both mediators and users alike. This section will remain, but should consist of a shorter list of bullet points linking to the [[Mediation]] article, being available on Keybase, mentioning what to do with updating / creating bug issues.''

* Contact both parties of the trade (BTC buyer and BTC seller) to find out what the problem is and why the Support ticket was opened.
* Check: Maker Fee Transaction ID, Taker Fee Transaction ID and Deposit Transaction ID to make sure the transaction was published and funds aren't stuck.
* If needed, Mediator will require the private keys from both traders to carry out a manual payout.
* In case of disagreement or unclear information, verified proof of payment may be required to either party by the Mediator.
* Close the ticket after analyzing the information obtained from both parties.
* Being available on Keybase to help users that may not be able to reach out through the Bisq app.
* Respond time of 24 hours or less.
* When bugs occur, create detailed issues on https://github.com/bisq-network/support/issues and notify L2 Support.

== Rights ==

* Writer access to the <code>bisq.support</code> Keybase subteam
* Compensation request rights per case solved

== Bonding ==

A 10,000 BSQ bond is required. See https://github.com/bisq-network/bisq/blob/42a037e/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L68

[[Category:Roles]]

Refund Agent

2020-03-06T14:18:26Z

Cbeams: Link to newly-renamed Roles article

This article documents the ''Refund Agent'' [[Roles|role]].

__TOC__

== Description ==
TODO

== Issue ==
https://github.com/bisq-network/roles/issues/93

== Team ==
[https://github.com/orgs/bisq-network/teams/refund-agents @bisq-network/refund-agents]

== Duties ==
* TODO

== Rights ==
* TODO

== Bonding ==
TODO

[[Category:Stubs]]
[[Category:Roles]]

Pricenode Operator

2020-03-06T14:18:09Z

Cbeams: Link to newly-renamed Roles article

This article documents the ''Pricenode Operator'' [[Roles|role]].

__TOC__

== Description ==
A Pricenode Operator runs and keeps up to date one or more [[pricenode]] instances.

== Issue ==
https://github.com/bisq-network/roles/issues/14

== Team ==
[https://github.com/orgs/bisq-network/teams/pricenode-operators/members @bisq-network/pricenode-operators]

== Duties ==
* Setup and maintain a suitable hosting environment for the pricenode
* Maintain an active BitcoinAverage "startup" plan subscription
* Operate your pricenode using the [https://github.com/bisq-network/bisq/tree/master/pricenode#how-to-deploy-for-production current pricenode documentation]
* Run collectd with the [https://github.com/bisq-network/bisq/tree/master/pricenode#Monitoring current monitoring documentation] from bisq-monitoring operator
* Maintain your Tor onion hostname in the [https://github.com/bisq-network/bisq/blob/master/core/src/main/java/bisq/core/provider/ProvidersRepository.java#L38 Bisq pricenode provider repository]

== Rights ==
* Claim 100 USD compensation each cycle

== Bonding ==
Required. See https://github.com/bisq-network/bisq/blob/42a037e/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L59

[[Category:Stubs]]
[[Category:Roles]]
[[Category:Operator]]

Project management

2020-03-06T14:17:54Z

Cbeams: Link to newly-renamed Roles article

This article documents the project management process used within the Bisq DAO.

== Purpose ==

The purpose of the project management process is to ensure we:

* work on what's most important,
* finish what we start,
* stay within our budget, and
* don't spread ourselves too thin.

== Philosophy ==

=== Most work is project work ===

Many efforts under the Bisq DAO require multiple tasks to be carried out by multiple contributors, possibly across multiple [[:Category:Teams|teams]] and a span of time. Such efforts are best managed as ''projects'' having a beginning and an end, with clear criteria for delivery and a strong owner who takes responsibility for its success.

=== Identifying candidate projects ===

Good examples of candidate projects include:

* Adding a new feature or making a major enhancement to the Bisq client
* Introducing a new process within the Bisq DAO or significantly changing an existing one

Non-examples include:

* Typo fixes
* Minor enhancements and bug fixes
* Carrying out the regular duties of a given [[Roles|role]]

It is ultimately a judgement call whether a given effort should be managed as a project. Here are a few rules of thumb:

* Does it require multiple tasks? It's probably a project.
* Does it require people other than yourself to take action? It's probably a project.
* Does it require documentation and/or promotion to make sure people know about it? It's probably a project.

Work that starts out as a single task may evolve to become a project, and that's fine. But by thinking ahead a little, we can often identify projects up front and better manage them as a result.

=== Good project management scales ===

A primary goal of the project management process is to help the DAO scale. We want many contributors collaborating on many efforts in parallel with minimal management. To achieve this, the process must have a bottom-up aspect in which any contributor can propose a project and any stakeholder can participate in approving it, and it must also have a top-down aspect for allocating budget to the most important projects. The approach laid out here is designed to strike that balance.

== Roles and teams ==

=== Project owner ===

A project owner:

* is responsible for the delivery of a given project
* is usually the same contributor that proposes the project
* attends review meetings and reports on the project(s) they are responsible for

=== Stakeholders and users ===

DAO [[stakeholder|stakeholders]] and Bisq users are responsible for providing approval feedback on project proposals.


=== Project management committee ===

The [https://github.com/orgs/bisq-network/teams/pmc @bisq-network/pmc] is responsible for the overall project management process, including:

* triaging new project proposals
* accepting or rejecting proposals per stakeholder approval
* leading project review calls

=== Team leads ===

[https://github.com/orgs/bisq-network/teams/team-leads @bisq-network/team-leads] are responsible for prioritizing accepted projects by allocating budget to them.

=== Contributors ===

Contributors are responsible for performing the tasks necessary to deliver a project.

== Resources ==

=== Projects repository ===

Projects are managed as GitHub Issues at https://github.com/bisq-network/projects/issues. The issue template there defines what a well-formed project proposal should include.

=== Project boards ===

An approved project may have its own dedicated project board at https://github.com/orgs/bisq-network/projects for the purpose of tracking individual tasks. Otherwise, tasks may be tracked as simple checkboxes in the project issue description or by whatever means the project owner sees fit (e.g. an external kanban board); in general, however, it is preferred that everything is managed within GitHub Issues.

=== Master projects board ===

The master projects board is available at https://github.com/orgs/bisq-network/projects/3 and provides an overview of all projects and their status.

== Process ==

=== Overview ===

Anyone may '''propose''' a project so long as they are prepared to ''own'' it. Each new proposal goes through '''triage''' and, if ''well-formed'', moves on to stakeholder '''approval''' where it is ''accepted'' or ''rejected'' on its merits. An accepted project is allocated '''budget''' according to its priority and is subject to regular '''review''' until the project is '''closed''' as ''delivered'' or ''aborted''.

=== Proposal ===

To create a well-formed project proposal:

# Create a new issue in the projects repository
# Choose the project proposal issue template
# Adhere to the format of the template and fill out its content according to the instructions within

New project proposal issues are automatically labeled as <code>a:proposal</code> and <code>needs:triage</code>.

=== Triage ===

A member of the project management committee will add each new project proposal to the <code>Backlog</code> column of the master projects board and assess whether it is well-formed according to the issue template.

If a proposal is well-formed, the triager will:
* remove the <code>needs:triage</code> label,
* add the <code>needs:approval</code> label and
* add a corresponding comment.

If a proposal is not well-formed, the triager will:
* add the <code>needs:info</code> label and a comment asking the submitter to provide the missing information, or
* add the <code>was:invalid</code> label and close the issue immediately with a corresponding comment.

=== Approval ===

Like any DAO [[proposals|proposal]], anyone may add comments providing feedback on a project proposal and may react to the proposal issue description with thumbs-up, thumbs-down or confused face emoji to indicate whether they believe the project should be approved. The goal is to arrive at a [https://en.wikipedia.org/wiki/Rough_consensus rough consensus] whether to approve the project. Taking a project proposal through formal stakeholder [[voting]] should be avoided unless there is significant unresolved contention.

Once consensus has been achieved, a member of the project management committee will:

* remove the <code>a:proposal</code> and <code>needs:approval</code> labels
* add the <code>has:approval</code> or <code>was:rejected</code> label as appropriate
* add a comment indicating the status change
* close the issue if rejected

=== Budgeting ===

Acceptance of a project is distinct from allocating budget to it. Acceptance indicates that a project is worth doing; allocating budget indicates that a project ''has priority.'' Team leads are responsible for reviewing accepted projects and adding the <code>has:budget</code> label when budget has been allocated.

=== Work ===

==== Starting work ====

Work may be started at any time on a project, even prior to approval and budgeting, but contributors should have no expectation of cooperation or compensation until the project has both.

In any case, when work starts, the project owner should move to project to the <code>In progress</code> column of the master projects board and add a corresponding comment.

If work is being resumed after a period of inactivity, the project owner should also remove any labels such as <code>is:blocked</code> or <code>is:stalled</code>.

==== Stopping work ====

When work stops for an extended period the project owner should move the project issue to the <code>Backlog</code> column with a corresponding comment. If the project is blocked in some way, the <code>is:blocked</code> label should be applied. If work has stalled due to inactivity, the <code>is:stalled</code> label should be applied.

==== Requesting help ====

If a project cannot progress because a certain skill set is not available within the current team of contributors, the project owner should add the <code>needs:help</code> label with a corresponding comment that explains what kind of help is needed.

=== Review ===

Approved projects are subject to a bi-weekly (once every two weeks) review call in which each project owner provides a brief summary of their project, including whether it is on or off track, blocked for any reason, at risk of exceeding its scope or budget, etc. See the [[events calendar]] for details.

=== Closure ===

==== Closing as delivered ====

Projects that meet their criteria for delivery will be closed with the <code>was:delivered</code> label and a corresponding comment.

==== Closing as aborted ====

Projects may be aborted prior to delivery for a variety of reasons, including abandonment by project owner, consensus that the effort is no longer worth pursuing, exceeding allocated budget, being blocked by external factors, and so forth. Such projects will be closed with the <code>was:aborted</code> label and a corresponding comment.

==== Closing as deferred ====

Projects that are blocked or stalled for an extended period of time may be closed with the <code>was:deferred</code> label and a corresponding comment. Deferral is appropriate if the project is something that we'd still like to do, but see no near-term path to actually working on. A deferred project may be reopened when it becomes feasible to work on it, but any prior budget allocation should be assumed invalid.

==== Closing as superseded ====

Projects may be closed with the <code>was:superseded</code> label when another project becomes a more appropriate vehicle for getting the same or similar work done. When closing, a comment should be added providing a link to the superseding project.

=== Compensation ===

Ideally, compensation should be requested after a project has been closed, but this is not always practical. A contributor may request compensation for work on a given project prior to that project's closure assuming that the work in question has itself been meaningfully delivered. For example, if a [[Growth Team]] project involves creating and publishing an instructional video, the video creator may request compensation for their work assuming the video has been published and promoted to its intended audience even if the larger growth project is still in progress.

[[Category:Processes]]

Bisq Maintainer

2020-03-06T14:17:36Z

Cbeams: Link to newly-renamed Roles article

This article documents the ''Bisq Maintainer'' [[Roles|role]].

__TOC__

== Issue ==
https://github.com/bisq-network/roles/issues/63

== Team ==
[https://github.com/orgs/bisq-network/teams/bisq-maintainers/members @bisq-network/bisq-maintainers]

== Duties ==
* Perform [https://docs.bisq.network/roles.html#common-duties duties common to all roles]
* Merge pull requests per the [[Development Process]]
* Manage critical bugs per the [[Critical Bugs]] process

== Rights ==
* Admin access to the bisq-network/bisq repository
* Write access to the [[Critical Bugs#Board|critical bugs board]]

== Bonding ==
Required. See https://github.com/bisq-network/bisq/blob/42a037e/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L51

[[Category:Roles]]
[[Category:Maintainer]]

Roles

2020-03-06T14:17:03Z

Cbeams: Cbeams moved page Role to Roles

Mediator

2020-03-06T14:00:32Z

Cbeams: Add TODO for transcribing the #Duties section to the new Mediation process article

This article documents the ''Mediator'' [[role]].

== Issue ==

https://github.com/bisq-network/roles/issues/83

== Team ==

[https://github.com/orgs/bisq-network/teams/mediators @bisq-network/mediators]

== Duties ==

''TODO: transcribe / adapt this section to the dedicated [[Mediation]] process article, such that it can be consumed by both mediators and users alike. This section will remain, but should consist of a shorter list of bullet points linking to the [[Mediation]] article, being available on Keybase, mentioning what to do with updating / creating bug issues.''

* Contact both parties of the trade (BTC buyer and BTC seller) to find out what the problem is and why the Support ticket was opened.
* Check: Maker Fee Transaction ID, Taker Fee Transaction ID and Deposit Transaction ID to make sure the transaction was published and funds aren't stuck.
* If needed, Mediator will require the private keys from both traders to carry out a manual payout.
* In case of disagreement or unclear information, verified proof of payment may be required to either party by the Mediator.
* Close the ticket after analyzing the information obtained from both parties.
* Being available on Keybase to help users that may not be able to reach out through the Bisq app.
* Respond time of 24 hours or less.
* When bugs occur, create detailed issues on https://github.com/bisq-network/support/issues and notify L2 Support.

== Rights ==

* Writer access to the <code>bisq.support</code> Keybase subteam
* Compensation request rights per case solved

== Bonding ==

A 10,000 BSQ bond is required. See https://github.com/bisq-network/bisq/blob/42a037e/core/src/main/java/bisq/core/dao/state/model/governance/BondedRoleType.java#L68

[[Category:Roles]]

Mediation

2020-03-06T13:56:14Z

Cbeams: Stub out the Mediation process

This article is a stub pending the adaptation of the current [[Mediator#Duties]] section here.

[[Category:Stubs]]
[[Category:Processes]]

User support

2020-03-06T13:53:56Z

Cbeams: Flesh out links to various user support resources; remove Stubs category

''This article documents how to get support as a Bisq user. For information on how to provide support, see [[Support Team]].''

Bisq users have a variety of options for getting their questions answered and problems solved. The sections below briefly describe and link to each support resource.

__TOC__

== Via the FAQ ==

Many common questions can be answered by browsing the [https://bisq.network/faq Bisq FAQ]

== Via the wiki ==

Common problems and solutions are documented in [[Troubleshooting]]. More generally, you can browse the articles in the [[:Category:Client|Bisq Client]] category.

== Via Keybase chat ==

The <code>#support</code> channel in the [[Keybase|Bisq Keybase team]] is Bisq's '''primary user support channel'''. When in doubt, ask your question here!

== Via the Bisq docs website ==

See https://docs.bisq.network

== Via GitHub issues ==

See https://github.com/bisq-network/support

== Via the Bisq Forum ==

See https://bisq.community

== Via Mediation ==

See [[Mediation]]

[[Category:Processes]]

Troubleshooting

2020-03-06T13:45:44Z

Cbeams: Link to newly-renamed User support article

This article is a stub. The specific sections below are just examples for demonstration purposes.

__TOC__

== Bisq won't start ==

== My Antivirus software flags Bisq as malware ==

== Bisq cannot connect via Tor ==

== My wallet has an incorrect balance ==

See [[Delete and resync SPV file]]

== My problem isn't addressed here ==

See [[user support]]

[[Category:Stubs]]
[[Category:Client]]

User support

2020-03-06T13:45:14Z

Cbeams: Cbeams moved page Support to User support

''This article documents how to get support as a Bisq user. For information on how to provide support, see [[Support Team]].''

Bisq users have a variety of options for getting their questions answered and problems solved. The sections below briefly describe and link to each support channel.

__TOC__

==Via the FAQ==
Many common questions can be answered by browsing the [https://bisq.network/faq Bisq FAQ]

==Via Keybase chat==

The <code>#support</code> channel in the [[Keybase|Bisq Keybase team]] is the project's '''primary user support channel'''. When in doubt, ask your question here!

==Via Bisq Documentation==

==Via Knowledge Base articles==

==Via GitHub issues==

==Via the Bisq Forum==

==Via Mediation==

[[Category:Stubs]]
[[Category:Processes]]

Support

2020-03-06T13:45:14Z

Cbeams: Cbeams moved page Support to User support

#REDIRECT [[User support]]

Support Team

2020-03-06T13:42:25Z

Cbeams: Link to newly-renamed User support article; polish links and structure

The Support Team is responsible for providing excellent [[user support|support]] for Bisq users. This includes:

* Handling individual support cases, including [[mediation]] and [[refunds]]
* Maintaining the Bisq [[Docs|docs website]]
* Maintaining support-related articles here on the Bisq [[wiki]].

__TOC__

== Roles ==

* [[Support Team Lead]]
* L1/L2 [[Support Agent]]
* [[Mediator]]
* [[Arbitrator]]
* [[Refund Agent]]
* [[Donation Address Owner]] (aka Burning Man)

== Resources ==

=== GitHub Team ===

[https://github.com/orgs/bisq-network/teams/support @bisq-network/support]

=== GitHub Repositories ===

* https://github.com/bisq-network/support
* https://github.com/bisq-network/bisq-docs
* https://github.com/bisq-network/wiki

=== Keybase chat ===

* [[Keybase]] <code>#support</code> channel (public, for providing user support)
* Keybase <code>bisq.support</code> subteam (private, for Support Team contributors)

[[Category:Teams]]

User support

2020-03-06T13:16:40Z

Cbeams: Add Stubs category

''This article documents how to get support as a Bisq user. For information on how to provide support, see [[Support Team]].''

Bisq users have a variety of options for getting their questions answered and problems solved. The sections below briefly describe and link to each support channel.

__TOC__

==Via the FAQ==
Many common questions can be answered by browsing the [https://bisq.network/faq Bisq FAQ]

==Via Keybase chat==

The <code>#support</code> channel in the [[Keybase|Bisq Keybase team]] is the project's '''primary user support channel'''. When in doubt, ask your question here!

==Via Bisq Documentation==

==Via Knowledge Base articles==

==Via GitHub issues==

==Via the Bisq Forum==

==Via Mediation==

[[Category:Stubs]]
[[Category:Processes]]