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