[Libreoffice-qa] Reminder: QA Meeting on Wednesday

m.a.riosv miguelangelrv at libreoffice.org
Thu Nov 26 12:06:07 PST 2015


El 26/11/15 a las 2:31, Joel Madero escribió:
> Hi There,
>
> On 11/25/2015 02:04 PM, m.a.riosv wrote:
>> BTW would be nice listen from the candidates their opinion about
>> concrete matters like this one.
>
> I would be surprised if there was any deviation for any of the
> candidates - we've discussed this at length on the Board. Hell I just
> brought it up today (saying it came up again in QA) and well, there was
> unanimous consensus and hopefully one of the developers will write a
> nice blog post about this issue to put it to rest once and for all.
> Telling others what to do is not how we work. We have a strong culture
> of "the doers decide" and the "doers" stick with what they "do" - thus
> again, I really do think there is a solution here.

"Telling others what to do", nothing is further from my mindset.

For your words seems everything is cooked, then why do the voting?,
expending resources and time.

I don't care on to have the reason, but reach some kind of progress to solve
a problem, problems don't disappear by saying not and looking for other
side, usually only get worse.

>
> If QA members just bisected each regression (fully bisect) and
> prioritized correctly I *honestly* believe that the regression count
> would fall. I don't understand why this point is being ignored as it's
> literally *completely* in our control.

01/08/15 - jmadero.dev at ...com
"I skimmed this and really...this isn't how the team works. We don't have
someone come and "insist" and "dictate" how we do our work. If you want then
the best thing for you to do is "lead by example" and then if it works,
others will follow."

Please take in account for yourself. I can't find in bugzilla how many
bisects you have done along the last year.

The concept is clear, but why is a QA job?, collaboration it's a matter for
two or more. I don't like the work flow, so wrongly or not I choose what to
do, hope it is a right for everybody?

>
> Anywho, I like the spirited conversation I just don't see any actionable
> item. I suggested that Pedro go track down developers to agree with him
> but he quickly dismissed that (because he couldn't convince me?) and
> asked Robinson or someone else to do the work of bringing up to the ESC.
> The ESC has also talked about this at length and rejected it (on several
> occasions). I've spoken with many of the developers who join the ESC and
> all of them reject this concept of QA dictating what they do, or that
> there should be any quasi-dictating by having "fix builds" or the like.
> But again, it's not outside of any of your powers to broach the subject
> yourselves on the dev list and pitch *concrete actionable ideas*.

I never talked about dictate no one what to do, who am I for that?, but who
choose what to do, must follow the project norms/rules or how you want call
it, in fact there are rules.
You can buy the car that you like or can, but you must follow the traffic
norms.

>
> At the same time, I highly encourage thinking about compromise positions
> - which I think I have actually given a good compromise. If we can go to
> the ESC and say "look our QA team is frantically doing *comprehensive
> triaging* and bisecting each and every regression, can you take over
> now? That seems like a more positive way to move things forward.

I have expressed some ideas several times, basically about if something can
be done to prevent the bugs, but you and by your comments everybody has only
an answer, all to the bin. So IMHO the ball is in your roof, but please
clean from your mind that QA people, at least me not, are here for your
...., it's for the project.

An example, one dev implements a new enhancement, a report comes in
bugzilla, a QA person confirm and bisect, sometimes a lot of their free time
for that, the dev patch the issue, also sometimes, with a simple change '>='
for '>', she/he is the Author, she/he has improved their stats, nobody
knows/cares about the QA person work.

And the conclusion is that QA must go behind devs begging for I don't know
what, I have no words.

Maybe will be better if you and who thinks like you, rethink about how the
people can approach to the QA, without the option to feel that they are
there only to clean the basket.

>
> Best,
> Joel

But I don't think into give up, fortunately some things are changing, as a
much more significant attention to the help or the interesting discussions
about more and better regular test, or even easier to see taking a look to
last minutes of ESC.  I'm feeling a bit happier. 

I hope sooner rather than later we find the space to propose achieve an ISO
certification in a few years. What really would be a key for open a lot of
doors.

Miguel Ángel



--
View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167534.html
Sent from the QA mailing list archive at Nabble.com.


More information about the Libreoffice-qa mailing list