-
Notifications
You must be signed in to change notification settings - Fork 4
New Contributors Guide
14.1.1 Hello new contributors, and welcome to dexbot. We are a group that works on open source market making with the Bitshares DEX. Before you get started, please observe the following:
14.1.2 For general information about DEXBot please visit the Website
14.1.3 If you would like to get involved you can join us in the Telegram Dexbot Chat Room and for new contributors, where you can ask questions and get help.
14.2 Information about the Worker Proposal 3 that is funding this project can be found here
14.3* Key project members are:
- 14.3.1 Project Manager: @permie
- 14.3.2 Lead Developer: @octomatic
- 14.3.3 Supporting Developer: @vvk123
- 14.3.4 Build Maintainer: @joelva
- 14.3.5 Quality Assurance : @bitProfessor
14.4.1 Please see https://github.com/bitshares/bitshares-ui/blob/develop/CODE_OF_CONDUCT.md This Code of Conduct is adapted from Bitshares-UI and the Contributor Covenant, version 1.4
14.5.1 This project cycle, is from January 1, 2019 - June 30, 2019. The roadmap for this cycle can be viewed in the Dexbot Workflow spreadhseet.
14.6.1 Check in issues if someone already has requested the feature 14.6.2 Create a new issue where you describe the feature
14.7.1 Check in issues if someone already has reported the bug 14.7.2 Create a new issue with a descriptive name. 14.7.3 Describe how to reproduce the bug. If possible, use images or GIF's.
14.8.1 The General process is as follows : sprint -> review & merge -> release
- 14.8.1.1 Build Releases are on an as needed basis and will be announced by the project manager. We currently estimate that builds to be released on a monthly basis.
- 14.8.1.2 Release Candidates sits 1-2 weeks for evaluation by the public before release
- 14.8.1.3 Bugs are always worked before enhancements
-
14.8.1.4 Developers should work each issue according to a numbered branch corresponding to the issue
git checkout -b 123-fix-gui-buttonwhich would refer to issue 123. see Git workflow guide for specifics. - 14.8.1.5 We pay bounties for issues that have not been claimed. If you fix this issue according to these guidelines and your PR is accepted you will earn bitCNY
- 14.8.1.6 If you are new, please review the issues have been tagged 'Good First Issue'. Before starting development, comment on the issue to submit a price that you would charge for the development to be completed.
14.9 Also please talk to us DEXBot on telegram in t.me/DEXBotbts. Work on unagreed bounties won’t be paid for.
- 14.10 To claim an issue, simple leave a comment with the request to work on it and your hours estimate. Alternatively, contact the project manager on telegram
- 14.11 If an issue is already claimed (assigned), do not attempt to claim it. Issues claimed by outside developers will have no assigned dev, but have the developers name in brackets. Do not claim an issue if you will be unable to complete it by the date indicated on the Milestone name. If an issue missed the intended milestone completion, be sure to make a comment on your progress including the reason for the delay. The issue is pushed to the next milestone. Failing to comment or complete the issue once more will result in release of the assigned issue.
14.12 Here are a list of the ongoing projects and bug sprints
14.13.1 An example can be found here (https://github.com/Codaone/DEXBot/projects/5)
14.14.1 Are you new to contributing to open source? here is a good guide: https://opensource.guide/
14.15 Can you contribute
- 14.15.1 documentation?
- 14.15.2 UX?
- 14.15.3 strategies?
- 14.15.4 data analysis?
- 14.15.5 graphics?
- 14.15.6 infographs?
- 14.15.7 videos?
- 14.15.8 user help?
14.16 Reach out to the project group in Telegram. We are prepared to pay for meaningful contributions.
14.17.1 Our style guidelines are based off of the PEP-8 Standard https://www.python.org/dev/peps/pep-0008/ with a few exceptions:
- 14.17.1.1 Lines do not need to be strictly 80 characters, up to 120 characters accepted.
- 14.17.1.2 make generally readable code, e.g. avoid using short one letter variables and instead use something more descriptive.
- 14.17.1.3 git commit style guideline - https://chris.beams.io/posts/git-commit/
14.18 If you wish to use an IDE, we recommend PyCharm. There are also many PEP-8 standard code verifiers should you wish to use a different IDE.
14.19 Coding guidelines in general:
- 14.19.1 Keep it simple. Try to think about development for future maintenance.
- 14.19.2 Write unit tests where necessary
- 14.19.3 Please contact the project manager and developers first if you wish to use new libraries or packages that are newer than the current project implementations.
- 14.19.4 Use setuptools, setup.py and requirements.txt accordingly for new package additions
14.20.1 In general,
- 14.20.1.1 developers should use Pandas for handling data, not arrays
- 14.20.1.2* Use the dash libraries for plotting
- 14.20.1.3 Ensure that the plotly data is privacy protected. Here is an example of how to turn on Plotly Data Privacy
- 14.20.1.4* avoid use of global variables
- 14.20.1.5 Keep your display controls simple. If your visualisations have a need for complex tabs or menus, please speak with one of team members first. Remember that your visualization will be integrated into the rest of the system and must be kept modular.
- 14.20.1.6 use logging instead of print statements - observe style for commenting and structure from existing code base
14.21 References below:
14.21.1 Guide to logging https://realpython.com/python-logging/
14.21.2 Guide to Pandas: http://pandas.pydata.org/pandas-docs/stable/
14.21.3 Dash User guide: https://dash.plot.ly/
14.22.4 Dash Plotting Examples: https://github.com/plotly/simple-example-chart-apps
14.23.1 We strongly encourage the use of virtualenv for your local development environment. For more about how to use virtualenv with python 3.6 please see
14.24.1 see https://github.com/Codaone/DEXBot/wiki/Git-Workflow