Triager-Guide.md

   1 # Express Triager Guide
   2
   3 ## Issue Triage Process
   4
   5 When a new issue or pull request is opened the issue will be labeled with `needs triage`.
   6 If a triage team member is available they can help make sure all the required information
   7 is provided. Depending on the issue or PR there are several next labels they can add for further
   8 classification:
   9
  10 * `needs triage`: This can be kept if the triager is unsure which next steps to take
  11 * `awaiting more info`: If more info has been requested from the author, apply this label.
  12 * `bug`: Issues that present a reasonable conviction there is a reproducible bug.
  13 * `enhancement`: Issues that are found to be a reasonable candidate feature additions.
  14
  15 If the issue is a question or discussion, it should be moved to GitHub Discussions.
  16
  17 ### Moving Discussions and Questions to GitHub Discussions
  18
  19 For issues labeled with `question` or `discuss`, it is recommended to move them to GitHub Discussions instead:
  20
  21 * **Questions**: User questions that do not appear to be bugs or enhancements should be moved to GitHub Discussions.
  22 * **Discussions**: Topics for discussion should be moved to GitHub Discussions. If the discussion leads to a new feature or bug identification, it can be moved back to Issues.
  23
  24 In all cases, issues may be closed by maintainers if they don't receive a timely response when
  25 further information is sought, or when additional questions are asked.
  26
  27 ## Approaches and Best Practices for getting into triage contributions
  28
  29 Review the organization's [StatusBoard](https://expressjs.github.io/statusboard/),
  30 pay special attention to these columns: stars, watchers, open issues, and contributors.
  31 This gives you a general idea about the criticality and health of the repository.
  32 Pick a few projects based on that criteria, your interests, and skills (existing or aspiring).
  33
  34 Review the project's contribution guideline if present. In a nutshell,
  35 commit to the community's standards and values. Review the
  36 documentation, for most of the projects it is just the README.md, and
  37 make sure you understand the key APIs, semantics, configurations, and use cases.
  38
  39 It might be helpful to write your own test apps to re-affirm your
  40 understanding of the key functions. This may identify some gaps in
  41 documentation, record those as they might be good PR's to open.
  42 Skim through the issue backlog; identify low hanging issues and mostly new ones.
  43 From those, attempt to recreate issues based on the OP description and
  44 ask questions if required. No question is a bad question!
  45
  46 ## Removal of Triage Role
  47
  48 There are a few cases where members can be removed as triagers:
  49
  50 - Breaking the CoC or project contributor guidelines
  51 - Abuse or misuse of the role as deemed by the TC
  52 - Lack of participation for more than 6 months
  53
  54 If any of these happen we will discuss as a part of the triage portion of the regular TC meetings.
  55 If you have questions feel free to reach out to any of the TC members.
  56
  57 ## Other Helpful Hints:
  58
  59 - Everyone is welcome to attend the [Express Technical Committee Meetings](https://github.com/expressjs/discussions#expressjs-tc-meetings), and as a triager, it might help to get a better idea of what's happening with the project.
  60 - When exploring the module's functionality there are a few helpful steps:
  61   - Turn on `DEBUG=*` (see https://www.npmjs.com/package/debug) to get detailed log information
  62   - It is also a good idea to do live debugging to follow the control flow, try using `node --inspect`
  63   - It is a good idea to make at least one pass of reading through the entire source
  64 - When reviewing the list of open issues there are some common types and suggested actions:
  65   - New/unattended issues or simple questions: A good place to start
  66   - Hard bugs & ongoing discussions: always feel free to chime in and help
  67   - Issues that imply gaps in the documentation: open PRs with changes or help the user to do so
  68 - For recurring issues, it is helpful to create functional examples to demonstrate (publish as gists or a repo)
  69 - Review and identify the maintainers. If necessary, at-mention one or more of them if you are unsure what to do
  70 - Make sure all your interactions are professional, welcoming, and respectful to the parties involved.