Proposals - Revision history

W000000t: keybase > matrix

2022-01-22T19:08:22Z

keybase > matrix

Plebeian9000 at 21:44, 23 April 2021

2021-04-23T21:44:53Z

Plebeian9000 at 21:44, 23 April 2021

2021-04-23T21:44:39Z

Plebeian9000 at 18:47, 13 August 2020

2020-08-13T18:47:02Z

Plebeian9000: improve formatting, wording, and add dao section

2020-08-13T14:44:50Z

improve formatting, wording, and add dao section

Show changes

MwithM: /* Maintainer */ Fix internal link

2020-08-12T10:39:37Z

Maintainer: Fix internal link

MwithM: /* Reviewer */ Fix internal link

2020-08-12T10:38:55Z

Reviewer: Fix internal link

MwithM: Format, internal links

2020-08-12T10:37:49Z

Format, internal links

MwithM: Import from docs, will be split in two pages.

2020-08-12T08:47:23Z

Import from docs, will be split in two pages.

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

2020-06-19T05:57:27Z

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

@@ Line 1: / Line 1: @@
-'''Proposals''' are a way to suggest significant ''project-wide'' changes or new initiatives where a broad consensus of contributors, users, and stakeholders is desired. Smaller changes to existing components, infrastructure, or processes are generally best discussed in other channels (on Keybase, other GitHub repositories, etc).
+'''Proposals''' are a way to suggest significant ''project-wide'' changes or new initiatives where a broad consensus of contributors, users, and stakeholders is desired. Smaller changes to existing components, infrastructure, or processes are generally best discussed in other channels (on Matrix, other GitHub repositories, etc).
 This article covers the roles, processes, and conventions for proposals.
@@ Line 19: / Line 19: @@
 Proposals are supposed to be significant items with enough weight to draw attention from core contributors, users, and stakeholders from across functions.
-{{Admonition_Note|If your idea is focused on a particular area of Bisq, it would be best to first float your idea in the channels for that area. For example, development-related ideas can be discussed in #dev on Keybase or in [https://github.com/bisq-network/bisq the main GitHub repository]. Growth-related ideas can be discussed in #growth on Keybase or the [https://github.com/bisq-network/growth/ growth GitHub repository].}}
+{{Admonition_Note|If your idea is focused on a particular area of Bisq, it would be best to first float your idea in the channels for that area. For example, development-related ideas can be discussed in #dev on Matrix or in [https://github.com/bisq-network/bisq the main GitHub repository]. Growth-related ideas can be discussed in #growth on Matrix or the [https://github.com/bisq-network/growth/ growth GitHub repository].}}
 Accordingly, proposals should be well-considered, well-researched, and well-articulated.
@@ Line 60: / Line 60: @@
 If you do not understand or care about a given proposal, ignore it.
-Use comments on the proposal issue to discuss, ask questions, and get clarifications. Take lengthy discussions offline to Keybase or elsewhere and then summarize them back on the issue.
+Use comments on the proposal issue to discuss, ask questions, and get clarifications. Take lengthy discussions offline to Matrix or elsewhere and then summarize them back on the issue.
 ==== Evaluate ====

← Older revision		Revision as of 21:44, 23 April 2021
Line 89:		Line 89:
	See [[Participating_in_a_DAO_voting_cycle\|how to submit a proposal for DAO voting]].		See [[Participating_in_a_DAO_voting_cycle\|how to submit a proposal for DAO voting]].

−	~~[[Category:Stubs]]~~
	[[Category:Processes]]		[[Category:Processes]]
−	~~[[Category:Roles]]~~

@@ Line 87: / Line 87: @@
 For most general proposals this should not be necessary—general proposals that have clear consensus (or clear lack of consensus) don't need to be voted upon in the DAO. In any case, a DAO submission should only be considered after considerable discussion on GitHub so that voters have context and reason to vote one way or another. Do not submit a DAO proposal before such discussion is established.
-See [[Submitting_a_DAO_proposal|how to submit a proposal for DAO voting]].
+See [[Participating_in_a_DAO_voting_cycle|how to submit a proposal for DAO voting]].
 [[Category:Stubs]]
 [[Category:Processes]]
 [[Category:Roles]]

@@ Line 17: / Line 17: @@
 ==== Research and Evaluate ====
-Proposals are supposed to be significant items with enough weight to draw attention from all core contributors, users, and stakeholders from across functions.
+Proposals are supposed to be significant items with enough weight to draw attention from core contributors, users, and stakeholders from across functions.
 {{Admonition_Note|If your idea is focused on a particular area of Bisq, it would be best to first float your idea in the channels for that area. For example, development-related ideas can be discussed in #dev on Keybase or in [https://github.com/bisq-network/bisq the main GitHub repository]. Growth-related ideas can be discussed in #growth on Keybase or the [https://github.com/bisq-network/growth/ growth GitHub repository].}}

@@ Line 23: / Line 23: @@
 ==== Maintainer ====
-The contributor(s) responsible for proposals infrastructure and [[https://bisq.wiki/Proposals#Process process]], as described in [[Proposals Maintainer]].
+The contributor(s) responsible for proposals infrastructure and [[Proposals#Process | process]], as described in [[Proposals Maintainer]].
 == Process ==

@@ Line 20: / Line 20: @@
 Other contributors who read, discuss and react to proposals.
-Any contributor may review a proposal, but no contributor is obligated to do so. This intentionally puts the onus on the submitter to ensure their proposal is relevant and well-written per the [[https://bisq.wiki/Proposals#Guidelines_for_submitters Guidelines]] below.
+Any contributor may review a proposal, but no contributor is obligated to do so. This intentionally puts the onus on the submitter to ensure their proposal is relevant and well-written per the [[Proposals#Guidelines_for_submitters | Guidelines]] below.
 ==== Maintainer ====
 The contributor(s) responsible for proposals infrastructure and [[https://bisq.wiki/Proposals#Process process]], as described in [[Proposals Maintainer]].

@@ Line 4: / Line 4: @@
 The Bisq DAO is a flat organization, with no command-and-control hierarchy available to make big decisions and carry them out. Usually this is not a problem, as most day-to-day changes happen without any need for organization-wide consensus. Certain kinds of changes, however, benefit from or even require it.
 What’s needed is a mechanism that allows any contributor to propose a change, and all other contributors to review it in order to arrive at an IETF-style [https://en.wikipedia.org/wiki/Rough_consensus rough consensus]. Proposals are that mechanism, and this document covers everything that participants need to know about the process.
@@ Line 18: / Line 19: @@
 ==== Reviewer ====
 Other contributors who read, discuss and react to proposals.
-Any contributor may review a proposal, but no contributor is obligated to do so. This intentionally puts the onus on the submitter to ensure their proposal is relevant and well-written per the [[https://bisq.wiki/index.php?title=Proposals&action=submit#Guidelines Guidelines]] below.
 ==== Maintainer ====
-The contributor(s) responsible for proposals infrastructure and [[https://bisq.wiki/index.php?title=Proposals&action=submit#Process process]], as described in [[Proposals Maintainer]].
+The contributor(s) responsible for proposals infrastructure and [[https://bisq.wiki/Proposals#Process process]], as described in [[Proposals Maintainer]].
 == Process ==
@@ Line 32: / Line 34: @@
 ====Submit====
-Create a new GitHub issue in the [https://github.com/bisq-network/proposals/issues|bisq-network/proposals] repository containing the text of your proposal, written and formatted per the [[guidelines]] below.
+Create a new GitHub issue in the [https://github.com/bisq-network/proposals/issues|bisq-network/proposals repository] containing the text of your proposal, written and formatted per the [[https://bisq.wiki/Proposals#Guidelines_for_submitters guidelines]] below.
 A [[Proposals_maintainer|maintainer]] will quickly review your proposal and will either (a) assign it to you to indicate your ownership and responsibility over it, or (b) close it and label it as <code>was:incorrect</code> if it does not follow the guidelines below.
@@ Line 41: / Line 44: @@
 * 👎: I disagree with the proposal and do not want to see it enacted.
 When reacting with a 😕 or 👎, add a comment explaining why. If you don’t, then don’t expect your opinion to have much weight or get addressed.
 If you do not understand or care about a given proposal, ignore it.
 Use comments on the proposal issue to discuss, ask questions, and get clarifications. Take lengthy discussions offline to Keybase or elsewhere and then summarize them back on the issue.
-::''Remember that the proposal review process is all about reaching a rough consensus, meaning that there is a broad agreement that the proposal should be enacted, and that any dissenting opinions have been addressed, though not necessarily fully resolved._''
+::''Remember that the proposal review process is all about reaching a rough consensus, meaning that there is a broad agreement that the proposal should be enacted, and that any dissenting opinions have been addressed, though not necessarily fully resolved.''
 ==== Evaluate ====
 After the two-week review period is over, a maintainer will evaluate reactions to and discussions about the proposal and will close the issue with a comment explaining that it is approved or rejected based on whether a rough consensus was achieved.
 Approved proposals will be labeled with <code>was:approved</code>. Rejected proposals will be labeled with <code>was:rejected</code>.
 If rough consensus has not been achieved, e.g. because discussion is still ongoing, dissenting concerns have not been addressed, or the proposal has turned out to be contentious, the maintainer will indicate that they cannot close the proposal, and that it is up to the submitter to take next steps to move the proposal forward. If the proposal does not move forward after another two weeks, the maintainer will close and label it <code>was:stalled</code>.
 If there have been no or very few reactions to a proposal after the two-week period, the maintainer will close it and label it as <code>was:ignored</code>.<!-- was:moved-->