search

cpprefjp / site

cpprefjpサイトのMarkdownソース
https://cpprefjp.github.io/
383 stars 157 forks source link

cpprefjpプロジェクトとしてスポンサーを受ける方法を検討したい #1116

Closed faithandbrave closed 11 months ago

faithandbrave commented 1 year ago

最近、私個人の作業に対するGitHub Sponsorsをはじめたのですが、「cpprefjp / boostjpプロジェクト自体のスポンサーになりたい」という連絡をいくつかいただいています (決まったわけでもないので具体的なことはオープンにできないのですが…)。

こういったお話は今後もでてくると思いますので、すぐ結論をだす必要はないですが、cpprefjpプロジェクトとしてスポンサーを募集し、コントリビューターの方々が報酬を得る環境作りもしていくことを考えたほうがよさそうです。

プロジェクトとして報酬を受取る選択肢はいくつかありそうです。

Open Source Collectiveもまだ調べきれていないですが、これが一番決めごとや追加作業が少なそうではあります。

それ以外の場合はとくに、問い合わせの窓口を作ったり、改めて企業と内々の話をしたりするための非公開の議論グループを作ったり、企業に実際に伺って話をしたり、報酬面をコントリビューターの方々と個別に相談したり、といったことが必要になるかと思います。

スポンサーシップの特典としては、以下のようなものが考えられます：

会社員をされている方などで副収入を得ることに不安のある方は、それはそれで相談に乗れることもあると思いますので (税理士さんも紹介できます)、個人的にでも連絡いただければと思います。

即座に具体的な議論を開始、といかずとも、情報収集 (似たような前例探しや、制度の調べものなど) からご協力いただきたいです。

faithandbrave commented 1 year ago

分配のあたりの仕組みが、まだよくわかっていません。

faithandbrave commented 1 year ago

boostjpの方もいっしょに考える必要があるかと思いますので、そちらへのコントリビューターにお知らせするためにも、そちらにもissueを立てておきました。

faithandbrave commented 1 year ago

分配についてですが、経費支払として、PayPalか銀行口座を指定して、都度または定期的にいくら支払う、ということができるようです。 なので、誰にいくら支払う、というのは自分たちでルールを決める必要があるのと、支払い対象の方には振込先を教えていただく必要がありそうです。

faithandbrave commented 1 year ago

cpprefjp / boostjpのお金の使いみち : 以前まで

以前まではmelponがMarkdown → HTMLの変換サーバーをレンタルするのにかかっていた費用がありました。

いまはGitHub Actionsを使っているので、お金はかかっていません (melponのサーバーレンタル代は、私のポケットマネーから毎年3万円くらい渡していました)。

cpprefjp / boostjpのお金の使いみち : これから

オプションをどこまで入れるかで、人件費の割合が減ります。

私の考えとしては、ひとまず90%ほどを人件費として支払って、残り10%をオプションのためにプールしておき、新規コントリビューターの方が入ってきたらひとまずそこから支払う、というのがいいのかなと思いました。 プールしているお金からの使用は、issueで随時提案を上げる形で。

人件費の算出

スポンサーのお金がどれくらい入ってくるかはわかりませんが (一人あたり数百円かもしれないし、数千円かもしれない)、毎月定額を支払うか、1年に1回まとめて支払うか、のどちらかがよいだろうなと考えています。

毎月入ってくる金額が変動すると、受け取る方が使用計画を立てにくくなってしまうのと、確定申告などがめんどうになるからです。 毎月定額の場合に懸念することは、新規コントリビューターの方が入ったときの計算し直しが発生するということです。

なので、経理的にラクなのは、1年に1回のまとめ払いですね。

どのような貢献にお金を支払うか

まず、報酬はいらない、という方への支払いは除外するとして (副業禁止の職業の方や、会社員で確定申告がめんどうという方など)。

https://github.com/cpprefjp/site/graphs/contributors?from=2022-01-01&to=2022-12-31&type=c

年間の貢献は上記のような指定でとれるので、コミット数か、AdditionsとDeletionsの合算値、のどちらかの、全体からのパーセンテージで決める、というのでどうでしょうか。

コミット数だと1コミットが大きい方が不利なので、個人的には「AdditionsとDeletionsの合算値」がいい気がしています。 ちなみに、cpprefjpとboostjpをいっしょにして、両方への貢献を合算したものを想定しています。

それをもとに、取り分を相談するissueを立てて、まず算出したパーセンテージを列挙し、

- @faithandbrave : 30%
- @tetsurom : 20%
- @onihusube : 10%
…

(上記の列挙は2022年の貢献度の上位3名に、てきとうなパーセンテージを割り当てた例です)

この中で期間内に連絡がとれない方と、辞退する方を除いて、再度パーセンテージを算出し、年間の支払額を決定する、というのでどうでしょうか。

onihusube commented 1 year ago

フロントエンドのところも対象にした方がいいかなと思いました（kunaiとcrsearch？）

寄付の規模が大きければ(だといいんですが）法人みたいなものを作ってもいいかもしれませんが、とりあえずは年一の個別支払いで良いと思います。

faithandbrave commented 1 year ago

対象リポジトリを追加しました。

貢献算出の対象リポジトリ

imageリポジトリはバイナリデータのため、貢献の算出がむずかしいので対象外。 kunai_configも小さいので対象外。

faithandbrave commented 1 year ago

報酬を受け取るコントリビューターの方に提出してほしいデータ

(ここは、実際に必要なデータを確認して、その都度、最低限必要な項目を求めます)

これらを、Googleフォームとかで提出していただき、支払い完了時に毎回破棄します。

onihusube commented 1 year ago

貢献度算出は難しいですね・・

悪いことを考えると、コミット数ベースだとコミットを細かくして貢献度向上を図れるし、AdditionsとDeletionsベースだと無意味に改行したり、無意味に行まとめたり、あるいはコミットを超えて追加と削除を無意味に繰り返したり・・・
と無限に悪い考えが浮かんできます。

コミット分割よりは無意味な行の追加/削除の方が見えやすいと思うので、AdditionsとDeletionsベースの方がいいでしょうか。

（無論そんなことする人居ないとは思ってますが

faithandbrave commented 1 year ago

寄付の規模は、恒久的なスポンサーというのはなかなか難しいので、1年間だけ月1,000円〜10,000円を支払う企業・個人が数件、というのが現実的な気がします。 最初の1年は集まるかもしれませんが。。。

オープンソースへの寄付というのが今後広まれば、もっとよくなる可能性はありますが。

faithandbrave commented 1 year ago

貢献度の算出は、一旦事例を探してみます。

ただ、新規ページの執筆だけでなく、修正もけっこう大変なので、修正も高く評価したい気持ちはあります。

私は全体を見てるため、スクリプトを書いて全体を一括変換、というのをたまにやるので、それでAdditions + Deletionsがかさ増しされやすいのはよくないな、と思ってます。

onihusube commented 1 year ago

予防的に考えると、無意味な行の追加・削除されるよりはコミット分割された方がコンテンツにダメージ少ないかもと思ったりも

akinomyoga commented 1 year ago

Additions/Deletions はコミット数よりは良いような気もしますが、無意味かどうかの判定って、無意味な行の追加・削除のような事は明らかだろうと思いますけれど、もっと実際的な場合でも結構グレーな所がある気がして線引が難しいような気がします。

後、簡単な項目を機械的に大量に処理して修正したようなものもカウントするのか? 例えば、ライブラリの対応バージョン確認などその気になれば自動化して、他の人を圧倒するコミット数 or 変更行数 みたいなことができてしまいそう。Qiita に定期的に(C++ WD が出るたび?)そういう C++ 記事が大量に生成されていますが…。下手にお金が絡むとそういう感じの人を呼び寄せないだろうか、というのは杞憂でしょうか。

他の可能性として、例えば、優先的な編集項目を運営側(?)が指定してそれを達成した数で決めるとかの方がはっきりしているし、何より直接的な益がある気がします。例えば TASK タグ の項目など? 数稼ぎでロークォリティーな修正を直 push されたりしても困るので PR 経由で解決したらカウントするなどの方が良いかも。

或いは、Hacktoberfest みたいにある一定以上の貢献した人全員にTシャツなどのグッズを配布、などにして傾斜をなくして広く浅くにするのもいいかもしれない。そうすれば無意味な編集を大量に行うモチベーションもなくなりますし、少数の人に金銭が払われるよりはコミュニティーとしての連帯感も出るかもしれない。

スポンサーの意向も確認したら他の良い案を出してくれるかもしれないor思いつくかもしれない。

(とここまで書いて、私の勝手な cpprefjp 理想像を投影しているだけの気がしてきました。。余り貢献もない癖に色々勝手に書いておりますが、最終的には @faithandbrave さんや他のコアメンバーの方が、cpprefjp の将来的なコミュニティーの形としてどのようなものを思い描くのかで決めていただくべきと思っています。)

faithandbrave commented 1 year ago

Revertのようなものは手作業で貢献をなかったことにするとして。 一番重要なことは、公平で、納得感があることだと思います。

一旦、集計の手間を考えずに、

を列挙して考えてみたほうがよさそうですね。

年間で高々1,000コミットほどでしょうから、最悪の場合でも手作業で集計できなくはないので、かんたんに集計できるようにすることは、一旦忘れましょう。

例としてはこんな感じでしょうか。

この形式でなくてもよいので、価値リストみたいなのを考えていきたいです。

チケット駆動開発のプラクティスとしては1チケット (タスクissue) は30分ほどで作業できる大きさで分割することで、作業の着手しやすさと、作業の評価がしやすくはなります。ただ現状、タスクをそこまで細かく分割できていないので、達成タスクの単純な数では評価しにくいですね。タスクの大きさによってポイントを振る、というのは検討の余地はありそうです。

このリポジトリは一般的なソフトウェア開発とは違うので、コントリビュートの評価として前例を見つけるのは難しいですね。なのでやはり自分たちで納得感あるものを考えることになると思います。

ここで意見をくださる方は、上で挙げた対象リポジトリで貢献されている方と、貢献の意思がある方 (潜在的なコントリビュータ) であれば歓迎します。貢献の大きさは関係なしで大丈夫です。むしろ、「こういう制度であればもっとやる気が出ます」というのがあれば言っていただければ。

お金の代わりにTシャツやステッカーなどの配布でもいいと思いますが、毎年追加でデザインする必要がでてきたりすると、それはそれで大変ではあります。ですが、デザイナーの確保なども含めて検討してよいと思います。

スポンサーの意向というのは、あまり考慮に入れたくない気はしてます。 スポンサーからのお金が労働の対価として十分ということにはならないでしょうから、我々が価値あると考えることを行い、それに価値あると考えたスポンサーがお金を出し、金額に見合った執筆要望を出すことができる、くらいで考えてよいかと思います。

faithandbrave commented 1 year ago

グッズは、オンデマンドで (オーダーがある都度) 作って発送してくれて、クーポンも発行できるサービスとかがあるといいですが…。 在庫管理も発送も、自前ではできるだけしたくないので…。

akinomyoga commented 1 year ago

年間で高々1,000コミットほどでしょうから、最悪の場合でも手作業で集計できなくはないので、かんたんに集計できるようにすることは、一旦忘れましょう。

例としてはこんな感じでしょうか。

  • typoの1件あたりの修正 (1pt)
  • リファレンス1ページ追加 (10pt)
  • 仕様変更にともなう1ページあたりの修正 (3〜5pt)
  • コンパイラの動作確認 (うーん、むずかしい)

この形式でなくてもよいので、価値リストみたいなのを考えていきたいです。

この方法は良さそうな気がします。手作業で集計するのは大変ですが、代わりに ChangeLog を作って普段から管理すれば集計も簡単になるし、貢献の可視化にもなるし良さそうな気がします (既にある分は手作業で集計しなければならないですが)。

評価を ChangeLog の項目で数えれば、本質的な変更を見ることになるので、無駄な削除・挿入による commit 数 or 変更行数水増しみたいなことも防げるし、逆にミス編集などで commit 数が嵩んでしまって申し訳ないみたいな葛藤もなくて個人的には気が楽な気がします。

コンパイラの動作確認は1回ごとにptをカウントするのではなくて、集計期間中の合計個数で割り当てることにする [例えば 1個3pt, 5個以上5pt, 20個以上10pt (最大) (← の pt は適当)] みたいな手もあるかもしれません。恐らく最初の1回が一番ハードルが高いので、最初が一番高くて、それ以降はもらえなくても良いという考えです。

グッズだと税金関係のことも気にしなくて良いかと思いましたが、代わりにデザインや在庫管理などの面で難があるのですね。確かにデザインが毎年同じという訳にはいかないですしね (というよりスポンサーからの支援金額の規模感を勘違いしていたかもです)。オンデマンドサービスはTシャツであればありそうですね。

faithandbrave commented 1 year ago

貢献リストを考えてみました。 こういったものに、Changelog集計用のタグ (例として [@faithandbrave:typo:2] 意味は @faithandbrave がtypoを2件修正) と、それぞれのポイントを考えていけばいいかなと。 一度ポイントを割り振ってしまえば、あとは貢献リストへの項目追加の際には、「xより難しく、yよりかんたんだからnポイント」のようなことがやりやすくなります。

Changelogとしては、先に例を挙げたタグ + 説明を書いていけばいいかなと。

typo修正のポイントについてですが、たとえば年間で1貢献以上してくれた方にはステッカー1枚のプレゼントは必ず行う最低保証みたいなものがあれば、「最初の貢献だけポイントを大きくする」のような条件付けをしなくてもいい気がしています。 それがあった上で、お金としての受け取りは辞退するのであれば、10円とか100円の受け取りのために、PayPalの設定などしなくて済むのかなと (ステッカーの発送先は連絡いただく必要がありますが)。

cpprefjp / boostjp貢献リスト

cpprefjp

site_generator / kunai / crsearch

boostjp

faithandbrave commented 1 year ago

ポイントの割り振りは苦手な領域ですが・・・ (だれかたたき台を作れるなら作ってほしい)、small / medium / largeで貢献度の高さの違いがあるうち、small (typoとかの軽微な修正) はそこそこ積み上げないとmedium相当にはならないようにはしたいです。

yumetodo commented 1 year ago

年間で高々1,000コミットほどでしょうから、最悪の場合でも手作業で集計できなくはないので、かんたんに集計できるようにすることは、一旦忘れましょう。

changelogベースのポイント制とするにしても、計算をしやすくすることを考えると、現状直接masterにcommitしてますが、PR駆動にしてラベルを付けておいたほうがいいという説がありませんか・・・。

もちろんセルフマージ可とします

yumetodo commented 1 year ago

貢献の中身として、誤ったリンクの修正も上げておきたいですね (ex. #942 )

faithandbrave commented 1 year ago

Pull Requestベースの開発に移行するのは、このリポジトリでは難しいかと思います。 一般的なソフトウェア開発とは違ってWikiのようなものなので、ある程度のコミットの気軽さが必要だと考えています。

毎回ブランチを作ってPull Requestを出す、というのは作業のハードルが上がって、作業者の減少が懸念されます。 集計のしやすさのために、そういった作業体制の根本見直しのようなことはしたくないですね。

集計の際に、どのコミットに対するものなのかは追跡できるようにしようと思うのと、集計に対しても一定の修正要望をだせる期間を設けるつもりなので、そこで集計から漏れてしまうことはある程度防げるかと思います。

faithandbrave commented 1 year ago

リンクの修正も何段階かあると思うので、

こういった感じですかね。

既存の枠に収まらない作業も今後でてくるとは思うので、それはこまめに集計していくたびに、当てはまる貢献がないものはポイント含めて提案・修正していくことになるかと思います。

akinomyoga commented 1 year ago

Changelog で管理するという案は当該 commit で一緒に Changelog も編集することを想定していました。対応 commit の追跡が必要になるのであれば一応 blame でできそうな気がしますが、複数 commit で一つの Changelog 項目などの時に駄目ですね。

でもそもそも Changelog にした時に対応 commit を記録・追跡する必要があるのでしょうか? Changelog を提案したのは変更履歴をラベルなどメタデータ化して管理云々みたいな目的ではなくて、ポイント項目をリアルタイムに管理して後の《労力を減らす》ためでした。ポイント集計を Changelog 方式にしなければそもそも記録する予定もなかった情報を、敢えて労力を割いて記録しなくてもいいのではという気がします。

あーでも、最後に Changelog 項目の対応 commit を手で検証するということでしょうか。だとすると、結局最後に集計するのと労力は余り変わらないというか、寧ろ労力が増えてしまいそうな気がするので、提案した身ではありますが Changelog はなくても大丈夫と思います。

或いは別の方式は、Changelog 専用の PR を一つ常時 open にしておいて、master に commits を push すると共に、Changelog 専用の PR branch に各自(或いは気づいた他の人が)項目 / commit id を追加する。ポイントの割当の細かい規則や、項目の内容に対する異議はその PR の上で議論する。集計時に Changelog を確定して、squash して (しなくても良いけれど) master にマージする。release-please bot の半手動みたいな。そういうのも良いかもしれません。

yumetodo commented 1 year ago

まあ確かにPR駆動にはデメリットが大きいのはそうなので、やってみてからうまくいかなかったら改めて考えれば済む話なのかもしれませんね。

faithandbrave commented 1 year ago

Changelogというか貢献の年間レポートを、公平性・透明性を確保しつつ、私が手作業で作ることを想定していました。 こまめにやるか、年に一度まとめてやるかは、私の裁量にまかせてもらいたいところではありますが、確定申告をするようなものだと思うので労力としてはそんなに気にしなくていいレベルかなとは思います。

その貢献の年間レポートをどこに置くかは悩ましいところではありますが (本リポジトリか、Wikiか、別リポジトリを作るか)、Webサイト上で貢献レポートに名前が載るとうれしいかなとも思うので、本リポジトリでいいかもしれません。

faithandbrave commented 1 year ago

本リポジトリでやるなら、 @akinomyoga さんがおっしゃるように、専用PRを作ってだれでも追加コミットでき、最後にまとめてSquash Mergeでいい気がします (force push禁止)。

faithandbrave commented 1 year ago

貢献に含めることが難しいものとして、「issue / Pull Request上の議論への参加」があるかと思います。 「1回以上の発言でNポイント」とか「M回発言したからN*Mポイント」とかの選択肢は考えられはしますが、コメントの価値を評価するのはむずかしいのと、コメントは外部の方でもできるため集計・連絡がむずかしいのと、実作業のみを貢献にしたい気持ちがあります。

faithandbrave commented 1 year ago

ひとまずOpen Collectiveに申請してみます！ 残り議論すべきものとしては、以下があるかと思います。

  1. 各貢献に対する具体的なポイント

  2. スポンサーシップの制度内容 (スポンサーになってくださる個人・企業向けの制度)

    1.についてはPull Requestベースで相談しながらポイントを調整するのがいいかなと思っています。 2.は一旦Open Collectiveの申請が通って、そのシステムを触ってみてから具体案を出そうかと思います。

faithandbrave commented 1 year ago

Open Collectiveのプロジェクトが承認されました。いろいろいじってみます。 https://opencollective.com/cpprefjp

faithandbrave commented 1 year ago

Open Collectiveですが、貢献・寄付のプランを設定できるのですが、中身は以下のようになっていて、

・頻度 (月ごと、年ごと、一度だけ) ・金額 (USDのみ)

これで決まったプランで支援いただくほかに、Flexibleというのがあって、支援内容をユーザーが任意に設定できるものがあります。

これらを見て考えたのですが、以下のようにするのはどうでしょう。

Open Collectiveの支援プランとしては、上記の枠に収まる月額プランを提示し、Flexibleにも対応できるよう条件付けをしておきます。

faithandbrave commented 1 year ago

支援金額によるスポンサーランクですが、日本円で考えると月額1万円 x 12ヶ月が現在のレートでドル換算で905ドルになってしまうので、以下のようにしましょう。

日本円ベースで随時見直します (潜在的なスポンサーから連絡があったときとかに)。

それとスポンサーの問い合わせですが、Open Collective上で問い合わせができるので、それで受けます。

faithandbrave commented 1 year ago

https://opencollective.com/cpprefjp

一旦、支援を受ける場所は準備ができました。 このページへのリンクをトップページに記載しておきます。

分配については、後ほどPull Requestをだします。

faithandbrave commented 1 year ago

日本円ベースでゴールドスポンサーが10万円程度に収まるように調整しました。

faithandbrave commented 1 year ago

Acerola Software社様にスポンサーになっていただきました。 https://opencollective.com/acerola

現在、掲載するロゴ画像について問い合わせ中です。 今後、スポンサーに関する仕組み作りが一通りおわってこのissueを閉じたあと、スポンサーの新たな動向があったら都度issueを立てて (すぐ閉じる) お知らせします。

faithandbrave commented 1 year ago

スポンサーロゴの表示ができました。 表示サイズの希望はないとのことでしたので、幅400pxで表示しています。

いまは一社だけなのでスポンサーランクを記載していないですが、スポンサーが増えてきたら記載します。

https://cpprefjp.github.io/

faithandbrave commented 1 year ago

Fixstars社様にスポンサーになっていただきました。 https://opencollective.com/fixstars

こちらも表示するスポンサーロゴについて問い合わせ中です。

faithandbrave commented 1 year ago

Fixstars様のスポンサーロゴを表示しました。 この表示で問題ないとのことです。

faithandbrave commented 1 year ago

とある企業様から、手数料がかからず振り込める方法を検討してほしいと連絡がありました。 Open Collectiveは10%、GitHub Sponsors (のOrganizationでのスポンサー募集) は6%の手数料がかかります。

やはり団体口座はもっておいた方が、いろいろな企業様に柔軟に対応できるかと思いますので、人格なき社団を作って団体口座を用意しようと思います。 それと、私個人に連絡がきてしまうのもコミュニティになりきれていないところだと思うので、管理者のGoogle Groupを作って、そのメールアドレスでも問い合わせを受け付けるようにもしようかと思います。

faithandbrave commented 1 year ago

口座は引き続き準備中です (任意団体の口座は審査落ちしたので、私の個人事業主の屋号付き口座として準備中)。

確定申告に合わせる必要があって12月中に分配を済ませたいので、1月から11月中までの作業を集計して分配率を決定とさせてください。。。 作業の集計方法も急ぎでまとめてPRを出します。

faithandbrave commented 1 year ago

私の個人事業主の屋号付き口座として、cpprefjpの口座を用意しました。名義は「cpprefjp高橋晶」となります。 銀行振込を希望されるスポンサーの方には、こちらをご案内しようと思います。

口座番号は非公開にしようと思います。 理由としては、突然振り込まれても困るのと、スポンサー画像を掲載する関係でスポンサー様と連絡をとってから振り込んでいただきたいからです。

口座には、私のポケットマネーで10,000円入れてありますが、これは使わない予定で、これを除いた残高をOpen Collectiveの説明文章に記載していこうと思います。ちなみに口座は利子がつかない全額補償の普通預金口座となります。

続いて、問い合わせ窓口としての管理者が入ったGoogle Groupを作成して、cpprefjpのトップページおよびOpen Collectiveの説明文章に記載します。

faithandbrave commented 1 year ago

Google Groupを作成し、銀行振込と問い合わせ窓口に関して、トップページとOpen Collectiveのページに記載しました。

faithandbrave commented 1 year ago

お金の分配の方法を調べました。

Open Collectiveでは、コントリビューターの方にOpen Collectiveのアカウントを作っていただき、以下のページからcpprefjp宛に指定の金額で請求書を発行していただく感じになりそうです。

https://opencollective.com/cpprefjp

その上でcpprefjp側が請求書を承認すれば、ご指定の銀行口座かPayPalに入金されるようです。 一度テストしてみたいので、私のアカウントでcpprefjpの$1スポンサーになって、そのお金を私の口座に支払ってみようと思います。換算レートの関係でcpprefjpに多少のマイナスになってしまったらごめんなさい。。。

faithandbrave commented 1 year ago

Open Collectiveでの経費申請の方法も、以下のPull Requestでまとめました。

faithandbrave commented 1 year ago

それとコントリビューターの方々へのステッカーの配布ですが、今年に限り、2023年までの全期間のどこかでcpprefjp / boostjpに貢献いただいた方にお配りしようと思います。 ステッカー作成はロゴの新デザインが上がってきたら話を進めようと思います。

faithandbrave commented 1 year ago

Open Collectiveからお金を受け取るのに四苦八苦しています。 請求書のフォーマットはできて銀行振込で送金もされたのですが、「5.0$の送金だと手数料の方が高くなってしまうので差し戻します」と私の銀行から連絡がありました。 銀行振込は少額振り込みについては、よろしくなさそうです。

銀行振込だと、一回の海外送金受け取りごとに、以下の2つがかかってしまいます。

PayPalだと、以下の2つがかかります。

この対策としては、以下の2つのどちらかが考えられます。

  1. 報酬の受け取り金額の下限を6$以上として、それ未満になる方は自動的に報酬の受け取りを辞退いただく (Open Collectiveでの支払い方法は銀行振込ではなくPayPalを選択してもらう)
  2. Open Collectiveからcpprefjpの銀行口座に一旦全額振り込んでから、cpprefjp側で銀行振り込み手数料を負担し (負担分として振込手数料275円x人数を、報酬分配金から除外する)、コントリビューターの方から申請フォームで入金先の情報を管理者宛に提出してもらう

どちらにしても手数料はかかりますが、2. のほうが少額は振り込めますね…。 それとOpen Collectiveだと請求書の審査で1〜2週間かかるので、年内に分配が完了するかは不透明な感じはします。cpprefjpの銀行口座に一旦振り込む場合だと、Open Collectiveでの請求書の審査はかかりますが一回でおわるので私の作業で完結するので、みなさんの申請が無事完了するかやきもきしなくて済むので安心感はあります。

なので私としては2. の「Open Collectiveからcpprefjpの銀行口座に一旦振り込んでから申請フォームベースで銀行振込としてみなさんに分配する」がいい気がします。 ただ、私たち管理者がみなさんの個人情報を受け取ることになるので (分配がおわったら破棄しますが)、そのような懸念からこの方法を避けたい、というようなことがあれば教えてください。

faithandbrave commented 1 year ago

スポンサーになるメリットとして、「シルバースポンサー以上の方は、cpprefjp/siteのissueとして採用情報を投稿できる」というのを追加したいです。 その条件であればスポンサーになりたいという方がいたからです。 異論なければ数日中に追加します。

faithandbrave commented 1 year ago

「シルバースポンサー以上の方は、cpprefjp/siteのissueとして採用情報を投稿できる」というのを追加したいです。

こちら、トップページ、およびOpen Collectiveのページで対応しておきました。

faithandbrave commented 11 months ago

スポンサーシップの仕組み作りがなんとかできて、分配までできました。 このissueはクローズして、あとは個別の問題改善としていこうと思います。