Xaraya.com Launches

November 3, 2002

After several months underground, the Xaraya Team is proud to launch Xaraya.com. For the moment, it is a simple site dedicated to providing interested users, developers and potential partners with basic information about the project, roadmap and timelines.

What to expect from this site...

We are starting with the facts. Over time, we will expand the site with additional content and resources aimed at the following audiences:

What not to expect from this site...

As noted above, this site will expand as additional resources come online. However, most of us are currently working furiously on the project. So, please keep in mind a couple of key things this site will not provide, at least not at the moment.

That is it for the moment. We look forward to providing you with the best open source Content Management Solution available.

Regards,

Team Xaraya

About Xaraya

Welcome to Xaraya.com, the official website of Xaraya Content Management Solutions. Xaraya is extensible, open source software written in PHP and licensed under the GNU General Public License. Xaraya utilizes robust permissions, data management and multilingual systems to dynamically integrate and manage content.

Xaraya's modular, database independent architecture introduces tools which separate form, function, content, and design. Xaraya delivers the requisite infrastructure for a fully dynamic multi-platform Content Mangement Solution (CMS).
 

What can Xaraya do for me?

In the simplest terms, Xaraya reduces web site development costs by introducing sophisticated administration tools & services which separate form, function, content, and design. With Xaraya, you work in a simple, structured environment to rapidly develop your website with diverse content, including: With over forty active developers spanning five continents and over ten languages, the Xaraya Development Team is a blend of some of the best and brightest developers found in the open source community. We expect the best of one another. As a result, you can expect the best from Xaraya.

How do I pronounce Xaraya?

It is not as difficult as it may look. In fact, saying Xaraya is actually sort of fun. Phonetically, it looks like this: Zah-rai-ah. Try pronouncing it yourself or hear Xaraya pronounced by our own Marie Altobelli (LadyofDragons).

What does the name "Xaraya" mean?

The name Xaraya was selected by the development team after an internal contest. Submitted by Marty Vance (Dracos), Xaraya does not really mean anything. We were looking for a name which was both interesting and unique. Xaraya certainly fits the bill.

That said, Xaraya is reminiscent of raya, the Spanish word for Manta Ray. We rather like the nautical feel of that reference, particularly when one thinks of the Internet as an "ocean" of information. With this in mind, we developed the current theme of our website.

In the near future, we will sponsor a public contest to create the official logo for the project. When contest details are finalized, we will post them in the News Room.

What makes Xaraya special?

Features

Supported Platforms

Server Requirements

What is the Digital Development Foundation?

The Digital Development Foundation, Inc. exists to provide the organizational structure and support mechanisms for open source development projects to obtain, through fair competition, their share of the software market. The DDF is committed to the vision of it's member projects establishing a reputation of excellence in the software industry and serving the user through accessible, standards-based products complimented with the requisite support mechanisms.

Development Roadmap

This document will take the development team through the first phase of the project. Most of this roadmap is dedicated to a general outline how the Project Management Committee (PMC) works with all group members. At the end of the document, we lay out the scenarios which need to be implemented to reach the first release.

Authors:
John Cox, Gregor Rothfuss, Paul Rosania, Marcel van der Boom (PMC)

Table of Contents

1. Guiding Principles of Operation
2. Involved Parties
3. PMC Internal Roles and Tasks
3.1. Attention Areas
3.1.1. External
3.1.2. Architecture
3.1.3. Process
3.1.4. General
3.2. Team Contacts
3.3. Scenario Buddies
4. Initial Roadmap

1. Guiding Principles of Operation

Global mind-set: we are a development group.

We produce and manage the code, documentation and tools that are Xaraya. Other activities related to Xaraya, we happily leave to other projects, organisations or individuals. Our exposure to the outside world will reflect this. We will primarily focus on supporting developers, not end-users. This does not mean that we won't support these activities, but we focus on development.

Mode of operation is: distributed development, both by necessity and by conviction.

As we are all in different countries and time zones, development must be distributed. Decentralization is required because we all are busy people and want to avoid loading to much work on the few. To make distributed development work, we need good tools to coordinate manage the source code. We use BitKeeper.

Release strategy: feature based releases following a development / stable analogy.

We are not driven by time to release the product. We are driven by when things work, and when they work very well. The roadmap will not contain deadlines, as PMC we will not enforce deadlines. We count on people who take responsibility for a task that they will produce a result within a reasonable timeframe. We realize that "reasonable" is subjective. If results cannot be produced in a reasonable timeframe we count on people to raise the issue themselves and search for a solution in the group.
Attitude: thinking before leaping (or even walking for that matter)

Good ideas come to people ten times a minute, or so it seems. That said, an idea that sounds good in discussions still requires a written specification before it can be managed by the PMC and included in the repository. If you choose to implement a technology prior to writing specifications for it, we will NOT consider it until the written specification is developed.

Expectations: self organising and thinking developers

We expect people to be self-organizing and think for themselves. We can't organise things for you. We can only help as an interface between developers and the group as a whole. We just don't know enough about the details to give you accurate answers on most of the stuff that's going on. We will however be able to direct you to the person who will.

Development process is: repository supported scenario based development.

The base development process has been described into considerable detail in an RFC in two parts.

These are our guiding principles by which we will manage the Xaraya project. The rest of this document will focus on the more practical issues to get us going.

2. Involved Parties

Xaraya as a project is embedded in a larger organisational framework. At the project level we have three involved parties:

  1. Digital Development Foundation (DDF)
  2. Project Management Comittee (PMC)
  3. Project Developer Pool (PDP)

The actual members of these parties may overlap, so each individual can act in multiple roles. [1]

The DDF holds the overview of all projects and discusses relevant issues with the PMC. An example of an optimised discussion as it might take place on IRC:

DDF: Hey PMC, we have this interesting opportunity for your project we came across. Here's some info. Let us know if you want to do anything with it.

PMC: Interesting, let us get back to you on that.

... time passes ...

PMC: Hey DDF, we have decided to use the opportunity you sketched earlier. Here's the summary of it.

DDF: Great, we'll publicise it.

The PMC holds the overview of the xaraya project. They will be experts on the big picture and losers on the details. The PDP provide information to the PMC rather than asking for it. An example of an optimised discussion between PMC and PDP as it might take place on IRC:

PDP: Hey PMC, I want to work on this great big thing. Here's the link for the spec for it. Can you get back to me if this conflicts with other scenarios and how it can be scheduled in?

PMC: Great, we'll have a look at the spec and get back to you on it.

PMC: Hey PDP, we expect that your scenario conflicts with scenario X which is nearly finished. After this scenario will be integrated your scenario will be spawned from the tree so you have all their improvements in your clone. We've updated the road-map to reflect this situation. What do you think?

PDP: Ok, no problem

The above examples should give you an idea how we would like to work. Obviously, in real life, the discussions will be somewhat longer and more complex. Our main point we would like to make is that we will not be able to answer questions on how things should be done most of the time, but we will make sure that we know when to do them. You, as a developer, are responsible for writing up (after getting confirmation from your peers that it is a sound idea in the first place) how things will be implemented. The PMC will take care of the necessary templates to write up RFCs for these scenarios.

For smaller efforts which do not require a RFC, like bug fixing or optimising, each developer can work in the normal repository as he/she sees fit. The PMC will sketch the overview of the available repositories in which work is needed for smaller efforts.

Releasing a version of the software is a scenario in itself. If the features planned in the road-map are completed and the scenarios have all been integrated, the release scenario for that release will be created. This is no different from a normal scenario except that changes will all be subject to a two phase commit cycle. Each change can be pushed to the release repository but will be reviewed before applying it to the tree.

3. PMC Internal Roles and Tasks

To give every group member a point of contact within the PMC we've organised ourself along attention areas, team contacts and scenario buddies. In short, we all four have a global task we pay attention to, each team has a point of contact in the PMC and for each active scenario a there is a buddy in the PMC.

3.1. Attention Areas

Within the PMC we have divided the project into four areas of attention which are more or less assigned to the four of us as follows:

This list gives everybody in the PMC a basic responsibility and the developer pool a hint who to turn to with certain issues. Some explanation may be in order here.

3.1.1. External

As a web application we are connected to the rest of the world and need to pay attention to what other groups are doing and which opportunities are out there to improve Xaraya in the area of talking to other systems. Gregor will cover this area.

3.1.2. Architecture

The overall picture of how Xaraya evolves technically and improves is monitored by Paul. While the rest of us are busy working on all kinds of scenarios, Paul might hit the brakes someday when he sees a risk of disrupting the overall sanity of the system.

3.1.3. Process

The development process is driven by our repository-engine. Marcel will monitor the issues of the repository hierarchy and keep an eye on active scenarios from an infra-structural point of view.

3.1.4. General

John will monitor the overall progress of the project and deal with the organisational issues involved to keep us all on the right track. He will coordinate the release scenarios.

3.2. Team Contacts

For all teams identified within the project, a member of the PMC is assigned as point of contact. For the current teams:

As our teams evolve over time, this is likely to be updated in the near future. We envision a quality ensurance team within a short period of time.

3.3. Scenario Buddies

Furthermore, for each scenario in the roadmap, there will be a PMC buddy who is the first point of contact with specific issues on the scenario. In the ideal case there are two points in time which contact with PMC is necessary. The first is when the specification for a scenario is ready and it needs to be scheduled. The second point is when the scenario is implemented and tested and needs to be integrated. In practice probably more contact points will be necessary, especially on larger or high risk scenarios.

In the following section the initial roadmap is described, with the assigned PMC buddy and the members of the developer group which are working on that scenario. Again, small tasks like bug-fixing are not part of an explicit scenario but can be applied to the repository in their own change-set (which is also a scenario, but doesn't have it's own repository).

4. Initial Roadmap

By it's very nature, the development roadmap is a dynamic piece of information. For ease of use, the development roadmap is made available in a graphic, GANNT chart formt. To view the development roadmap, click the link below. This roadmap will be updated on a regular basis.

View current Development Roadmap.



Notes

[1] A developer is anyone who contributes to the progress of the product, this can be a coder, designer, documenter, reviewer etc. etc. We use developer as the generalised term for any contributing member of the project.