[jdev] XMPP Certification Opinion Poll

[Sander Devrieze]

This is my long post that I promised to send in another post in this thread.

Op vrijdag 13 mei 2005 04:32, schreef Hal Rottenberg:
> We're having quite a debate on the JSF Members list today.
> (https://www.jabber.org/members/) The main topic is
> certification of open-source Jabber projects.  There are at least two
> types of certifications being discussed, and I'll go over them very
> briefly:
>
> 1) Certification.  You would have several levels.  I'm proposing the
> bare minimum would be 100% XMPP compliance.  Beyond that you would
> have multiple levels, and some would be pertinent to clients, others
> to servers, and perhaps still others would apply to tools, libraries,
> and other categories.  An example is that you can get your XMPP
> button, and if you like, go for a Silver ribbon which means you meet
> XMPP, plus Basic and Intermediate IM Suite JEPs. (That's a totally
> made up example, no real decisions have been made at this oint.)
>
> 2) Official JSF Projects.  This proposal would entail the JSF voting
> on naming multiple projects, as "official".  It would be a badge of
> honor.  It's assumed (by me anyway) that you would have to meet some
> level of certification to become eligible.

I vote for another system:
3) Supported JSF Projects. This is a mix of 1) and 2), but it looks mostly 
like 2). The big advantage of this system, is that it can handle many 
projects, with less JSF efforts.

How should it work?:
a) The JSF creates a list with requirements for projects. Some parts of this 
list only applies to clients, servers or libraries. The important thing of 
this list is that the list requirements are extremely hard to be compliant 
with.

b) The JSF only votes on the list requirements, not on each software project 
that want to become "Supported". This will save the JSF much time. It should 
work like this: Projects that think they are compliant to all requirements in 
the list, need to ask someone (this shouldn't be limited to one or a few 
persons) of the JSF to add their project to the queue. The person who is 
asked this, can deny to do this if he sees a requirement is not met. When it 
is added in this queue, this will be noticed somewhere. In this case *all* 
people (this can be external or internal people) can contact the JSF to 
dispute the new entry. If they can prove a requirement is not met in the 
project (e.g. an incompliancy with XMPP), everyone within the JSF can remove 
the entry. When removing the entry a message with all information *why* it 
was removed needs to be made public. In this way the project can try to fix 
the issue(s) to apply again later. After a project is <needs to be defined> 
time in the queue, it will be automatically moved to the Supported JSF 
Projects list. Even in this list the remove system described above is 
possible!! The difference is that only this list will be "Supported" and so 
promoted. The queue is to encourage projects to take the appliance serious 
from in the beginning.

c) After a fixed period (needs to be defined), the JSF should vote on 
eventually new or changed requirements in the list. (Just like the voting of 
JEPs) If there are changes, the diff should be made public and it is possible 
that projects are removed from the queue and/or Supported JSF Projects list. 
Also in this case the removed projects should be informed *why* they are 
removed (e.g., your library do not met the new version of JEP number X that 
is needed by the new requirements list).

Remarks:
* It is possible that (at some moments) the Supported Projects list is empty, 
but that at some moments there are many (hopefully ;-) ) projects in it. This 
is not a problem.
* The list should be not limited to open source projects.

Motivations for this system or why?
1) The system will encourage innovation in the Jabber world:
   * There will be an optimal interaction between the projects and the JSF 
(the feedback that the projects receive) which will result it better overal 
compliance and quality of Jabber software projects.
   * When a project is listed as Supported JSF Project (which is very hard to 
reach), people can see that that project is supporting the Jabber protocols 
very good. As a result, if a project can say it is on this "golden list", it 
will be like a label/certification.
2) The projects need to apply by themselves. This saves a lot work for the 
JSF.

Some *ideas* for the list:
1) General:
* stability
* localization (e.g. translations in 10 languages at least are required)
* XMPP compliancy
* project website needed
* project mailinglist needed
* project chatroom needed
* documentation needed
2) Clients:
* only Jabber-only clients (it swears when the JSF adds multi-protocol clients 
that do also support IM protocols not defined in its mission statement)
* some client JEPs

3) Servers:
* some server JEPs
* minimum number of users it can handle without crashing on one computer
* at least X public servers running this implementation

4) Libraries:
<no ideas>

<snip>

-- 
Mvg, Sander Devrieze.

xmpp:sander at l4l.be ( http://jabber.tk/ )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20050513/cfd2273f/attachment-0002.pgp>