TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
A big part of my job is editing poorly written developer documentation.
As part of the discussion that happened after my firs post here, I got a
better understanding of what he is requesting of me.
He would like for me to prepare git PRs that are specific to single SMEs
for them to review. He had not explicitly asked me to do this in the past.
If you haven't used git, you might not understand what this means. Think of
it as having a Word doc on which you turned on "track changes" for changes
made that relate only to content that a specific SME will review.
Now that I understand what he is asking, I am fine with it. Chalk it up to
people being a bit too busy and understandable misunderstandings arising.
Word play fully intended.
On Wed, Apr 18, 2018 at 12:02 PM, Lauren <lauren -at- writeco -dot- net> wrote:
> On 4/18/2018 11:18 AM, Elisa R. Sawyer wrote:
>
>> ...
>> Dots are only at end of items in list if each item is a full sentence. ...
>>
>> He's wrong, and of course it is easy to find information online that
>> refutes his claim.
>>
>
> You are correct that he is mistaken about grammar rules. Although he may
> be correct about the structure of the list items. If it is the case that
> the list items must be incomplete sentences without periods, then make the
> introductory clause a complete sentence that ends with something like, "in
> the list that follows."
>
> This he did in the context of pushing me to complete a task and complaining
>> that I had edited topics within the chapter-size chunk of developer
>> documentation while coming to an understanding of the context of the new
>> topic I created.
>>
>
> I do not understand what you are saying here. If the developer
> documentation should remain unedited, then do not edit it. There may be a
> developer reason for how something is written. Avoid being a grammar cop in
> developer document. If developers are the audience, then write for
> developers and not for the general public who requires grammatical
> correctness.
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Visit TechWhirl for the latest on content technology, content strategy and
> content development | http://techwhirl.com
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as elisawyer -at- gmail -dot- com -dot-
>
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
--
Elisa Rood Sawyer
~~~~~^~~~~~
Technical and Creative Writer
"Apparently there is nothing that cannot happen today." Mark Twain
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com