This article is to inform the locals that are to be participating to the beta testing of the membership system. OC for joining is closed, unless your local qualifies for a special demographic/use case situation. New locals will be added little by little as we see the system being ready/fit for business.

Step-by-step timeline

This is the timeline of the beta testing

1. 13th August, 19:00 CEST - Skype call informing the participants (the locals selected, subscribed to the ML oms-beta-l@) about the key concepts
2. (1 week after point 1: 20th August) - Small follow up by the development team to gather the first impressions (look&feel of the application, functionalities). Expected time: 5 to 10 minutes per call (or a very well written email: remember the network relies on you to improve the system at best as it could be)
3. (every 2 weeks after point 2) - Feedback calls where important points and features are discussed

Key concepts

Here some terminology

• Member : An AEGEEan, like you
• Body: An European body (EB) or a local, like HRC or AEGEE-Genova
• Circle: A 'group' of related things. A circle can be "bound" or "unbound"
  • An "bound" circle is generally tied to a Body: it groups members within a body e.g. members of the ITC are in the Body ITC, and in the Circle ITC.
  • An "unbound" circle is for grouping members with something in common. This 'something' is not depending on the body they are in: e.g. all board members in the system (for announcements); all administrators of the system (for maintenance); interest groups; all IT responsibles...
  • Circles have been created to handle permissions and privileges within the system but also within a specific body
    • For example within a body (AEGEE-Sofia), the board will have different privileges than the members: the members will be in the circle "Sofia members", the board will be in both "Sofia members" and "Sofia boards" circles. Because they are in the "Sofia board" circle, they will have additional permissions (e.g. "approve member for SU", "approve member join request"...)
• Recruitment campaign (RC): A RC generates a special signup link. An EB's board can make a campaign, that will make the users who join the system through that link be automatically member of that EB.
  • E.g. if a local has recruitment through an autumn school fair, a new year event, and a spring fair, the local can make three recruitment campaigns "Autumn18", "NY1819", "Spring19". By comparing the turnout rate with the campaigns of the previous year (e.g. "Autumn17", "NY1718", "Spring18") one local can see difference in numbers and perfection themselves (of course that would be only effective with good knowledge management practices, i.e. if the local documents every thing that they do...)

Expectations from the devs to the locals

• Do not be afraid of writing us: we're fellow AEGEEans like you!
• Use extensively the button "report a bug"! We simplified it to the maximum to report a bug
• Please be detailed in your bug report or your request for an additional feature we haven't thought of.
• There are no stupid questions. Ask away
• If you are willing to make one step further, we need people who are good in writing guides (i.e. human language, not technical one)

Enrolment procedure

Here is how enrolment (adding to the new system) will happen

1. 13th August, 19:00 CEST - During the informative Skype call we will showcase how to add users manually to the system (i.e. creating an account not through registration). Inserting the contact person of a local, and assigning them board privileges.
2. During informative Skype call, we will showcase how to make a recruitment campaign.
   1. Contact person can decide whether making the rest of the board join through campaign, or through manual adding
3. Contact person and board decide whether adding the whole local by hand () or through recruitment campaign.
   1. If recruitment campaign method is selected, it will be simple enough to share the campaign link through their own internal mailing list)