[Bugsquad] Long range planning (and Seli background)

[A. Spehr]

> I'll be frank, bug triage is
> boooooring, especially to those that develop.

That's why I'd rather old people do the occasional bugday, and 
otherwise work on bugs for projects they find *interesting* on their
own vs. just do bugdays and burnout from being bored. 

But I'd like to know what other people think, and maybe I shouldn't
have said that just yet. ;) 

> Keeping large, public triage days is going to be a big deal as far as
> our long term viability. 

Yes, I think it will keep new people showing up. :)
And we haven't been around long enough to figure out what how long
people will actually be active triagers for. Maybe if we ask people who
used to, we can get an idea of what to expect. So far, I think we've
had really good retention, people who did two sets of bugs/bugday, I
think, always come back for another. I keep meaning to draw up a 
little attendance chart... I mean, I don't think I'm making this up?

> If folks after doing the triage days wish to,
> of their own initiative start up triaging projects... that would be
> great! More on what is required to make that happen...

I think it reasonable to coordinate on that. Both internally, and
with developers. I suspect that people "leading" a project are likely
to be a junior-junior developer, and that we'd lose them eventually to
it. 

>> Also:
>> Technical triage notes:
>>
>> Other projects...??? Have you talked to them? 

Right, I should also mention that my guess is konq file system bugs
that still exist in 3.5.x aren't ever going to get fixed. Unless 
somebody clones dfaure... 
I think they're a safe close. He probably even told us that during
that one bugday. I don't remember...

> This... is very useful. If we could get projects to specifically lay
> out what they would like to see triagers do in their bugzilla space,
> we could get more activity. Important things are, what is your policy
> with KDE 3.5.x bugs. Do we close, or simply note that they need
> closing? Any other specific things to their project? Having kde
> projects that want our help lay these out somewhere would advance our
> cause, and make it easier to branch into task forces when the project
> grows.

Yes, we need to go corner everyone else. :)

I note that aRts is still in bugzilla, I'm pretty sure that's been 
discussed somewhere, and there was some good reason to keep it. So we
probably shouldn't close them all even though it's obsolete in 4.

And njaard said I'd better not touch his noatun bugs. Even though he
took it out of SVN... 

So obviously policies vary more than might be expected. I suspect it
depends on if the developers have ported to 4, and are using it 
themselves on a regular basis. If they are, they don't want to mess
with three branches. 

> When I did triage on Konq, the worst thing was what to do with the old
> bugs that we could not reproduce in 4.0.x but could do so in 3.5.x. I
> did not get clarification on this issue until I had done over 50 or so

Yes, but we know now! And we know to ask different projects. ;)

> bugs. Another thing, how/if/when/ do we apply a LATER tag. This may
> vary between projects.

David thought we were crazy for using LATER that way, so I think we
should skip the LATER stuff. Just close it, he has todo lists on top of
todo lists.

> In short what I'm advocating here is for us to get active in asking
> the various kde projects (perhaps post to some central mailing
> list...) what their bugzilla policies are. Make it widely known we
> want this info and let the devs tell us. This project has proven its
> value on Konq, so I don't think devs will mind taking the time to
> detail this to us.

Yeah, what would that mailing list be? kde-devel? kde-core-devel is just
libraries, I think? Or do we just corner on irc/email all lead devs?

Alex