dashpay · vijaydasmp · Nov 14, 2023 · Nov 15, 2023 · Nov 16, 2023 · Nov 16, 2023
diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -1,6 +1,6 @@
 ---
 name: Bug report
-about: Create a report to help us improve
+about: Create a report to help us improve (use this for suspected bugs only, if not sure, open a regular issue below)
 title: ''
 labels: Bug
 assignees: ''

diff --git a/.github/ISSUE_TEMPLATE/good_first_issue.md b/.github/ISSUE_TEMPLATE/good_first_issue.md
@@ -9,15 +9,14 @@ assignees: ''
 
 <!-- Needs the label "good first issue" assigned manually before or after opening -->
 
+<!-- A good first issue is an uncontroversial issue, that has a relatively unique and obvious solution -->
+
+<!-- Motivate the issue and explain the solution briefly -->
 
 #### Useful skills:
 
 <!-- (For example, “C++11 std::thread”, “Qt5 GUI and async GUI design” or “basic understanding of Bitcoin mining and the Bitcoin Core RPC interface”.) -->
 
 #### Want to work on this issue?
 
-The purpose of the `good first issue` label is to highlight which issues are suitable for a new contributor without a deep understanding of the codebase.
-
-You do not need to request permission to start working on this. You are encouraged to comment on the issue if you are planning to work on it. This will help other contributors monitor which issues are actively being addressed and is also an effective way to request assistance if and when you need it.
-
 For guidance on contributing, please read [CONTRIBUTING.md](https://github.com/dashpay/dash/blob/master/CONTRIBUTING.md) before opening your pull request.
diff --git a/.github/workflows/release_alpha.yml b/.github/workflows/release_alpha.yml
diff --git a/.github/workflows/release_docker_hub.yml b/.github/workflows/release_docker_hub.yml
@@ -67,7 +67,9 @@ jobs:
         push: true
         tags: ${{ steps.docker_meta.outputs.tags }}
         labels: ${{ steps.docker_meta.outputs.labels }}
-        build-args: TAG=${{ steps.get_tag.outputs.build_tag }}
+        build-args: |
+          TAG=${{ steps.get_tag.outputs.build_tag }}
+          GITHUB_REPOSITORY=${{ github.repository }}
         cache-from: type=gha
         cache-to: type=gha,mode=max
         platforms: linux/amd64,linux/arm64

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -14,9 +14,40 @@ purposes. As such there are repository "maintainers" who are responsible for
 merging pull requests as well as a "lead maintainer" who is responsible for the
 release cycle, overall merging, moderation and appointment of maintainers.
 
+Getting Started
+---------------
+
+New contributors are very welcome and needed.
+
+Reviewing and testing is the most effective way you can contribute as a new
+contributor, and it also will teach you much more about the code and process
+than opening PRs. Please refer to the section [peer review](#peer-review) later
+in this document.
+
+Before you start contributing, familiarize yourself with the Dash Core build
+system and tests. Refer to the documentation in the repository on how to build
+Dash Core and how to run the unit and functional tests.
+
+There are many open issues of varying difficulty waiting to be fixed.
 If you're looking for somewhere to start contributing, check out the
 [good first issue](https://github.com/dashpay/dash/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)
 list.
+Some of them might no longer be applicable. So if you are interested, but
+unsure, you might want to leave a comment on the issue first.
+
+### Good First Issue Label
+
+The purpose of the `good first issue` label is to highlight which issues are
+suitable for a new contributor without a deep understanding of the codebase.
+
+However, good first issues can be solved by anyone. If they remain unsolved
+for a longer time, a frequent contributor might address them.
+
+You do not need to request permission to start working on an issue. However,
+you are encouraged to leave a comment if you are planning to work on it. This
+will help other contributors monitor which issues are actively being addressed
+and is also an effective way to request assistance if and when you need it.
+
 
 Contributor Workflow
 --------------------
@@ -34,6 +65,8 @@ To contribute a patch, the workflow is as follows:
 The project coding conventions in the [developer notes](doc/developer-notes.md)
 must be followed.
 
+### Committing Patches
+
 In general, [commits should be atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention)
 and diffs should be easy to read. For this reason, do not mix any formatting
 fixes or code moves with actual code changes.
@@ -57,6 +90,8 @@ about Git.
   - Push changes to your fork
   - Create pull request
 
+### Creating the Pull Request
+
 Pull request titles should follow the Conventional Commits specification which
 uses the `<type>(optional scope): <description>` scheme. Please see the
 specification linked below for valid types. When making a change to a specific
@@ -94,18 +129,24 @@ Examples:
     fix(log): fix typo in log message
     feat(rpc)!: modify gettransaction parameter type
 
+The body of the pull request should contain enough description about what the
+patch does together with any justification/reasoning. You should include
+references to any discussions (for example other tickets or mailing list
+discussions).
+
+### Translation changes
+
 Note that translations should not be submitted as pull requests. Please see
 [Translation Process](https://github.com/dashpay/dash/blob/master/doc/translation_process.md)
 for more information on helping with translations.
 
+### Work in Progress Changes and Requests for Comments
+
 If a pull request is not to be considered for merging (yet), please
 prefix the title with [WIP] or use [Tasks Lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#task-lists)
 in the body of the pull request to indicate tasks are pending.
 
-The body of the pull request should contain enough description about what the
-patch does together with any justification/reasoning. You should include
-references to any discussions (for example other tickets or mailing list
-discussions).
+### Address Feedback
 
 At this stage, one should expect comments and review from other contributors. You
 can add more commits to your pull request by committing them locally and pushing

diff --git a/autogen.sh b/autogen.sh
@@ -1,5 +1,5 @@
 #!/bin/sh
-# Copyright (c) 2013-2016 The Bitcoin Core developers
+# Copyright (c) 2013-2019 The Bitcoin Core developers
 # Distributed under the MIT software license, see the accompanying
 # file COPYING or http://www.opensource.org/licenses/mit-license.php.
 

diff --git a/ci/dash/build_src.sh b/ci/dash/build_src.sh
@@ -45,11 +45,11 @@ rm -rf build-ci
 mkdir build-ci
 cd build-ci
 
-../configure --cache-file=config.cache $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false)
+../configure $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false)
 make distdir VERSION=$BUILD_TARGET
 
 cd dashcore-$BUILD_TARGET
-./configure --cache-file=../config.cache $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false)
+./configure $BITCOIN_CONFIG_ALL $BITCOIN_CONFIG || ( cat config.log && false)
 
 make $MAKEJOBS $GOAL || ( echo "Build failure. Verbose build follows." && make $GOAL V=1 ; false )
 

diff --git a/ci/lint/05_before_script.sh b/ci/lint/05_before_script.sh
@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-# Copyright (c) 2018 The Bitcoin Core developers
+# Copyright (c) 2018-2019 The Bitcoin Core developers
 # Distributed under the MIT software license, see the accompanying
 # file COPYING or http://www.opensource.org/licenses/mit-license.php.
 

diff --git a/ci/lint/06_script.sh b/ci/lint/06_script.sh
@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-# Copyright (c) 2018 The Bitcoin Core developers
+# Copyright (c) 2018-2019 The Bitcoin Core developers
 # Distributed under the MIT software license, see the accompanying
 # file COPYING or http://www.opensource.org/licenses/mit-license.php.
 
@@ -10,6 +10,8 @@ if [ "$TRAVIS_EVENT_TYPE" = "pull_request" ]; then
   test/lint/commit-script-check.sh $TRAVIS_COMMIT_RANGE
 fi
 
+# This only checks that the trees are pure subtrees, it is not doing a full
+# check with -r to not have to fetch all the remotes.
 test/lint/git-subtree-check.sh src/crypto/ctaes
 test/lint/git-subtree-check.sh src/secp256k1
 test/lint/git-subtree-check.sh src/univalue

diff --git a/ci/test/00_setup_env_mac.sh b/ci/test/00_setup_env_mac.sh
@@ -8,7 +8,7 @@ export LC_ALL=C.UTF-8
 
 export CONTAINER_NAME=ci_macos_cross
 export HOST=x86_64-apple-darwin
-export PACKAGES="cmake libcap-dev libz-dev libbz2-dev python3-dev python3-setuptools"
+export PACKAGES="cmake libcap-dev libz-dev libbz2-dev python3-setuptools"
 export XCODE_VERSION=12.2
 export XCODE_BUILD_ID=12B45b
 export RUN_UNIT_TESTS=false

diff --git a/ci/test/03_before_install.sh b/ci/test/03_before_install.sh
@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-# Copyright (c) 2018 The Bitcoin Core developers
+# Copyright (c) 2018-2019 The Bitcoin Core developers
 # Distributed under the MIT software license, see the accompanying
 # file COPYING or http://www.opensource.org/licenses/mit-license.php.
 

diff --git a/ci/test/wrap-valgrind.sh b/ci/test/wrap-valgrind.sh
@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-# Copyright (c) 2018 The Bitcoin Core developers
+# Copyright (c) 2018-2019 The Bitcoin Core developers
 # Distributed under the MIT software license, see the accompanying
 # file COPYING or http://www.opensource.org/licenses/mit-license.php.