[Libreoffice-qa] When it's time to basic bases?

[Miguel Ángel]

I have had this mail in the freeze for months, but seeing the discussion 
about unit test on dev's ML, the interest for the "Help Authoring 
Extension", and the recent thread in QA ML about how recruit.

There are a lot of fantastic changes and improvements in LibreOffice, 
what I'm sure is a pride for all of us.

But, always there is a but, my perception on a common feel about 
LibreOffice, is that it has a lot of improvements but with too much 
issues.

To find the best way in doing the things, there is not other way than to 
be a bit critics with our self and test if we are doing the things so 
well as we can.

What I perceive is that everyone does what she/he likes and how she/he 
likes, well, maybe a bit exaggerated from my side.

Sure it was fine in the beginning of the project, because at those times 
the priority was to go forward, but some time ago we should have started 
to change to look for a better way. 
http://nabble.documentfoundation.org/Libreoffice-qa-Looking-for-a-new-approach-in-QA-workflow-tc4052468.html

I know sometimes it's needed even more it's indispensable, force things 
and go a step forward to moving ahead.

But I'm feel obligated to insist, that at least a very basic steps to 
follow, need to be established, specially about new improvements.

a) New additions, and specially modifications, implies changes that 
always affect someone in someway, then have a previous discussion in the 
right place of the project, finding the pros and cons, to reach a 
minimal consensus, allows the Author have more security about what is 
doing, having a first feedback for a better implementation.

b) At least with the first commit of any addition, and with new changes, 
a breve explanation, about:
      - What it's the target?
      - How it supposed it must work?

c) Announce in QA ML when the implementation is ready to verify,  with 
what and how verify by QA, so we can do a truth QA job.

d) Encourage make public the intentions about new works, because maybe 
others have tried first and someone can help in some way, avoiding 
duplicated works.

Often putting black on white forces oneself understand better and 
rethink about what is doing, helping in to do it better.

Help others to help, specially for verification purposes. Sometimes is 
hard to help people in forums/ML, but even worse, looking for something, 
when there is not any kind of help in the program and nowhere.

IMHO I's unacceptable having implementations in LibreOffice without a 
minimal help, for me a job without help, it's not finished and it 
shouldn't be released.

I have not doubt, that improving the QA only can leads to a less prone 
to error improvements -> less developing time -> more time for more 
improvements.

Really, e.g., we can't find a way to have professionals, helping in 
develop a better QA process, when we have the opportunity.

Is there any problem on having a basic rules?, or it's possible e.g. 
don't follow the languages rules to write the code.

We must take into consideration that the whole merit for a quality job 
it's for their Author, so I can't see any issue for their side.

Miguel Ángel.

An open project needs open minds.