Introduction

AEGEE is an organisation of around 13.000 members, having local branches in around 200 university cities. On European level there is a board of directors and several commissions, working groups and project teams that all need certain information from the local branches. AEGEE also has an active alumni network called Les Anciens.

Till summer 2009 the core IT system was based on Lotus Notes. This provided accounts (called 'aegee.org accounts') as well as a lot of databases, including document store, event calendar, address book and summer university (a yearly project organising around 90 events Europe-wide) project management, application and evaluation system. Next to that, several stand-alone applications were in use, like a forum, Agora/EBM (statutory events) applications and a photo page. All stand-alone applications were linked to the core system using LDAP, MySQL and XML.

In August 2009 the whole IT system was turned off by the Comité Directeur 2008/2009, and replaced for an externally developed system called 'Intranet'. While some new functionality was added, a lot of relevant functionality was also lost. Not only is the too strict design far from useful for AEGEE, also the implementation by the contracted company Troxo was done in an inconsistent way that puts too strong limits on corrections and future enhancements. Next to that, hardly any transition was taken care of, resulting in the loss of a lot of valuable information from the past.

General constraints & requirements

As AEGEE is a quickly changing organisation, the new system needs to be flexible enough to adjust to the changing organisation; it should not become too tight, should not go into too much detail if not absolutely required, because hardcoding of processes or business logic can be obsoleted quickly with CIA changes made during an AGORA. As there is a high turnover of members (also the ones maintaining the IT facilities) the system needs to be easy to understand, and proper documentation needs to be available, both for the users of the system as well as for the administrators and developers.

To keep the system maintainable, and also make it possible for new people to get involved, the system needs to be modular. In this way one only has to understand a small piece of the whole system to be able to start development, and modules do not need to reside on the same server that OMS Basic runs on. Between the different modules a fixed interface should be defined, one that is preferably technology independent (preferably XML instead of a certain database language).

Many local members will be using the system, as it contains their membership data. As not everybody is as fluent in English, the system should support multi-lingual user-interface, including non-latin characters (cyrillic, greek, but still left-to-right languages (no arabic or chinese). Translation is out of the scope of ITC work, but a framework should be provided that makes it possible to present the whole user-interface in different languages, at least for the modules that are used by people that don't need English for their work in AEGEE (this means that member administration needs to be in different languages, while Agora/EBM/event applications don't need that, as you can hardly participate if you don't speak English).

As the system will contain a lot of data fitting within privacy laws, it needs to be secure. For login and accessing this data, encryption should be used (SSL/TLS). Access rights should be properly defined, and fitting with the requirements and needs of everybody using the system, but always keeping in mind that as little as possible information should be available to others.

Structure of the AEGEE IT system

Overview of the design of the whole Online Membership System for AEGEE.

The system will be modular. The different modules should be loosely linked, meaning that they should not depend on the language a module is written in, or the underlying database structure. Interfaces should exist that are fixed or at least backwards compatible, and every module should be aware of the other modules that access its data, this to be aware of which modules will be influenced by changes in the interfaces.

The core of the system will be the accounts and membership module. This module is responsible for storing the accounts (formerly known as 'aegee.org accounts') and the membership relations a person has with different bodies (both locals and European level bodies).

Around this core module, tools like the Calendar of Events, Event Applications, Summer University (SU) tools (list of SUs, applications, selection, evaluation etc.), Forum, Document store (both per body as well as general ones), Photo page, Agora/EBM applications, Address Book, Network Management tools and Voting/polling tool will have to be build. Through interfaces the different modules can exchange data with each other. Each module is free to choose its own implementation language and database, but for consistency certain programming languages, libraries, frameworks and databases should be encouraged by AEGEE, to keep the system maintainable also after a certain person leaves.

This document will further focus on the OMS-basic part. Other tools can either be taken from existing applications, extracted from intranet or written from scratch, depending on what is available already.

For access control OMS-basic will provide basic information, like group memberships. The detailed ACLs will be implemented by the different modules themselves.

Modules of the Online Membership System

The AEGEE Online Membership System (OMS) is defined in several modules. Below you can see the modules that are currently under development and future prospects!

Note: it is business logic diagram not technical

Information is provided per module, sorted by order of importance:

1. The core module

• The framework of the system

• Database Interaction (LDAP & MySQL)

• Layouting

• Basic Access Handling

1. The OMS Basic Project

• Account handling

• Management of all bodies by AEGEE-Europe

• Including date of (re-)foundation and board election(s)

• With revision history and past boards

• Member management for each body (local, working group, commission, team, project, alumni, etc)

• AEGEE CV focused on AEGEE experience (like a LinkedIn) – connection to HR Module

• Address Book

• Administration

1. The Event Management Project

• Event Creation

• Event Calendar – online ical or ics, xml export

• Event Applications

• Data store related to event – via Document store module

• Event Evaluations with Impact Measurement via IM/ Statistic module

• Mass mailing to applicants via email module

• Event photo – Document store and API connection to Flicker

• Facebook API – group membership management

These modules are based on events module and add additional functions related to special purpose of Summer University and Statutory events

1. Summer University (SU) tools

• Management of SU applications for locals

• Management of SU applications for members

• Selections algorithms

1. Statutory tools

• Statutory event creation

• Applications criteria check

• Activity reports submission – connection to Document store

• Candidatures - connection to Statutory vote module

• Submission of AEGEE-Europe budget – connection to Finance module

1. Document store

• Connection to Cloud storage tool via API

• General

• Official documents

• AGORA – connection to Statutory module

• CD decisions

• statements

• Press releases

• Downloads

• Bodies

• Public

• Members only

• Related to Events

• Organisers only

• Participants only

• Deposit store of other modules

• Designs from PR module

• Certificates from HR module

• Personal repository

1. The Juridical Commission Project – Statutory Vote

• CIA Maintenance

• CIA Proposals Management

• Online Voting for Agorae

1. Email Tools

• Emails Aliases management – API connection to mail service

• Mailing list management – API connection to mailing list

• Mass mailing tools

1. Network Management tools

• activity report and future plans of locals – connection to events module

• Antenna criteria – connection to events and finance module

• NetCom trips reports

• Facebook API – group creation and membership management

• Mailing list connection

• Podio API connection

1. European level tools

• Body activity report and future plans

• Working Groups criteria

• Facebook API – group creation and membership management

• Mailing list connection

• Podio API connection

1. Working Group and Committee Election tool

• Tool via which members of body can elect new board of WG or Committee

1. Impact measurement/Statistic module

• connected to event management

• survey tool for members

• Statistics

1. HR Module

• Trainers database

• Certificates creations – learning path

1. PR Module

• Logo for locals generation

• Generation of PR materials based on template (Business cards, flyers etc)

1. Finance Module

• Fee payments and overall financial status body <--> AEGEE-Europe

• AEGEE Europe budget

• Reimbursement form

• Submission and evaluation of Financial reports of locals – connection to Network module and document store connection

• API connection to bookkeeping software

1. Alumni Module

• Local Alumni management

• European Alumni management

OMS Basic

Full version of specification at:

https://docs.google.com/document/d/1WERCys2cR7HBY4ud-wLze4WjY6c0sI4y67aJMQ4iwBo/edit?usp=sharing

OMS-basic is the core of the system. It basically needs to replace the aegee.org accounts that AEGEE used to have till summer 2009, the list of bodies including all data that was present of bodies in the old Address Book, provide a members management tool for locals, replace the working groups portal and access groups.

The bodies are maintained by the CD. For that a team of people taking care of the data should be introduced. Next to the possibility for CD and ABC to modify and create bodies, also board members of the bodies will have the possibility to edit the data of the body.

Every member will get only one single account that is valid for all his/her memberships. All memberships are linked to the account. As long as there are active memberships connected to an account, the person is considered AEGEE member, with the related access. The person can of course be a member of more than one local and have them both under the same account.

New members can be added to the system by board members of their local, or people can apply themselves for membership, after which board approval is required. The members data is solely accessible by the local to which the membership applies. It is up to the local to decide if only the board has access, or if all members have access to (part of) the data. For Eurolevel bodies, only statistical data is provided if their work requires this. No access is available to the data of the members, except when required by CIA.

Board can define access groups, and if only the board can edit them, or also people in the access group. Certain access groups will be compulsory, like the 'board' or 'SU-outgoing', others can be freely created.

Logging of when a person logs in and from where needs to be done to see which accounts are active, and to show the user when he did log in last.

Password recovery functionality is needed so people can recover their own passwords.

Local board should be able to import and export data from and to common formats. This provides them with possibilities to mass-import new members, as well as generating offline access to the data.

Text continues on next page.

AEGEE Local Profile

European Body Profile

Membership Management Dashboard

List of

• Applicants

• Members

• Sub Team

• Past Members

• Alumni Members

• All

Filter by:

• Items in database,

• Multiple options, like show: applicants, gender: female, interested to join: SUm, Sub Team

Set status

Options

• Individually for each application

• Globally for selected items

For applicants

• Pending – when application submitted – After one month with no status change -> Rejected

• Accepted -> become AEGEE Member, set Payment Expected and date 1 month from date of acceptance

• Rejected -> Non AEGEE Member role

For Members

• Fee Status

• Payment Expected

• Date till when to pay

• Paid

• Payment Overdue – within 1 month after date of expiration

• Not paid – after one month, automatic expiration and setting role Alumni

• Sub-Team Membership

• Local Custom Roles

Fee Management

• Size

• Group

• Member

• Board member

• Honorary Member

• Sub Team Member

• Local Custom Role

Sub Team Management

• Create - Form

• Sub Team Name

• Team Leader

• List of people of the group

• Membership – for CD sub-teams

• Only members from Body/local

• Open - AEGEE Member

• Description

• Logo

• OMS Rights – set up to the rights of body/local

• Edit

• Edit items

• Membership

• Add/remove members

• Close sub-team

• Set suspended status for the sub-team -> Hide from list

Export

• Export data to csv, based on filter

• Generate PDF Report – stilled document

Event Module

Full description at

https://docs.google.com/document/d/16oaivoRE3iaKIQ-LaD4hxHYYgWq0Pgu3b_pXJDfMY1A/edit?usp=sharing

Note SU and statutory events descriptions is not fully done yet!

Events module is one of the main modules of OMS, responsibility of this module is to maintain the flow of the event life cycle to ensure quality and impact of events and form applicant point of view provide needed information in structured and concise way.

The modules merge into one currently 3 systems (Statutory events, Summer University and General Events) for event applications into one. Specific functions of each application systems were taken into account and parallel functions are defined in the system.

Event life cycle

Functions of the module are based on event life cycle, which defines the whole process of the event, from idea creation, concept submission to participants’ application process and to ends with event evaluation. Figure 1 visualised such a process.

Figure 2: Event life cycle

Event development phases

Event development is based on division of event conceptual design followed by event detail description. Reason behind is to divide conceptual design such as aim and objectives of the event, which are fundamental part of event design with detail description which are based on event aim and objectives. This division is to help develop better event concepts with clear and concise event designs (objectives are supporting aim of the event) which leads to more quality events.

Figure 1: Event Development Phases

Sessions sub-module

Application to organise event is based on two options:

• Developing own concept

• Application of defined concept

Such a concept builds on current practice of event frameworks prepared by European Level bodies. Content and logistic part of the event are divided and can have different responsible. This means content of the event can be prepared by other body and local will be responsible for implementation of this content to certain level (it can be fully implemented by local or external trainers will deliver the sessions) and take care of logistics. OMS concept is based that event concept is defined in advance and organising local choose these concept to implement or define own concept.

In Event Module design is such a process institutionalised by prepared concepts stored in Sessions sub-module of the Event Module.

As Figure 2 shows event which was organised can become event concept, this way it should be possible to spread event ideas among the network. Also European Level body can first create testing event to try how such event concept will work and after implementation create event concept in session sub-module.

European Event Concepts

Above described process is related to European Event Concepts which is one of three parts of Sessions sub-module. For these events application will be done via OMS entirely including evaluation process.

Local Activity Concepts

Another function is Local Activity Concepts which works on similar basis as European Event Concepts, providing concept for Local Activity to organise in the city of the local. In this case concept is prepared in the way that local can just implement it no approval takes a place.

Individual Sessions

This function is based on SALTO YOUTH Toolbox, which stores outlines of sessions, games which any event organiser can use. In AEGEE case it should work on similar principle.

Sessions

• Type

• Icebreaking

• Energiser

• Name Game

• Group Division

• Group Building Activity

• Thematic session

• Soft Skills session

• Format

• Workshop - interactive

• Presentation – on given topic with notes for presenter

• Game

• Simulation

• Length

• 5 min

• 10 min

• 45 min

• 60 min

• 90 min

• Topic of the session – based on Strategic plan and thematic focus

• Aim of the session

• Description

• Implementation

• Material Needed

Differences in application procedures

Event life cycle take into account 3 different categories of events in terms of application system and merge them into one, but keeps specific requirements.

Events with individual application

Events with individual application are classical European Events which take place in AEGEE. Here standard procedures will take place which will be evaluated by QUAC (Quality Assurance Committee previously Events Committee)

Events with group application

Events with group application are these events which have special application procedure. Such type as at this time used for Summer University, however OMS should count with option that such a system can be used also for other projects.

In general such events are:

• Events of same type grouped by umbrella project

• Special application take place

• Specific questions in application form

• Participant application for several events at once (in general 3)

• Pre-selection which reduce number of participant applications to one

• Specific timeline and deadlines for whole project

Statutory Events and NWMs

For statutory events and NWMs another special application takes places, for these types of events event development is prepared by defined body Chair, EBM Content Team or NetCom and is evaluated by them.

Timeline of Events process

Application to organise European Event

Application process is based on event life cycle and for this reason two forms are in place. First short one and second more elaborated to provide event details

Questions in this form are based Event Quality Indicators of European Youth Forum

Application form for Event application

Application form for applicants is composed of these parts, depending on type of event

• Person identification – read from OMS Core

• Custom Questions from Organisers

• Standard event Questions

• SU questions

• Statutory event or NWM questions

• Impact Measurement questions – predefined by Impact/Statistic OMS Module

Calendar of Events

Main purpose of Calendar of events is to visualize list of events, it shows data processed by events module.

List of events view and info bubble on map

Such view provides filtered information of events based on criteria. As default view are the events which will take place in future and which is possibility to apply

• Title of the event – link to event details

• Dates

• Application deadline

• Venue

• Type

• Category

• Short description. – 300 Char limit. , not visible in map

List of Events

Map of events

Functions of Calendar of events

RSS export of events

Data which should be exported via RSS

• Title of the event – link to event details

• Dates

• Application deadline

• Venue

• Type

• Category

• Short description

XML export of events

XML output file with all events following parameters the request, function should be similar to filter function on list of events, show events based on dates, category or type, matching these categories.

• Title of the event – link to event details

• Dates

• Application deadline

• Venue

• Type

• Category

• Short description

Online calendar export – ical or ics export

Data from event database accessible as online calendar which can linked to Google Calendar, Outlook, Apple Calendar or any other service which use ical or ics format of calendar data.

In such a calendar all events should be presented.

For each event two calendar events will be created

1. One day event marking Deadline of Title of the event

2. Event marking when event take place

Exported data:

• Title of the event – link to event details

• Dates or Application deadline

• Venue - Location

• Type – first line in description

• Category – second line in description

• Short description –in description

Event page

Data of each event are visualised on event page, which should view all data and related process of event life cycle.

User roles:

• Event evaluator

• General events QUAC

• Summer University SUCT

• Statutory events Chair

• Anonymous

• general public

• access without login

• AEGEE member

• Any member which is logged in

• Accepted participants

• Applicants which have event application status Accepted

• Organisers

• Local organisers