openstack-doc-core team mailing list archive
-
openstack-doc-core team
-
Mailing list archive
-
Message #00503
[openstack-doc-core] Bug triaging
-
To:
"openstack-doc-core@xxxxxxxxxxxxxxxxxxx" <openstack-doc-core@xxxxxxxxxxxxxxxxxxx>
-
From:
Alexandra Settle <a.settle@xxxxxxxxxxx>
-
Date:
Fri, 27 Jan 2017 12:10:17 +0000
-
Accept-language:
en-GB, en-US
-
Authentication-results:
lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=none action=none header.from=outlook.com;
-
Spamdiagnosticmetadata:
NSPM
-
Spamdiagnosticoutput:
1:99
-
Thread-index:
AQHSeJZSvQ1HKX08aEqecY05zs2xaQ==
-
Thread-topic:
[openstack-doc-core] Bug triaging
Hi core team,
As some of you may or may not have noticed, I’ve spent the last 2 weeks living in Launchpad Land triaging our, rather large, set of bugs.
I noticed a few things I’d like to bring up with you all now:
1. There were a lot of bugs that were fixed, but not closed.
2. There were a lot of bugs that were triaged for dev doc bugs - not for manuals.
3. There were a lot of bugs that were re-triaged, and instead of being fixed per release, were being moved from Juno -> Kilo -> Liberty -> Mitaka -> Newton -> Ocata. By the time I got to them were completely out of date and already fixed. But this is a scripted action that we are pausing for now.
We need to find a better way to triage these bugs, and ensure we're actually completing them on time. I've been tagging more bugs with low-hanging-fruit and in the last week I've noticed a lot more one off contributors. Which is great! But this doesn’t fix our problems…
I proposed an idea at the docs meeting which was agreed upon and I would like to trial. (You can see our meeting minutes from yesterday here: http://eavesdrop.openstack.org/meetings/docteam/2017/docteam.2017-01-26-21.03.log.html )
I'd like there to be designated bug triager for all 'new' bugs. There are approximately 1-3 bugs max that come into the manuals per-day. It's not a heavy job, but it's something we have to start doing regularly to lighten the load and ensure we’re catching the right issues at the right time. Joseph suggested we could rotate the responsibility, and Andreas suggested that each core takes on this responsibility – which I completely agree with.
Using the appropriate guide tags, the specialty teams would then in charge of ensuring their bug lists are looked after. The rotation would be aligned with the release cycles (another suggestion from Joseph, thank you!).
Other projects take on similar ways to triage their bug list, and I think it would be a valuable move in the future for all of us to take on this responsibility. Thoughts, concerns, feelings, questions?
Thanks,
Alex