<div dir="ltr">Filtering bugs by tags works fine in advanced search, the only problem is that you can't combine it with filtering by releases (since that's broken in advanced search and you have to use milestone page for that).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 12:18 PM, Dmitry Pyzhov <span dir="ltr"><<a href="mailto:dpyzhov@mirantis.com" target="_blank">dpyzhov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We definitely need to assign these bugs to the fuel-docs team. And there is a good point from Alexandra Fedorova that commit message needs to have enough information for tech writer. And reviewers should not merge fixes that do not apply this rule. Otherwise we will end up with new bottlenecks.<div><br></div><div>One bottleneck is bug triage with bunch of badly formatted bug reports every day. And another bottleneck is bugs on fuel-docs team. They will have to drive each bug, find a developer, get the information, find a place for it and so on. Let's try to make their life easier.</div><div><br></div><div>And another point. I don't like bug tags. You can not see them from the milestone page. You can not filter out documentation bugs even from advanced search page. We could try to add [doc] prefix for bug subjects automatically. It will help a little bit.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 9, 2014 at 12:27 AM, Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Hi,</div><div><br></div><div>Dima, that's really good approach. </div><div><br>Mike, technical writer may ask developer and assign bug to him/her if bug impacts developer documentation only.<br><div><br></div><div>Best Regards,</div><div>Sergii Golovatiuk</div></div><div><div><div><br>On 08 Oct 2014, at 21:08, Mike Scherbakov <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Thanks Dmitry,<div>let's try to go this way and correct process if needed when we get first results.</div><div><br></div><div>> <span style="font-family:arial,sans-serif;font-size:12.8000001907349px">Where is your 80% dev vs user docs figure coming from?</span></div><div><span style="font-family:arial,sans-serif;font-size:12.8000001907349px">it's no more than my guess. We will see real number over time.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 10:31 PM, Dmitry Borodaenko <span dir="ltr"><<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At the moment OpenStack infrastructure doesn't allow to customize the<br>
bugs it creates, we should propose a patch at some point to implement<br>
that. When we do, I think we should assign such bugs automatically to<br>
fuel-docs team.<br>
<br>
I don't think we should separate user and dev docs bugs, we're working<br>
in the opposite direction towards merging dev docs into fuel-docs:<br>
<a href="https://review.openstack.org/124551" target="_blank">https://review.openstack.org/124551</a><br>
<br>
Where is your 80% dev vs user docs figure coming from?<br>
<br>
I think that whether it's dev or user documentation, a technical<br>
writer should drive the process, collect information from the commit<br>
author, and add it to the right documentation areas. It's commit<br>
author's responsibility to provide an informative commit message in<br>
the first place, to answer technical writer's questions, and to review<br>
docs commits that address the DocImpact bug.<br>
<span><br>
On Oct 8, 2014 10:59 AM, "Mike Scherbakov" <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>> wrote:<br>
><br>
> Very good improvement in our documentation process.<br>
><br>
> Is there a way to configure it, so bugs would be created with tag "docs" automatically? It would simplify triaging process I believe.<br>
> From the other hand, as far as I understand, up to 80% of commits with "DocImpact" will impact development documentation (or it's intended to be affecting only user documentation?). It would be hard for tech writers, who are mostly specialized in Fuel user docs, to work on low-level details of how, let's say, l23network [1] works.<br>
> Do we want to separate docs bugs somehow, user/dev?<br>
><br>
> In other words, what would be the flow, who becomes responsible for fixing bugs created automatically by Infra?<br>
><br>
> [1] <a href="https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network" target="_blank">https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network</a><br>
><br>
> On Wed, Oct 8, 2014 at 5:34 PM, Sergii Golovatiuk <<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Fuel Summit '2014 we discussed our Documentation process. According to follow up we aligned it to OpenStack 'DocImpact' process. The new process has been tested on background by me and Bogdan Dobrelya. Today, I have updated Fuel Documentation Process so we are making it official.<br>
>><br>
>> Why?<br>
>> Developer perspective:<br>
>> It gives more flexibility for the developers to participate in Documentation Process. Every time when the Reviewer sees that patch requires Documentation update, it may ask the Commiter to update 'Commit Message' with DocImpact message. Once patch passes the review Openstack Infra will trigger a new bug in Launchpad that should be assigned to Fuel Documentation team.<br>
>><br>
>> From Fuel Documentation Team perspective:<br>
>> When Fuel Documentation Team sees this bug they know who was the commiter and reviewers and whom they should add for documentation review.<br>
>><br>
>> Community:<br>
>> Community member may ask the developer to put 'DocImpact' message when it's required.<br>
<br>
</span><div><div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Dmitry Borodaenko</div></div>
</div>