作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

次回はまとめる人を決めておこう。。。

今回はまとめる人を決めていなかったので忘れていることもたくさんあるはず。。。

「CC BY-SA 4.0 International」が正しい。

#2 (comment)

このリポジトリのライセンスなんですが
リンク先はCC BY-SA 4.0 Internationalになっているのに、ファイルにはUniversalとなっているので直してもいいですかね？

このワークショップをよりよくするために気づいたことやアイディアを書く場所。

これは作業ログissueのテンプレートです。各参加者はこのテンプレートを元に1人1つのissueを作ってください。ワークショップ中はそのissueに作業ログをつけていきます。

まず、 https://github.com/oss-gate/workshop/issues/new で新しいissueを作ります。タイトルは次の内容にします。

OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ

たとえば次のようになります。

OSS Gateワークショップ2016-03-26: kou: Rabbit: 作業ログ

以下を内容にコピーしてissueを作ります。issueを作ったら説明を読んでください。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

  * 参加者は作業ログの内容を順にメンターに説明する。
  * メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

  * 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
  * 参加者が困っていることについて、解決策を一緒に考えてくれます。
  * 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
  * 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
  * 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

  * 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
  * 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
  * issueを出したとき
  * pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

  * 作業（やること、やっていること、やったこと。）
  * 思っていること（そのときどう思っているか。）
  * 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

    * 作業（ここにやること、やっていること、やったことを書く）
    * 思っていること：（今どう思っているかを書く）

    備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

    * 作業：インストールを始めた
    * 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

    * 作業：インストールが失敗した
    * 思っていること：ドキュメントに手順が足りない？

    備考：エラーメッセージは次の通り

    ```text
    XXX is not found
    ```

    必要なファイルが足りないのかなぁ。

Find improvement

・VTKの改善について調査
・https://github.com/Kitware/VTK はミラーサイトで
・コミットはkitwareのgitlab repositoryにするとのこと。
・issueタブもなくてコミットはパッチリリースの形でしかできない。
・ハードルが高いので断念。

・Plasma simulator に対象を変更 BOUT++
http://www-users.york.ac.uk/~bd512//bout/
Github repository
https://github.com/bendudson/BOUT
上記サイトGetting BOUT++にしたがってgit clone
-> 成功
https://github.com/bendudson/BOUT/wiki
にしたがってインストール
インストールのインストラクション
https://github.com/bendudson/BOUT/wiki/Installing-bout--
にprerequisiteとして
MPI
FFTW
NetCDF
と書いてあるが、MPIと言っても色々あるので困る
http://www.fftw.org/　でFFTWをダウンロードしようとする。
http://www.fftw.org/download.html　からダウンロード
http://www.fftw.org/fftw3_doc/Installation-on-Unix.html#Installation-on-Unix
にしたがってインストール
./configure
make
(sudo) make install
でインストールできたようだが、インストール時のメッセージが成功したのかわかりにくい
Libraries have been installed in:
/usr/local/lib
というメッセージが途中で出てくるがこれが最後に出てくると良いと思う。

make check でテストが走っているのでいいのか?
Issue title: Want install success to be clearly shown in message of 'make install'
text:
The message of 'make install' is as follows:

Libraries have been installed in:
/usr/local/lib
....................
make[2]: Nothing to be done for install-exec-am'. make[2]: Nothing to be done forinstall-data-am'.
make[2]: Leaving directory `/home/hoge/src/fftw-3.3.4/m4'

make[1]: Leaving directory `/home/hoge/src/fftw-3.3.4/m4'

But I'd like to suggest that some message which states its install success/failure come to the last.
Please consider this.
　
Leaving directory で終わるのはmakeの仕様なので、この問題は難しいとのこと。
suggestと書くのは通常しない。

NetCDFのインストール開始
array-oriented scientific dataのシェアのためのプラットフォーム
http://www.unidata.ucar.edu/downloads/netcdf/index.jsp
からダウンロード　(tar.gz)
http://www.unidata.ucar.edu/software/netcdf/docs/getting_and_building_netcdf.html
を見てインストール、またRequirementsがあって厳しい
Requirements
HDF5 1.8.9 or later (for netCDF-4 support)
zlib 1.2.5 or later (for netCDF-4 compression)
curl 7.18.0 or later (for DAP remote access client support)
https://www.hdfgroup.org/HDF5/release/obtainsrc.html
からソースコード入手 (tar.gz)
https://www.hdfgroup.org/ftp/HDF5/current/src/unpacked/release_docs/INSTALL
にしたがってインストール
$ gunzip < hdf5-X.Y.Z.tar.gz | tar xf -
$ cd hdf5-X.Y.Z
$ ./configure --prefix=/usr/local/hdf5
$ make
$ make check
$ sudo make install
$ sudo make check-install

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

やること(目標)

PHPUnitのassertSameのアサーションエラー情報を増やす

インストール

• 最新コミットのPHPUnitを持ってくる
• 最新コミットであれば不満に感じていることが修正されてるかも
• 修正されていなければ、何故アサーションエラー情報が少ないのかドキュメントを見る
• ドキュメントに記載がなければ、PHPUnitを修正してPRを投げてみる

composer.jsonに最新コミットでインストールしてみたところ、PHPのバージョンが古いためインストールできなかった(5.6以上)

$ phpenv install 5.6.0

5.6.0をinstallしようとすると、ビルドエラーになった

-----------------
|  BUILD ERROR  |
-----------------

Here are the last 10 lines from the log:

-----------------------------------------
configure: WARNING: This bison version is not supported for regeneration of the Zend/PHP parsers (found: 2.3, min: 204, excluded: 3.0).
configure: error: Cannot find OpenSSL's <evp.h>
-----------------------------------------

この記事を参考にBUILD ERRORをなおしてみた
http://qiita.com/yurishima/items/8df59615bbd085522e92

また、異なるBUILD ERRORが

-----------------
|  BUILD ERROR  |
-----------------

Here are the last 10 lines from the log:

-----------------------------------------
1 warning generated.
/var/tmp/php-build/source/5.6.0/sapi/cli/php_cli_server.c:541:25: warning: address of '(sapi_globals.sapi_headers).headers' will always evaluate to 'true' [-Wpointer-bool-conversion]
        if (!&SG(sapi_headers).headers) {
            ~ ~~~~~~~~~~~~~~~~~^~~~~~~
1 warning generated.
/var/tmp/php-build/source/5.6.0/sapi/cgi/cgi_main.c:1698:25: warning: address of '(sapi_globals.sapi_headers).headers' will always evaluate to 'true' [-Wpointer-bool-conversion]
        if (!&SG(sapi_headers).headers) {
            ~ ~~~~~~~~~~~~~~~~~^~~~~~~
1 warning generated.
PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled.
-----------------------------------------

こちらを参考にBUILD ERRORをなおしてみた
http://qiita.com/yurishima/items/8df59615bbd085522e92

ビルドに成功した。

無事、PHPのバージョンを上げれた

php -v
PHP 5.6.0 (cli) (built: May 28 2016 12:12:49)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.3.3, Copyright (c) 2002-2015, by Derick Rethans

気を取り直して再度PHPUnitをインストール

$ composer install

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for phpunit/phpunit dev-master -> satisfiable by phpunit/phpunit[dev-master].
    - phpunit/phpunit dev-master requires phpunit/php-code-coverage ^4.0 -> satisfiable by phpunit/php-code-coverage[4.0.x-dev] but these conflict with your requirements or minimum-stability

composer.jsonを以下に変更してcomposer installすれば、インストールできた。
最新コミットがほしいのであえて、dev-masterにしてる

{
    "require-dev": {
        "phpunit/phpunit": "dev-master",
        "phpunit/phpunit-mock-objects": "dev-master",
        "phpunit/php-code-coverage": "dev-master"
    }
}

PHPUnitの最新コミットを取得できた

./vendor/phpunit/phpunit/phpunit --version
PHPUnit 5.4-g7735f76 by Sebastian Bergmann and contributors.

修正したいこと確認

配列を扱ったassertEqualsとassertSameのアサーションエラー情報に差異がある。

<?php

class Test extends PHPUnit_Framework_TestCase
{
    /**
     * @test
     */
    public function assertEqualsTest()
    {
        $actual = [];
        $expected = [];
        $actual[] = ['name' => 'fuga'];
        $actual[] = ['name' => 'hoge'];
        $expected[] = ['name' => 'hoge'];
        $expected[] = ['name' => 'hoge'];

        $this->assertEquals($expected, $actual);
    }

    /**
     * @test
     */
    public function assertSameTest()
    {
        $actual = [];
        $expected = [];
        $actual[] = ['name' => 'fuga'];
        $actual[] = ['name' => 'hoge'];
        $expected[] = ['name' => 'hoge'];
        $expected[] = ['name' => 'hoge'];

        $this->assertSame($expected, $actual);
    }
}

1) Test::assertEqualsTest
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
     0 => Array (
-        'name' => 'hoge'
+        'name' => 'fuga'
     )
     1 => Array (...)
 )

/Users/hamuhamu/php/oss/Test.php:17

2) Test::assertSameTest
Failed asserting that Array &0 (
    0 => Array &1 (
        'name' => 'fuga'
    )
    1 => Array &2 (
        'name' => 'hoge'
    )
) is identical to Array &0 (
    0 => Array &1 (
        'name' => 'hoge'
    )
    1 => Array &2 (
        'name' => 'hoge'

assertSameをassertEqualsと同等のエラー出力にしたい

仕様かバグか確認

まずは、公式ドキュメントを確認
https://phpunit.de/manual/5.4/ja/appendixes.assertions.html#appendixes.assertions.assertSame

公式ドキュメントを呼んでもめぼしい情報は見当たらなかった

次にGitHubのissueに取り上げられていないか確認
https://github.com/sebastianbergmann/phpunit/issues?q=assertSame+is%3Aclosed

同じことに気づいて取り上げている人がいた
sebastianbergmann/phpunit#1252

雑な翻訳
新しいバージョンをリリースするからひとまず、バグレポートを閉じます(バグが修正されるかもしれないから)
新しいバージョンでも問題が起こるのであればissue切ったりPRを送ってください

この後のやり取りはないみたいなので、放置されっぱなしだと思う
誰も修正する気はなさそう

なので、PRを送ってしまいましょう
PRは現在の安定ブランチに基づくものでなければならない(5.3.4)

ガイドはこちら
https://github.com/sebastianbergmann/phpunit/blob/master/CONTRIBUTING.md

issueに起票

ひとまず、事象をissueに起票
sebastianbergmann/phpunit#2178

原因追求

コードを読んで実行して原因を探る
forkした https://github.com/hamuhamu/phpunit

forkしてテスト実行してみた
既に数件、テスト失敗してる辛い

assertSameのテストを探して実行する

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

問題:ASUS X205TAにおいて、Linux Kernel 4.2以上において、頻繁にフリーズが起こる。
報告先がわからない。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

今後、このワークショップをよりよくするためにフィードバックをおねがいします。

• 参加者向けアンケート
• メンター向けアンケート

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

• ビギナー向けアンケート
• メンター向けアンケート

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

次回、須藤が進行役をしなくても進められるように、2016-03-26での進め方をメモしておく。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

・何をする？
jQueryの不具合修正
・どう探す？
GitHub上のissueを見て、わかるものを探してみる
issueは難しいので、他のプラグインでわかるものを探してみた
・どう探した？
　→公式HPを見てみる
　→jQuery+pullrequestでぐぐってみる
　→jQueryUIのファンドネーションページがある
　→https://contribute.jquery.org/commits-and-pull-requests/
　→contributing to...に貢献方法が書いてある

・再現方法
★cloud9でやろうとしたが、
そもそも参照してるpluginの変更はできないと気づく。
→ローカル開発で再現

・下記のものを試す
https://bugs.jqueryui.com/ticket/6814

・不具合再現しなくない？

・報告

//ttt

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

rbenv 環境に rails をインストールするのをやってみます。

告知の仕方をいくつか試してみた。その結果を活かすことで今後より有効に告知できるのではないか。

これは作業ログissueのテンプレートです。各参加者はこのテンプレートを元に1人1つのissueを作ってください。ワークショップ中はそのissueに作業ログをつけていきます。

まず、 https://github.com/oss-gate/workshop/issues/new で新しいissueを作ります。タイトルは次の内容にします。

OSS Gateワークショップ2016-01-30: ${アカウント名}: ${OSS名}: 作業ログ

たとえば次のようになります。

OSS Gateワークショップ2016-01-30: kou: Rabbit: 作業ログ

以下を内容にコピーしてissueを作ります。issueを作ったら説明を読んでください。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

  * 参加者は作業ログの内容を順にメンターに説明する。
  * メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

  * 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
  * 参加者が困っていることについて、解決策を一緒に考えてくれます。
  * 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
  * 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
  * 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

  * 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
  * 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
  * issueを出したとき
  * pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

  * 作業（やること、やっていること、やったこと。）
  * 思っていること（そのときどう思っているか。）
  * 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

    * 作業（ここにやること、やっていること、やったことを書く）
    * 思っていること：（今どう思っているかを書く）

    備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

    * 作業：インストールを始めた
    * 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

    * 作業：インストールが失敗した
    * 思っていること：ドキュメントに手順が足りない？

    備考：エラーメッセージは次の通り

    ```text
    XXX is not found
    ```

    必要なファイルが足りないのかなぁ。

目的

「OSS Gate」という取り組みとその実現方法の1つである「OSS Gateワークショップ」の普及。

実現方法

2016-05-28日開催のワークショップは東京Ruby会議11実行委員会から1部屋貸してもらって実施する。さらに、チラシを配ってもいいよと言ってもらっている。この機会を活かし、東京Ruby会議11参加者にチラシを配り目的を達成する。

TODO

この実現方法をするにあたり、やらなければいけなそうなこと。

• チラシを作る
  • 内容はどうする？
  • デザインはどうする？
• チラシを配る
  • だれかが配る？
  • 東京Ruby会議11の受付（かどこか配布場所）に置いてもらう？
• ???

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

目的

• OSS Hack 4 Beginnersに参加していない人も「どういうイベントなのか」を体験する
  • 体験することで、どうすればOSS Gateを継続的に成果をあげられる取り組みにできるかをより考えれるようになることを期待。
• OSS Gate を立ち上げようであがった継続的に成果をあげる案を試す
  • すべての案を100%の力で試すのではなく、試せるものは試せる範囲で試す。試して成果がでなくてもよい。試してフィードバックを得て、次の行動につなげられれば十分。なので、成果がでない案かもしれないというのがわかるということも重要なフィードバック。

内容

OSS Hack 4 Beginnersの内容をベースにOSS Gate向けにアレンジする。

規模

OSS Gateという取り組みに協力したい！という人たち（≒ OSS Gateを立ち上げように参加した人たち）がフィードバックを得られる規模でよい。OSS Hack 4 Beginnersのアンケート結果を見るとOSS Hack 4 Beginnersは参加者が約30人だったが、もっと少なくても十分だと思う。

TODO

• 会場を決める
• 内容をアレンジ
• 告知
• 開催

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

* 作業 : 
* 思っていること: 

対象gem

https://github.com/asonas/chatwork-ruby

終日ではなく、午後だけで終わるようにした方がよいのかもしれない。

https://twitter.com/trorornmn/status/690833865250762752

＿人人人人人人人人＿
＞　10:30 - 18:00　＜
￣^Y^Y^Y^Y^Y^Y^Y^￣

https://twitter.com/trorornmn/status/690833896515043328

せめて午後からだったらな〜

時間が短くても同じ成果を出せるなら参加者だけでなく開催する側の負担も減らせるのでよさそう。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

これは作業ログissueのテンプレートです。各参加者はこのテンプレートを元に1人1つのissueを作ってください。ワークショップ中はそのissueに作業ログをつけていきます。

まず、 https://github.com/oss-gate/workshop/issues/new で新しいissueを作ります。タイトルは次の内容にします。

OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ

たとえば次のようになります。

OSS Gateワークショップ2016-03-26: kou: Rabbit: 作業ログ

以下を内容にコピーしてissueを作ります。issueを作ったら説明を読んでください。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

  * 参加者は作業ログの内容を順にメンターに説明する。
  * メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

  * 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
  * 参加者が困っていることについて、解決策を一緒に考えてくれます。
  * 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
  * 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
  * 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

  * 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
  * 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
  * issueを出したとき
  * pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

  * 作業（やること、やっていること、やったこと。）
  * 思っていること（そのときどう思っているか。）
  * 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

    * 作業（ここにやること、やっていること、やったことを書く）
    * 思っていること：（今どう思っているかを書く）

    備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

    * 作業：インストールを始めた
    * 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

    * 作業：インストールが失敗した
    * 思っていること：ドキュメントに手順が足りない？

    備考：エラーメッセージは次の通り

    ```text
    XXX is not found
    ```

    必要なファイルが足りないのかなぁ。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ2016-03-26: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

参加者とふりかえりをする中でメンターが印象に残ったことのうち、他の参加者に共有したいことをコメントに書いてください。ワークショップの最後に全員に共有する機会があります。

メンター自身に紹介してもらうのでメンター自身が思い出せれば一言二言で構いません。

OSS Gate へようこそ。

Workshop では一人ずつ GitHub issue を立ててそこで作業ログを残していきながら進めます。
過去のビギナーのものはこちらで見られます。 https://github.com/oss-gate/workshop/issues?q=is%3Aissue+is%3Aclosed

この issue 作成時点でまずやること

• この issue のタイトルを「OSS Gateワークショップ ${YEAR}-${MONTH}-${DAY}: ${アカウント名}: ${OSS名}: 作業ログ」の形式でつけてください
• OSS 名が未定の場合はタイトルは後からでも変えられるので、とりあえず未定などでも OK です

作業開始してからやること

以下を参考にしながらやってみます。

https://github.com/oss-gate/workshop/blob/master/tutorial/scenario.md

作業ログについての説明（わからなくなったら都度読み返してください）

作業ログは、ビギナーが、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• ビギナーは作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いてビギナーにフィードバックをする。

メンターは次のようなフィードバックをします。これは、ビギナーとは違う視点からビギナーの行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• ビギナーが気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• ビギナーが困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をしてビギナーが整理できていない行動や考えを整理してくれます。
• ビギナーが「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• ビギナーが次にどの方向に進めばよいかを整理してくれます。

このように、ビギナーの作業をメンター視点で一緒に整理し、ビギナーの今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「ビギナーにとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、ビギナーが重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

事前アンケートより。

参加者が使える言語一覧：

• C
• C++
• C#
• Java
• シェルスクリプト
• Ruby
• Go
• Python
• PHP
• JavaScript

メンターが開発に参加しているOSS一覧：

• tDiary (Ruby) https://github.com/tdtds/tdiary-core
• massr (JavaScript, Ruby) https://github.com/tdtds/massr
• 宅配トラッカー (JavaScript, Ruby) https://github.com/tdtds/takuhai_tracker http://takuhai-tracker.herokuapp.com/
• Focuslight (Ruby)
• JRuby (Java)
• Rabbit (Ruby)
• Ruby-GNOME2 (C)
• test-unit (Ruby)
• Ruby (C)
• Groonga (C)
• Mroonga (C++)
• PGroonga (C)
• Rroonga (C)
• Pikzie (Python)
• Debian (...?)
• OpenStack (Python)
• Linux Kernel (C)
• sendgrid-ruby (Ruby)
• rws-php-sdk (PHP)
• ruby-net-ldap (Ruby)
• ROMA (Ruby)
• tdiary-core (Ruby)
• tdiary-contrib (Ruby)
• rws-ruby-sdk (Ruby)
• Node.jsを含むJavaScript関係 (JavaScript)

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。

作業ログは、参加者が、このワークショップを通して得るものをより増やすために重要になります。なぜなら作業ログがメンターからのフィードバックをより充実させるからです。

作業ログを元にメンターと「ふりかえり」をするタイミングがあります。「ふりかえり」では次のことをします。

• 参加者は作業ログの内容を順にメンターに説明する。
• メンターは説明を聞いて参加者にフィードバックをする。

メンターは次のようなフィードバックをします。これは、参加者とは違う視点から参加者の行動を観察することおよびメンターの経験があるからできることです。（「ふりかえり」の前にこんなフィードバックをよろしくお願いします！とお願いすると効果が高まるので実践してみましょう。）

• 参加者が気づかずにやっていたよい行動に気づくきかっけを与え、今後もその行動を継続するように促します。
• 参加者が困っていることについて、解決策を一緒に考えてくれます。
• 適切な質問をして参加者が整理できていない行動や考えを整理してくれます。
• 参加者が「問題」だと認識していないこと（「問題発見」は難しい！）をメンターの視点から「問題」だと見つけてくれます。「問題」がはっきりしたら直しましょう。
• 参加者が次にどの方向に進めばよいかを整理してくれます。

このように、参加者の作業をメンター視点で一緒に整理し、参加者の今後の行動に活かす活動がここでいう「ふりかえり」です。そのため、「参加者にとって」ログに残すべきかどうか、という視点ではなく、「とりあえずログに残す」という視点でログを残してください。これは、参加者が重要だと判断しなくてもメンターの視点から見たら大事なこともあるからです。

ログに残すときは次のようなときです。

• 違う作業を始めたとき（インストールを始めた、動作確認を始めた、テストを始めた、とか）
• 詰まったとき（インストール時にエラーがでた、ビルドが失敗した、とか）
• issueを出したとき
• pull requestを出したとき

ログに残すことは次のことです。「備考」以外は作業の邪魔にならないように一言でよいです。備考は作業に役立つので必要な分だけ書いてください。

• 作業（やること、やっていること、やったこと。）
• 思っていること（そのときどう思っているか。）
• 備考（必要な付加情報。）

ログはコメントとして追記していってください。テンプレートは次の通りです。

* 作業（ここにやること、やっていること、やったことを書く）
* 思っていること：（今どう思っているかを書く）

備考：（必要なら必要なだけ書く。必要ないなら書かなくてもよい。）

例1（備考なし）：

* 作業：インストールを始めた
* 思っていること：ドキュメント通りに進めれば大丈夫だろう

例2：

* 作業：インストールが失敗した
* 思っていること：ドキュメントに手順が足りない？

備考：エラーメッセージは次の通り

```text
XXX is not found
```

必要なファイルが足りないのかなぁ。