Selecting technical writing projects

Current phase:
The 2019 Season of Docs program finished on March 6, 2020. See timeline.

This page contains guidelines for open source organizations on how to assess technical writing project proposals and select the projects they want to mentor in Season of Docs.

Introduction

Technical writers submit their Season of Docs proposals to work on a project with their selected open source organization. The Google program administrators forward the proposals to the open source organizations for assessment and project selection. For details of the steps involved, see the organization administrator's guide.

Assessing technical writer proposals

Technical writing skills and experience

  • Examine the technical writer's prior experience. The technical writer's proposal includes information about their most recent technical writing experience. Ideally, the applicant should have some prior experience in writing technical documentation for the software industry. One of the goals for Season of Docs is to give technical writers the opportunity to get involved with developer-focused products. For that reason, it's not essential that the writer has experience with APIs or SDKs or other developer platforms, even if your project focuses on a developer audience.

  • Focus on language and communication skills. Evaluate the technical writer's proposal from this point of view. Most importantly: Can you understand what the person wrote? As a mentor, your role will be to help the technical writer with the open source processes, tools, and code—you don't want to have to review the text of the resulting documentation too. If you want to do an indepth review of the language of the proposal, look for consistency in punctuation and phrasing, correct spelling, and clear language. Is the phrasing simple or complicated? Are the sentences short or do they run on until they become difficult to follow?

  • Pay attention to doc design and layout. As part of their proposal, the technical writer has the opportunity to provide examples of documentation they've developed. Check the overall layout of the document sample(s). Is the design logical? Can you easily find your way around the document or documentation set? Is there duplication of content or are there obvious gaps?

The proposal

  • Check that the proposal fits your requirements. Does the proposal tie in with any of the project ideas that you submitted for this year's Season of Docs? If the technical writer has proposed a new idea, check that the proposal fits the needs of your open source project, and that you have the right people to help the technical writer achieve the goals of the proposed project.

  • Look for enthusiasm and thoroughness. Does the proposal demonstrate that the technical writer is excited about the project? Consider whether they've put thought and work into the proposal, either by consulting with your organization during the exploration phase, or by adding their own thoughts on how to achieve the project's goals.

FAQ

How do we decide how many projects to submit?

Focus on one or two projects. If your organization has the capacity to mentor more than that, then you can submit more. For each technical writer project, you need at least one mentor (preferably two) who is committed to mentor only that project.

Read the information on how the Season of Docs slot allocation works.

How do we choose which technical writing proposal to accept?

Make sure you select the best of the technical writer proposals you have received. That is, select the proposals that best suit your requirements, and that best fit the assessment guidelines listed above.

Where are the forms we need to submit the selected proposals?

See the organization administrator's guide.