Skip to content

Latest commit

 

History

History
95 lines (68 loc) · 4.97 KB

contributing.md

File metadata and controls

95 lines (68 loc) · 4.97 KB
Raw

When to create an issue?

  • Identifying a Bug (something's broken)
  • Requesting an Enhancement (something could be better)
  • Suggesting a change (to improve the user or developer experience)
  • Asking a question (perhaps guidance can be improved)

When not to create an issue?

  • General feedback (eg: great job! Or I don't like the color blue)
  • Conversation without a resolution

Use the Yammer group or email innovate@its.ny.gov if your issue does not seem to fit with the criteria above.

Creating Issues

  • Search and review the current issues to see if anyone else has already reported it (Duplicate issues will be closed).
  • If your issue is a duplicate of another issue, read the original issue, as comments may give enough temporarily information until a permanent solution is fully realized.
  • Keep issues, and comments contstructive and respectful (GitHub is a public place... deconstrutive comments will be deleted).
  • Abstract your problem... avoid mentioning names or any information that may be sensitive.
  • Review the "Mastering Issues" GitHub Tutorial https://guides.github.com/features/issues/

Problem Identification

When creating an issue, please provide all possible of the following:

  • Screenshot illustrating issue
  • URL that currently exhibits the problem (Might not be possible for all people)
  • Operating System, Browser/version
  • Whether or not you are behind an aggressive firewall or not (many state agencies are)
  • Detailed description of your issue.
  • Steps needed to replicate the issue.

Issues that do not follow the contributing.md guidelines may be closed.

Determining Issue Effect Scope
  • Issues effect may be to a single browser, device, physical location, site instance, or other subsets of users.
  • If issues are not immediately apparent to affect a large portion of the userbase, they will be put into the milestone "Instance Issues" where research can be done to further define the effect scope and to get peer assistance.
  • If after research, an issue's scope is understood, it may be brought back to a global milestone.
Steps to Determine Scope
  • Determine if someone else can replicate the issue with the same device/OS/browser.
  • Determine in the issue is just affecting your site/app or if it is more widespread (see the site tracking spreadsheet to find other sites to test against)
  • Test in multiple browsers and devices (ask others for assistance if there is a certain target device you need to test).
  • Summarize all your results at the very top of the issue for easy reference.

Issue Naming

  • Create descriptive names that represent the nature of the problem, rather than your site or instance.
  • Propose a renaming of an issue in a comment if you do not have the ability to change it directly.

Labels

Each issue should have minimum required labels

If you don't have the ability to add labels write them in your description or comment and they will be added for you.

  • product (required)
    • Guidance and Demos
    • Universal Navigation
      • version (required)
      • type (requried)
      • status
      • priority
        • critical: impacts all users or all users of a certain site
        • moderate: only impacts subset of users

Reference

Filters

Create an issue if any of the labels need more clarification

Milestones

  • New issues should be placed in "ITS Reviewing" milestone http://git.io/HsPWnQ where all new issues will be incubated until they either get Iceboxed or pulled to an instance/documentation milestone.
  • After full discovery and consensus (ITS and Dev Partner) issues can be moved to "NY.GOV Launch - Development" http://git.io/3ToKZw.
  • Milestones https://github.com/nys-its/universal-navigation/milestones
  • Issues will be tasked to a milestone (by an admin) so that sprints can be scoped and there is an indication of when issues will be addressed.
  • If you re-milestone an issue, comment to communicate your rational, or discuss before moving.
  • Create an issue if any milestones could be better named or described.

Getting Things Done

  • If you can fix an issue yourself (guidance and demos for this repo), assign yourself to an issue, or comment to claim (admin will assign).
  • If contributing, Fork the repo, make changes and create a pull request (If that's "all greek to you"... just help contribute to issues for now... we'll share tutorials at a later date)

ProTips