openstack-doc-core team mailing list archive

[Joseph Robinson <joseph.robinson@xxxxxxxxxxxxx>]

On 17/11/2016, 1:10 PM, "Openstack-doc-core on behalf of Lana Brindley"
<openstack-doc-core-bounces+joseph.robinson=rackspace.com@lists.launchpad.n
et on behalf of openstack@xxxxxxxxxxxxxxxx> wrote:

>On 17/11/16 12:55, Anne Gentle wrote:
>>
>>
>> On Tue, Nov 8, 2016 at 5:42 AM, Alexandra Settle
>><alexandra.settle@xxxxxxxxxxxxx <mailto:alexandra.settle@xxxxxxxxxxxxx>>
>>wrote:
>>
>
><snip>
>
>>
>>     Sorry for all the questions! Just many thoughts running through my
>>head. Let it be known that I definitely think this is a good idea! But I
>>suggest some lines are drawn so we are all clearly on the same page.
>>
>>
>> I suggest we try it and see what chaos ensues with these guidelines:
>> 1. If it's technically accurate, merge it. If it fixes a bug correctly,
>>merge it.
>> 2. If it's accurate and correct but could be written better, edit, then
>>merge it with a comment to coach the person how the writing could be
>>better.
>> 3. If it's not the kind of patch we want for the docs, explain that in
>>the review and also follow up to make sure the person doesn't feel
>>rejected outright. Take ownership of the coaching areas more than the
>>"this is wrong and here's why" aspect. (I'm not saying your reviews are
>>like that, mind you, I just want ownership of the growth of contributors
>>and the accurate doc base, not ownership of "it meets our English
>>standards.")

I think that¹s a good set of guidelines, agreeing with Lana. For the first
point as well, and to help out with the ownership and coaching, one idea I
have is to create a weekly 'editing bug¹.

If a patch is accurate and improves the content (but could be written
better) merge it and add the review to the editing bug description. After
gathering one or two reviews, add a patch with the edits and closing the
bug, and then adding the original contributors as a reviewer.

This is a bit more overhead, but it invites new contributors into the
process of continuous improvement, and might help create some distance
from patch and person - the patch has merged, and now the original
contributor can see their work in the doc, and see ways to improve writing.


>>
>
>I like these guidelines!
>
>What about relaxing our requirements on the number of votes required? Is
>a +1 and a +2A enough?

At the moment, I think the current standard is okay, but just my thoughts.


>
>L
>
>--
>Lana Brindley
>Technical Writer
>Rackspace Cloud Builders Australia
>http://lanabrindley.com
>

Best Regards,

Joe Robinson
Information Developer II
 -------------------------------
Joseph.Robinson@xxxxxxxxxxxxx






________________________________
Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Level 1, 37 Pitt Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse@xxxxxxxxxxxxx and delete the original message. Your cooperation is appreciated.