Proposed organization model for GUADEC 2018

In our experience this kind of events works very well with a two tier organization:

owner team (GNOME team)
local team

The GNOME team

The GNOME team is core part of the organization owning the event. In this case the GNOME Foundation and whatever individual from the GNOME community trusted by the organization. As your wish.

The team typical responsibilities are:

brand management, this way you can keep and exquisite brand control and QA, and probably you have access to familiar collaborates skilled on desing;
event website control, setting it up and run on services under control of the GNOME community;
communication leadership: the relation with press and any kind of media is better to be driven by the GNOME team because you have better and direct contacts from long ago (and if not you really should); the press releases and communications sent by you has more probabilities to be published by international media than anything we can do;
leading the search of sponsors, for same reason: GNOME Foundation should keep a very good addressbook of previous sponsors, with precise contact persons so the work would be more efficient and faster;
leadership in CfP: you'll want to have full control and QA of the conference contents so the CfP should be driven by trusted individuals; of course you'll have a lot better echo promoting the CfP between de GNOME community than anything we could do;
and obviously to have formal mandate or responsibility to accept budget proposals and confirm contracts and close agreements.

The local team

Local team responsibilities usually are everything related with logistics and local information gathering and publishing.

to provide the event with any local information needed for the conference;
to contribute and QA this information published in the conference website;
propose a set of budgets for the services the conference needs;
propose a set of ludic activities for the attendees;
propose a set of active tourism activities for attendees companion not interested in the conference;
to set up a team of local volunteers for working in the physical organization of the conference in the previous days and for removing materials after the conference;
to receive any kind of material needed for the conference
to receive, help, guide and support our visitants while the conference;
to collaborate and help in any kind of technical activity driven by the GNOME team on which we could help (contents, systems, QA, etc);
to help with the communication, specially the local and, as far as we can, the national;
to help the search of sponsors, with focus on national and local ones.

Workgroup tools

As we are absolutelly familiar with the opensource development ethos we propose using a workgroup tools schema very similar to the next list. We would like to contribute to the spirits of transparency and openness working with, as much as possible, open access tools so anyone could examine and contribute to the progress of the organization effort. In one way or other you are absolutely familiar with these kind of tools:

an open canvas, with open reading access and writing restricted to the team;
a private shared folder, because it would contain working draft documents and private data of speakers, registered users and sponsors;
a Telegram, or similar, team chat group; Telegram is nicer than IRC because persistence of the conversations;
a web development system, say a wiki, git repository or an equivalent;
e-mail;
a CFP and agenda management software like Pentabarf or equivalent;
an a conference registering system like Eventbrite or equivalent.

Conclusion

We believe this model of work sharing is the most efficient and adequate for the knowledge and scope of both teams. It helps the GNOME community too to keep an strategic body of knowledge reusable in the coming years.

Back to the main page