How Should a Research Software Engineer in Spain Combine Papers, Datasets, Code, and Demos?
A research software engineer should create one project entry per coherent research system, explain their exact engineering contribution, and link the artifact that best supports that claim: paper, repository, dataset, documentation, or demo.
A publication list records citations and authors, while a repository records code; neither necessarily explains who built the pipeline, interface, package, or reproducibility tooling. A portfolio should join those facts without overstating the contribution.
What counts as one research-software project?
Treat a coherent tool, model implementation, dataset pipeline, or interactive research system as one project even when its evidence lives in several repositories and publications.
Name the research question at a safe level and describe the engineering boundary you owned. Separate scientific authorship, software contribution, maintenance, and data stewardship instead of blending them into a vague team claim.
A paper replication or lab utility can be included when your contribution is substantial and permitted. Course exercises and unmodified forks should not displace original maintained work.
- Paper: supports the research context and authorship record.
- Repository: supports public implementation work.
- Dataset: supports an authorised data release.
- Demo: supports a usable or interactive result.
What is the fast way to organise research work with IndieShow?
The fast way is to create one IndieShow card per coherent system, label its discipline, and group completed, active, and retired research software by status.
Use the description for the problem, your contribution, and the relationship between paper and code. Choose one primary destination; that page can point to secondary artifacts when you control it.
Order projects for the audience: an applied research role may value a working system first, while a software-maintenance role may value a documented package.
Build your IndieShow pageClaim your handle, organise the projects in the editor, then review the $15 one-year and $30 lifetime publishing options in the dashboard.
Should the paper, dataset, repository, and demo be separate cards?
Keep them together when they are outputs of one research system, and split them only when an artifact became an independently maintained product with its own users and purpose.
Four cards for one project make the reader reconstruct the relationship. One strong entry can name the paper and explain whether the destination is the code, dataset, or demonstration.
A library reused beyond the original study can stand alone if its maintenance and contribution story are distinct. Do not duplicate it merely to expose every hosting platform.
How do you avoid overstating reproducibility or research credit?
State exactly what is public, what can be run, what you contributed, and which limitations remain instead of describing any repository as fully reproducible by default.
Check licences and data permissions before linking. Never publish restricted datasets, participant information, credentials, or unpublished review material to make the card look complete.
For related patterns, the IndieShow guides below cover open-source maintenance and technical explanation across multiple artifacts.
Related IndieShow guides: presenting maintained open-source work · connecting documentation and code
How does IndieShow help a research software portfolio?
IndieShow turns fragmented institutional and technical records into one maintained index without replacing the paper, repository, dataset, or demo as the source of truth.
Update a link when a lab page moves, mark discontinued prototypes Archived, and keep current maintained work first. Use an optional metric only for a factual figure you can support.
The result is one IndieShow URL that lets a reviewer understand the engineering contribution before opening the specialist evidence.
Frequently asked questions
What counts as one research-software project?
Treat a coherent tool, model implementation, dataset pipeline, or interactive research system as one project even when its evidence lives in several repositories and publications.
What is the fast way to organise research work with IndieShow?
The fast way is to create one IndieShow card per coherent system, label its discipline, and group completed, active, and retired research software by status.
Should the paper, dataset, repository, and demo be separate cards?
Keep them together when they are outputs of one research system, and split them only when an artifact became an independently maintained product with its own users and purpose.
How do you avoid overstating reproducibility or research credit?
State exactly what is public, what can be run, what you contributed, and which limitations remain instead of describing any repository as fully reproducible by default.
How does IndieShow help a research software portfolio?
IndieShow turns fragmented institutional and technical records into one maintained index without replacing the paper, repository, dataset, or demo as the source of truth.