Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Resources

Page tree
Skip to end of metadata
Go to start of metadata

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.

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.


  • No labels