November 3, 2002After 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 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.
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:
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.
What makes Xaraya special?
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.
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.
John Cox, Gregor Rothfuss, Paul Rosania, Marcel van der Boom (PMC)
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.
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.
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:
The actual members of these parties may overlap, so each individual can act in
multiple roles. 
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.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.
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
3. PMC Internal Roles and TasksTo 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:
3.1.1. ExternalAs 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. ArchitectureThe 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. ProcessThe 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. GeneralJohn 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:
3.3. Scenario BuddiesFurthermore, 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.
4. Initial RoadmapBy 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.
 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.