コントリビュートしやすい作業を掲載したい

[faithandbrave]

いまこのリポジトリに貢献しやすい作業としてはtypoの修正がありますが、ほかにも手が回っていない編集しやすい項目はいくつかあります。 それをWebサイトの見やすいところに書いておくのはどうかなと思いました。

私が思いついたところでは、以下の項目が規格を見る必要なく編集しやすいかなと思いました。

• 誤字・脱字の修正
• 動作確認できたコンパイラバージョンの記載
• サンプルコードの追加
• 関連項目の追加

ほかにもあったら教えていただきたいのと、方針自体へのコメントもいただきたいです。

[onihusube]

LWG/CWG Issueの適用・・・はハードル高いでしょうか

[faithandbrave]

「規格案を追える方はissueとWikiに未完了のタスクがあるので、どんどん引き取ってください」 みたいに書いておきましょうか。

↑に挙げたのは、個別issueを立てるほどでもなく、しかし永遠になくならないであろう継続タスクですね。

[faithandbrave]

サンプルコードを追加しやすいように、いま以下のようになっている見出しレベルを、

## 例
### 出力

以下のように全体的に直さないと…。

## 例
### 基本的な使い方
#### 出力

[yohhoy]

• 誤字・脱字の修正
• 動作確認できたコンパイラバージョンの記載

参加(contribute)への手軽さを基準に考えると、まずは上記2点を推すのが良いのではないでしょうか。 特に動作確認バージョン記載はとにかく人手を要する作業ですし、訪問ユーザへの利便性向上にもつながると思います。

ライブラリリファレンスとして良質なサンプルコードを生み出すのは労力を要しますし、cpprefjpサイト執筆に慣れてないと関連項目の追加は少し敷居が高いように感じています。 というのもこの2点はどこまで書けば良いかが自明でなく、作業者によって記述の幅・深度がばらつくことが予想されるため、最初の参加項目としてはちょっと推奨しずらいかなと思いました。 （もちろん参加してもらうこと自体はWelcomeですが、ちょっとだけハードル高めかもという意見です）

[faithandbrave]

そうですね。 編集難易度みたいなもので段階的にどういう作業があるかを示せるといい気もします。

良質なサンプルコードを作るのが大変なのはそうなのですが、そういう貢献の仕方があるというのが現状あまり気づいてもらえていない気もしているので (1例でおわりと考えられている)、不足していると感じたら足してもいい、ということは知ってもらいたいなと。

[faithandbrave]

せっかくPull Requestがきたものをお断りするのも心苦しいので、サンプルコードの追加は、要件みたいなものを考えないといけない気はしてます。

[yohhoy]

せっかくPull Requestがきたものをお断りするのも心苦しい

はい。まさにこの手のトラブル未遂を懸念してのコメントでした。

サンプルコードの追加は、要件みたいなものを考えないといけない気はしてます。

方針には賛同です。が、言語化が難しいですね... 固く表現すると「既存サンプルコードとは異なるユースケースや、異なる観点を与えるものであれば追加歓迎」とかでしょうか。

[faithandbrave]

固く表現すると「既存サンプルコードとは異なるユースケースや、異なる観点を与えるものであれば追加歓迎」とかでしょうか。

そうですね。あとは「特殊な状況を除き、プラットフォーム非依存のコードであること」とかですかね。native_handleとかが特殊な状況です。「標準の範囲内でその機能の有用性を説明しにくい場合を除き、プラットフォーム非依存のコードであること」かな。

[yumetodo]

動作確認できたコンパイラバージョンの記載

これは手順をマニュアル化できる気がするので、マニュアル化すると参加しやすくなる可能性があるかもと思いつつ、そのマニュアルを書く時間が取れないですね・・・

[yumetodo]

あとはC標準ライブラリの範囲やC++のstream周り記事を宣言だけひたすら規格書からコピペしてくる作業・・・とかも思いましたが規格書を読んで貰う必要がある時点で簡単ではないですね・・・。スタブ記事量産がどうなのって話もありますし。

[faithandbrave]

Pull Requestベースで相談したほうが話が進みやすい気がするので、書きます！ 要件を作るのがむずかしいものは、納得できそうなものが書けなかったら (一時) 断念しましょう。

@yumetodo コンパイラバージョン記載のマニュアルは、どういうものを想定していますか？

[yumetodo]

要するにコンパイラが対応する提案文章のサポート宣言を出していること、記事中のサンプルコードがすべてビルドできればいいと思うので、その手順とコンパイラフラグの調整方法(-std=//std:, /permissive-など?)がコンパイラごとにかかれている感じを想定していました。

ただ考え直すと、提案文章を見つけに行くのが地味に大変かもしれないですね・・・

[faithandbrave]

なるほど。yumetodoさんが想定しているのは、言語機能の対応コンパイラバージョンですかね。 現状で言語機能の対応コンパイラバージョンは、そこまで厳密な検証は行っていないので、新規参加者向けとしては少なくともできないですね。

個別の言語機能ページに対応コンパイラバージョンや対応状況の詳細を記載するところは今ないですし、このissueでの新規参加者が引き取りやすいタスクとは別な問題かなと思います。

私が「動作確認できたコンパイラバージョンの記載」と書いたのは、ライブラリリファレンスの方で、記載されているサンプルコードが動作したコンパイラのバージョンを、以下の項目に記載してくことをイメージしていました。

## 処理系
### バージョン
- [Clang](/implementation.md#clang):
- [GCC](/implementation.md#gcc):
- [Visual C++](/implementation.md#visual_cpp):

ライブラリ機能のリファレンスは、コンパイラが実装する前から書かれていることがあるので、実際にコンパイラが実装したあとの、動作確認をしての情報更新が行われていない場合があります。

その動作確認と情報更新は比較的シンプルな作業なので、新規参加者にお願いしやすいかなと思ってます。

[faithandbrave]

ひとまず、ディレクトリ整理として「cpprefjpを編集するには」をサイドバーに表示されるように置きました。 https://cpprefjp.github.io/start_editing.html

[faithandbrave]

• 1104

Pull Requestを作りました。そちらで相談して形にしていきましょう。