Project management - Revision history

Plebeian9000: /* Approval */

2021-04-23T21:57:15Z

Approval

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

2020-04-29T12:23:12Z

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

MwithM: /* Starting work */

2020-03-07T07:30:51Z

Starting work

Cbeams: Use correct MediaWiki literal syntax

2020-03-06T15:59:19Z

Use correct MediaWiki literal syntax

Cbeams: Use correct MediaWiki link syntax

2020-03-06T15:56:37Z

Use correct MediaWiki link syntax

Cbeams: Use correct MediaWiki link syntax

2020-03-06T15:55:55Z

Use correct MediaWiki link syntax

Cbeams: Link to new project proposal issue template

2020-03-06T15:54:51Z

Link to new project proposal issue template

Cbeams: Link to newly-renamed Roles article

2020-03-06T14:17:54Z

Link to newly-renamed Roles article

Cbeams: /* Closure */ Document use of the `was:deferred` and `was:superseded` labels

2020-03-06T12:54:26Z

Closure: Document use of the `was:deferred` and `was:superseded` labels

Cbeams: /* Work */ Document using the `needs:help` label

2020-03-06T12:41:39Z

Work: Document using the `needs:help` label

@@ Line 117: / Line 117: @@
 === 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.
+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.
 Once consensus has been achieved, a member of the project management committee will:

← Older revision		Revision as of 12:23, 29 April 2020
Line 149:		Line 149:

	=== Review ===		=== 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.		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.

@@ Line 136: / Line 136: @@
 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.
+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>.

@@ Line 97: / Line 97: @@
 # Create a [https://github.com/bisq-network/projects/issues/new/choose new issue in the projects repository]
-# Choose the `Project proposal` issue template
+# 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

@@ Line 96: / Line 96: @@
 To create a well-formed project proposal:
-# Create a [new issue in the projects repository](https://github.com/bisq-network/projects/issues/new/choose)
+# 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

@@ Line 76: / Line 76: @@
 === 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.
+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 ===

@@ Line 27: / Line 27: @@
 * Typo fixes
 * Minor enhancements and bug fixes
-* Carrying out the regular duties of a given [[role]]
+* 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:

← Older revision		Revision as of 12:54, 6 March 2020
Line 161:		Line 161:

	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.		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 ===		=== Compensation ===

← Older revision		Revision as of 12:41, 6 March 2020
Line 143:		Line 143:

	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.		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 ===		=== Review ===