cpprefjp
報酬の分配制度を見直す
2024年の分配が完了したので、2025年に向けて分配制度の見直しをしようかと思います。
改善したいところ、変更したいところなどありましたらコメントをください。
ひとまずは、 @yohhoy さんからコメントがあった以下の点：
手間を増やさないようポイント計上自体は現行通りで実施し、生のpointsに対して対数関数(log)的な圧縮をおこなってrateへ換算するという程度のイメージでした。
typo修正とかの小さい修正をされた方にもある程度の報酬を配るために、ポイントの差を小さくしたいという話がでています。 こちらは、私としてはがんばった人により報われてほしいという考えがあったためネガティブでした。しかし2024年に @akinomyoga さんがポイントの譲渡をしたところ、報酬受け取りの申請が活発になり作業者のモチベーションにつながった気がしているので、改善として入れてもいい気がしています。
ポイントが大きい人にとっては報酬の割合が減ることになるので、長めの時間をとっての合意が必要になると思いますが、私はアリだと思います。
具体的にこれくらいにしたいとか、計算式とかあれば教えていただきたいです (昨年までのポイントの表はありますので、それを元にどれくらいの値に変換したいか)。
ほかのこととして、私はboostjpをいつまで続けるかというのをずっと考えてます。
最近はリリースノート翻訳くらいしかしてないですが、作業としてはChatGPTでルールに沿って翻訳してちょっと手直ししてるくらいです。私しかやってないのでタスクissueも作れてないです (1〜2時間で全部おわるので、タスクissueを立てるほうが大変)。
Boostは衰退していっていますが、将来のC++や経緯を考えるのに有用性はまだあるのと、運営がBoost FoundationからC++ Allianceに移行したことによって再起する可能性もあって、まだまだむずかしい時期ではあります。
Boost逆引きリファレンスの古くなったものはそろそろ削除していきたい気持ちもあります。
あとは、標準ライブラリと比較してBoostにしかできないことをまとめてもいい気はします (たとえば、Boost.Containerのvectorは未初期化のresizeができるとか、static_vectorがあるとか)。
私は pt に対して変換をするのではなくて、「その年に一回でも貢献していたら XX pt 追加」のような報酬を用意するものがあったらいいなと思っていました。他にも初心者向けに「〇〇したら YY pt 追加」のような項目を複数用意してもいいかもしれません。後、報酬が少ないからわざわざもらう気にならないっていうこともあるかもなので、上限付き (100pt とか) で次の年への pt 自動持ち越し制度を作ってもいいのではとも思いました
pt に対して変換をする方式の場合、log(pt) だと強すぎるかなって気がします。例えば 1000 pt の人と 1万pt の人で報酬が 3:4 しか違わないというのは微妙な気がします。あと log だと 1pt の人が報酬 0 になってしまいます (元の提案は log 的 な関数ってことだったので log そのままの意図ではなかったでしょうが)。変換を入れるとしたら pow(pt, alpha) (0.0 < alpha < 1.0) という関数形も選択肢の一つとしてありそうです。
年間ポイントの下限を作るのであれば、ポイント決め打ちよりは、「1%以上保証」とかでもいいかもしれませんね。 全体の報酬が100,000円だったら1,000円になります (実際は手数料を引くことになりますが)。 こうする際の問題は、年間100人以上のコントリビュートがあると破綻してしまうことですが、パーセンテージは年によって変えてもよいと思いますので。
ポイントの次年持ち越しは、人によってアクティブな年、非アクティブな年があると思いますので、とくにコントリビュートした年以外は完全に忘れてしまっていて通知も切っているかもしれません。 これを想定すると、多少の少額であっても (下限保証があれば) コントリビュートした年に渡して・受け取ってしまった方が鮮度があってよい気がします。 忘れ去られた人の次年繰り越しをずっと続けるのも作業負担になりますし。。。
pt に対して変換をする方式の場合、log(pt) だと強すぎるかなって気がします。例えば 1000 pt の人と 1万pt の人で報酬が 3:4 しか違わないというのは微妙な気がします。あと log だと 1pt の人が報酬 0 になってしまいます (元の提案は log 的 な関数ってことだったので log そのままの意図ではなかったでしょうが)。
仰る通り「logっぽい操作」程度の雑なニュアンスでコメントしておりました。
本件に対する私(yohhoy)の考えは下記のようなものです：
- せっかくの原資なので、多数の参加者（特に新規参入者）への動機付けになってほしい。
- 生の貢献ポイントだとロングテール分布になり（過去も、おそらく今後も）ため、上記対象者への絶対的な分配量が微小になるのは残念。
- 上位貢献者にとっても激しい傾斜により単純換算されると、後ろめたい気持ちや面倒さが生じることもある。動機はひとそれぞれですし。
- 複雑なルールを導入・運営するのは負担になるため、公開された計算式で圧縮してしまうのがベターなのではないか。
上限付き (100pt とか) で次の年への pt 自動持ち越し制度を作ってもいいのではとも思いました
ポイント持ち越し制度へは、反対の立場です。運用コスト増は極力避けるべきと思います。
とりあえず、たたき台のポイント変換プログラムを用意しました。 https://wandbox.org/permlink/So8Kw2fAQhtCByJ8
これのconvert_point関数の変更案をだしてもらえると話がスムーズに進むかなと思います。
いまは単にlog関数を適用して、結果がゼロになったら1を返すようにしてあります。
別件として、全体をスクリプトで一括変換するような修正の場合、fixsの2ポイントに割り当てたとしても、かんたんに数千ポイントを稼げてしまいます。 私はポイントを減らしてるので問題になっていないですが、荒稼ぎが行われた際には、そのときの事情に合わせて「この作業はページごとにポイントをつけるのではなく、全体でNポイントにする」という対応をすることも必要かと思ってます。
問題が起きてないのに考えすぎても仕方ないので、いまは「荒稼ぎがあったら是正する予定」という話があることだけ共有しておきたいです。
pow(p, 0.36)はわりとよさそうな感じがします。
https://wandbox.org/permlink/3guV3U93BzTM0iBS
- https://github.com/cpprefjp/site/issues/1366
私とyohhoyさんのポイントが大きく減って、2024年にポイントを減らして受け取ったくらいのパーセンテージになり、1ポイントの人も1,000円くらいは受け取れます (去年の報酬総額では)。
自分としては
- 持ち越しは反対: 運用コスト以前にそもそも税務上の取り扱いが不明瞭になりそうなため
- 補正の関数についてはノーコメント
- そこまでたくさん貢献できてないので・・・
- 多数の参加者（特に新規参入者）への動機付けになってほしい気持ちとたくさん貢献されている方がたくさんもらってほしい気持ちのバランスがどうすれば取れるのか・・・。
- この点については、近視眼的には不利益を受けることになる、特に継続的な貢献上位陣の皆様の納得が大事かなと思うので @suomesta @onihusube さんあたりの意見も伺いたいです
1ポイントの人でもある程度の額を受け取れるようにする方式に賛成します。 求め方はpow()でもmin()でもどちらでも良いかな、と思います。個人的には、もし自分の貢献が多いとしても、pow()で特に問題があるとは感じません。（今のペースだと今年は私も最少額になってしまいそうなので、貢献がんばっていきます。）
年間ポイントの下限を作るのに賛成です そこまで貢献できていない私が言うのもなんですが、実際に初回貢献のハードルはあると思うのでそこへの配慮があって良さそうと思いました ネガティブとしては、初回貢献のみを狙う人が来るかもという懸念があるかもしれませんが たとえそういう人が貢献しに来たとしても、枯れ木も山の賑わいになるので、それはそれでありかなと、個人的には思います 年間ポイントの下限が年によって変動されるのも、全く違和感ないです とはいえ、貢献上位者の方との差はある程度あった方が良いと思います（貢献度が低い人の目線で考えた時、やはりそうあって欲しい。そうじゃないと下限額を受け取るのも申し訳ない。） 月並みなコメントですが、今年も頑張りたいです
長らく停滞してしまっていますが、結局のところ今年のポイントに適用してみないと納得感があるかわからない気がしました。 ひとまず、powを使ってよさそうな値にはなってきたので、年ごとにpowに与える定数を変えて調整し、調整された値で合意を得るプロセスを用意すればいい気がします。