• litchralee@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    15
    ·
    edit-2
    4 months ago

    If not code or documentation contributions, then well-written bug reports. Seriously, the quality of bug reports sometimes leaves a lot to be desired. And I don’t necessarily mean a full back-trace attached – and please, if you ever send a back-trace, copy-and-paste the text, never a screenshot – but just details like: system details, OS, version, step-by-step instructions to reproduce that a non-coder could also understand, plus what you expected to happen versus what actually happened.

    This stuff (usually) comes naturally to programmers and engineers, but users don’t necessarily see things this way. I sometimes think bug reports need to adopt a “so tell me what happened?” approach, where reporters are encouraged to describe free-form what they think of the software, then providing the specific details that developers need. That at least would collect all the relevant details, plus extra details that no developers thought to ask.

    Even just having folks that help gather and distill details from user reporters on a forum is easing a burden off of developers, and that effort should be welcomed by any competently-organized project. Many projects already have a template for reports, although it often gets mistaken for boilerplate. Helping reports recognize that they need to fill in all the details is a useful activity that isn’t code or docs.

    • lad@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 months ago

      bug reports need to adopt a “so tell me what happened?” approach

      I think, this may be one of the rare cases where use of LLMs may be reasonable. Help user structure their report, then call for a human