Il giorno dom, 23/01/2011 alle 10.00 +0100, Torsten Veller ha scritto:
> 
> The current "QA team's role and purpose" (GLEP 48) always talks about
> the QA TEAM -- and I think this is good: QA needs a leader who can
> build
> a team IMHO. 

I'd be all for not having to specify so much the presence of the QA
lead, but the problem lies in what the past year taught us: devrel will
refuse to cooperate to anybody on the QA team but the lead.

With "cooperate" here I don't only mean "listen to the requests for
suspension"; devrel refused to keep the team as a whole in the loop of
pending requests, as well as ignoring any evidence/suggestion coming
from single team members.

Which is why they "force" us to actually specify a lead in our very
definition.


> "the lead will be held responsible for their actions"
> I think this can be dropped: the team is responsible for its actions
> anyway
> (whatever that means) and the lead will be replaced soon too.

It's a matter of bringing some balance in the game; if we drop the four
months rule, one could expect that the lead could call in his cronies
just to take over QA. By forcing a lead to take direct responsibility
for the people he or she let join the team.

Maybe I should specify it better, but it was intended as implicitly not
making the lead be directly responsible for the members that were on the
team _before_.

> "be ascribed to bona-fide mistake" --
> how can we evaluate this?
> 
> Do you think this rule would have been used in the past?

This would be easy to pass under the "it's just common sense" idea, but
I wanted to have it in anyway. If a developer ends up breaking the tree
by simply not thinking about the effects of his or her action, that's
bad, but it's one thing.

When a developer knows very well what his or her actions imply but still
applies them without caring about the repercussions, that cannot be
ascribed to bona-fide.

As an example, think about a developer committing a non-masked package,
the installation of which prevents Portage from completing its tasks
correctly. By default it's just a mistake, but if said developer
actually provided the fix beforehand to the Portage team but then didn't
wait for it to be deployed before committing the package, then it cannot
be a mistake in good faith.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/