[OpenStack-docs] openstack-doc-tools on Launchpad

Brian Moss kallimachos at gmail.com
Thu Feb 16 04:33:43 UTC 2017


On 15 February 2017 at 11:21, Anne Gentle <annegentle at justwriteclick.com>
wrote:

>
>
> On Mon, Feb 13, 2017 at 10:57 PM, Brian Moss <kallimachos at gmail.com>
> wrote:
>
>>
>>
>> On 14 February 2017 at 13:45, Anne Gentle <annegentle at justwriteclick.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Feb 13, 2017 at 8:44 PM, Brian Moss <kallimachos at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> There is an openstack-doc-tools [1] project in Launchpad. It asks
>>>> reporters to file bugs in openstack-manuals [2]. The openstackdocstheme
>>>> project in Launchpad does the same thing [3].
>>>>
>>>> For the openstackdocstheme project, bug reporting has been disabled.
>>>> This ensures that reporters will file theme bugs in openstack-manuals.
>>>>
>>>> For the openstack-doc-tools project, bug reporting is still enabled.
>>>> This means that some tools bugs are reported in openstack-manuals, and some
>>>> in openstack-doc-tools.
>>>>
>>>> I propose that we migrate the existing bugs in openstack-doc-tools to
>>>> openstack-manuals, then disable bug reporting in openstack-doc-tools.
>>>>
>>>> Please let me know if you think this is a good/bad idea.
>>>>
>>>
>>>
>>> A year ago last month I established the Launchpad bug tracker. [4] The
>>> skill set and people could then grow in a focused direction. Plus it allows
>>> for less split attention, and the bug numbers in openstack-manuals can
>>> accurately reflect docs and content quality, not tool quality.
>>>
>>> What is the reasoning for consolidating? I'd like to hear more about
>>> your reasons and why bug reporting was disabled for the theme, for example.
>>> We could use separate tracking for the logo and web theme changes, for
>>> example, so I see the separate tracker as a good way to separate concerns
>>> and prioritize without distracting content work.
>>>
>>>
>> I actually don't know when or why bugs were disabled for the theme. Maybe
>> someone in the know can chime in?
>>
>> The doc-tools project says "File bugs at https://bugs.launchpad.net/ope
>> nstack-manuals" in the description. Consequently there are tools bugs in
>> openstack-manuals. Not everyone reads that message though, so there are
>> also tools bugs in doc-tools. My proposal was based on analogy with
>> openstackdocstheme, which tells reporters to file bugs in openstack-manuals
>> and has disabled bug reporting. In addition, the Contributor Guide
>> currently indicates that doc bugs for openstackdocstheme,
>> openstack-doc-tools, openstack-manuals, and security-doc should be filed in
>> openstack-manuals (http://docs.openstack.org/con
>> tributor-guide/doc-bugs.html), and that tools bugs should be filed in
>> openstack-manuals (http://docs.openstack.org/con
>> tributor-guide/doc-tools/contributing.html#file-a-bug-against-the-tools).
>>
>> But I'm quite happy to go the other direction if people would prefer. We
>> could add a note to the openstack-manuals description instructing people to
>> file tools and theme bugs in their respective projects, and then migrate
>> all those bugs out of openstack-manuals. We'd also need to update the
>> contributor guide appropriately.
>>
>> The end goal is making it clear for reporters where they should file
>> bugs, and making it clear for contributors where to look for bugs. On the
>> one hand, it makes sense to keep tools, theme, and content bugs in separate
>> projects to minimize noise. On the other hand, there are benefits to
>> consolidating all the bugs in one place as it gives the theme and tools
>> work more visibility.
>>
>>
> My thinking was that our goal right now is to reduce the bug count in
> openstack-manuals, and sorting more precisely helps with that goal, which
> in reality isn't about the count but about the doc quality.
>
> So I'm inclined to update:
> - bug reporting in the theme docs
> - wording in the openstack-doc-tools project
> - contributor guide instructions
>
> That'll keep us going along the top priority, accurate bug counts. Here's
> a patch for the openstack-doc-tools README.rst: https://review.
> openstack.org/434006.
>
> Feel free to review there or write back here on the list. Would also like
> to hear from Andreas -- he was the one who set up the bug tracking in
> mid-2015, not me, heh.
>
>
Theme bugs in openstackdocstheme and tools bugs in openstack-doc-tools
works for me if it suits everyone else. Andreas, did you have any thoughts?

Brian


> Anne
>
>
>> Cheers,
>>
>> Brian
>>
>>
>>> Say more about your idea so I can better evaluate the need.
>>>
>>> Anne
>>>
>>> 4. http://lists.openstack.org/pipermail/openstack-docs/2016-Jan
>>> uary/008192.html
>>>
>>>
>>>>
>>>> Cheers,
>>>>
>>>> Brian
>>>>
>>>> [1] https://launchpad.net/openstack-doc-tools
>>>> [2] https://launchpad.net/openstack-manuals
>>>> [3] https://launchpad.net/openstackdocstheme
>>>> <https://bugs.launchpad.net/openstack-manuals>
>>>>
>>>> _______________________________________________
>>>> OpenStack-docs mailing list
>>>> OpenStack-docs at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Read my blog: justwrite.click <https://justwriteclick.com>
>>> Subscribe to Docs|Code: docslikecode.com
>>>
>>
>>
>> _______________________________________________
>> OpenStack-docs mailing list
>> OpenStack-docs at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>>
>>
>
>
> --
>
> Read my blog: justwrite.click <https://justwriteclick.com>
> Subscribe to Docs|Code: docslikecode.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20170216/f909515d/attachment.html>


More information about the OpenStack-docs mailing list