Incomplete with no response >30 days

[HggdH]

On Tue, 2008-05-27 at 12:38 -0700, Jordan Mantha wrote:

> While I do think this could be a good "solution", why not just educate
> people on what kinds of bugs are out there? 

Both of them should be pursued. Clear identification -- even redundant
-- is always better. At the same time errors should be pointed out and
corrected with good manners.

But, on the other hand, there are bugs, and there are things that look
like bugs, smell like bugs, and feel to the touch like bugs, but are not
bugs. Duh.

The fact is we are overloading the BTS with tasks, we are using the BTS
a bit outside its original scope. As such, both education and clear
markings could be used. 

This is not the best possible scenario, but is one that would allow us
to keep on until LP development catches up.

> I have great confidence in the learning abilities of Ubuntu
> contributors and I think it's often better to educate rather than
> ignore/hide/obfuscate. From what I've seen almost all cases where
> we've had problems is when people didn't know any better. That sounds
> like an education and community integration problem to me. Triaging is
> a part of the Ubuntu development process and as such triagers and
> packagers should be working together in a common space and with common
> goals. Triaging is a subset of development activities and so triagers
> should be within that community and should feel like they are.

Good point. We can also add in the fact that some packages would benefit
from specialised trial requirements. The bugsquad has some requirements
written [1], but it is rather incomplete. Developers/maintainers with
specific requirements could help writing their "ideal" bug data; the
bugsquad can help in normalising all contributions, and putting them
available on the wiki.

Reinhard Tartler, for example, has just done so (see [2]), and we are
trying to contact him to get it published (TZ issues caused me to fail
on that today).

And, to stress Jordan's point -- education helps a lot. Always. Even
when some say users cannot be educated (and I myself have said that, in
despair, when trying to explain some requirements or clear up some
misconceptions -- not amazingly, mostly related to security).


> I believe it was only when triaging was split off into it's own entity
> because of scaling issues and the two communities (triagers and
> packagers) grew apart that we ran into problems. 

I was not playing with Ubuntu when this split happened but, having
worked on some software houses, this does not surprise me.

Yes, they will grow apart: they deal with different issues.
Nevertheless, triaging is an ideal exposure for future developers, if a
triager wants to go in this direction. But we should not allow triagers
and packagers/developers/maintainers to grow so much apart as it seems
to be the case nowadays. We need, we desperately need, to maintain a
dialog.

We also depend on the contributors from all sides. Ergo, dialog is
required. Respect for both sides is required.

> Can we perhaps work to bring them back together more? If I were a
> budding triager (as I was once upon a time) I would want to know about
> *all* kinds of bugs and how they're used and to talk with packagers
> about how they do what they do. Would something like a mentoring
> program be feasible? Perhaps triagers who have similar working hours
> to a developer/packager/advanced triagers can work with them on the
> education process. Perhaps also weekly Triager Education classes could
> be done to go over issues like workflow bugs. I don't expect things
> like workflow bugs to be obvious to new triagers, but I *do* expect
> them to have a willingness to learn because that is at the heart of
> our community.

It is clear, methinks, that more education classes on (for example)
#ubuntu-classroom) are needed. Another good point.

Everybody must be willing to learn. Triagers must learn about specific
packages requirements, and packagers must learn (or remember) what it is
to do support on high volume. 

And, as far as I can understand, this all has to be documented, and the
procedures should as much as possible *not* create exceptions (or, at
least, not create too many of them).

..hggdh..

[1] https://wiki.ubuntu.com/DebuggingProcedures I note that the material
there was written by contributors from all areas.
[2]
https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-May/000863.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20080527/8db30658/attachment-0001.pgp