プルリクエストのレビュー - 版の履歴

Hideaki Hagiwara: /* TL;DR;(Too Long, Didn't Read 長すぎると読まれません) */

2021-01-11T11:16:22Z

TL;DR;(Too Long, Didn't Read 長すぎると読まれません)

Hideaki Hagiwara: /* TL;DR; */

2021-01-11T11:14:33Z

TL;DR;

Hideaki Hagiwara: /* TL;DR; */

2021-01-11T11:10:08Z

TL;DR;

Hideaki Hagiwara: /* 機能のレビュー */

2021-01-11T11:01:27Z

機能のレビュー

Hideaki Hagiwara: /* 機能のレビュー */

2021-01-11T10:57:32Z

機能のレビュー

Hideaki Hagiwara: /* Review Functionality */

2021-01-11T10:54:57Z

Review Functionality

Hideaki Hagiwara: /* コードレビュー */

2021-01-11T10:50:11Z

コードレビュー

2021年1月11日 (月) 10:42にHideaki Hagiwaraによる

2021-01-11T10:42:32Z

2021年1月11日 (月) 10:41にHideaki Hagiwaraによる

2021-01-11T10:41:15Z

2021年1月11日 (月) 10:38にHideaki Hagiwaraによる

2021-01-11T10:38:11Z

@@ 56行目: / 56行目: @@
 結果が肯定的な場合は、チケットをテストしてみて、解決策が問題ないことがわかったとコメントしてください。
-= TL;DR;(Too Long, Didn't Read 長すぎると読まれません) =
+= TL;DR;(Too Long, Didn't Read 長すぎると読まれません-> 要約) =
 # [https://github.com/idempiere/idempiere/pulls オープンなプルリクエスト]をひとつ選んで下さい。
 # Do a code review based on the project's guidelines to [[Contributing to Trunk|contribute to the trunk]].

@@ 56行目: / 56行目: @@
 結果が肯定的な場合は、チケットをテストしてみて、解決策が問題ないことがわかったとコメントしてください。
-= TL;DR; =
+= TL;DR;(Too Long, Didn't Read 長すぎると読まれません) =
-# Choose one of the [https://github.com/idempiere/idempiere/pulls open pull requests].
+# [https://github.com/idempiere/idempiere/pulls オープンなプルリクエスト]をひとつ選んで下さい。
 # Do a code review based on the project's guidelines to [[Contributing to Trunk|contribute to the trunk]].
-# Test the ticket's functionality.
+# チケットの機能をテストして下さい。
-# Make sure there is no collateral damage or security breaches caused by the ticket.
+# チケットによる巻き添え被害やセキュリティ違反がないことを確認してください。
-# Report your findings on JIRA or directly to the pull request.
+# 発見したことを JIRA に報告するか、プルリクエストに直接報告してください。
 <br><br>

@@ 64行目: / 64行目: @@
 <br><br>
-'''I recommend you to test thoughtfully and be completely honest about what you did and what you didn't do. This is an open-source community, you have many eyes on you and your reputation will benefit or get hurt depending on what you do.'''
+'''思慮深くテストし、何をしたか、何をしなかったかについて完全に正直になることをお勧めします。これはオープンソースのコミュニティであり、あなたは多くの目で見られており、あなたの評判はあなたが何をするかによって利益を得たり傷ついたりします。'''
 [[en:Pull Request Review]]

@@ 41行目: / 41行目: @@
 <br><br>
-Once you have the changes in your local environment.
+一度、ローカル環境の変化を把握しておきましょう。
-# Apply the migration scripts if necessary.
+# 必要に応じてマイグレーションスクリプトを適用して下さい。
-# Run iDempiere and '''TEST'''.
+# iDempiereを起動して'''テスト'''して下さい。
-# Test every possible scenario, do not only test what was intended to be solved with the ticket but verify also that previous functionality is not affected by the commit. The system should behave as before except for the new addition.
+# 可能な限りのシナリオをテストしてください。そのチケットで解決しようとしていたことをテストするだけでなく、以前の機能がコミットの影響を受けていないかどうかも確認してください。システムは、新たに追加された以外は以前と同じように動作するはずです。
-Revert everything to keep master clean.
+マスターをクリーンに保つためにすべてを元に戻して下さい。
-After you've performed your review, report your findings on the Jira ticket, or add a comment directly to the pull request.
+レビューを実行した後は、Jira チケットで発見したことを報告したり、プルリクエストに直接コメントを追加したりしてください。
-You can be as specific as possible, describing what you've tested and the results.
+テストした内容と結果をできるだけ具体的に記述して下さい。
-If you found any issues, comment on what you've found and how you think it could be solved if you have any suggestions.
+何か問題点が見つかった場合は、何か提案があれば、それをどのように解決できると思うかコメントしてください。
-If the results are positive, comment that you've tested the ticket and you find the solution to be OK.
+結果が肯定的な場合は、チケットをテストしてみて、解決策が問題ないことがわかったとコメントしてください。
 = TL;DR; =

@@ 38行目: / 38行目: @@
   git pull --no-commit https://github.com/(pullrequest-github-user)/idempiere.git IDEMPIERE-(Jira-ticket-number) (for example: git pull --no-commit https://github.com/globalqss/idempiere.git IDEMPIERE-1848) <small>1</small>
-<small>1</small> ''Sometimes even when you specify --no-commit, git adds the commit to your log. If that is the case, check with git log and run git reset --soft HEAD~ to remove the commit from the log and keep your tree clean.''
+<small>1</small> ''--no-commit を指定していても、git がコミットをログに追加してしまうことがあります。そのような場合は、git のログを確認して git reset --soft HEAD~ を実行すると、ログからコミットを削除してツリーをきれいに保つことができます。''
 <br><br>

@@ 31行目: / 31行目: @@
 コードがよく書かれていること、プロジェクトのガイドラインやベストプラクティスを満たしていることを確認したら、ローカル環境にコードを引っ張り出してテストします。
-== Review Functionality ==
+== 機能のレビュー ==
-In your local environment run:
+あなたのローカル環境で実行して下さい。:
   git checkout master
   git pull upstream master

@@ 19行目: / 19行目: @@
 == コードレビュー ==
-* Choose one of the [https://github.com/idempiere/idempiere/pulls open pull requests].
+* [https://github.com/idempiere/idempiere/pulls オープンになっているプルリクエスト]から、１つを選んで下さい。
-* Open the list of commits done against the pull request to see the changes in the code that were done by the developer.
+* プルリクエストに対して行われたコミットのリストを開くと、開発者によって行われたコードの変更を見ることができます。
 * Check that the submitted code complies with the project guidelines to [[Contributing to Trunk|contribute to the trunk]]. The main points to consider are:
-** It has to work in PostgreSQL and Oracle.
+** PostgreSQL と Oracle の両方で動作しなければなりません。
-** When possible avoid the use of SQL Code, use the data model instead.
+** 可能な限りSQLコードの使用を避け、代わりにモデルクラスを使用してください。
-** If changes in the database were made, the migration scripts are present.
+** データベースに変更があった場合は、移行スクリプトが存在します。
-** JDBC should be avoided if it is used because there is no other way, every cursor must be closed in a "finally" block.
+** DBにSQLでアクセスする際には、すべてのカーソルは"finally"句で、閉じなければなりません。
-** All the code is written in English.
+** コードはすべて英語で書かれています。
-** The pull request does not mix purposes (f.i refactoring and new feature) and changes only the necessary classes to address the ticket's goal.
+** プルリクエストは目的(例えば、リファクタリングと新機能など)を混在させることなく、チケットの目的に対応するために必要なクラスのみを変更します。
-Once you validate that the code is well written and satisfies the project's guidelines and best practices, proceed to pull the code to your local environment to test.
+コードがよく書かれていること、プロジェクトのガイドラインやベストプラクティスを満たしていることを確認したら、ローカル環境にコードを引っ張り出してテストします。
 == Review Functionality ==

@@ 4行目: / 4行目: @@
 '''なぜこれが重要なのか?''' <br>
-年4月以降、ブルリクエストは[[Fork and Branch Git ワークフロー|プロジェクトへのコードの貢献]]のデフォルトの方法([Fork and Branch Git ワークフロー])となっています。ご存知のように、iDempiereはオープンソースのソフトウェアプロジェクトであり、コードはプロジェクトの最も重要な部分です。これらのバグ修正や機能追加は、コードが適切に書かれていれば、コミュニティの全員に利益をもたらします。 <br>
+年4月以降、ブルリクエストは[[Fork and Branch Git ワークフロー|プロジェクトへのコードの貢献]]のデフォルトの方法([[Fork and Branch Git ワークフロー]])となっています。ご存知のように、iDempiereはオープンソースのソフトウェアプロジェクトであり、コードはプロジェクトの最も重要な部分です。これらのバグ修正や機能追加は、コードが適切に書かれていれば、コミュニティの全員に利益をもたらします。 <br>
 iDempiereのリーダーたちは、最高品質のコードを維持することを重視しています。彼らは、トランクに入るものや変更すべきものをレビューし、フィルタリングすることで、これを実現しています。問題は、プロジェクトが多くのリクエストを受ければ受けるほど、キューが長くなり、時間の経過とともに迷走するリクエストが出てくることです。
@@ 16行目: / 16行目: @@
 # コードは意図した通りの動作をしているか？
-The first thing that you can do without having to add anything to your local environment is to review the code.
+ローカル環境に何も足さなくてもできることは、まずコードを見直すことです。
-== Code Review ==
+== コードレビュー ==
 * Choose one of the [https://github.com/idempiere/idempiere/pulls open pull requests].
 * Open the list of commits done against the pull request to see the changes in the code that were done by the developer.

@@ 4行目: / 4行目: @@
 '''なぜこれが重要なのか?''' <br>
-年4月以降、ブルリクエストは[[Fork and Branch Git ワークフロー|プロジェクトへのコードの貢献]]のデフォルトの方法となっています。ご存知のように、iDempiereはオープンソースのソフトウェアプロジェクトであり、コードはプロジェクトの最も重要な部分です。これらのバグ修正や機能追加は、コードが適切に書かれていれば、コミュニティの全員に利益をもたらします。 <br>
+年4月以降、ブルリクエストは[[Fork and Branch Git ワークフロー|プロジェクトへのコードの貢献]]のデフォルトの方法([Fork and Branch Git ワークフロー])となっています。ご存知のように、iDempiereはオープンソースのソフトウェアプロジェクトであり、コードはプロジェクトの最も重要な部分です。これらのバグ修正や機能追加は、コードが適切に書かれていれば、コミュニティの全員に利益をもたらします。 <br>
-The iDempiere leaders put a lot of emphasis on keeping code of the highest-quality, they are able to do this by reviewing and filtering what gets into the trunk and what needs to be changed before doing so. The problem is that the more requests the project gets, the longer the queue, and there might be requests that get lost in time.
+iDempiereのリーダーたちは、最高品質のコードを維持することを重視しています。彼らは、トランクに入るものや変更すべきものをレビューし、フィルタリングすることで、これを実現しています。問題は、プロジェクトが多くのリクエストを受ければ受けるほど、キューが長くなり、時間の経過とともに迷走するリクエストが出てくることです。
-This is where you can help, by reviewing pull requests you can be the first filter if you do it properly you take a lot of work off the leaders' shoulders, helping to get important code into the trunk faster.
+プルリクエストをレビューすることで、最初のフィルタになることができ、適切に実行すれば、リーダーの肩から多くの作業を省くことができ、重要なコードをより早くトランクに入れることができます。
-= How can I review a pull request? =
+= プルリクエストをレビューするには? =
-There are many things that need to be reviewed before code gets into the trunk, but it can be roughly summarized in two:
+コードがトランクに入る前にレビューしなければならないことはたくさんありますが、大まかには2つにまとめることができます。
-# Is the code well written and does not add collateral damage or security breaches?
+# コードはきちんと書かれていて、付随的な損害やセキュリティ侵害をもたらさないか？
-# Does the code do what it is intended to do?
+# コードは意図した通りの動作をしているか？
 The first thing that you can do without having to add anything to your local environment is to review the code.

@@ 1行目: / 1行目: @@
-There are many pull requests being pushed to the project and you can help the core team by reviewing and testing them.
+プロジェクトには多くのプルリクエストがプッシュされており、それらをレビューしたりテストしたりすることでコアチームを支援することができます。
-In this wiki, I want to explain how you can help with this task
+このWikiでは、この作業をどのように支援するかを説明したいと思います。
-'''Why is this so important?''' <br>
+'''なぜこれが重要なのか?''' <br>
-Pull requests are the default way of [[Fork and Branch Git Workflow|contributing code to the project]] since April 2020. As you know, iDempiere is an open-source software project, therefore, the code is the most important piece of the project. Daily the project is receiving more and more pull requests to address issues or add new features, these bug fixes and features benefit everyone in the community if the code is well written, otherwise, it might harm the whole project if a bad written piece of code gets to the core. <br>
+年4月以降、ブルリクエストは[[Fork and Branch Git ワークフロー|プロジェクトへのコードの貢献]]のデフォルトの方法となっています。ご存知のように、iDempiereはオープンソースのソフトウェアプロジェクトであり、コードはプロジェクトの最も重要な部分です。これらのバグ修正や機能追加は、コードが適切に書かれていれば、コミュニティの全員に利益をもたらします。 <br>
 The iDempiere leaders put a lot of emphasis on keeping code of the highest-quality, they are able to do this by reviewing and filtering what gets into the trunk and what needs to be changed before doing so. The problem is that the more requests the project gets, the longer the queue, and there might be requests that get lost in time.