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/
signature.asc
Description: This is a digitally signed message part
