Quality Standards for Modules??

Are there any?

I find some 2.0.x modules don't work right, incompatible, are poorly or not at all documented or even trash your system.

Example: XP Weather V 1.72
Documentation not up to date (refers to V 1.4)
Upon config, a Note: "Not all locations are active, if you choose one that does not work try another near that location"
e.g. San Francisco does not work, yet it appears to be correct in the dB. adding manually SF USCA0987 yields results. So why is it mot workingand the author even notes it?

Example: Blockadmin v.27
Appears trash dB when modules are installed after it.

etc. more to come...

Are there Quality Standards for Modules or not?

B

the QA team is working on defining the standards - which should of course include "does not trash the install"

If you want to help out, contact Dave_L and/or MarcoFr

Keep in mind that this is Open Source software at no cost to you. I look at the modules as gifts to the community because in all reality no one has to release these to us. So with that being said if the modules don't work just right or there isn't good documentation remember that the gift was free to you on the first place. Oh and you could always fix the module yourself or write some better documentation and submit it to the author. In a way you would be giving a gift back.

Well, half of the task would be to report the bugs back to the author. The author has limited testing facilities, limited time and limited resources. Therefore things can change or tests be inadequate and your help be crucial in making the module bug-free.

I don't believe you have to fall on your knees and overload the module developer with thanks just because he has made a module that you would like to use - but which doesn't work. But you should not have too high demands either (I'm talking in general here, it is not aimed at or criticising the original poster)

Some modules will work wonders, some will work and some will fail - that's life at the moment and the best thing to do is to acknowledge that... and try to change it for the better

Welcome aboard and I hope you have more luck with the next module(s) you try.

I am sorry JimLunsford but I do not agree with you.

If a gift is useless, it is not gift…

Consider also XOOPS, PHP, MySQL, Linux … you name it. They are all free but they work!

At least, the module developers should note under which specific XOOPS version they have tested their module and provide a live site link that it is up and running.

We, the no programmers who love and use XOOPS, cannot spend days and days to just check if a module works or to understand what it is doing…
Please try to understand our limited programming knowledge and don’t blame us if we cannot make a module to work if it simply doesn’t or there is not any documentation.

Adding a "tested in version xxx" would be a rather good idea - but I can imagine it could take a long time to do.

Perhaps - as a suggestion - 2 fields added to modules in the repository.... 1 - a QA badge (where applicable) - the second to show what XOOPS versions it has been tested in.

First: Thank you all for your input so far! Much appreciated!

My post is not about "complaining" or” whining" but more so about trying to say that even though free, there is a responsibility toward the community.
Having my work after two weeks of building it up ruined by the carelessness of some programmer is not acceptable, gift or free.

I'm no full programmer and my php knowledge is limited. Thus I don't even attempt to start "editing" modules. But I'm learning.

However, I need to deliver results and such failures of incomplete or poorly designed products e.g. modules can be ruinous. Furthermore it also reflect poorly on XOOPS concept and can damage a great idea and concept substantially.

Linux is free to. You accept to loose your business (because Linux is a gift) because a programmer screwed up or was careless or did not test his product thoroughly ?

By the way, regarding "gift": If you'd build a house and receive tools or the lumber as a gift and then, when almost done, your house build with sweat and many hours of labor collapse or burns down because it turns out that one tools was defective or the lumber rotten or full of termites. How would you feel then?*

I like XOOPS very much, I think it's one great idea and I support it fully as I can.

I am interested to help establish and implement a concept for Quality Control (QC), a sort of "clearing house". It will serve the community and the XOOPS idea making it even better. XOOPS can achieve the greatness it deserves, by follwing the footsteps of the concept and ideology of the Linux QC assurance.

I looking forward to your input.

Best regards,

Basi


*Next time you sit in an airplane, 30,000 ft above ground flying 500+ mph, look out the window, at an engine, and think about one little part in there, a fan blade for example. Aren't you happy that someone took great care that it works, not fails, comes loose or some other part fails or catches fire? Or the surgeon and the medical equipment and tools he uses to (I hope not) operate on you? Or, or, or.

It is that care and QC giving you safety, comfort and peace of mind reaching your destinations and goals.

Just giving a bit of background info to shed light on the comments received here.

Unfortunately we have seen examples in the past that have been somewhat... un-diplomatic... about modules, implying that the module developer has the responsibility for which modules someone else downloads and uses.

Yours was in no way like that and I don't think that the replies implied that it was. It's just that there is a rather fine line between expecting and demanding and I guess people just wanted you to be aware of this.

We'd all like modules that do what we want, how we want it - and reliably so. However, this can not be guaranteed and therefore there is usually some testing and tweaking necessary in order to get things working like we want them to. Anything you can do to help minimise the testing and tweaking necessary will be grudgingly accepted.

And to stay in the analogy :
Quote:
Sure, but I'd also be very happy that the airline technicians have made sure that it does in fact work as intended and don't blindly trust the manufacturer

Sorry if my post offended anybody that wasn't the point. In another Open Source project that I am involved in it seems all people do is demand, demand, demand. That is how I arrived at the gift concept. Which from the tone of the posts after mine people don't agree with that concept. Oh well just trying to help. *crawls back into his corner*

Noone was offended, I think, just discussing the fine balances between useful information and scaring off a new guy