Hello everyone!

After a small hiatus due to summer and holidays for everyone, our team is back again. We are looking forward to begin programming and start “playing” with our agents.

There are three important areas of interest at the moment and when they are resolved our work can progress further.

  1. Distributed Project Management: Group Forming
  2. White Paper #2: Preface
  3. Software Management: Proposals

 

Distributed Project Management: Group Forming

As mentioned before, we feel it is time the management of the project gets distributed among the team members so we can work more effectively and all participants feel actively involved.

The project consists of specific domains of interest, like web site administration, mailing list administration, etc. We designed a proposal for a distributed control and administration of the various project's domains, so that every member can volunteer and participate actively in the project management. Some of our members with professional experience in management are welcomed to comment and improve this scheme.

The proposal is this. Project control is distributed in three main domains:
* G-SMC: members coordination & software availability center
* G-WRC: web site & resources (references) administration center
* G-DFC: discussion forum & communication center
The first domain is basically what the administrators have been doing since the beginning of the project, so we feel it is best we continue doing so for the time being. The second domain contains web site management, references to resources, file repository on-site, etc. The third domain contains mailing list management, contact with other groups in similar projects, some file sharing on-site, etc.

Any member who wishes to contribute with his/her experience and work in one of the G-WRC or G-DFC domains is welcomed. Many members may participate, but in any case there should be one head admin for each of the domains for coordination reasons. After a list of candidates is formed (during the next few weeks), the names and relative experience of each one will be posted on the site for voting by all members. Candidates can send a message at the project's admin team (
mailto:genesis_proj@yahoo.com).

 

White Paper #2: Preface

Since the opening of our mailing list at eGroups, many important issues have been discussed regarding the design of the environment and the agents. Clever ideas and experience have resolved, much or less, many important choices about various design parameters and although few implementation issues have been discussed in depth, we are close to the beginning of actual coding.

As all project design and implementation is and will be distributed by nature, the idea is to try and formulate the environment coding guidelines in a second White Paper, which will be the result of the fusion of the experience and ideas of all the project’s members.

In order to formulate the exact contents of the paper, we ask everyone who has contributed with ideas and comments through postings on the mailing list to state a list of subjects and issues to be addressed by the paper. For the record, some of these issues are: terrain & morphology, weather model, physics & mechanics, resource management, event logging, database management & storage, scheduler, networking and distribution models, integrity control, stress control.

The White Paper #2 should contain all necessary info and details needed for the beginning of coding and testing of the early versions of the Genesis environment module. Subjects directly involved with environment design will all be included in the paper, while others (regarding agents) will be addressed in a future design & implementation paper. Experienced members may optionally participate in writing some of the actual text of the paper itself. All suggestions, comments and references should be addressed, as always, to the project's admin team (mailto:genesis_proj@yahoo.com).

 

Software Management: Proposals

Since implementation phase should begin shortly, it is time we decide the way our software and source will be managed. The basic goals are simple: easy usage and participation for novices, robust file management, source control for versions, testing and debugging so that all can work on the same program platform without any problem.

The choices for the time being are two: automated source code management and version control though SourceForge (sourceforge.net), or manual project control by one of the management teams. SourceForge is an open source community for hosting many collaborative projects such as ours. It works much like eGroups, only it has a very powerful set of tools and features for complete and automated project management, including news posting, discussion forums, bugs report, file repository and version control. The disadvantage is that the participants have to use specialized applications (SSH, CVS) which might be difficult to find or use for all available operating systems. The second option (manual management) is by far simpler for the novice user, but it creates many burdens for the administration team as the project grows. We as a team have to decide the way that better fits our needs before we start posting source files and get stuck later with hundreds of different versions. Any comments and suggestions, especially from people who have used SourceForge, should be addressed to (you guessed it!) the project's admin team (mailto:genesis_proj@yahoo.com).

We are looking forward to your feedback.


_________________

GENESIS
Project Admin Team
mailto:genesis_proj@yahoo.com
http://www.oocities.org/genesis_proj
http://www.egroups.com/group/GENproj