[Feature]: last-edited dates on instruction pages
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 48/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- html
調査の方向性
https://intel.github.io/SDM/sdm.html?instr=ADDSS の命令ページから始め、そのコンテンツが intel/SDM リポジトリからどのように生成されているかを調べます。実質的なドキュメント変更と CSS の編集や誤字修正をどのように区別できるかを判断し、そのうえで、結果として得られる日付を各ページにどのように表示するかを定義します。完了条件は、命令ページに、実質的なコンテンツ変更を反映した意味のある最終編集日が表示されることです。
索引モデルが issue の本文から書いたものです。
説明
Feature Description
on a page like https://intel.github.io/SDM/sdm.html?instr=ADDSS, it would be great to have a date for the last time the content on the page was substantially changed. CSS changes of course are probably not interesting, fixing a typo might be, and fixing a bug in an instruction's description probably is!
Why Is This Needed?
intel.github.io is a more authoritative source than something like (the loved and appreciated!) docs at https://www.felixcloutier.com/x86/xadd - I know Félix's site is best effort and every page says as much in the footer. if I'm doing something interesting I historically might have started at that site, fetched a fresh copy of the SDM, and noted which revision of the SDM I was working from.
importantly, I may quote parts of the SDM as explanatory prose in a system I'm working on, and I include the version of the SDM I'm working to help later readers find (or explain the lack of) the quoted passage. quoting intel.github.io is different, since clearly it is not a document one can download, but it is a git repo one can easily fetch the history of. thinking through how I would quote intel.github.io, I would probably include a note like "as of Sept 4, 2026", and know that later I should check the page at that date and potentially update the date to the next time I've verified the docs match the reasoning I'm working with.
a "last updated" date on the page itself helps short-circuit all of this: a git edit date does not immediately indicate if the substantive content has changed in the same way an intentional date describing the encoding rules, description, operation, exceptions, etc would. at that point I wouldn't feel a need to cite either a specific rev of github.com/intel/SDM or corresponding SDM version. in the ideal world, and tragically, I'll stop having an accurate collection of every SDM revision.... alas.
I realize maintaining such a date would be a little complicated, and I don't have great ideas there, sorry! :)
- 主要言語
- HTML
- スター
- 66
- フォーク
- 5
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
intel/SDM のほかの issue
-
SDM PDF issue
難易度 1/5 1〜3時間 初心者へのやさしさ 72/100
-
SDM PDF issue
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
SDM PDF issue
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
SDM PDF issue
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
SDM PDF issue SDM Volume 1
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
streamlink/streamlink#7192 · コメント 4 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
aws-samples/sample-per-model-bedrock#795 ·
メンテナーはふだん 1 日以内に返信
-
documentation easy good first issue help wanted
難易度 1/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信