Difference between revisions of "Github Issues"

From Dreamwidth Notes
Jump to: navigation, search
(incorporated Fu's suggested changes)
(Working on Bugs)
 
(17 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
__FORCETOC__
 
__FORCETOC__
 +
As of early 2014, we migrated from [[Bugzilla]] to Github Issues. Workflows for GHI are documented here in addition to the <dwuser>dw_dev</dwuser> community. For more details on git in its own right, see [[Git How To]] and [[Git Getting Started]].
  
As of early 2014, we migrated from [[Bugzilla]] to Github Issues. Workflows for GHI are documented here in addition to the dw_dev community.
+
===Signing up for Github===
  
===Logging bugs===
+
[https://help.github.com/articles/signing-up-for-a-new-github-account Github's guide on signing up for a new account]. You can use a free personal plan to collaborate with Dreamwidth.
  
'''DO NOT''' use this process for security issues or non-code (e.g. documentation) bugs.
+
===Reporting Bugs===
  
1. Go to the dw-free repository's [https://github.com/dreamwidth/dw-free/issues Issues]. (You can get there by going to the main [https://github.com/dreamwidth/dw-free dw-free repository], then looking on the right-hand sidebar for the "Issues" link.)
+
<div style="padding:1em; background-color:#fee;">'''DO NOT''' use this process for security issues. Any security concerns should be reported privately to our staff -- you can email Denise and Mark. (denise@/mark@ the site's domain.)</div>
  
2. Do a quick skim over the existing issues to see if yours is a duplicate. (Right now, finding things is harder than it will be: adding more tags to help significantly with categorization and search is my next major task, but again, I wanted to get this posted as quickly as possible. In the meantime, it's okay if we get a few dupes.)
+
# Go to the dw-free repository's [https://github.com/dreamwidth/dw-free/issues Issues]. (You can also get there from the main page for the  [https://github.com/dreamwidth/dw-free dw-free repository], looking on the right-hand sidebar for the "Issues" link.)<br /><br />
 +
# Do a quick skim over the existing issues to see if yours has already been reported. By default, only open issues are shown, but you may also want to check closed issues for any recent fixes that might not be live on the site yet. (Right now, the easiest way to find relevant issues is a full text search. We are planning to add more tags to help significantly with categorization and search, but in the meantime, it's okay if we get a few duplicate reports.)<br /><br />
 +
# Go ahead and open a new issue if you don't see an existing one that covers what you want to report. To open an issue, use the green button in the upper right hand corner, to the right of the search field, labelled "[https://github.com/dreamwidth/dw-free/issues/new New Issue]".<br /><br />
 +
# For "Title", put something both concise and descriptive. In the case of outright buggy behavior, use a phrase that explains what's going wrong. For usability issues, try to state the desired behavior, e.g., what's the one-sentence summary of the task? When in doubt, make the first word an active verb ('remove', 'update', 'fix', etc) and make the sentence itself imperative: "add missing link on update page", "correct display issue in Celerity on community pages", "change text on crosspost tab of Manage Settings to reflect new workflow", and so forth.<br /><br />
 +
# For the larger "Leave a comment" box, describe the issue as thoroughly as you can: steps to reproduce, details of what needs to be changed, what it's doing that it shouldn't do, what it should do that it isn't doing, what would be necessary for the bug to be considered 'fixed', etc. This might be a few sentences, or it might be a few paragraphs - whatever it takes to give enough detail that someone coming along to work on it can understand the bug and be reasonably confident in tackling it.  Include links to any relevant support requests or discussions of the issue elsewhere.  If you have a screenshot, you can include that as well.<br /><br />
 +
# When you're done, click 'Submit new Issue'.
  
3. Open an issue if you don't see one already existing for what you want to report. To open an issue, use the green button in the upper right hand corner, before the list of open issues, labelled "[https://github.com/dreamwidth/dw-free/issues/new New Issue]".
+
===Working on Bugs===
 +
# If you're a new contributor, you'll need to send in your [[Contributor Licensing Agreement]]. Once that's received, you'll be added to the Dreamwidth contributors team on Github.  If you've contributed in the past and are coming back after a hiatus, do double-check whether you're on [https://github.com/orgs/dreamwidth/teams/contributors the list of Dreamwidth contributors]. If the button at the bottom of the left-hand table on that page says "Leave", you're on the team! (DON'T CLICK THE BUTTON.) If you're not listed, let us know and we'll add you ASAP.<br /><br />
 +
# To find an existing issue to work on, go to the dw-free repository's [https://github.com/dreamwidth/dw-free/issues Issues]. You'll see a list of all the current open issues. If already claimed, the issue should have the "status: claimed" label, and the Gravatar (user icon) of the assigned user appears near the right-hand side of the entry. <br /><br />
 +
# To see all unclaimed (available) issues, click on the "Assignee" dropdown below the search field, and choose "[https://github.com/dreamwidth/dw-free/issues?q=is%3Aopen+is%3Aissue+no%3Aassignee Assigned to nobody]". You can filter with multiple constraints: for example, to see [https://github.com/dreamwidth/dw-free/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+-label%3A%22status%3A+claimed%22 only issues without the label status:claimed] (in the event that an issue has been claimed by someone to whom it has not been automatically assigned), or you can find a handy list of [https://github.com/dreamwidth/dw-free/issues?q=is%3Aopen+is%3Aissue+no%3Aassignee+label%3A%22curated%3A+beginner%22 unassigned issues that have been selected as suitable for beginning coders or people new to our codebase]! The [https://github.com/dreamwidth/dw-free/labels labels page] lists all of our current tags for issues, with links to search on each. [https://github.com/dreamwidth/dw-free/milestones Milestones] are now used to designate major projects, so if you're looking for something smaller in scope, "no milestone" is a useful term to filter on. We've done our best to come up with a collection of labels and milestones that will be useful for people to search with, and we're going to keep refining them over time. (See [http://wiki.dreamwidth.net/wiki/index.php/Github_Issues#Curating_Bugs Curating Bugs] below for more about the labels we use.)<br /><br />
 +
# Once you've found something you want to work on, load the issue. Leave a comment saying "I'll claim this" or similar - any comment with the words "claim", "claimed", or "claiming" will do, as long as you're on our contributors team, and the issue isn't already claimed by someone else. Case doesn't matter -- you can use capital letters if you want. You can also have other words be part of the comment, so you don't need to memorize a specific format. "I'm claiming this" will work just as well as "Claimed!"<br /><br />
 +
# After claiming the issue you're interested in, go through the normal process of creating a branch, making your changes, testing your changes, committing your changes to your branch, pushing the branch to Github, etc. (as documented in [[Git How To]]). Make sure you include the originating issue number in your commit message -- Github will automatically create a link to the issue, and even adds a link from the issue page to your changes! You can find the issue number after the title of the issue on the issue detail page, on the right-hand side of the issue on the "all issues" page, or -- if all else fails -- in the URL of the issue.<br /><br />
 +
# Submit a pull request to have your changes reviewed and eventually accepted into the main develop branch. '''In the description field of the pull request form, it is very important to include the phrase "Fixes #XXX", where #XXX is the issue number.''' Including this in the description (not the title!) of the pull request accomplishes two things: it automatically assigns the related issue to you if you didn't do that earlier, and it automatically closes the issue when the pull request is merged. For more information about automatically closing the related issue, see [https://help.github.com/articles/closing-issues-via-commit-messages/ Closing issues via commit messages] on Github.
  
4. For "Title", put something both concise and descriptive: what's the one-sentence summary of the task? When in doubt, make the first word an active verb ('remove', 'update', 'fix', etc) and make the sentence itself imperative: "add missing link on update page", "correct display issue in Celerity on community pages", "change text on crosspost tab of Manage Settings to reflect new workflow", yadda.
+
===Curating Bugs===
  
5. For the larger "Leave a comment" box, describe the issue as thoroughly as you can: steps to reproduce, details of what needs to be changed, what it's doing that it shouldn't do, what it should do that it isn't doing, what would be necessary for the bug to be considered 'fixed', etc. This might be a few sentences, or it might be a few paragraphs - whatever it takes to give enough detail that someone coming along to work on it can understand the bug and be reasonably confident in tackling it.
+
Because most contributors don't have the necessary permissions to label issues directly using Github's web interface, <dwuser>afuna</dwuser> wrote a monitoring service (bot) to add labels to issues in respond to comments. These are the label comments currently recognized by the system:
  
6. When you're done, hit 'submit new issue'.  
+
<dt><pre>##curated: beginner</pre></dt>
 +
<dd>Used for "babydev bait" - relatively simple fixes appropriate for new contributors who are just getting their feet wet.</dd>
  
===Finding bugs to work on===
+
<dt><pre>##curated: mostwanted</pre></dt>
 +
<dd>Used by project administrators (usually <dwuser>denise</dwuser>) to indicate issues that should be resolved sooner rather than later, all other things being equal, because they will reduce annoyances in the day-to-day use of the site.</dd>
  
1. Go to the dw-free repository's [https://github.com/dreamwidth/dw-free/issues Issues]. You'll see all the current open issues. This view is a bit of a muddle, with claimed/unclaimed issues all lumped together and pull requests lumped in with the issues. If claimed, the Gravatar (user icon) of the user the bug's assigned to is displayed on the right-hand side of the issue bar.
+
<dt><pre>##from: suggestions</pre></dt>
 +
<dd>Issues imported from <dwuser>dw_suggestions</dwuser>.</dd>
  
2. Fortunately, there are labels and milestones! We've done our best to come up with a collection of labels and milestones that will be useful for people to search with, and we're going to keep refining them.
+
<dt><pre>##from: support</pre></dt>
 +
<dd>Issues generated from support requests.</dd>
  
3. For now, though: to see all unclaimed bugs, hit "Assignee" on the Issues page and choose "[https://github.com/dreamwidth/dw-free/issues?q=is%3Aopen+is%3Aissue+no%3Aassignee Assigned to nobody]". You can filter with multiple constraints: for example, you can find a handy list of [https://github.com/dreamwidth/dw-free/issues?q=is%3Aopen+is%3Aissue+no%3Aassignee+label%3A%22curated%3A+beginner%22 unassigned issues that have been selected as suitable for beginning coders or people new to our codebase]! ''Milestones'' are now used to designate major projects, so if you're looking for something small "no milestone" is a useful term to filter on.
+
<dt><pre>##is: bug</pre></dt>
 +
<dd>Things that are broken that need to be fixed.</dd>
  
4. Once you've found something you want to work on, load the issue. Leave a comment saying "I'll claim this" or similar - see below for more details!
+
<dt><pre>##is: feature</pre></dt>
 +
<dd>New functionality for the site, or significantly improving functionality of an existing feature.</dd>
  
5. Go through the normal process of creating a branch, making your changes, testing your changes, committing your changes to your branch, opening up a pull request, etc. In your commit message for when you commit your changes, include the sentence "Fixes issue #XXX", where #XXX is the issue number. (You can find the issue number after the title of the issue on the issue detail page, on the right-hand side of the issue on the "all issues" page, or -- if all else fails -- in the URL of the issue. For instance, "[https://github.com/dreamwidth/dw-free/issues/663 Update in-repository documentation to point to GHI instead of Bugzilla]", an issue I opened this morning, is issue #663: this is listed after the title on the issue detail page, and at the end of the URL for the issue detail page.)
+
<dt><pre>##is: upkeep</pre></dt>
 +
<dd>Maintenance tasks, like adding site embeds, mood themes, or new styles.  Converting pages to Template Toolkit and/or Foundation is also categorized here.</dd>
  
6. If you mention the originating issue number in the commit, github will automatically provide a link!
+
<dt><pre>##needs: docs</pre></dt>
 +
<dd>Issues that require changes to site documentation (e.g. FAQs).</dd>
  
===Claiming an issue===
+
<dt><pre>##effort: lower, ##effort: average, ##effort: higher</pre></dt>
 +
<dd>Most issues will have one of these tags as a best guess for how much effort they will require to implement.  The simplest is lower (measured in hours), followed by average (measured in days) and higher (measured in weeks). They really are our best guess up front -- sometimes we get it wrong and something labelled "effort: lower" will wind up being much more sprawling or something labelled "effort: higher" will wind up being a two second fix once you find the root cause!</dd>
  
You can claim an issue by leaving a comment with the words "claim", "claimed", or "claiming". Case doesn't matter -- you can use capital letters if you want. You can also have other words be part of the comment, so you don't need to memorize a specific format. "I'm claiming this" will work just as well as "Claimed!"
+
<dt><pre>##severity: minor, ##severity: major, ##severity: critical</pre></dt>
 +
<dd>Most issues will have one of these tags as a best guess for how much impact the issue has on the day-to-day functioning of the site. Minor is by far the most common, meaning the site is still functioning just fine for most users and the proposed change will have little impact; major is for issues that are "breaking the build" in development or preventing some people from using the site, or for significant new features; and critical means DROP EVERYTHING THE SITE IS ON FIRE. (Probably. We don't actually use this one much, unsurprisingly.)</dd>
 +
<hr />
 +
There are two other labels which are applied automatically: "status: claimed" when someone claims an issue (see [http://wiki.dreamwidth.net/wiki/index.php/Github_Issues#Working_on_Bugs Working on Bugs] above), and "status: untriaged" which is used for issues that haven't had any of the other listed labels applied. There is also "review: requested changes" which is reserved for pull requests that need further work before they can be accepted.
  
Claiming will only work if the current issue is not yet claimed -- this will avoid the problem of accidentally grabbing the bug from someone else during a long discussion about claiming something else in a different context.
+
All of the labels are listed on the [https://github.com/dreamwidth/dw-free/labels dw-free labels page] for easy searching.  If you are interested in the program that applies the labels to issues automatically in response to user comments, that code is maintained in <dwuser>afuna</dwuser>'s [https://github.com/afuna/ghi-assist ghi-assist] repository.
 
+
You ''do'' need to be part of the Dreamwidth contributors team on Github before assigning issues will work. If you're a new contributor, you'll be automatically added when you send in your [[Contributor Licensing Agreement]].
+
 
+
For existing contributors, do double-check if you're on any of the Dreamwidth teams. If it shows you a list of teams you're on, you're good! If we missed you somehow and tells you that you're not on any teams, let us know and we'll add you ASAP.
+
  
 
[[Category: Development]]
 
[[Category: Development]]
 
[[Category: Git]]
 
[[Category: Git]]

Latest revision as of 14:15, 7 November 2015

As of early 2014, we migrated from Bugzilla to Github Issues. Workflows for GHI are documented here in addition to the [info]dw_dev community. For more details on git in its own right, see Git How To and Git Getting Started.

Signing up for Github

Github's guide on signing up for a new account. You can use a free personal plan to collaborate with Dreamwidth.

Reporting Bugs

DO NOT use this process for security issues. Any security concerns should be reported privately to our staff -- you can email Denise and Mark. (denise@/mark@ the site's domain.)
  1. Go to the dw-free repository's Issues. (You can also get there from the main page for the dw-free repository, looking on the right-hand sidebar for the "Issues" link.)

  2. Do a quick skim over the existing issues to see if yours has already been reported. By default, only open issues are shown, but you may also want to check closed issues for any recent fixes that might not be live on the site yet. (Right now, the easiest way to find relevant issues is a full text search. We are planning to add more tags to help significantly with categorization and search, but in the meantime, it's okay if we get a few duplicate reports.)

  3. Go ahead and open a new issue if you don't see an existing one that covers what you want to report. To open an issue, use the green button in the upper right hand corner, to the right of the search field, labelled "New Issue".

  4. For "Title", put something both concise and descriptive. In the case of outright buggy behavior, use a phrase that explains what's going wrong. For usability issues, try to state the desired behavior, e.g., what's the one-sentence summary of the task? When in doubt, make the first word an active verb ('remove', 'update', 'fix', etc) and make the sentence itself imperative: "add missing link on update page", "correct display issue in Celerity on community pages", "change text on crosspost tab of Manage Settings to reflect new workflow", and so forth.

  5. For the larger "Leave a comment" box, describe the issue as thoroughly as you can: steps to reproduce, details of what needs to be changed, what it's doing that it shouldn't do, what it should do that it isn't doing, what would be necessary for the bug to be considered 'fixed', etc. This might be a few sentences, or it might be a few paragraphs - whatever it takes to give enough detail that someone coming along to work on it can understand the bug and be reasonably confident in tackling it. Include links to any relevant support requests or discussions of the issue elsewhere. If you have a screenshot, you can include that as well.

  6. When you're done, click 'Submit new Issue'.

Working on Bugs

  1. If you're a new contributor, you'll need to send in your Contributor Licensing Agreement. Once that's received, you'll be added to the Dreamwidth contributors team on Github. If you've contributed in the past and are coming back after a hiatus, do double-check whether you're on the list of Dreamwidth contributors. If the button at the bottom of the left-hand table on that page says "Leave", you're on the team! (DON'T CLICK THE BUTTON.) If you're not listed, let us know and we'll add you ASAP.

  2. To find an existing issue to work on, go to the dw-free repository's Issues. You'll see a list of all the current open issues. If already claimed, the issue should have the "status: claimed" label, and the Gravatar (user icon) of the assigned user appears near the right-hand side of the entry.

  3. To see all unclaimed (available) issues, click on the "Assignee" dropdown below the search field, and choose "Assigned to nobody". You can filter with multiple constraints: for example, to see only issues without the label status:claimed (in the event that an issue has been claimed by someone to whom it has not been automatically assigned), or you can find a handy list of unassigned issues that have been selected as suitable for beginning coders or people new to our codebase! The labels page lists all of our current tags for issues, with links to search on each. Milestones are now used to designate major projects, so if you're looking for something smaller in scope, "no milestone" is a useful term to filter on. We've done our best to come up with a collection of labels and milestones that will be useful for people to search with, and we're going to keep refining them over time. (See Curating Bugs below for more about the labels we use.)

  4. Once you've found something you want to work on, load the issue. Leave a comment saying "I'll claim this" or similar - any comment with the words "claim", "claimed", or "claiming" will do, as long as you're on our contributors team, and the issue isn't already claimed by someone else. Case doesn't matter -- you can use capital letters if you want. You can also have other words be part of the comment, so you don't need to memorize a specific format. "I'm claiming this" will work just as well as "Claimed!"

  5. After claiming the issue you're interested in, go through the normal process of creating a branch, making your changes, testing your changes, committing your changes to your branch, pushing the branch to Github, etc. (as documented in Git How To). Make sure you include the originating issue number in your commit message -- Github will automatically create a link to the issue, and even adds a link from the issue page to your changes! You can find the issue number after the title of the issue on the issue detail page, on the right-hand side of the issue on the "all issues" page, or -- if all else fails -- in the URL of the issue.

  6. Submit a pull request to have your changes reviewed and eventually accepted into the main develop branch. In the description field of the pull request form, it is very important to include the phrase "Fixes #XXX", where #XXX is the issue number. Including this in the description (not the title!) of the pull request accomplishes two things: it automatically assigns the related issue to you if you didn't do that earlier, and it automatically closes the issue when the pull request is merged. For more information about automatically closing the related issue, see Closing issues via commit messages on Github.

Curating Bugs

Because most contributors don't have the necessary permissions to label issues directly using Github's web interface, [info]afuna wrote a monitoring service (bot) to add labels to issues in respond to comments. These are the label comments currently recognized by the system:

##curated: beginner

Used for "babydev bait" - relatively simple fixes appropriate for new contributors who are just getting their feet wet.

##curated: mostwanted

Used by project administrators (usually [info]denise) to indicate issues that should be resolved sooner rather than later, all other things being equal, because they will reduce annoyances in the day-to-day use of the site.

##from: suggestions

Issues imported from [info]dw_suggestions.

##from: support

Issues generated from support requests.

##is: bug

Things that are broken that need to be fixed.

##is: feature

New functionality for the site, or significantly improving functionality of an existing feature.

##is: upkeep

Maintenance tasks, like adding site embeds, mood themes, or new styles. Converting pages to Template Toolkit and/or Foundation is also categorized here.

##needs: docs

Issues that require changes to site documentation (e.g. FAQs).

##effort: lower, ##effort: average, ##effort: higher

Most issues will have one of these tags as a best guess for how much effort they will require to implement. The simplest is lower (measured in hours), followed by average (measured in days) and higher (measured in weeks). They really are our best guess up front -- sometimes we get it wrong and something labelled "effort: lower" will wind up being much more sprawling or something labelled "effort: higher" will wind up being a two second fix once you find the root cause!

##severity: minor, ##severity: major, ##severity: critical

Most issues will have one of these tags as a best guess for how much impact the issue has on the day-to-day functioning of the site. Minor is by far the most common, meaning the site is still functioning just fine for most users and the proposed change will have little impact; major is for issues that are "breaking the build" in development or preventing some people from using the site, or for significant new features; and critical means DROP EVERYTHING THE SITE IS ON FIRE. (Probably. We don't actually use this one much, unsurprisingly.)


There are two other labels which are applied automatically: "status: claimed" when someone claims an issue (see Working on Bugs above), and "status: untriaged" which is used for issues that haven't had any of the other listed labels applied. There is also "review: requested changes" which is reserved for pull requests that need further work before they can be accepted.

All of the labels are listed on the dw-free labels page for easy searching. If you are interested in the program that applies the labels to issues automatically in response to user comments, that code is maintained in [info]afuna's ghi-assist repository.