[Sugar-devel] RFC: Catch-all Trac component, bug wrangling team
Tomeu Vizoso
tomeu at sugarlabs.org
Wed Sep 23 04:18:17 EDT 2009
On Wed, Sep 23, 2009 at 00:07, Sascha Silbe
<sascha-ml-ui-sugar-devel at silbe.org> wrote:
> Hi!
>
> I'd like to propose
> a) adding a "catch-all" component on bugs.sugarlabs.org and
> b) making the catch-all component the default.
> c) "finding" a bug wrangler (individual or team).
All excellent ideas!
Regards,
Tomeu
> An increasing number of bugs get assigned to the wrong component (usually
> "sugar" because it's the default) and often just stay there for a long time.
>
> To make a real difference, the catch-all component should _not_ be assigned
> to one of the usual, already busy suspects.
>
> On the Gentoo Bugzilla, Jakub Moc did an awesome job as a "bug wrangler"
> [1]. If you didn't find an existing ticket and filed a new one, he usually
> redirected you to the right one instead (closing yours as duplicate). His
> memory was amazing.
> While I don't expect anyone to even come close to that standard, we could
> use someone doing bug wrangling work, i.e.:
>
> - assign new bugs to the correct component
> - assign type (defect / feature request) and initial severity (data loss ->
> critical, cosmetic change -> trivial)
> - ask for additional information if incomplete (logs, versions, steps to
> reproduce, ...)
>
>
> Please note that detailed technical knowledge is _not_ necessary to do this
> job properly - just a general idea of how the parts of Sugar fit together.
> The developers can easily bounce a ticket to a "sibling" component once they
> know what's going on.
>
> In the past we've had some instances of a Bug Triage (*) team, recruited
> from the usual suspects, each time only lasting shortly (e.g. directly prior
> to SoaS or Sugar release). With a permanent bug wrangling team (or person)
> the workload is spread over time and thus much easier to manage.
>
>
> [1] http://www.gentoo.org/proj/en/qa/bug-wranglers/
> (*) "Triage" is also used by Ubuntu to describe bug wrangling work. I try to
> avoid the term because it describes a military process that has been adopted
> in civil "emergency response" teams. I think it suffices to say that both
> are problematic.
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJKuUqVAAoJELpz82VMF3DaKi8IAJ5/hhNaFC/tIBVsZdDRTn6g
> qIm51WtFN1mSm199qKaLsQPkkh/KJj/HBmrijxzowMaiWGhWoZ3YJ/sw4/q2D6p2
> cN4C623I9L9iUlDpsCjIOz1Cul6LtU2kuidM0Nk1lIDphR/7nNjG7iN3w9Xm7fXG
> YNDYWRujXp65ItnNgwHYᨒ㹔멅ﲦ☸魄㐆黹랍㭼 䐡ľ�
> z4jh9B4Kyd/gs6C0JmYWZfcNSCvUMCbmlFjRybfjsoqYPdQ2/6pfNAZZkJXxmWti
> zzjyCC쎨掵얶ٖƢ쒁瀤⃝с簇ඡ桀�ꨟﲂ鴛体⸬ᅰ=
> =N7Xz
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
--
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning
More information about the Sugar-devel
mailing list