How To Contribute(如何贡献)


#1

How To Contribute

Want to hack on XDAG? Awesome! Here are instructions to get you started. They are not perfect yet. Please let us know what feels wrong or incomplete.

XDAG is an Open Source project and we welcome contributions of all sorts. There are many ways to help, from reporting issues, contributing code, and helping us improve our community.

Topics

Security Issues

Community Guidelines

Reporting Issues

Implementation Design

Community Improvement

Translations

Contribution Guidelines

Helping in other ways

Security Issues

The XDAG protocol and its implementations are still in heavy development. This means that there may be problems in our protocols, or there may be mistakes in our implementations. And many people are already running nodes on their machines. So we take security vulnerabilities very seriously. If you discover a security issue, please bring it to our attention right away!

If you find a vulnerability that may affect live deployments, please send your report privately to communitymanager@xdag.io, please DO NOT file a public issue.

If the issue is a protocol weakness or something not yet deployed, just discuss it openly.

Community Guidelines

We want to keep the XDAG community awesome, growing and collaborative. We need your help to keep it that way. To help with this we’ve come up with some general guidelines for the community as a whole:

Be nice: Be courteous, respectful and polite to fellow community members: no regional, racial, gender, or other abuse will be tolerated. We like nice people way better than mean ones!

Encourage diversity and participation: Make everyone in our community feel welcome, regardless of their background and the extent of their contributions, and do everything possible to encourage participation in our community.

Keep it legal: Basically, don’t get anybody in trouble. Share only content that you own, do not share private or sensitive information, and don’t break laws.

Stay on topic: Make sure that you are posting to the correct channel and avoid off-topic discussions. Remember when you update an issue or respond to an email you are potentially sending to a large number of people. Please consider this before you update. Also, remember that nobody likes spam.

Reporting Issues

If you find bugs, mistakes, inconsistencies in the XDAG project’s code or documents, please let us know by filing an issue at the appropriate issue tracker (we use multiple repositories). No issue is too small.

The main issues for bug reporting are as follows:

  • xdag/issues - Issues related to xdag.

  • DaggerGpuMiner/issues - Issues related to DaggerGpuMiner.

  • xDagWallet/issues - Issues related to xdag wallet C lib.

  • xdag-ios/issues - Issues related to xdag iOS wallet.

  • android-wallet/issues - Issues related to xdag Android wallet.

  • XDagWalletforMac/issues - Issues related to xdag Mac wallet.

  • QtXdagWallet/issues - Issues related to QtXdagWallet.

  • openxdagpool-scripts/issues - Issues related to scripts to open pool.

  • openxdagpool/issues - Issues related to xdag pool website.

- XDagger.github.io/issues - Issues related to xdag.io website.

  • explorer/issues - Issues related to block explorer.

The xdag issues use a template that will guide you through the process of reporting a bug. We will be adding this kind of issue template to other repositories as bug reports become more common.

Implementation Design

When considering design proposals for implementations, we are looking for:

A description of the problem this design proposal solves

Discussion of the tradeoffs involved

Discussion of the proposed solution

Community Improvement

The XDAG community requires the maintenance of various “public infrastructure” resources. These include documentation, Github repositories and more. There is also helping new users with questions, spreading the word about XDAG, and so on. We will be planning and running conferences. Please get in touch if you would like to help out.

Translations

This community moves very fast, and documentation swiftly gets out of date. For now, we are encouraging would-be translators to hold off from translating large repositories. If you would like to add a translation, please open an issue and ask the leads for a given repository before filing a PR, so that we do not waste efforts.

If anyone has any issues understanding the English documentation, please let us know! If you would like to do so privately, please email @Sofar. We are very sensitive to language issues and do not want to turn anyone away from hacking because of their language.

Contribution Guidelines

Discuss big changes as Issues first

Significant improvements should be documented as GitHub issues before anybody starts to code. This gives other contributors a chance to point you in the right direction, give feedback on the design, and maybe point out if related work is underway.

Please take a moment to check whether an issue already exists. If it does, it never hurts to add a quick “+1” or “I have this problem too”. This helps prioritize the most common problems and requests.

Pull Requests always welcome

We are always thrilled to receive pull requests and do our best to process them as quickly as possible. Not sure if that typo is worth a pull request? Do it! We will appreciate it.

We’re also trying very hard to keep XDAG focused. This means that we might decide against incorporating a new feature. However, there might be a way to implement that feature on top of (or below) XDAG.

If your pull request is not accepted on the first try, don’t be discouraged! If there’s a problem with the implementation, hopefully, you received feedback on what to improve.

Git

We use a simple git branching model:

master must always work

develop is the branch for development

create feature-branches to merge into develop

all commits must pass testing so that git bisect is easy to run

Just stay current with develop (rebase).

Commit messages

Commit messages must start with a short subject line, followed by an optional, more detailed explanatory text which is separated from the summary by an empty line.

Code

Write clean code. Universally formatted code promotes ease of writing, reading, and maintenance.

Documentation

Update documentation when creating or modifying features. Test your documentation changes for clarity, concision, and correctness, as well as a clean documentation build.

Pull Requests

Pull requests descriptions should be as clear as possible. Err on the side of overly specific and include a reference to all related issues. If the pull request is meant to close an issue please use the Github keyword conventions of closes, fixes, or resolves. If the pull request only completes part of an issue use the connects keywords. This helps our tools properly link issues to pull requests.

Code Review

We take code quality seriously; we must make sure the code remains correct. We do code review on all changesets. Discuss any comments, then make modifications and push additional commits to your feature branch. Be sure to post a comment after pushing. The new commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.

Merge Approval

We use Thank you for your efforts. in comments on the code review to indicate acceptance. A change requiresThank you for your efforts. from the maintainers of each component affected. If you know whom it may be, ping them.

Helping in other ways

To be continued.

Written by Frozen

如何贡献

希望能够hack一下XDAG?很棒!下面就是你如何开始的指南。

目前指南还不够完美,如果感觉哪里有错误或者不完整的地方,那么请告知我们。

XDAG是一个开源项目,我们欢迎各种贡献。有很多方法可以提供帮助,从报告问题,贡献代码到帮助我们改善社区。

话题

安全问题

社区准则

报告问题

实施设计

社区改善

翻译

贡献指南

其他帮助方式

安全问题

XDAG协议及其实现仍处于重大发展阶段。这意味着我们的协议可能存在问题,或者我们的实现可能存在错误。许多人已经在他们的机器上运行节点,因此我们非常重视安全漏洞。如果您发现安全问题,请立即引起我们的注意!

如果您发现可能影响实时部署的漏洞,请将您的报告私下发送到communitymanager@xdag.io,请不要提交公开问题。

如果问题是协议弱点或尚未部署的问题,请公开讨论。

社区准则

我们希望让XDAG社区保持卓越,成长和协作。我们需要你的帮助才能保持这种状态。为了解决这个问题,我们为整个社区提出了一些一般性指导原则:

要友善:对社区成员要礼貌,尊重和礼貌:不容忍任何地区,种族,性别或其他虐待行为。我们更喜欢好人, 而不是刻薄的人。

鼓励多元化和参与:让社区中的每个人都感到受欢迎,无论他们的背景和贡献程度如何,并尽一切可能鼓励他们参与我们的社区。

保持合法:基本上,不要让任何人遇到麻烦。仅共享您拥有的内容,不共享私人或敏感信息,不违反法律。

保持主题明确:确保您发布到正确的频道并避免偏离主题的讨论。请记住,当您更新问题或回复可能发送给大量人员的电子邮件时。请在更新前考虑这一点。还记得没人喜欢垃圾邮件。

报告问题

如果您发现XDAG项目的代码或文档中存在错误,错误,不一致,请通过在相应的代码库上提交问题告知我们(我们使用多个代码库)。没有问题是小问题!

用于报告错误的主要问题列表如下:

  • xdag/issues - 与xdag相关的问题。

  • DaggerGpuMiner/issues - 与GPU矿机相关的问题。

  • xDagWallet/issues - XDAG钱包C库相关的问题。

  • xdag-ios/issues - XDAG iOS钱包相关的问题。

  • android-wallet/issues - XDAG Android钱包相关的问题。

  • XDagWalletforMac/issues - XDAG Mac钱包相关的问题。

  • QtXdagWallet/issues - 与QT钱包相关的问题。

  • openxdagpool-scripts/issues - 与开池脚本相关的问题.

  • openxdagpool/issues - 与矿池网站相关的问题.

- XDagger.github.io/issues - 与官网相关的问题

  • explorer/issues - 与区块浏览器相关的问题。

XDAG问题使用模板来指导您完成报告错误的过程。错误报告变得更加常见,因此我们将把这种问题模板添加到其他代码库。

设计实现

在考虑实施的设计方案时,我们正在寻找:

当前设计方案解决的问题描述

关于所涉及的权衡的讨论

关于提出的解决方案的讨论

社区改善

XDAG社区需要维护各种“公共基础设施”资源。这些包括文档,github代码库等。还有帮助新用户提出问题,传播关于XDAG的信息等等。我们将规划和组织会议。如果您想帮忙,请联系我们。

翻译

这个社区进展得非常快,文档很快就会过时。目前我们鼓励潜在的翻译人员暂缓翻译大型存储库。如果您想添加翻译,请在提交PR之前打开一个问题并向代码库的主要贡献者询问,这样我们就不会浪费时间和精力。

如果有人对英文文档有任何疑问,请告诉我们!如果您想私下这样做,请发送电子邮件至@Sofar。我们对语言问题非常敏感,并且不希望因为他们的语言而让任何人远离研究XDAG。

贡献指南

首先讨论重大变化问题

在任何人开始编码之前,应将重要的改进记录为GitHub问题。这使得其他贡献者有机会指出正确的方向,提供有关设计的反馈,并可能指出相关工作是否正在进行中。

请花点时间检查问题是否已存在。如果确实如此,那么添加快速的“+1”或“我也有这个问题”永远不会受到伤害。这有助于确定最常见问题和请求的优先级。

PR总是受欢迎的

我们总是很高兴收到PR,并尽最大努力尽快处理它们。不确定这个拼写错误是否值得提交PR?大胆提交吧!我们将不胜感激。

我们也非常努力地保持XDAG的工作中心。 这意味着我们可能决定不采用新功能。 但是,可能有一种方法可以在XDAG之上(或之下)实现该功能。

如果您第一次尝试提交PR没有被接受,请不要气馁! 如果实现存在问题,希望您收到有关改进的反馈意见。

Git

我们使用一个简单的git分支模型:

master分支必须永远工作正常

develop分支是开发分支

创建功能分支以合并到开发分支中

所有提交都必须通过测试

只需要通过rebase命令同develop保持同步

代码

写清洁代码。 通用格式的代码可以提高编写,阅读和维护的便利性。

文档

创建或修改功能时更新文档。 测试文档更改的清晰度,简洁性和正确性,以及完整的文档构建。

PR

PR描述应尽可能清楚。 Err过于具体,包括对所有相关问题的引用。 如果PR旨在解决问题,请使用关闭,修复或解析的Github关键字约定。 如果pull请求仅完成部分问题,请使用连接关键字 closes, fixes或resolves。 这有助于我们的工具正确地将问题关联到PR。

代码审查

我们认真对待代码质量; 我们必须确保代码保持正确。 我们对所有变更集进行代码审查。 讨论任何评论,然后进行修改并将其他提交推送到您的功能分支。 请务必在推送后发表评论。 新提交将自动显示在PR中,但除非您发表评论,否则不会通知审阅者。

代码合并

我们在代码审查的评论Thank you for your efforts.表明接受。 PR需要接受来自受影响的每个组件的维护者给出Thank you for your efforts.评论。如果你知道谁是维护者,请联系相关维护者。

其他帮助方式

如何贡献

希望能够hack一下XDAG?很棒!下面就是你如何开始的指南。

目前指南还不够完美,如果感觉哪里有错误或者不完整的地方,那么请告知我们。

XDAG是一个开源项目,我们欢迎各种贡献。有很多方法可以提供帮助,从报告问题,贡献代码到帮助我们改善社区。

话题

安全问题

社区准则

报告问题

实施设计

社区改善

翻译

贡献指南

其他帮助方式

安全问题

XDAG协议及其实现仍处于重大发展阶段。这意味着我们的协议可能存在问题,或者我们的实现可能存在错误。许多人已经在他们的机器上运行节点,因此我们非常重视安全漏洞。如果您发现安全问题,请立即引起我们的注意!

如果您发现可能影响实时部署的漏洞,请将您的报告私下发送到communitymanager@xdag.io,请不要提交公开问题。

如果问题是协议弱点或尚未部署的问题,请公开讨论。

社区准则

我们希望让XDAG社区保持卓越,成长和协作。我们需要你的帮助才能保持这种状态。为了解决这个问题,我们为整个社区提出了一些一般性指导原则:

要友善:对社区成员要礼貌,尊重和礼貌:不容忍任何地区,种族,性别或其他虐待行为。我们更喜欢好人, 而不是刻薄的人。

鼓励多元化和参与:让社区中的每个人都感到受欢迎,无论他们的背景和贡献程度如何,并尽一切可能鼓励他们参与我们的社区。

保持合法:基本上,不要让任何人遇到麻烦。仅共享您拥有的内容,不共享私人或敏感信息,不违反法律。

保持主题明确:确保您发布到正确的频道并避免偏离主题的讨论。请记住,当您更新问题或回复可能发送给大量人员的电子邮件时。请在更新前考虑这一点。还记得没人喜欢垃圾邮件。

报告问题

如果您发现XDAG项目的代码或文档中存在错误,错误,不一致,请通过在相应的代码库上提交问题告知我们(我们使用多个代码库)。没有问题是小问题!

用于报告错误的主要问题列表如下:

  • xdag/issues - 与xdag相关的问题。

  • DaggerGpuMiner/issues - 与GPU矿机相关的问题。

  • xDagWallet/issues - XDAG钱包C库相关的问题。

  • xdag-ios/issues - XDAG iOS钱包相关的问题。

  • android-wallet/issues - XDAG Android钱包相关的问题。

  • XDagWalletforMac/issues - XDAG Mac钱包相关的问题。

  • QtXdagWallet/issues - 与QT钱包相关的问题。

  • openxdagpool-scripts/issues - 与开池脚本相关的问题.

  • openxdagpool/issues - 与矿池网站相关的问题.

- XDagger.github.io/issues - 与官网相关的问题

  • explorer/issues - 与区块浏览器相关的问题。

XDAG问题使用模板来指导您完成报告错误的过程。错误报告变得更加常见,因此我们将把这种问题模板添加到其他代码库。

设计实现

在考虑实施的设计方案时,我们正在寻找:

当前设计方案解决的问题描述

关于所涉及的权衡的讨论

关于提出的解决方案的讨论

社区改善

XDAG社区需要维护各种“公共基础设施”资源。这些包括文档,github代码库等。还有帮助新用户提出问题,传播关于XDAG的信息等等。我们将规划和组织会议。如果您想帮忙,请联系我们。

翻译

这个社区进展得非常快,文档很快就会过时。目前我们鼓励潜在的翻译人员暂缓翻译大型存储库。如果您想添加翻译,请在提交PR之前打开一个问题并向代码库的主要贡献者询问,这样我们就不会浪费时间和精力。

如果有人对英文文档有任何疑问,请告诉我们!如果您想私下这样做,请发送电子邮件至@Sofar。我们对语言问题非常敏感,并且不希望因为他们的语言而让任何人远离研究XDAG。

贡献指南

首先讨论重大变化问题

在任何人开始编码之前,应将重要的改进记录为GitHub问题。这使得其他贡献者有机会指出正确的方向,提供有关设计的反馈,并可能指出相关工作是否正在进行中。

请花点时间检查问题是否已存在。如果确实如此,那么添加快速的“+1”或“我也有这个问题”永远不会受到伤害。这有助于确定最常见问题和请求的优先级。

PR总是受欢迎的

我们总是很高兴收到PR,并尽最大努力尽快处理它们。不确定这个拼写错误是否值得提交PR?大胆提交吧!我们将不胜感激。

我们也非常努力地保持XDAG的工作中心。 这意味着我们可能决定不采用新功能。 但是,可能有一种方法可以在XDAG之上(或之下)实现该功能。

如果您第一次尝试提交PR没有被接受,请不要气馁! 如果实现存在问题,希望您收到有关改进的反馈意见。

Git

我们使用一个简单的git分支模型:

master分支必须永远工作正常

develop分支是开发分支

创建功能分支以合并到开发分支中

所有提交都必须通过测试

只需要通过rebase命令同develop保持同步

代码

写清洁代码。 通用格式的代码可以提高编写,阅读和维护的便利性。

文档

创建或修改功能时更新文档。 测试文档更改的清晰度,简洁性和正确性,以及完整的文档构建。

PR

PR描述应尽可能清楚。 Err过于具体,包括对所有相关问题的引用。 如果PR旨在解决问题,请使用关闭,修复或解析的Github关键字约定。 如果pull请求仅完成部分问题,请使用连接关键字 closes, fixes或resolves。 这有助于我们的工具正确地将问题关联到PR。

代码审查

我们认真对待代码质量; 我们必须确保代码保持正确。 我们对所有变更集进行代码审查。 讨论任何评论,然后进行修改并将其他提交推送到您的功能分支。 请务必在推送后发表评论。 新提交将自动显示在PR中,但除非您发表评论,否则不会通知审阅者。

代码合并

我们在代码审查的评论Thank you for your efforts.表明接受。 PR需要接受来自受影响的每个组件的维护者给出Thank you for your efforts.评论。如果你知道谁是维护者,请联系相关维护者。

其他帮助

Written by Frozen