Issues and waffles

SirCaptainMitch edited this page Feb 1, 2017 · 3 revisions

First and foremost: this page is a draft and the whole process is a work in progress. Nonetheless we'll try to stick with it as much as possible, listing here what is the current process to help you contribute to dbatools in the best way possible. Rules will apply but common sense will rule above all.

We use to get a better handle of the state of the repo (more on that, later). Waffle is a kanban board that maily uses labels to identify statuses.

If you don't like waffle, you can still use github labels to filter through the issues, but it'll be less fun ^_^

Here are the rules:

  • Issues and PRs have already a pre-built template to fill: please fill the dots accordingly.
  • Issues and PRs should be restricted to one file only, and that file should appear in the title (e.g. "Get-DbaDatabaseState, speed enhancements")
  • you should fork the dbatools repo and work on a topic branch spawned from "development", then issue PRs from your topic branch to the "development" branch of the dbatools repo
  • if the PR is raised to fix a bug, please use the commit message with the "closing" keyword (e.g. "Get-DbaDatabaseState, fixes #330"). This will link the PR to the issue both on github and on waffle, and will close the issue ONLY when the commits gets merged to "master", which is what dbatools latest stable release is generated from
  • issues that report that an enhancement is needed will be tagged as "enhancement"
  • issues that report bugs will get the "bug" label
  • every "bug" and PR will be associated to a milestone, so everybody can know when it'll be fixed (AND the priority assigned to it)
  • PRs (both for "bugs" and for new commands) will be reviewed using github reviews, and if further development is needed, they'll get a "needs development" tag
  • once review is done, "needs development" will go away and either "code review complete" will kick in (when there is no need to test it) or "needs testing"
  • testers will do their best to break the new code, and report back any further findings to fix before merging
  • testers will eventually give the go-ahead and "needs testing" will go away
  • the PR is ready to be merged into "development", and will be automatically closed once the code gets to the stable release

And here is what everybody will have to do to max out the fun (and profit):

  • developers:
    • check on waffle for new "approved" commands with the "Ready" Flag.
    • start a topic branch on the forked repo
    • issue a PR
    • PR gets a milestone
    • the process described above for PRs kicks in
  • testers:
    • tackle "needs testing" issues
  • core devs:
    • triage issues and PRs with milestones
    • merge ASAP when there is no "needs testing" and "code review complete"
  • fixers/contributors:
    • tackle any unassigned issue tagged as "bug" or "enhancement" (here)
    • hop in and when an issue is targeted, either auto-assign it to you or comment in it to let others know you're working on it

Every "view" explained above can be quickly visualized in the waffle board, optionally requiring to use the filters at the top right corner. Please note that shifting cards between columns will effectively "toggle" matching labels, so be nice to triagers ;-)

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.