Plan for populating material

Session 1: Where, why, how

• Setting the scene: Why publish software as an article?

  • Value of software papers in academic careers (citations, recognition, tenure/promotion) (Di)
    • Show a couple with citations and uptake? https://www.jstatsoft.org/article/view/v059i10, https://www.jstatsoft.org/article/view/v040i01 (Di)
  • Benefits for the community (visibility, credibility, discoverability).
    • How to cite software, why? (Di)
  • Why is a paper better than supplementary material for a regular paper? (Di)
  • Common outlets for publishing software:
    • Journal of Statistical Software (Di)
    • the R Journal (Di)
    • Journal of Open Source Software (Di)
    • Genome Biology (Di)
    • Methods of Ecology and Evolution (Fonti)
    • Any others ??
    • Similarities and differences and metrics (Di)
    • Review criteria (Di)

• Writing the article (Di)

  • Problem statement and motivation: why did you write the software? What is special and why others should use it? Why existing tools don't do the job? Putting your work in the context of existing software
  • Key features of the software
  • Design/implementation details
  • Overview of workflow
  • Examples/use cases/applications/speed comparisons/benchmarking
  • Handling big data, or private data.
  • Handling slow computation/reproducibility.
  • Tips for figures.
  • Reproducibility of your article.
  • Writing a cover letter.

What activities to do in this session? (Fonti)

Session 2: Prepare to write your article

• Small group activity: Review some examples of articles of published software (Fonti)

  • Structure
  • Motivation
  • Functionality
  • Usefulness in getting started

• Preparing Your Software for Publication

  • Open source practices (Fonti)
    • Version control, zenodo/DOI, GitHub releases (Fonti)
  • Minimum standards: clear documentation, license, installation instructions, tests, example data. (Fonti)
  • Writing a good README (Fonti)
  • The submission process (journal-specific requirements) (Di)
  • Responding to reviewer comments—common issues (docs not clear, lack of tests). (Di)

• Hands-on activity:

  • Draft a short abstract for your own software.
  • Sketch an outline for an article on your own software.
  • Identify a target journal.

Start with the two-session outline in the issue and turn its listed topics into a concrete plan for workshop material and activities. The issue does not name a target file, format, or existing tests; done means the sessions have populated content, defined activities, and resolved open questions such as additional journals and review criteria.