A proposal to combine quality and bugsquad teams
Nicholas Skaggs
nicholas.skaggs at canonical.com
Thu Oct 24 20:28:38 UTC 2013
Matthew, thank you for pointing this out. I know you've triaged a bug
from a tablet before haven't you?! :-p
I updated the pages to reflect everything that's been said, please have
a look:
https://wiki.ubuntu.com/QATeam/Roles/BugTriager
I removed SRU verification from the tester role, but left in triaging. I
made no mention of release / devel specific triage activities -- thanks
for clarifying Matthew.
* Note obviously there will be much more wiki and other work to do if
the merge moves forward ;-)
Nicholas
On 10/24/2013 03:46 PM, Matthew Fischer wrote:
> I think the release distinction for triage is artificial and possibly
> incorrect. Unlike a tester, a triager does not need to have the
> release, specific software, or even required hardware to triage a bug.
> They mainly exist to move new bugs into the right bucket, remove
> dupes, and to get bugs into a triaged state (Full list of
> responsibilities <https://wiki.ubuntu.com/BugSquad>). They certainly
> can attempt a repro if possible, but it's not necessary. Pretty much
> everything the triage person does is possible from a web browser open
> to Launchpad and maybe Debian/Gnome BTS. They could triage bugs on a
> Windows tablet for all it matters. Note: not a recommended platform
> for triage ;)
>
>
> On Thu, Oct 24, 2013 at 9:39 AM, Nicholas Skaggs
> <nicholas.skaggs at canonical.com <mailto:nicholas.skaggs at canonical.com>>
> wrote:
>
> On 10/24/2013 08:49 AM, Matthew Fischer wrote:
>
> I'll second what's been said here by Dave. Combining the teams
> is a good idea. The Bug Squad team could benefit from having
> more active management. Howver, the Tester role needs to be
> expanded or perhaps a new role added. As Dave said, people on
> the Bug Squad do not always run dev releases. Many are still
> on precise, triaging bugs there. And I think bug triage should
> be called out as a separate activity.
>
>
> Hmm, ok, so we can add a 4th role without it getting too confusing
> ;-) Shall we call it simply 'bug triager', and focus the
> activities on doing SRU's and stable release triage work?
>
> If we do so it might make sense to push the SRU activity to this
> role from the 'tester' role. Essentially then you would have the
> following in regards to bugs --
>
> testers, working on the devel release and doing bug work around it
> bug triagers, working on the stable release(s) and doing bug work
> around them
>
> Does that distinction work well? Folks of course can still do both
> roles, I would just like to define them crisply for newcomers :-)
> I would like to encourage any current bugsquader's who've only
> dabbled in the devel releases to take a more active tester role (I
> think you might find it quite enjoyable), but there is no
> obligation to change your commitment level. I'm pushing us as a
> team to run the devel release for the entire cycle and look for
> bugs as we do so -- I think it's a fun and exciting way to be
> involved and it will really help find bugs sooner and get them
> fixed. I think bugsquaders may enjoy doing this also :-) For those
> bugsquaders adhering to only stable releases, the proposed 'bug
> triagers' role should fill that niche and contain everything you
> do today.
>
> For example, Dave mentions
>
> I primarily triage and don't test.
> Other than one or two dev installs as part of a cycle, I'll tend
> to only test things in bugs being triaged for
> repeatability/repeatability
> on the latest dev.
>
> I think this is perfectly fine, and I would consider you today to
> have a "tester" hat on :-) Your current activities wouldn't have
> to change at all.
>
> So how does adding the additional role sound? If we like it I'll
> add it to the wiki.
>
> The feedback I've recieved on and off list has been positive. Does
> anyone have any concerns about the transition? Do you know of
> activites that aren't yet listed on one of the roles pages? I
> don't want to lose anything!
>
> I'd like to leave this thread open for a bit longer to collect
> feedback before we commit one way or the other so everyone has a
> chance to read and respond.
>
> Thanks!
>
> Nicholas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20131024/d2e8f5e3/attachment.html>
More information about the Ubuntu-quality
mailing list