[Bugsquad] Long range planning (and Seli background)

[James Spahlinger]

On Mon, May 19, 2008 at 2:14 AM, Alex Spehr <zahl+kde at transbay.net> wrote:
>
>
> Ok, so that's background. What does this actually mean?
> We're being asked if we're a long-term viable group. How big can we
> grow? How big should we grow? What motivates people? How do we not burn
> out? How long are we likely to keep people until they end up either
> a) being killed by their Significant Others, b) bored, c) developing?

Interesting... Sorry I've not been around much, I've been a victim of
c. I'll try to stick around more ;). *joins IRC channel*

> I see BugDays as being a great way to train new people and bring them
> in. Now we need to figure out what exactly to do with them. I mean,
> surely not everybody wants to do Konqueror bugs. And I'm guessing we
> only have 1000 or so of them left.
>
> So do we set up triage teams of people who want to talk to developers
> of a particular package, and keep up to date with them? Do we all fight
> over incoming triage? (How many a day do we get?)

I'm not sure if we want to split up into multiple groups right away,
I've been gone for a while, but it seems like we did best when we had
a large public effort, and we can continue bringing *new* people in
and maintaining public interest. I'll be frank, bug triage is
boooooring, especially to those that develop.

Keeping large, public triage days is going to be a big deal as far as
our long term viability. 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...

> What do you think?
>
> Also:
> Technical triage notes:
>
> SVG in khtml is under a rewrite as a google summer of code project, so
> its been requested that we ignore those bugs for the most part.
>
> KOffice is undergoing major code change and is ignoring 1.6 bugs, but
> 2.0 is still alpha. So they've requested we not waste time on their bugs
> until 2 is out.
>
> KHTML really doesn't want to futz with 3.5.x. Be very nice, but close
> their bugs if it works in trunk.
>
> Kopete is still fixing 3.5.x bugs.
>
> The MS-Windows port doesn't get many bugs to b.k.o, but to their
> mailing list. I think they want us to redirect any that seem to be
> platform specific.
>
> Other projects...??? Have you talked to them? (Ok, that possibly should
> have been it's own post ;)

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.

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
bugs. Another thing, how/if/when/ do we apply a LATER tag. This may
vary between projects.

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.

Thoughts?