Readouble

Laravel master 貢献ガイド

バグレポートBug Reports

より積極的に援助して頂きたいため、Laravelではただのバグレポートでなく、プルリクエストしてくれることを強く推奨しています。「バグレポート」は、失敗するテストを含めた、プルリクエストの形式で送ってください。To encourage active collaboration, Laravel strongly encourages pull requests, not just bug reports. "Bug reports" may also be sent in the form of a pull request containing a failing test.

しかし、バグレポートを提出する場合には、その問題をタイトルに含め、明確に内容を記述してください。できる限り関連する情報や、その問題をデモするコードも含めてください。バグレポートの目的はあなた自身、そして他の人でも、簡単にバグが再現でき、修正されるようにすることです。However, if you file a bug report, your issue should contain a title and a clear description of the issue. You should also include as much relevant information as possible and a code sample that demonstrates the issue. The goal of a bug report is to make it easy for yourself - and others - to replicate the bug and develop a fix.

バグレポートは同じ問題にあった他の人達と、解決するために協力できる望みを生み出すのだということを覚えておいてください。バグレポートにより、自動的に何かが起きたり、誰かがすぐ修正したりすることを期待しないでください。バグレポートの提出は、あなた自身と他の人が、問題を解決する道筋を開始するきっかけなのです。Remember, bug reports are created in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the bug report will automatically see any activity or that others will jump to fix it. Creating a bug report serves to help yourself and others start on the path of fixing the problem.

LaravelのソースコードはGitHubで管理され、各Laravelプロジェクトのリポジトリーが存在しています。The Laravel source code is managed on Github, and there are repositories for each of the Laravel projects:

コア開発の議論Core Development Discussion

新機能や、現存のLaravelの振る舞いについて改善を提言したい場合は、Laravel内部のissueボードへおねがいします。新機能を提言する場合は自発的に、それを完動させるのに必要な、コードを最低限でも実装してください。You may propose new features or improvements of existing Laravel behavior in the Laravel Internals issue board[https://github.com/laravel/internals/issues]. If you propose a new feature, please be willing to implement at least some of the code that would be needed to complete the feature.

バグ、新機能、既存機能の実装についてのざっくばらんな議論は、SlackのLaraChatチームにある#internalsチャンネルで行っています。LaravelのメンテナーであるTaylor Otwellは、通常ウイークエンドの午前8時から5時まで(America/Chicago標準時、UTC-6:00)接続しています。他の時間帯では、時々接続しています。Informal discussion regarding bugs, new features, and implementation of existing features takes place in the #internals channel of the LaraChat[http://larachat.co] Slack team. Taylor Otwell, the maintainer of Laravel, is typically present in the channel on weekdays from 8am-5pm (UTC-06:00 or America/Chicago), and sporadically present in the channel at other times.

どのブランチ?Which Branch?

全てのバグフィックスは、最新の安定ブランチ,もしくは現在のLTSブランチ(5.1)へ送ってください。次のリリースの中にだけ存在している機能に対する修正でない限り、決してバグフィックスをmasterブランチに送ってはいけません。All bug fixes should be sent to the latest stable branch or to the current LTS branch (5.1). Bug fixes should never be sent to the master branch unless they fix features that exist only in the upcoming release.

現在のLaravelリリースと完全な後方コンパティビリティを持っているマイナーな機能は、最新の安定ブランチへ送ってください。Minor features that are fully backwards compatible with the current Laravel release may be sent to the latest stable branch.

次のLaravelリリースに含めるべき、メジャーな新機能は、常にmasterブランチへ送ってください。Major new features should always be sent to the master branch, which contains the upcoming Laravel release.

もし、あなたの新機能がメジャーなのか、マイナーなのかはっきりしなければ、LaraChat#internalsチャンネルでTaylor Otwellに尋ねてください。If you are unsure if your feature qualifies as a major or minor, please ask Taylor Otwell in the #internals channel of the LaraChat[http://larachat.co] Slack team.

セキュリティ脆弱性Security Vulnerabilities

Laravelにセキュリティー脆弱性を見つけたときは、メールでTaylor Otwell(taylorotwell@laravel.com)に連絡してください。全セキュリティー脆弱性は、速やかに対応されるでしょう。If you discover a security vulnerability within Laravel, please send an email to Taylor Otwell at taylor@laravel.com[mailto:taylor@laravel.com]. All security vulnerabilities will be promptly addressed.

コーディングスタイルCoding Style

LaravelはPSR-2コーディング規約とPSR-4オートローディング規約に準拠しています。Laravel follows the PSR-2[https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md] coding standard and the PSR-4[https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader.md] autoloading standard.

PHPDocPHPDoc

次に正しいLaravelのドキュメントブロックの例を示します。@param属性に続け2スペース、引数タイプ、2スペース、最後に変数名となっていることに注意してください。Below is an example of a valid Laravel documentation block. Note that the @param attribute is followed by two spaces, the argument type, two more spaces, and finally the variable name:

/**
 * Register a binding with the container.
 *
 * @param  string|array  $abstract
 * @param  \Closure|string|null  $concrete
 * @param  bool  $shared
 * @return void
 */
public function bind($abstract, $concrete = null, $shared = false)
{
    //
}

StyleCIStyleCI

コードのスタイルが完璧でなくても心配ありません。プルリクエストがマージされたあとで、StyleCIが自動的にスタイルを修正し、Laravelリポジトリへマージします。これにより、コードスタイルではなく、貢献の内容へ集中することができます。Don't worry if your code styling isn't perfect! StyleCI[https://styleci.io/] will automatically merge any style fixes into the Laravel repository after pull requests are merged. This allows us to focus on the content of the contribution and not the code style.

章選択

開発環境
ビューとテンプレート
公式パッケージ

設定

明暗テーマ
light_mode
dark_mode
brightness_auto システム設定に合わせる
テーマ選択
photo_size_select_actual デフォルト
photo_size_select_actual モノクローム(白黒)
photo_size_select_actual Solarized風
photo_size_select_actual GitHub風(青ベース)
photo_size_select_actual Viva(黄緑ベース)
photo_size_select_actual Happy(紫ベース)
photo_size_select_actual Mint(緑ベース)
コードハイライトテーマ選択

明暗テーマごとに、コードハイライトのテーマを指定できます。

テーマ配色確認
スクリーン表示幅
640px
80%
90%
100%

768px以上の幅があるときのドキュメント部分表示幅です。

インデント
無し
1rem
2rem
3rem
原文確認
原文を全行表示
原文を一行ずつ表示
使用しない

※ 段落末のEボタンへカーソルオンで原文をPopupします。

Diff表示形式
色分けのみで区別
行頭の±で区別
削除線と追記で区別

※ [tl!…]形式の挿入削除行の表示形式です。

テストコード表示
両コード表示
Pestのみ表示
PHPUnitのみ表示
OS表示
全OS表示
macOSのみ表示
windowsのみ表示
linuxのみ表示
和文変換

対象文字列と置換文字列を半角スペースで区切ってください。(最大5組各10文字まで)

本文フォント

総称名以外はCSSと同様に、"〜"でエスケープしてください。

コードフォント

総称名以外はCSSと同様に、"〜"でエスケープしてください。

保存内容リセット

localStrageに保存してある設定項目をすべて削除し、デフォルト状態へ戻します。

ヘッダー項目移動

キーボード操作