reported_success back-filled with numeric junk from the main sheet's `outcome` column (43 rows)

オープン
  • 何か問題がありますか？
#132 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
64/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
r
領域
data-engineering

調査の方向性

prepare_fred.qmd:570 から始めて R/outcome_vocabulary.R を読み、その後パイプラインをレンダリングして invalid reported_success 警告を再現します。outcome の fallback をガードするか削除するかを判断し、valid な outcome ラベルと provenance 列を維持したまま、数値のゴミが生成されなくなったことを確認します。

索引モデルが issue の本文から書いたものです。

説明

Problem

prepare_fred.qmd:570 back-fills reported_success from the main FReD Google Sheet's outcome column:

reported_success = coalesce(reported_success, outcome),

That column does not contain outcome codes. Of its 3,109 non-NA values:

shape n
purely numeric (1×1018, 124×262, 10×183, 92×172, 31×102, 2×104, …) 2,256
#N/A (broken spreadsheet formula) 839
long free text (>60 chars, e.g. "independent predictors of forgiveness") 4
actual outcome labels 2 (one failed, one successful)

So wherever the COS success-coding join leaves reported_success empty, the pipeline substitutes an unrelated number.

Impact

A fresh render of prepare_fred.qmd (2026-07-25) produces 43 rows with numeric reported_success: 31×19, 12×12, 1×10, 124×2.

Affected fred_ids include all the XPHI* entries (XPHI1, XPHI9, XPHI17, XPHI18, XPHI20, XPHI21, XPHI24–XPHI27, XPHI29), additional_studies4/40/48/76/78/91, Boyce_etal2023137_1, Boyce_etal202368, CORE_147, curatescience23.

Note their reported_success_quote_source is populated correctly (abstract, https://osf.io/4ewkh, …), so only the code itself is wrong — the provenance columns are fine.

How it was found

The outcome-vocabulary normalisation added in 01d5e75 includes a check that warns when reported_success falls outside the 15 allowed values. It fired on the first fresh render:

⚠ reported_success values outside the allowed vocabulary: '1', '12', '124', '31'

This is pre-existing — the coalesce predates that commit. It did not show in the committed output/FReD.xlsx (last built 2026-02-01) because the source sheet has drifted since.

output/FReD.xlsx was not updated with the bad render; it remains at the 2026-02-01 build.

Options

  1. Guard the coalesce — only fall back to outcome when the value is in VALID_OUTCOMES (see R/outcome_vocabulary.R). The 43 rows become NA, which is honest; costs the 2 genuine labels unless they are re-coded at source.
  2. Drop the coalesce entirely — the column yields 2 usable values out of 3,109, so the fallback arguably has no value at all.
  3. Fix the source sheet — work out what the outcome column is actually holding (the numbers look like counts or IDs), rename it so it stops colliding with the outcome vocabulary, and repair the #N/A formula.

Option 1 or 2 unblocks re-rendering FReD; option 3 is the durable fix.

Also worth noting

A fresh render also changes the row count 2,164 → 2,036 and leaves 33 rows with no reported_success at all. That is ~6 months of upstream sheet drift rather than a bug, but it means the next FReD.xlsx refresh is a substantive data change that should be reviewed on its own.

主要言語
HTML
スター
1
フォーク
0
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

forrtproject/fred-data のほかの issue

forrtproject/fred-data の issue をすべて見る

似ている issue

Data Engineering の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。