{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiceqdq7gxdf37r7dyt7mvvvm3h55cslvbndv4falekpjihziztrvi",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mpnvmgxeilx2"
  },
  "path": "/t/how-to-publish-my-research-in-huggingface/177341#post_4",
  "publishedAt": "2026-07-02T10:37:33.000Z",
  "site": "https://discuss.huggingface.co",
  "textContent": "Yes, I would curate them rather than upload every checkpoint.\n\n* * *\n\nFor a public HF release, I would make the default path very clear:\n\n  1. publish only the checkpoint(s) that are actually usable out-of-the-box;\n  2. mark one as the recommended/current checkpoint;\n  3. keep failed or discarded checkpoints private unless they are important for reproducibility or ablations;\n  4. if you later want to publish historical/ablation checkpoints, put them in separate repos or an archive and link them from the model card/Collection.\n\n\n\nBy convention, HF model repos are usually easiest to understand when one repo corresponds to one main checkpoint or one clear release artifact. If there are multiple materially different variants, separate repos grouped in a Collection are usually clearer than one huge repo full of every training output.\n\nFor the first public release, I would optimize for “someone can download this and run it successfully” rather than “every experiment is preserved.” You can still summarize failed/discarded checkpoints in the README, for example as a small table:\n\ncheckpoint | status | reason\n---|---|---\n`tis-v1-recommended` | public/recommended | works out of the box\n`tis-v1-alt` | optional | useful comparison\n`old-run-042` | not published | failed / superseded\n\nIf any failed checkpoint is important evidence for the research story, I would publish it later as an archival artifact, not as part of the main user-facing model repo.",
  "title": "How to publish my research in HuggingFace?"
}