This organization collects the research, teaching, and administrative repositories of the HPC group at Hochschule Fulda – University of Applied Sciences.

All repositories sit side by side on one level. There are no nested folders or sub-organizations: the repository name and its GitHub topics carry all the structure, and both follow the rules below.

Notes on categories

• tool is for long-lived software that outlives any single paper (e.g., research tools, teaching systems). Paper-specific code belongs in artifact-*.
• workshop is for workshops we organize: CFP, website sources, program, and organizational material. Review content never goes into these repositories.
• infra is for configuration and deployment of systems we operate (teaching clusters, GPU servers, platforms for students).

The same rules apply to every identifier in this organization, whether repository name, topic, or slug:

• lowercase only
• words separated by hyphens; no spaces, no underscores
• short, descriptive, and stable over time

Keeping names this uniform makes them easy to filter, script against, and archive.

Categories

paper | artifact | benchmark | talk | poster | workshop | proposal | grant | tool | topic | teaching | infra | protocol | cv | travel | misc

<venue>: acronym of a conference or journal.

sc, isc, europar, ipdps, cluster, eurompi, ppam, wamta, tpds, jpdc, fgcs

<event>: any event code, including venue acronyms, workshops, and poster tracks.

sc, isc, europar, amte, pmbs, eesp, sc-src

<funding-org>: acronym of the funding body.

dfg, bmftr, hmwk, eu, hsf

<course>: course acronym as used internally.

pp, hpc, llm-agents

<semester>: ssYY (summer) or wsYY (winter).

ss26, ws26

<thesis>: thesis type.

ba, ma

<name>: first and last name.

jane-doe

<year>: two digits.

25, 26, 27

<date>: ISO 8601 (YYYY-MM-DD).

2026-11-04

<destination>: full city name, hyphenated; abbreviations only if globally unambiguous.

hamburg, st-louis, new-york, hong-kong

<slug>: a short, readable label for the specific content of the repository.

coll-tuning, adaptive-resources, task-runtimes

<research-area>: one or more values from this fixed list:

Use as few values as needed. If none fits, talk to the organization admins before creating the repository.

Topics are mandatory and are the only way to express hierarchy.

• They follow the naming rules above.
• Only values from the vocabulary above are allowed; do not invent new ones.
• A topic should still make sense in five years.

New repositories are private. Making a repository public needs a reason, such as a published artifact, released tool, or public teaching material.

Every public repository protects main with a ruleset named main-protection, configured exactly as follows:

• Bypass: organization admins
• Target: branch pattern main
• Rules:
  • restrict deletions
  • require linear history
  • require a pull request before merging, with
    • 1 required approval
    • stale approvals dismissed on new commits
    • review from code owners
    • approval of the most recent push
    • all conversations resolved
    • merge methods limited to squash and rebase
  • block force pushes

.github holds the organization-wide defaults:

• this README (profile/README.md)
• issue and pull request templates
• contribution guidelines, where needed

A repository is a record, not a scratch space. Anyone opening it later, whether a student, reviewer, or funder, should understand it without asking.

Examples of what this means in practice:

• paper-*
  • small, meaningful commits
  • Git tags for every submitted, revised, and accepted version, with the reviews stored alongside
  • the current compiled PDF is committed and always matches the sources
• artifact-* and benchmark-*
  • experiments are scripted end to end and can be rerun on another system without manual steps
  • results are stored together with the exact configuration that produced them

These are examples, not a complete list. The same standard applies to every category.

Supervision and project meetings use a shared Markdown template, one file per meeting, so that decisions and tasks stay traceable.

Template: misc-meeting-log-template

paper-* and teaching-* repositories use this template unless a documented reason says otherwise.

Shared rules for AI coding assistants (e.g., Claude Code, Cursor) live in misc-ai-rules. Reference them in your editor to keep language, style, and editing conventions consistent across projects.

The scheme is meant to:

• work across many years and many projects
• survive students and staff coming and going
• be readable by reviewers, students, and funding agencies
• replace implicit knowledge and ad-hoc names with explicit rules

When a repository doesn't fit, we change the scheme, not the repository.