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

Latest revision as of 19:58, 22 October 2022

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 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 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 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 main

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 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 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
   • sometimes they have been kind and left a sentence or three labeled "CODE TOUR"
   • 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 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