# Rseng User Support > Covers running user support as an operation for research software: triaging and answering support requests, converting recurring questions into documentation and FAQ entries, office hours and support channels, forum gardening, and feeding support signals into the roadmap. Use when support questions arrive faster than they are answered, when the same question keeps being answered by hand, when the user asks how to organize support, office hours or a helpdesk for their software, or when support load is invisible to planning. - Skill: `fdiblen/rseng-user-support` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add fdiblen/rseng-user-support` - Raw SKILL.md: https://api.skillmd.com/api/skills/fdiblen/rseng-user-support/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: CC-BY-4.0 - Author: fdiblen (https://skillmd.com/u/fdiblen) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fdiblen/rseng-user-support --- # 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