Difference between revisions of "How to do a Code Tour"

From Dreamwidth Notes
Jump to: navigation, search
m (What is a code tour?: removed reference to Bugzilla)
(This link should be hack.dreamwidth.net, not dev-hack.dreamwidth.net.)
 
(8 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
== How to make a code tour ==
 
== How to make a code tour ==
  
First, find the ending date of the latest code tour post by [http://dw-dev.dreamwidth.org/tag/code+tour viewing the previous code tours]. Then, plug that date into the [http://hack.dreamwidth.net/dev/codetour/ Code Tour Template Generator], and click Generate. The script will automatically find all the RESOLVED FIXED bugs that have been modified since then, and present a text box with a pre-filled template, which you should copy and paste into a text editor on your computer.
+
First, find the ending date of the latest code tour post by [http://dw-dev.dreamwidth.org/tag/code+tour viewing the previous code tours]. Then, plug that date into the [http://hack.dreamwidth.net/dev/codetour/ Code Tour Template Generator], and click Generate. (Using the "From the date of the last code tour" option requires the repository to have been updated - it's best to double-check manually so you don't duplicate effort.) The script will automatically find all issues and pull requests that have been closed since that date, and present a text box with a pre-filled template, which you should copy and paste into a text editor on your computer. '''Note that this is different to the old Bugzilla code-tour generator''', which only compiled bugs marked RESOLVED FIXED: you need to check each item manually to make sure that you're not including anything that would in Bugzilla have been marked e.g. RESOLVED DUPLICATE or RESOLVED WON'T FIX.
  
There may be a few bugs that overlap with the previous code tour; those should be listed at the top, and can be deleted. (If any bugs from the previous code tour are in the list, but don't appear at the top, that means they've been updated since the last code tour and you should check them in case there have been any new patches.)
+
There may be a few bugs that overlap with the previous code tour; you will need to cross-reference with the last code tour, because bugs are listed in ascending numerical order not chronologically by date closed.
  
You should double-check the 'Category' and 'Patch by' fields to make sure they accurately reflect the bug (for example, sometimes the "patch by" field only includes who made the patch, but other people may have worked on it, especially in the arena of themes - and sometimes the assignee on the bug isn't the one who actually does the patch!), and then write a description for the bug. By default, the text "FILL IN" is pre-filled to make it easy to search for at the end and see if you missed anything, but if you prefer it blank, there's a ticky box on the first page of the generator that will do that for you.
+
You should double-check the 'Patch by' field to make sure they accurately reflect the bug (for example, sometimes the "patch by" field only includes who made the patch, but other people may have worked on it, especially in the arena of themes - and sometimes the assignee on the bug isn't the one who actually does the patch!), and then write a description for the bug. The text "FILL IN" is pre-filled to make it easy to search for at the end and see if you missed anything. The 'Category' field is legacy from Bugzilla and does not need filling in manually.
  
Then, make an entry in <dwcomm>dw_dev</dwcomm> tagged "code tour".  The subject line should include the dates covered by the code tour, and the tour should be behind a &lt;cut&gt; tag to spare people's reading pages. The time to do these is generally the day of the <dwcomm>dw_news</dwcomm> update or the day before. (The day for this has in the past been Wednesday, or Monday, but is as always subject to change.)
+
For preference, make a note of any issue that should be documented (generally changes in behaviour or functionality) and [https://docs.google.com/forms/d/1wsOq8TIdV7v3FrddsKSMze9DnKRIb1o20Jxx2juKrOM/viewform record it in the documents management system].
 +
 
 +
Then make an entry in <dwcomm>dw_dev</dwcomm> tagged "code tour".  The subject line should include the dates covered by the code tour, and the tour should be behind a &lt;cut&gt; tag to spare people's reading pages. The time to do these is generally the day of the <dwcomm>dw_news</dwcomm> update or the day before.
 +
 
 +
When you've finished this, grab someone with commit access to the repositories in question, tell them what the latest issue included in the code tour was (preferably with link!), and get them to update the pointer (so that the tool offers the correct date for the "From the date of the last code tour" option). The committer will need to run the following commands:
 +
 
 +
  git checkout code-tour
 +
  git merge --no-ff develop
  
 
== How to manually make a code tour ==
 
== How to manually make a code tour ==
Line 17: Line 24:
 
(You generally don't need to do this; this is just included for reference in case the generator fails. You should normally use the section above.)
 
(You generally don't need to do this; this is just included for reference in case the generator fails. You should normally use the section above.)
  
First, get a link to a Bugzilla search from <dwuser>denise</dwuser> or by putting the start and end dates of the week into [http://bugs.dwscoalition.org/query.cgi?bug_status=RESOLVED&chfield=bug_status&chfieldfrom=2009-09-21&chfieldto=2009-09-27&query_format=advanced&resolution=FIXED this search form]. Then, put the information each bug into this example format:
+
First, get a list of closed issues and pull requests by filtering [https://github.com/dreamwidth/dw-free/issues?utf8=%E2%9C%93&q=is%3Aclosed+ the list of closed issues] by date (note that this link gives you closed issues in the dw-free repository only, and it may be appropriate to also include issues from dw-nonfree). Then, put the information for each issue into this example format:
  
  <b><a href="http://bugs.dwscoalition.org/show_bug.cgi?id=NNNN">Bug NNNN</a>:</b> Bug Title
+
  <b><a href="https://github.com/dreamwidth/dw-free/issues/NNNN">Issue NNNN</a>:</b> Bug Title (<a href="https://github.com/dreamwidth/dw-free/pulls/MMMM">pull request</a>)
 
  <b>Category:</b> What section of the site is this bug about?
 
  <b>Category:</b> What section of the site is this bug about?
  <b>Patch by:</b> <user name="username"> or submitter name
+
  <b>Patch by:</b> <user name="username" site="github"> or submitter name
 
  <b>Description:</b> What problem does this bug solve, or what new feature does it add?
 
  <b>Description:</b> What problem does this bug solve, or what new feature does it add?
  
Then, make a post to <dwuser>dw_dev</dwuser> tagged "code tour". The time to do these is generally Monday, so they can be included in the <dwuser>dw_news</dwuser> update.
+
Then, make a post to <dwuser>dw_dev</dwuser> tagged "code tour". The time to do this is generally the day before or of a code push.
  
 
Makes sure to double check the bug--sometimes the "patch by" field only includes who made the patch, but other people may have worked on it, especially in the arena of themes.
 
Makes sure to double check the bug--sometimes the "patch by" field only includes who made the patch, but other people may have worked on it, especially in the arena of themes.
Line 33: Line 40:
 
# spot a post in <dwuser>dw_volunteers</dwuser> requesting a code tour
 
# spot a post in <dwuser>dw_volunteers</dwuser> requesting a code tour
 
# follow the link to the list of bugs/HTML template for the code tour. <strong>It's worth checking the previous code tour to make sure you don't have any duplicates, especially if you have more than 15 bugs to write up.</strong>
 
# follow the link to the list of bugs/HTML template for the code tour. <strong>It's worth checking the previous code tour to make sure you don't have any duplicates, especially if you have more than 15 bugs to write up.</strong>
# open up the wiki page on how to do a code tour (well done! you're here!) and the handy Bugzilla list (both linked to from the handy HTML template)
+
# open up the wiki page on how to do a code tour (well done! you're here!) and the handy issues list (both linked to from the handy HTML template)
 
# copy the template into your Post Entry box.
 
# copy the template into your Post Entry box.
 
# stare at it in dismay until you work out whether (and how) you want to try to be funny (that's the hard part!)
 
# stare at it in dismay until you work out whether (and how) you want to try to be funny (that's the hard part!)
# write the pre-amble and closing notes, stick in the cut tag, fill in the subject with "Code tour: date--date", open all of the bug descriptions at the Bugzilla link
+
# write the pre-amble and closing notes, stick in the cut tag, fill in the subject with "Code tour: date--date", open all of the bug descriptions at the issue link
 
# for each bug:  
 
# for each bug:  
 
#* confirm that the "patch by:" field matches the info given on the bug page (esp. in comments)
 
#* confirm that the "patch by:" field matches the info given on the bug page (esp. in comments)

Latest revision as of 22:14, 26 July 2015

What is a code tour?

A code tour lists information about all of the issues that have been closed since the last code tour. You can view previous code tours in [info]dw_dev .

How to make a code tour

First, find the ending date of the latest code tour post by viewing the previous code tours. Then, plug that date into the Code Tour Template Generator, and click Generate. (Using the "From the date of the last code tour" option requires the repository to have been updated - it's best to double-check manually so you don't duplicate effort.) The script will automatically find all issues and pull requests that have been closed since that date, and present a text box with a pre-filled template, which you should copy and paste into a text editor on your computer. Note that this is different to the old Bugzilla code-tour generator, which only compiled bugs marked RESOLVED FIXED: you need to check each item manually to make sure that you're not including anything that would in Bugzilla have been marked e.g. RESOLVED DUPLICATE or RESOLVED WON'T FIX.

There may be a few bugs that overlap with the previous code tour; you will need to cross-reference with the last code tour, because bugs are listed in ascending numerical order not chronologically by date closed.

You should double-check the 'Patch by' field to make sure they accurately reflect the bug (for example, sometimes the "patch by" field only includes who made the patch, but other people may have worked on it, especially in the arena of themes - and sometimes the assignee on the bug isn't the one who actually does the patch!), and then write a description for the bug. The text "FILL IN" is pre-filled to make it easy to search for at the end and see if you missed anything. The 'Category' field is legacy from Bugzilla and does not need filling in manually.

For preference, make a note of any issue that should be documented (generally changes in behaviour or functionality) and record it in the documents management system.

Then make an entry in [info]dw_dev tagged "code tour". The subject line should include the dates covered by the code tour, and the tour should be behind a <cut> tag to spare people's reading pages. The time to do these is generally the day of the [info]dw_news update or the day before.

When you've finished this, grab someone with commit access to the repositories in question, tell them what the latest issue included in the code tour was (preferably with link!), and get them to update the pointer (so that the tool offers the correct date for the "From the date of the last code tour" option). The committer will need to run the following commands:

 git checkout code-tour
 git merge --no-ff develop

How to manually make a code tour

(You generally don't need to do this; this is just included for reference in case the generator fails. You should normally use the section above.)

First, get a list of closed issues and pull requests by filtering the list of closed issues by date (note that this link gives you closed issues in the dw-free repository only, and it may be appropriate to also include issues from dw-nonfree). Then, put the information for each issue into this example format:

<a href="https://github.com/dreamwidth/dw-free/issues/NNNN">Issue NNNN</a>: Bug Title (<a href="https://github.com/dreamwidth/dw-free/pulls/MMMM">pull request</a>)
Category: What section of the site is this bug about?
Patch by: <user name="username" site="github"> or submitter name
Description: What problem does this bug solve, or what new feature does it add?

Then, make a post to [info]dw_dev tagged "code tour". The time to do this is generally the day before or of a code push.

Makes sure to double check the bug--sometimes the "patch by" field only includes who made the patch, but other people may have worked on it, especially in the arena of themes.

How-to: a ten-step guide for first-timers

  1. join #dreamwidth and cry on people until they hold your hand
  2. spot a post in [info]dw_volunteers requesting a code tour
  3. follow the link to the list of bugs/HTML template for the code tour. It's worth checking the previous code tour to make sure you don't have any duplicates, especially if you have more than 15 bugs to write up.
  4. open up the wiki page on how to do a code tour (well done! you're here!) and the handy issues list (both linked to from the handy HTML template)
  5. copy the template into your Post Entry box.
  6. stare at it in dismay until you work out whether (and how) you want to try to be funny (that's the hard part!)
  7. write the pre-amble and closing notes, stick in the cut tag, fill in the subject with "Code tour: date--date", open all of the bug descriptions at the issue link
  8. for each bug:
    • confirm that the "patch by:" field matches the info given on the bug page (esp. in comments)
    • the commit message - generally in the final comment - forms a good basis for your summary in the "FILL IN"/Description space, but you'll probably want to flesh it out with details taken from the other comments
    • if you're confused about what it does, #dreamwidth is generally a good place to track down someone who can explain it to you so you can explain it to everyone else
    • and, for that matter, #dreamwidth is an excellent place to give running updates of the "ONE THIRD... ONE HALF... TWO THIRDS... but what if I get something WRONG and the WORLD ENDS... FIVE SIXTHS..." nature, and receive cheerleading in return!
  9. post your COMPLETED CODE TOUR to [info]dw_dev, making sure to tag it with "code tour"
  10. gnaw on your nails until people start telling you it's okay: you have now achieved SUCCESS