XoopsWiki - QA and Testing : XOOPS Project

XOOPS

Home All about XOOPS XOOPS News XOOPS Links Board of Advisors XOOPS Innovators XOOPSers Awards License Terms of Use Link to us Refer a friend WOX Newsletter

Lost Password?

Register now!

Support

Support Forums Forum New Posts International Support

Downloads

XOOPS Core Modules Module Packs Themes

Documentation

Wiki FAQ Demo API

Development

SourceForge dev.xoops.org Code SVN Report Bug Request Feature Submit Patch

Why have a Quality Assurance(QA)Program within the Xoops Project

to facilitate end user experience (no bugs ==> happy users)
to harmonize the look and feel of xoops websites
to make the gui homogeneous
to facilitate API appropriation by new users
to promote creation and facilitate future evolution
to facilitate knowledge sharing
to increase the overall security of your website (on application point of view)
to act as professionals

Quality should be a pragmatic approach and should not limitate the creativity, but should facilitate it. Quality is one of the tool that make it possible to match the Xoops_Essence_&_Project_Manifesto

[edit]

Mandatory Points to promote Quality in the Xoops Project

To promote Quality in our projet, here are some points we must take care about :

[edit]

A common and well shared behavior ("quality in everything we do")

To promote a professional behavior in everything we do ==> quality IS a community effort, not an effort dedicated soley to a team

[edit]

Promotion of due experts

There is a need to look for expertise.

[edit]

Roadmaps (no patchwork)

A project roadmap
A core roadmap
A supported technologies roadmap
An architecture roadmap

[edit]

A documented API

API Naming Conventions (core, modules, themes)
Core API documentation
A strong database model : to build a strong, efficient (scalable / high performances) and extensible solution
Release protocols, release naming convention

[edit]

Module and theme "how to"

There are already 2 dedicated guides :

module how to
theme how to

Moreover, there is a need of one theme and one module samples (1+1) ==> to push ahead quality, to indicate a way of coding, and to demonstrate perfect use of the Xoops API ==> those samples should be distributed within the xoops release package as default module/theme

[edit]

A clean module/theme repository

we need to try to keep the repository as clean as possible, to simplify the end user experience
end users should be able to find the best/must have modules easily (popularity of the module is one way to find the 'must haves').
all non maintained modules (> 18 months for example) have to go to a cementery category, so that we signify that this module is waiting for someone to reactivate the dev of it. SEE: DeadModules
all modules that are not compatible with latest release of xoops (now >=2.0.18) have to be declared as such : user comments are one way to identify these modules
we have to focus on PHP5 exclusively when the core is complete in order to guaranty php4 compatibility, which will happen soon. Php4 is already an abandonned branch (except for sec reasons), we have to prepare that event. FYI, php6 will be released before the end of the first trimester of 2008.
of course we have to find the pragmatic approach. the rules should be set in accordance with reality : maintainers have to minimize their work, because maintaining the repository is not an easy task, so keep it easy should be our tagline.

==> we must promote all the best modules in order to promote the state of the art, e.g. to give great samples for newcomers (users or devs). We definitely need to be more professional by increasing the quality of the work. And that does not mean more complicated, but requires that we demonstrate how to use all the powerful features of the xoops API so that developers can create modules using the xoops API correctly (for compatibility reasons).
==> For that we have to push ahead and must have/state of art modules... by the way the solution should be "keep it easy", because someone will have to maintain something

[edit]