A comprehensive set of guidelines for live collaborative community work

1. WhatsApp Working Community

The WhatsApp Working Community of the International Free Flight Competition Pilots’ Union Community aims to gather competition pilots' inputs and convert them into proposals that can be integrated by institutional bodies or companies. This bottom-to-top approach brings together a large group (>300 pilots) to define common interests and to reach common goals that will change their air sports. The idea is to gather diverse viewpoints and involve pilots to facilitate support, workload management, and institutional acceptance.

For this ambitious collaboration to work, we propose strong working guidelines. By staying in the WhatsApp group, members indicate their acceptance of these guidelines. The main principles underlying these guidelines are: openness, transparency, efficiency, inclusivity, care for each other and the sport, freedom of speech, and a commitment to data driven progress

Everyone involved in competition flying is welcome to join the community. Every aspect of free flight competition is included: paragliding accuracy, XC, aerobatic, hike and fly, as well as hang gliding.

The community language is English.

By joining the community, members allow other members to contact them for working and community purposes only. Spam, sales, and discussion unrelated to competition flying will not be allowed.

 

2. WhatsApp Working Group

2.1 Group creation

Any pilot can propose the creation of a working group. The working group meeting point is a WhatsApp group within the WhatsApp community.

2.2 Group purpose

The purpose of a group is to bring a deliverable that can be approved by competition governing institutions (e.g. CIVL, PWCA, SRS…). It shall have a detailed, explanatory, and practical effect on the field. The more narrow and accurate, the better.

  • Ex. 1: “Safety” cannot be a group but “Improvements in harness design for hike and fly” could be.
  • Ex. 2: “Hang Gliding” cannot be a group but “Training curricula for pilot safety in HG” could be. 

Describe what you want to fix, improve, or add, and what you intend to deliver. The purpose can be a tool, a rule, a set of guidelines, a method etc… The purpose should be written into the description of the WhatsApp group and is used as a guide to structure the debate.

Only one general purpose group is allowed (“General Discussion”), to allow ideation and requests for help in definition of working groups. 

Once again, in no group or topic will advertisement (gear, comp venue…) or spam be tolerated.

2.3 Group scope

A group scope should be defined and written into the description of the WhatsApp group. This should define where the purpose is applicable, e.g. Cat 2, PWC, paragliding accuracy, etc. 

2.4 Group institutional target

Each group should define an institutional target (e.g. CIVL, PWCA, SRS…) in the group description. This specifies the institution in which the purpose is to be accepted and applied.  A group can have multiple targets.  

2.5 Group approval

Groups must be voted on and approved by the community. If an idea is unpopular or lacks support or perceived utility, it must be reworked until it receives community support. Keep in mind that any project is always harder to sell to an institution. If the community has no interest, let it go.

To be approved, a poll must be organised explaining the purpose, the scope, and the target of the group. The approved group must raise significant votes.

2.6 Group administrator(s)

Each working group shall have at least one administrator. Administrators are volunteers who serve as leaders and moderators of the working group. If one chooses to step down, the community must select a replacement.

2.7 Group moderation

Multiple points of view are valuable. Free speech is important. No aggression, threats, or offensive statements towards other individuals will be tolerated, either direct or indirect. Administrator(s) must monitor carefully their groups and are allowed to ban people. Repeated offences can lead to a complete ban from the community.

GIFs and icons are permitted as long as they cannot be construed as abusive or offensive. Be polite.

2.8 Group Tools

Group tools are left to the discretion of the administrator(s). We recommend accessibility and ease of use as a priority when selecting collaboration tools. A shared folder must link to all available documents regarding the current working group. Editor mode or commenting permission should be provided along with contribution guidelines to any member who requests it. Providing open editing mode to all members is discouraged due to versioning and traceability issues. Video conference meetings and polls are a critical component of community collaborating workflow.

If the deliveries are IT based (Webpage, Apps…), then open source tools, libraries, licences and Github repositories should be used.

2.9 Group Schedule

  • First 1.5 weeks: Brainstorming. Everybody can comment and add a point of view in the relevant WhatsApp group or into a shared “gathering” document to ideate around all aspects of a topic (e.g. requirements, costs, scope definition). Group members are responsible for reviewing others’ contributions. Positive icons may be used to support points of view. Negative icons may be used to express a lack of support but never to harass, embarrass or make fun of any individual. Let’s encourage participation.

     

  • Week 2 end: First video conference meeting. Administrators release and present a synthesis of the deliverable as they intend to steer / handle it. They should take direction, choose principles, create a first draft, prototype something... The main objective is to find acceptance and support, discuss next steps, and divide practical work between attendees. Polls can be used to get feedback.

     

  • Week 3 on:, every message should be related to an actual document / work : edition, version, comment… We recommend the groups meet bimonthly at least

     

  • Recommended working group duration: 2 Month maximum.

 

  • If a working group can’t reach a consensus, administrator(s) should seek to arbitrate before declaring group status to be “aborted,” either temporarily or permanently.

2.10 Group Status 

Group Status should be visible in the WhatsApp description of the group.

2.10.1 Submitted

After the initial proposal the group project should be approved by the community via the poll system. The group is visible to the WhatsApp community, its purpose and further details are made public, and advertised broadly together with poll links.

2.10.2 Rejected by community

A group that fails to be approved by the community (50% in favor and significant amount of votes) is rejected and archived.

2.10.3 Brainstorming

Approved projects enter the brainstorming phase. Over a period of 2 weeks maximum, anyone can comment on the WhatsApp group and fulfill the anonymous open “gathering” document. After this period, the administrator(s) is in charge of collecting data, releasing a synthesis, and building a first draft / prototype of the delivery.

2.10.4 Drafted

A mandatory video conference meeting starts the “Drafted” phase. Administrator(s), present the draft and its collaborative tools, seeking for support and to distribute the workload across the attendees. From this period, the project can only be contributed by making actual work or reference to the drafted document / deliverable. 1 minimal video conference meeting per month is mandatory to keep track of the progress and to reach agreement live.

Drafted phases are likely to show multiple opinions within the community. This is normal and administrator(s) should :

  1. Respect every point of view. We are a small community and need to focus on general agreement.
  2. Seek compromise and consensus whenever possible.
  3. Use a poll procedure in between 2 meetings to provide data and numbers to everyone regarding every possible option.
  4. In last resort, steer a direction where more than a majority is keeping in mind it will complexify the institutional acceptance process.

2.10.5 Polishing

During the “drafted” phase and when general agreement is found, administrator(s) can declare the project as being “Polished”. During this period, final rewording / editing work on the delivery continues but the community focuses mainly on explaining / advertising the work that has been done, organising the final poll and starting to seek institution acceptance (Delegate or committee approval).

2.10.6 Aborted

A group that can’t pass the brainstorming or draft phase can be declared aborted by its administrator(s). Lack of support, lack of handwork, discharge of administrator(s) can lead to aborted projects. The community should accept that some projects will be aborted.

2.10.7 Proposed

A group reaches ”Proposed” status when its delivery has been proposed to their institutional targets. Administrator(s) are in charge of doing so. The work is frozen and documents preserved in their submitted state. 

2.10.8 Succeed

Groups which see their purpose and delivery accepted by the targeted institution are deemed successful. Successful groups are archived.

2.10.9 Rejected

If the project fails to pass the institution, it enters a failed state and can be reworked for better adoption in another occasion or archived. Failed projects must provide the reason and the institution process which involved their rejection. Rejected proposals may be reworked by the working group or archived.

ex : 2026 CIVL Plenary voted against 8 - 20 after x specific reason was raised.

The community should accept that some projects will fail.

3. Video Conferences

Video conferences are mandatory after the “Brainstorming” phase to enter a “Drafted” phase. Video meetings are organised via the chosen tool of the administrator(s). They shall have an agenda prior to their start and share minutes 1 week after their end (AI generated is allowed). Video meetings should be recorded and shared publicly in the working group.

4. Poll procedures

Polls are used to solicit feedback from the community. They should be public and shared broadly. Subsets of data or pilots can be analysed (Discipline, Country, WPRS rank, Gender…) but a poll is always supposed to be shared broadly across the community and should not be secret.

Answering may require a CIVL ID (to keep a scope to international comp pilots). Before sending polls, a presentation or live meeting shall be associated to explain the matter and the consequences of every option in a contradictory way.

5. Deliveries

Deliveries are communicated to the institutions, governing bodies, and companies (CIVL, PWCA, SRS …) together with their community poll support rate and data. We use the submission rules defined by these institutions and we respect the results and the outcomes of the voting or other process established there (Delegates, Plenary, Committee, assembly, decision etc). The community should accept that some projects will be rejected.