Apply suggestions from code review

Co-authored-by: Sylvia Moss <moss@hashicorp.com>

packer-plugin-sdk/communicator/config.go

@@ -24,7 +24,7 @@ import (
 	"golang.org/x/crypto/ssh/agent"
 )
 
-// Config is the common a builder uses to define and configure a Packer
+// Config is the common configuration a builder uses to define and configure a Packer
 // communicator. Embed this struct in your builder config to implement
 // communicator support.
 type Config struct {

packer-plugin-sdk/communicator/doc.go

@@ -5,6 +5,6 @@ Normally, a builder will want to implement StepConnect, which is smart enough
 to then determine which kind of communicator, and therefore which kind of
 substep, it should implement.
 
-Various helper functions are also supplied. CommHost
+Various helper functions are also supplied.
 */
 package communicator

packer-plugin-sdk/net/configure_port.go

@@ -1,4 +1,4 @@
-// package net contains some helper wrapping functions for the http and net
+// Package net contains some helper wrapping functions for the http and net
 // golang libraries that meet Packer-specific needs.
 package net
 

packer-plugin-sdk/packer/doc.go

@@ -11,7 +11,7 @@ absolutely necessary.
 
 Plugins will need to implement either the Builder, Provisioner,
 or Post-Processor interfaces, and will likely create an Artifact. The
-Communicator must be implemented in the Builder and is then passed into the
+Communicator must be implemented in the Builder and then passed into the
 Provisioners so they can use it communicate with the instance without needing
 to know the connection details.
 

packer-plugin-sdk/rpc/init.go

@@ -1,7 +1,7 @@
 /*
 Package rpc contains the implementation of the remote procedure call code that
 the Packer core uses to communicate with packer plugins. As a plugin maintainer,
-You are unlikely to need to directly import or use this package, but it
+you are unlikely to need to directly import or use this package, but it
 underpins the packer server that all plugins must implement.
 */
 package rpc