Google Season of Docs 2020

Each year Google brings students and open source projects together in the Season of Docs. This page tracks Wireshark's participation in GSoD 2020.


The ideas below have been contributed by Wireshark's community of developers and users. Some of them are "what ifs". Some are based on very specific and immediate needs. Either way, if you are a student you should contact the submitter/mentor or the wireshark-dev mailing list for background information or clarification before submitting your proposal. More information about wireshark-dev and complete list archives can be found on the mailing lists page.

If you are adding an idea below, please be as clear and provide as much information as possible. Projects that can be completed in about 12 weeks are preferred.


We're collecting proposals for projects. See "Ideas" below. The mentor organization application has *not* been completed.

Important dates (from Timeline):

  • 2020-04-13 20:00 UTC - Mentoring organizations can begin submitting applications to Google.
  • 2020-05-04 20:00 UTC - Deadline for organization applications
  • 2020-05-11 12:00 UTC - Google publishes the list of accepted mentoring organizations
  • 2020-06-09 18:00 UTC - Start of technical writer application period
  • 2020-07-09 18:00 UTC - Deadline for technical writer applications
  • 2020-07-31 20:00 UTC - Deadline for project selections by organizations
  • 2020-08-16 22:00 UTC - Google announces the accepted technical writer projects
  • 2020-09-14 - Doc development officially begins!
  • 2020-12-05 18:00 UTC - Technical writers submit their project reports, also known as final work products



  1. User's Guide updates

  2. Developer's Guide updates

  3. Wiki updates

  4. Add quick starts / tutorials via Qt Help

  5. Man page updates

  6. There are 35 menu items that aren't documented in the User Guide. These are indicated in the docs as "Not yet written. See"

  7. The User Guide references the Wiki. Move any referenced information to the User Guide and Developer Guide so that a single release's guides has all of the information.

  8. There appears to still be some ambiguity to what belongs in the Wiki vs the User Guide. One possible approach would be to move any Wireshark-specific guidance from the Wiki to the User Guide and then remove it from the Wiki. (note: this has overlap with #2)

  9. Proofread and review the existing guides for clarity and accuracy.

  10. Update screenshots from GTK UI to QT UI. Document (in comments) which version of Wireshark was used to create the screenshots.

  11. Remediate the known documentation issues in Bugzilla:

  12. Update USBPcap website. Write new tutorial including the extcap integration. Document what different "USB packet" types supported by Wireshark really are.

  13. Expand the preferences documentation. For example, the column preferences have a lot of functionality that is either undocumented or sparsely documented.

Draft Proposal

The main goals of this project are to reduce the friction for new Wireshark users and developers to get up and running. As such, this project consists of two major tasks:

  1. Review new contributor information in the Wireshark Developer’s Guide, write a friction log, and fix all discovered issues. There is an existing “Quick Setup” section in the Developer’s Guide, but it is missing significant details and is far from quick for Windows. The technical writer will likely prefer to rewrite these materials entirely.
  2. Write a “Quickstart” guide for new Wireshark users to help them launch Wireshark and understand basic packet details as briefly and effectively as possible.

There are many other documentation-related tasks that could improve the general user experience. Time permitting, some additional tasks could include the following:

  1. Write documentation for common use cases, including:

    1. Decrypting HTTPS traffic with Wireshark
    2. Extracting files from HTTP traffic
  2. Review all user-facing strings in the GUI for clarity and consistency

  3. There are currently 37 mentions within the Wireshark User’s Guide of materials which are “Not yet written”. Write this missing documentation.

  4. There are approximately 50 references to the Wireshark Wiki in the Wireshark User’s Guide. The Wireshark documentation would be more usable if users had all the information in one place. If this subtask is chosen, the technical writer and mentor will review these references to come up with a list of which wiki references should be migrated into the Wireshark User’s Guide.

  5. Wireshark enables users to directly open a related Wiki page with the “Wiki Protocol Page” button in the context menu for protocol fields in the packet tree. Not all protocols have an entry, and for those that exist, they may not be well-structured. A full list of Wiki pages (~1200) is available here: We have a list of popular pages based on page views, these could potentially be used to prioritize updating these references. Maybe a better way to link pages to each other (discoverability) could be envisioned.

  6. The old wiki software (MoinMoin) is being migrated to a new place (potentially GitLab) which uses Markdown as formatting. There are quite some opportunities here to reorganize information and make it more accessible.


The above list of projects are suggested examples. Feel free to propose your own idea on the wireshark-dev mailing list.

The result

The project was successfully finished. The results are published on Successful 2020 Season of Docs technical writing projects web page.

Fun art

This fun art by Alex Nik is under CC BY-SA license. wireshark-tls-small

--. Users might also ask questions on, but are typically requested to open a bug entry if they have feature requests or bug reports.

Imported from on 2020-08-11 23:14:28 UTC