fdiblen User support for research software
Support is where users meet the project - and in research software it is usually nobody's job, so it becomes the maintainer's evenings. Running it as a lightweight operation turns the same effort into documentation, roadmap signal and community goodwill. The core loop: answer once, then make the answer permanent - every question answered twice by hand is a process failure.
The support-to-documentation pipeline
The habit that pays off most, and ideal agent work:
- Answer the question where it was asked, then immediately route it: a recurring how-do-I question becomes a FAQ entry or documentation section (rseng-documentation), an error-message question becomes a better error message (rseng-ux-accessibility) or a troubleshooting entry, a "can it do X" becomes a tracked feature request or a documented limitation (rseng-project-tracking).
- Link, do not retype: subsequent identical questions get the canonical link plus a sentence - which also reveals when the canonical answer is not findable enough (a search-terms problem, fixable in headings).
- Review the support log periodically: three questions on the same topic in a month is a docs gap or a design gap (rseng-lessons-learned captures the pattern; rseng-ux-accessibility asks whether the interface caused it).
Channels and expectations
- Fewer channels, tended well: one primary question channel (forum-style with public archives beats chat for reuse - the answer helps the next searcher) plus the issue tracker for bugs; state in the README where questions GO and what response time to expect (the same stated-promise discipline as rseng-community-governance).
- Public by default: private support answers help one person; public ones compound. Redirect kindly from private mail to the public channel except where data sensitivity demands otherwise (rseng-regulatory-compliance).
- Office hours work for research software: a recurring short slot (with notes posted after) concentrates support load, gives users a human moment, and surfaces the confusions that never get written down. Announce via the community digest (rseng-science-communication).
- Support is contribution: answering questions counts, is credited (rseng-citation-metadata's all-kinds rule), and is a proven on-ramp - active answerers make good future maintainers (rseng-contributor-onboarding).
Triage discipline
- Separate the streams on arrival: bug (to the tracker with reproduction info - rseng-debugging's reproduce-first), usage question (answer + pipeline), feature request (tracker with the need, not the demanded design), sensitive report (security contact - rseng-security).
- The first response does not need the answer: acknowledging with a timeframe beats silence while a fix is researched - first-response time is the retention metric (rseng-community-metrics).
- Reproduce before diagnosing user-reported bugs; ask for the environment, exact command and full error (a saved reply or issue template collects these - rseng-community-governance).
- It is fine to say no and to say "out of scope" - kindly, with reasons and alternatives where they exist (rseng-software-reuse may know the right tool).
Support signal in planning
Support load is data: time spent, topics, affected user groups - a line in the status record (rseng-project-tracking) makes it visible in planning, fundable in proposals (support and maintenance are budgetable work - rseng-management-planning), and honest in the sustainability story (rseng-maintenance-sustainability).
Working with this skill
This skill is source-independent: it encodes community support practice for research software. It feeds rseng-documentation and rseng-project-tracking and draws on rseng-community-metrics for its health signals.
Learn more (verified):
- https://opensource.guide - open source guides (best practices for maintainers)
- https://www.cscce.org - CSCCE community engagement resources
- https://chaoss.community - CHAOSS metrics (responsiveness)
Related skills
Check whether any of these applies before moving on:
- rseng-community-metrics - first-response time is the metric
- rseng-contributor-onboarding - answerers are future contributors
- rseng-debugging - reproduce user-reported bugs first
- rseng-documentation - answers become FAQ entries
- rseng-project-tracking - requests and load feed planning
- rseng-ux-accessibility - error messages causing the questions