[shardingsphere] branch master updated: Review article translation (#6205)

[do...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

dongzonglei pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git


The following commit(s) were added to refs/heads/master by this push:
     new 4e848ef  Review article translation (#6205)
4e848ef is described below

commit 4e848efb08836008c52c8f8f69f88903c38689e4
Author: Juan Pan(Trista) <pa...@apache.org>
AuthorDate: Mon Jun 29 11:47:34 2020 +0800

    Review article translation (#6205)
---
 docs/blog/content/material/community.en.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/blog/content/material/community.en.md b/docs/blog/content/material/community.en.md
index 649c946..6f64f69 100644
--- a/docs/blog/content/material/community.en.md
+++ b/docs/blog/content/material/community.en.md
@@ -57,11 +57,11 @@ There were only 11 initial committers during an extended period. This situation
 
 2. Believe contributors. Anyone willing to join an open-source community is generally full of enthusiasm and wants to make the project better through their contribution. Therefore, the community is supposed to respect and welcome them and provide the needed help. However, one point needed note is that committers and contributors are different. We would like to grant more privileges to a committer and trust them more since they have become familiar with this project and built faith with others.
 
-3. Automated testing. With more and more contributors, the code submission will become more and more frequent. Relying on manpower to control the final quality will become more and more uncertain. The ShardingSphere community puts more emphasis on reducing the probability of error through automation. The automated testing framework can ensure that contributors do not submit code with fear. As long as the automated testing is correct, the correctness of the code can be guaranteed. Automat [...]
+3. Automated Testing. More contributors, more Pull requests. In this situation, it is hard to guarantee the effectiveness and efficiency of the project by manual. Therefore, we decide to rely on automated testing to evaluate each Pull request, which helps contributors and reviewers merely focus on their work.
 
-4. Create a self-service channel. As the project is used by more and more users, various problems will occur. It may be a bug of the project, a problem of the user itself or caused by unclear documentation. Therefore, it is important to create a self-service channel. Through documents and FAQs, users can solve most problems in a self-service manner. When there are unsolvable problems, you can find the core developers of the community through email, GitHub, or even WeChat group to further [...]
+4. Self-service first. More questions get increased with more and more users. How to handle these questions efficiently? Our solution is to build user self-service channels firstly and provide other communication ways. In general, users can solve some of the common issues with documents and FAQ pages by themselves. If that does not work, users can raize their special issues on GitHub or discuss them by email. 
 
-5. Open and remote working mode. Only open discussion on the mailing list or GitHub will be considered a problem that has already occurred. The community will not deal with private communications and commitments. The community hopes that all issues and resolutions will be publicly available. Remote collaboration means that there is no need for collaborators to be geographically concentrated, which means that work is asynchronous. It requires information exchange to explain the context cl [...]
+5. Public and online working mode. Public work means the issue only discussed in public is valid—otherwise, invalid and no chance to be solved. Online work means most of the discussions are online and asynchronous, requiring participants to provide information as detailed as possible.
 
 The Apache Software Foundation provides a community maturity assessment model from the seven aspects of code, copyright, release, quality, community. unanimous resolution and product independence. At present, Apache ShardingSphere has completed the evaluation and passed the evaluation of all 34 sub-projects.