Together with the release of the PoP API, we announce a major feature: the PoP API has been completely decoupled from the overall application, so it can be used as a standalone API to power any application, using a PoP theme or any standard WordPress theme.

For instance, we have deployed a site under https://nextapi.getpop.org, which uses the default WordPress 5.0 theme “Twenty Nineteen”:

If, however, we add parameter ouput=json to the URL, we get the data through the PoP API:

This makes it possible to use PoP purely as an API to fetch or post data, alongside any other theme out there.

Enjoy!

We have started releasing the new PoP. This is the first time ever that PoP can be installed without fear of it breaking up: originally the codebase was not split into plugins, so if certain plugins were not activated, everything broke, greatly impairing the chance of developers being able to use it (for which the project barely has 50+ stars on GitHub). After 10 months of heavy work and tears, it started being ready. Hurray!

To download the new PoP API, simply head to the repository on GitHub and follow the instructions.

The overall migration is not finished though: only the API layer is ready, the rendering layers (for both client-side and server-side) are still under development, so they will be released in stages as soon as they are finished. We expect everything to be up by 2nd quarter 2019.

This is a major release: The new PoP API is fully based on components (we believe this is a primer among APIs, we’ve never seen or heard of one before), and will be able to offer unique capabilities, making it extremely easy to build any kind of website, from simple sites to decentralized social networks.

We will keep blogging about the new capabilities alongside each new release. Enjoy!

 

We are re-architecting PoP to make it much simpler to code with it, faster, and more versatile, planning to release it around end of 2018 or beginning of 2019. The new PoP will feature an architecture based on the following foundations:

• Everything is a module
• The module is its own API
• Reactivity

At the core of these changes is an upgraded API model, which will feature server-based components. Following the example set by GraphQL, which owes its success in part to being a specification instead of an implementation, PoP will be composed of the following layers:

1. The API (JSON response) specification
2. PoP Server, to serve content based on the API specification
3. PoP.js, to consume the content in the client

Being built around an open specification, we can expect different implementations to emerge, for different technologies. The current PoP site will immediately provide the first implementation of PoP Server and PoP.js:

• PoP Server for WordPress, based on PoP Server for PHP
• PoP.js through vanilla JS and Handlebars templates

The API (JSON response) specification

In PoP, a component is called a module. Each module is either an atomic functionality, or a composition of other modules. Hence, starting from the lowest-level modules (the atoms), modules will be iteratively composed together until obtaining the highest-level module (the page). The new API model respects the structure of how modules are composed, and print all information needed at each module level.

In PoP, the logic of the application does not reside on the client-side, but on the server-side. The server indicates what javascript functions will be executed, on what elements on the DOM, and with what values. This will extend to reactivity: it is the server who will decide when to make a component be re-rendered. Reactivity is supported by splitting the information for each module into two groups: static, which is non-reactive, and stateful, which is reactive; the application in the server knows if to apply reactivity based on the querystate parameters added to the URL.

The API structure is divided into module configuration, database data, and additional meta entries. Once finished, it will look something like this:

modulesettings:
    static:
        foreach module {
            configuration
                module
                template
            jsmethods
            dbkeys
            datafields
            foreach nestedmodules {
                repeat ...
            }
        }
    stateful:
        foreach module {
            configuration
            foreach nestedmodules {
                repeat ...
            }
        }
moduledata:
    static:
        foreach module {
            feedback
            foreach nestedmodules {
                repeat ...
            }
        }
    stateful:
        foreach module {
            feedback
            foreach nestedmodules {
                repeat ...
            }
        }
datasetmoduledata:
    static:
        foreach module {
            dbobjectids
            foreach nestedmodules {
                repeat ...
            }
        }
    stateful:
        foreach module {
            dbobjectids
            foreach nestedmodules {
                repeat ...
            }
        }
datasetmodulemeta:
    static:
        foreach module {
            dataloadsource
            lazyload
            foreach nestedmodules {
                repeat ...
            }
        }
    stateful:
        foreach module {
            dataloadsource
            lazyload
            querystate
            queryparams
            queryresult
            foreach nestedmodules {
                repeat ...
            }
        }
modulejssettings:
    static:
        foreach module {
            configuration {
                foreach jsmethod: {...}
            }
            foreach nestedmodules {
                repeat ...
            }
        }
    stateful: 
        foreach module {
            configuration {
                foreach jsmethod: {...}
            }
            foreach nestedmodules {
                repeat ...
            }
        }
modulejsdata:
    static:
        foreach module {
            inputs {
                foreach jsmethod: {...}
            }
            foreach nestedmodules {
                repeat ...
            }
        }
    stateful:
        foreach module {
            inputs {
                foreach jsmethod: {...}
            }
            foreach nestedmodules {
                repeat ...
            }
        }
databases
    primary {
        ...
    }
    userstate {
        ...
    }
requestmeta
    entry-module
sessionmeta
    loggedinuserdata
sitemeta
    sitetitle

Let’s analyze the features provided by the API’s structure:

Concerning modules

The “Everything is a module” maxim implies at there will only be 1 module at the top of the page, from which we start composing all the other modules. This module is defined under entry-module. Then, rendering the page will simply be rendering the entry-module:

Concerning data

Not all modules fetch data from the database. Hence there is a datasetmoduledata and datasetmodulemeta entries, which lists those properties needed only for modules fetching data, such as the queried object IDs, query state, etc.

Concerning extensibility of the API

The API is highly extensible for both module configuration and database data:

Module configuration: Because modules are nested, the information for one module will never clash with that from another module (for instance, the property “class” for each module will never override the property “class” for another module).

Database data: databases entry contains a relational representation of the data as stored in the database, with objects referencing each other through their ID, so the data for each object is rendered only once:

databases
    primary {
        posts: {
            1: {author: 1, title: "This is a post", ...},
            2: {author: 2, ...},
        },
        users: {
            1: {name: "Leo", ...},
            2: {name: "Pedro", ...},
            ...
        },
        comments: {
            1: {author: 1, post_id: 1, content: "This is a comment by Leo on post 'This is a post'", ...}
        },
        events: {...},
        locations: {...},
    }

This feature can already be observed in PoP’s current implementation, such as under item database in the produced JSON code in this link, which looks like this:

Increasingly complex relationships are possible, yet without ever making the query reach an infinite loop:

Fetch all posts. For each post:
    Fetch the author. For each author:
        Fetch the posts the user has "liked". For each post:
            Fetch all its comments. For each comment:
                Fetch the comment author. For each author:
                    Fetch all the events which this user is attending. For each event: 
                        Fetch its location. For each location: ...

Which translates into object types being loaded like this:

post => user => post => comment => user => event => location => ...

Concerning performance

The API introduces performance considerations for both module configuration and database data:

Module configuration: Splitting the API entries into static and stateful groups makes the configuration highly cacheable: whereas stateful data has state specific to the URL, static data has state specific to the module structure (ie how modules are nested inside each other, from the entry-module to the lowest levels), so it can be re-used for pages with different URLs, such as /events/1/ and /events/2/.

Database data: the retrieved data fields under entry databases are not defined in advance, but are the union of all data fields required by all modules, for all database objects. This model outperforms REST, which has a rigid structure in which all the data fields are defined in advance, and GraphQL, since it similarly fetches all the required data for the page in a single request, but it is cacheable on the server-side.

Concerning reactivity

Because reactivity is server-based, it can’t be implemented through client-based reactive libraries such as React, requiring a completely different approach. Whereas React employs a Virtual DOM to calculate and idenfity the minimal set of operations to apply on an existing element on the DOM to update it, which makes it ideal for highly dynamic operations, Handlebars, on the other side, simply generates the whole view for a module, hence its reactivity is slower. In order to also provide a reasonable reactive behavior, it will need be coupled with vanilla javascript operations and a sensible methodology of when/how to update the DOM:

• Re-render the layout when:
  • module’s layout configuration was modified
  • module’s database object changed to a different one
• Re-execute a javascript method when:
  • an input to the javascript method changed

And instead of executing a diff operation to calculate if the state has changed, the response from the API will simply return data whenever it must be re-rendered, under the stateful branch. Hence, the server will know the state of the application (passed back and forth through entry querystate) and return data, or not, accordingly.

In summary, the reactivity produced will not be as highly dynamic as React’s, but it will be good enough to have the site be self-updated after an operation is produced, such as when editing or deleting a post, adding more posts on an infinite-scroll, adding the user’s RSVP to an event, or updating the counter of post likes and user followers.

Concerning data loading

“The module is its own API” concept means that the module does not need be provided an external API to fetch data from (REST, GraphQL), but it can already fetch its own data from the server. The module is self-sufficient, providing rendering and dataloading, and it is isomorphic, providing all the different functionalities from a single codebase. Hence, there is no difference between a module and its API: the module is the API, and the API is the module.

As a consequence, coding in PoP becomes incredibly simple: a single developer can tackle both the layout rendering and dataloading at once, and these two tasks will always work together (for instance, there is no risk of an API not retrieving a field required by the layout).

Once rendered in the client, a module can interact with itself simply by setting its dataloadsource property (i.e. the field indicating from where the module will fetch its data, or execute a POST operation) to the URL of the page where the component was added, plus an entry-module parameter with its module path (i.e. the list of modules, starting from the top level module, until reaching the corresponding module). For instance, requesting URL /some-page/ may produce the following response, bringing database data and module configuration for all modules in the page:

module1
    configuration
    nestedmodules
        module2
            configuration
            nestedmodules
                module3
                    configuration
                module4
                    configuration
                module5
                    configuration
                    nestedmodules
                        module6
                            configuration

And requesting URL /some-page/?entry-module=module1.module2.module5 will produce the following response, bringing database data and configuration for all modules starting only from the module module5, and removing everything else:

module1
    nestedmodules
        module2
            nestedmodules
                module5
                    configuration
                    nestedmodules
                        module6
                            configuration

In addition, a parameter modulefilter can allow to bring a pre-arranged set of modules. For instance, calling a page with ?modulefilter=userstate can print only those modules which require user state for rendering them in the client, such as modules module3 and module6:

module1
    nestedmodules
        module2
            nestedmodules
                module3
                    configuration
                module5
                    nestedmodules
                        module6
                            configuration

Hence, this API delivers better performance than both REST and GraphQL since it can bring more data on each request:

• REST fetches all data for one entity (eg: one post) or group or similar entities (eg: one set of posts)
• GraphQL fetches all data for entities of different types in a component (eg: one post plus its author plus the author’s location)
• PoP fetches all data for all entities, for all components in a page or from a subset of components (eg: all posts, their authors, and their locations, for all components on the page, and with all data retrieved in a relational structure so no data item is duplicated)

Concerning reusability/documentation/maintenance

Using the entry-module parameter to fetch the data for a specific module can also be used to produce the output of that module alone, in isolation, meaning that it will also request the resources (JS/CSS) needed starting from that module onwards. Hence, if requesting /events/ produces the following webpage…

… in which the module for the central calendar is found under the module path toplevel.mainsection.calendar-block.calendar, requesting /events/?entry-module=toplevel.mainsection.calendar-block.calendar will produce the following response:

… and loading the controls module under toplevel.mainsection.calendar-block.calendar.controls we get:

This is the rendering of the module, independent of the context under which it is placed, providing the following benefits:

• Automatic documentation: the module is self-documented and a living pattern library
• Transclusion: websites can render other websites’ modules into themselves, and the rendering happens directly in the page, and not in an iframe, as can be already seen in SukiPoP.com (whose feed is rendered with data from several other websites)

Concerning versatility of outputs for different mediums

The nesting of modules allows to make a fork to another module to add compatibility for a specific medium or technology. For instance, let’s say the webpage has this structure…

module1
    configuration
    nestedmodules
        module2
            configuration
            nestedmodules
                module3
                    configuration
                module4
                    configuration

… and we would like to make the website for AMP, however module2 and module4 are not AMP-compatible (eg: they add unsupported Javascript), then we are able to fork the modules into a similar, AMP-compatible modules module2AMP and module4AMP, only for those specific cases, while everything else stays the same:

module1
    configuration
    nestedmodules
        module2AMP
            configuration
            nestedmodules
                module3
                    configuration
                module4AMP
                    configuration

Summary

The new PoP will bring powerful new features. By being based around an open specification, it will open the doors for implementation for other platforms (in addition to PHP/WordPress). The server-based reactivity will provide an alternative to client-based javascript libraries. It will be thoroughly based on components called modules, which provide both their rendering and dataloading from a single codebase. And it will be highly cacheable, both at the server and client-side.

If everything goes fine, the new PoP will be released around end of 2018 or beginning of 2019.

Even though released as open source 2 years ago, PoP still doesn’t have installation scripts, making unfamiliar developers unable to install it (to this day, it has barely received 50+ stars in GitHub.) 8 months ago we finally started working on the scripts. In the process, we discovered several issues which had to be fixed too. Given the ambition of what the new PoP will be able to offer, and the amount of code developed during the last 5+ years which needs refactoring, after 8 months of work we still haven’t finished. If everything goes fine, the new PoP will be released around the end of 2018 or beginning of 2019.

After PoP is newly released, it will live up to the expectations of being called a framework: until now, PoP was pretty much limited to building community-focused social networks like MESYM.com, but through the new PoP it will be possible to build any type of website: static, dynamic, with/out users, with/out Single Page Application, with/out Server-Side Rendering, etc

There are 2 big announcements:

1. PoP is being re-written, based on the following foundations:
   • Everything is a module
   • The module is its own API
   • Reactivity
2. The codebase has been modularized and made CMS-agnostic, and plenty of new features have been developed

Announcement #1 is quite big on its own, so it will be dealt with in its own blog post. Below we deal with Announcement #2, describing some of the new features/enhancements produced during the past 8 months. These have not been uploaded to the Github repo yet, because the code in still under heavy development (we expect to do it around the end of 2018 or beginning of 2019).

Split the codebase up into countless plugins, allowing to progressively enable features

In the past, PoP was a huge monolithic codebase, in which you either got everything (a site such as MESYM.com) or nothing, since code was dependant in such a way that deactivating a feature may break everything else.

We have progressively fixed this by identifying pieces of code, analyzing their functionality, and placing them in a specific plugin. To this date, we have produced more than 50 plugins, and since we haven’t finished, it is still increasing.

Some plugins we have created deal with functionality, such as the following:

• pop-userlogin: Allows users to log-in to the site from the front-end
• pop-userplatform: Allows users to create an account on the site
• pop-socialnetwork: It transforms the site into a social network, adding features such as liking posts, following users, and others

Some other plugins deal with the framework itself, such as the following:

• pop-spa: Transforms the site into a Single Page Application
• pop-ssr: Enables Server Side Rendering on the site
• pop-resourceloader: Enables code-splitting

Until now, all code had been housed under a unique Github repo, but from now on every plugin will have a repo of its own. Having their own repository, each plugin will have its own documentation, and its own methodology for installation (some plugins may depend on Composer, others on NPM, others on GitHub subprojects, etc…)

Introduced dependencies among plugins

Plugins will be activated only if their dependencies are all active. Then, in the hierarchy from plugins described above, we can declare:

• Activate pop-socialnetwork only if pop-userplatform is active
• Activate pop-userplatform only if pop-userlogin is active

This way, the application will always work, such as avoiding compilation errors if a required PHP class is not loaded anymore.

Split the application into 4 layers: API, Frontend, Backend, and Implementations

Each plugin is divided into up-to-4 separate yet interconnected subplugins:

• API: it deals with data-loading/posting for each module
• Frontend: JS and CSS resources, Handlebars JS templates, general functionality when there is a browser client.
• Backend: abstract classes establishing the configuration for a module
• Implementations: actual module implementations, filling the configuration values as suitable

This architecture makes a module itself be modularized. Such fine-grained modular architecture allows for scalability/extensibility: developers can add their own custom implementations, replace the frontend JS/CSS files, establish a different configuration for a module, all without affecting the other portions of code.

In addition, if the Frontend layer is disabled, then the site barely returns the data in JSON, hence effectively becoming an application server. If we have all the layers enabled, the site will look like normal:

However, when plugin pop-engine-frontend is disabled, and we reload the page, we get this response instead:

Which viewed through a JSON formatter looks like this:

 

This is basically the JSON response containing all the data needed to render the page. Since disabling the frontend layer in the application, PoP assumes that only the data is needed and nothing else.

Re-organized the architecture to support other Content Management Systems

Because most of the code for PoP is plain PHP, it can perfectly be made CMS-agnostic, so that PoP could also be powered by other PHP-based Content Management Systems, such as Joomla or Drupal.

For this purpose, we implemented several interfaces (such as PoP_CMS_FunctionAPI, PoP_CMS_ObjectPropertyResolver and others), which list those functions that will be needed by PoP, expecting the implementing CMS to provide an implementation for them.

Currently, this feature is still under heavy development, with the function signatures being those used by WordPress (eg: functions names get_posts, get_users, etc, and also expecting the same parameters as by the WordPress functions) so it is not expected for other CMSs to be plugged in and work immediately; plenty of work is still required. However, the architecture has already support for the extending into other CMSs, so it must just be implemented.

Introduced interfaces to make functionality be plugin-agnostic.

Many modules in PoP rely on 3rd-party plugins for their functionality, and if that 3rd party plugin was not installed, then the component would not function. For instance, the events calendar in MESYM.com relies on plugin Events Manager for fetching the events; if Events Manager is not installed, then the website cannot display the PoP events calendar module.

We have now overcome this restriction by introducing interfaces to connect the 3rd party plugins with the PoP modules. For instance, for the events calendar mentioned above, we have now added interface PoP_Events_API listing down all the functions required by the calendar functionality, so that Events Manager just provides an implementation of this interface. This way, other plugins can also be used as functionality providers.

Implemented infinite data-loading

Similar to GraphQL, the site allows to fetch relational data, involving many relationships among object types and as complex as needed, such as:

Fetch all posts. For each post:
    Fetch the author. For each author:
        Fetch the posts the user has "liked". For each post:
            Fetch all its comments. For each comment:
                Fetch the comment author. For each author:
                    Fetch all the events which this user is attending. For each event: 
                        Fetch its location. For each location: ...

Which translates into object types being loaded like this:

post => user => post => comment => user => event => location => ...

PoP will fetch the data from the database, and replicate the relational structure of the data into the resulting JSON object:

database: {
    posts: {
        1: {author: 1, title: "This is a post", ...},
        2: {author: 2, ...},
    },
    users: {
        1: {name: "Leo", ...},
        2: {name: "Pedro", ...},
        ...
    },
    comments: {
        1: {author: 1, postId: 1, content: "This is a comment by Leo on post 'This is a post'", ...}
    },
    events: {...},
    locations: {...},
}

The data for each object is fetched only once from the database, and it is printed only once on the output (i.e. it is not nested), making it very efficient. Adding additional levels doesn’t incrase the complexity of the query operation (as in GraphQL), while being fully cacheable on the server side (unlike GraphQL.)

Allowed data to be marked as dynamic, so it will be sent to the frontend even when doing SSR

For optimization reasons, when doing Server Side Rendering (SSR) we don’t send the JSON object with all the database data, which may be quite big. However, this carried the issue that some data is actually dynamic, i.e. it will be used on the client to dynamically create views. Hence, for these situations, we had to send the whole database.

Now, through the newly added function get_dynamic_data_settings, it is possible to mark what data-fields are dynamic, and in that case only these are also sent to the frontend, and all static data, which is already rendered in the HTML generated in the server through SSR, is discarded, effectively sending less data down the wire.

Many more

• Used PHP traits to re-use code, between classes in plugins PoP Engine and PoP Frontend Engine
• Converted categories with particular functionality/inputs into custom post types (eg: Highlight custom post type)
• Made blocks self-aware if they require lazy-loading based on the checkpoint status of their corresponding page, so that lazy-loading can be done automatically instead of through configuration
• Streamlined code by grouping functionality (eg: function pop.DynamicRender.render), created interfaces (eg: FormComponent)
• Split all Handlebars helpers into multiple files, as to only load what is needed and improve modularity
• Moved all PoP JS functions under global variable pop, so as not to pollute the global scope anymore
• Re-wrote plenty of modules from scratch
• And many others

TL;DR: This is the story of how and why PoP quit Station F starting from March 2018, as a consequence of Station F staff’s lack of accountability and professionalism, of their operating with favouritism and breaching of the trust put in them, and of Station F itself not living up to its stated inclusivity values.

---

In the screenshots from Station F’s Slack below, the usernames, names and avatars on the posts by Station F residents have been blurred. Station F staff info has also been blurred, however the "-staff-stationf" bit on their usernames has been kept intact for ease of understanding. All screenshots have, as a title attribute, the date in which they happened.

Hi, I’m Leonardo Losoviz, creator of PoP. I will recount how and why I decided to have PoP quit Station F, the biggest startup campus in the world, which is located in Paris.

In April 2017, PoP was accepted to be part of Station F’s Founders Program, for which I took the decision to move to Paris and start operations there. However, because I am not a European citizen, I need a visa to be able to move to France. I flew to France and joined Station F from the day it opened its doors in early July, under a tourist visa, and immediately started searching for ways to obtain a permanent visa.

On 17th July 2017, after the first startup founders meeting for our guild, I explained my situation to Station F’s Startups Relations Director, who from now on I will call Jacques (not his real name), and he told me that Station F’s Founders Program would soon be accepted as a partner of the French Tech Visa program, a scheme recently implemented by the French Government which allows foreign entrepreneurs to obtain a visa to live and work in France for 1 year, and renewable for up to 4 years. I had to wait though, since the French Government would not indicate when Station F’s fast track to become a partner of the program would come through. After being told that by being part of Station F’s Founders Program I could obtain a visa, I returned to Malaysia in September 2017, and continued working on my Paris-based plans under the understanding that the fast track would soon come through and I could then obtain the visa.

I initiated the process to get my visa in Kuala Lumpur, in October 2017, and waited for the fast track to come through during October, November, December 2017 and then January 2018, all the while paying for my membership and regularly communicating with the Station F staff concerning progress of the Founders Program’s fast track. On 18th January 2018 the fast track finally came through, meaning that I could finally ask Station F to grant me the Lettre de Reconnaissance (Recognition Letter), an official document required for applying to the French Tech Visa. This was the last document I needed in order to get the visa and move to France. However, to my utter surprise and chagrin, Jacques (Station F’s Startups Relations Director) had a change of mind, and on 1st February informed me that, since they were not obligated to help me in the process of getting my visa, they would not do so:

The content of this email is unmistakable: in barely a few words, Jacques, who back in July 2017 had told me that by being part of Station F’s Founders Program I could apply to the French Tech Visa, contradicts his assurance, completely disrupting the plans I had been working on for 5 months, and the goals I had laid out for the future.

Jacques’ behavior is certainly troublesome. I could have attempted to talk the situation through with Station F’s Director, however, I was discouraged to do so because this person had actually been CCed in the email (this is not visible in the screenshot having had the names blurred), suggesting that Jacques’ actions are supported by the management. If the management is aware of Jacques’ initial pledge in July 2017, and later reversal in February 2018, of that I have no information. (As far as I can tell, there is no paper trail of what happens behind the scenes: as Jacques mentions in his email, Station F is a private enterprise that has no obligations towards, or be accountable to, Station F’s residents.)

The whole episode triggered many thoughts in my head over the following days. Feeling disturbed by the staff treating me without the respect I deserve either as a person or, more importantly from their perspective, as a paying customer, I started reviewing all my interactions with the Station F staff, as well as all public interactions between the staff and all residents, and discovered that it was riddled with unpleasant situations and half-truths.

The result of my observations is this blog post. In it, I will show how the Station F staff have subjected me to a very unfair and unjustified treatment when they decided to not grant me the document required to obtain my visa anymore. We will also see how my situation was produced by the inherent conditions at Station F, under which residents are constantly frustrated for one reason or another, even up to this day (end of February 2018.)

My post on Slack from August 2017

Let’s start analyzing Jacques’ email. In it, he justifies not helping me obtain the visa by accusing me of:

• having a bad tone
• having a bad/negative attitude
• complaining about not having some services (like VCs, printers, lockers, construction work, directory, Wifi, etc)

At the end he says:

Our role is to […] always improve based on your feedbacks but there are certain ways to do it. The long list of questions you had in August, your last emails make wonder if our offer matches with what you expect.

He is referring to a message that I posted on Station F’s Slack on 29th August 2017 (that is the screenshot he added in his email), which is the following:

That day, the atmosphere at Station F was experiencing extreme negativity, due to residents feeling particularly frustrated from several ongoing issues, such as: deafening construction noise taking place inside of the premises, Internet not working properly, lack of information/feedback concerning promised services, tickets requesting information or fixing some problem being ignored or mishandled, and others (a more complete list of issues can be found in the Appendix at the end of this article). Many of these issues had happened regularly since Station F opened its doors in early July (such as the Internet not working properly), while others started taking place only a couple of weeks earlier (such as the construction noise). The improper handling of these issues by the Station F team led, that day, to an outburst of anger from some residents.

Construction noise was making it difficult for the residents hosted nearby the construction area to work properly, and so they were asking/complaining about the situation. A resident posted the message below on 21st August:

Both the noise and residents’ frustrations intensified during the following days, leading to more explicit protests, like the message below which was posted on 25th August:

Finally, on 29th August, the noise reached a crescendo that many residents could not cope with anymore, making the atmosphere inside the campus incredibly negative. One resident asks the Station F staff to stop the noise, since it was almost impossible to work in those conditions. A Station F staff member replies saying "it’s almost done", to which the resident complains to have been told that for 3 weeks, yet the noise continued unabated:

A few minutes later, the same resident uploads a video of the construction noise to Slack, and threatens with sharing it with his 25000 followers on Twitter:

The video shows the noise inside of Station F at the time:

Download video

25 minutes later, the same resident threatens once again to upload the video to Twitter, since no Station F staff is answering his concerns, and all the while the noise continues:

25 minutes later, the Station F staff promises that construction will continue for only 40 minutes more, and then it would stop:

While some residents were venting their anger by cursing, others were releasing their frustration by making fun of the situation:

2.5 hours later, the noise resumed, prompting some residents to claim how the handling of the situation was a failure, and even questioning the credibility of the staff:

Only after 30 minutes or so later the noise finally stopped. The Station F staff posted a message announcing it, including a GIF image which was unsuitable to the set of circumstances:

The GIF is this one:

It was at this stage, noticing how residents were angry and frustrated, yet the staff did not comprehend the seriousness of the situation, that I felt compelled to write my post. In it, I pointed out that the real issue was a lack of proper communication inside of Station F: residents knew all along that Station F was still under construction and they accepted it with no objections; they only requested to be told, in advance, when the construction would take place, so they could prepare accordingly. The message suggested that all that was needed was a small gesture to handle the situation properly, and avoid making residents angry. And most residents seemed to agree with the message: a full 39 people showed approval (through Slack reactions), making it among the most-upvoted posts on Slack ever posted by a resident (even to this day, and even taking into account that Station F had fewer residents back then):

Furthermore, a few residents replied to my message, showing their support. In particular, a "thank you" note to me posted by a resident was itself upvoted by 13 people. This act of support by other residents shows that my message had achieved its intended objective, bringing back a sense of peace to the environment.

The Station F staff apologized about the ongoing situation, while addressing the many issues mentioned in my message:

However, my message was not itself about getting a response for those specific issues, but to point out the actual underlying problem: the lack of proper communication at Station F. In addition, because my goal was to improve the situation for everyone, I claimed that us residents should be patient with Station F staff since they were also learning all along. So I posted a follow-up message on Slack:

My message was immediately acknowledged by the Station F staff:

No more messages were posted on the Station F open channel on Slack, signalling that the issue had been overcome. One day later, however, Jacques contacted me through a direct message on Slack, accusing me of being pissed and causing a scene:

I explained to him that, on the opposite, I was the one trying to improve the situation, not the one who originated it:

He seemed to understand then:

Finally, I gave him a more detailed account of what happened, while praising Station F for what had achieved, yet claiming that it still had to improve on the tiny details:

He didn’t reply back. The whole episode seemed to be clarified, and would hopefully lead to a positive outcome: posting the message had been the right thing to do. Fast forwarding to 1st February, I received Jacques’ email (already shown previously):

I had never expected, back then, that posting my well-intentioned message on Slack would lead to such dire consequences for me, as making Jacques decide to not grant the Lettre de Reconnaissance to me anymore, thus denying me the chance to apply for the French Tech Visa and be able to move to France. Unfair, isn’t it?

Addressing Jacques’ accusations of bad tone/attitude from my side

As I mentioned earlier, Jacques told me on 17th July 2017 that I could apply for the French Tech Visa through Station F’s Founders Program when the fast track came through. Because it was not known when the fast track would go through, and not under their control (they were themselves waiting for procedures from the French Government), he suggested that I should also consider other avenues of applying for the visa, so I wouldn’t have to wait.

Between July and September, I attempted to get my visa through other means, but was unsuccessful. Then, upon the expiry of my tourist visa on mid September, I returned to Malaysia and announced to the staff that I would initiate the visa procedures:

On 12th October I had an interview at the French Embassy in Kuala Lumpur. One day later, they informed me that I must present the "Lettre de Reconnaissance" to apply for the French Tech Visa:

Because Station F could not grant the Lettre de Reconnaissance before being a partner of the French Tech Visa, and because they didn’t know when the fast track would come through, they got me in touch with a representative from the French Government to ask them directly. I did so, but after a few days, I still didn’t get a response to my inquiry.

Then, on 23rd October 2017, I asked Station F’s Startups Junior Manager to ask the French Government’s representative to reply to my email. Please notice how this email explicitly states the understanding between me and the Station F staff: once Station F Founders Program’s fast track got through, Station F would help me get the required documentation to apply for the visa:

Dear reader, would you think that the Station F staff replied to me saying that this information was incorrect, that the Station F staff had never told me they would grant me the Lettre de Reconnaissance? No, this person did not do that, did not deny any information that I said, thus demonstrating that what I said was our common understanding of the situation.

Instead, and as I had requested, the Startups Junior Manager forwarded my inquiry to the French Government’s representative, and also CCing Jacques in the email (this is not visible since the name is blurred):

Indeed, in all our communications between September 2017 and January 2018, the Station F staff NEVER indicated that they would not grant the required documentation to apply for the visa. The email below is another example: on 17th January 2018, Station F’s Startups Junior Manager informed me that:

French Tech Visa is almost done with their process, it is a matter of days, we’ll let you know as soon as they announce it!

So, just 1 day before the fast track went through, and less than 2 weeks before Jacques’ email on 1st February, the Station F staff still evidenced that they would grant the Lettre de Reconnaissance to me.

Fast track comes through, Jacques changes his mind

On 19th January, I was informed by the French Government’s representative that the French Tech Visa fast track finally went through:

I immediately notified the French Embassy in Kuala Lumpur, who were waiting for me since end of November to present the Lettre de Reconnaissance, that I could finally apply for the visa:

And I asked the Startups Junior Manager to process the Letter de Reconnaissance for me:

However, the Station F staff never replied to me. I asked again 5 days later.

Once again I got no response, so I wrote again one week later. Since I had first written almost 2 weeks earlier, the French Embassy in Kuala Lumpur was waiting for me, and the Staff was ignoring my emails, I mentioned that I was getting frustrated:

And then, Jacques finally replied my email. However, utterly unexpectedly, he informed me that they had decided to not grant the Lettre de Reconnaissance to me anymore, thus effectively barring me from moving to France, under the justification of a negative attitude from my side when I posted my message on Slack, my demands, and the tone I employed when addressing them on my emails. Once again, this is Jacques’ email:

In summary: I waited for the Founders Program fast track to come through for several months, all the while paying for my membership and making plans to move to France. One day the fast track finally went through, and I requested the staff to grant me the Lettre de Reconnaissance; however, my emails were ignored, prompting me to ask for feedback again, only to be ignored again, and finally be flatly denied the document I had waited for, and which the Staff had evidenced they would provide to me.

Is that what a normal person would call "such demands and tone every day"? Not really, right? His accusations of bad attitude and tone from my side are completely unfounded, simply evidencing a dislike that this person has towards me.

Analyzing Jacques’ behavior from his email

Jacques’ emails is revealing in that it exemplifies how Station F staff operate, evidencing lack of professionalism, favouritism and exertion of undue power, among others.

Lack of responsibility

In his email, Jacques says that he will not deal with my demands for feedback concerning the Lettre de Reconnaissance:

I will be honest with you: I can’t deal with such demands and tone every day (and I won’t deal with it).

Jacques is Station F’s Startups Relations Director. Obtaining the Lettre de Reconnaissance, which is the last document I needed to obtain my visa, is indeed no small matter for me, a Station F’s customer, yet he repeatedly ignored my emails and finally said that he would not deal with my demands. Hence I wonder, what is the Startups Relations Director’s role for then?

Lack of respect

Jacques seems to ignore the fact that I am a (paying) customer, or at least he doesn’t treat me with the respect that I deserve as such. He may dislike me, but that doesn’t give him the right to treat me with comtempt.

Absence of due process

Jacques had initially said I could obtain my visa through Station F’s becoming a partner of the French Tech Visa program, yet later on, once the fast track finally went through, he changed his mind and denied granting the required document to me.

Hence I wonder: How did this happen? Was the decision reviewed/approved by management, or taken by a single individual following his whims? Why wasn’t I given the chance to explain the situation before such drastic decision was taken?

Favouritism

It is apparent that I was denied the Lettre de Reconnaissance not as a general policy, but due to having fallen into disfavour with the staff. When I mention that they decided to not grant the Lettre de Reconnaissance to me, we need to pay special attention to these keywords: To me. Whenever any member of the Founders Program requests the Lettre de Reconnaissance, will the staff also deny it, as a general policy? This doesn’t make sense at all, since the obvious reason for having the Founders Program be a partner of the French Tech Visa program is to allow its members be able to apply for the visa.

Moreover, Station F’s Director Roxanne Varza explained that hosting international startups is among the top priorities for Station F:

From the first day I joined Station F, I promised myself I would do everything I could to make Station F as international as possible. In fact, being international is so important that it quickly became one of our 3 core principles at Station F. We strive to integrate international elements into everything we do — whether it be hosting international startups, […] or seeking out administrative solutions to help foreign entrepreneurs coming to Station F… and the list goes on.

In other words, the Station F staff are giving unfair preferential treatment to its startups/customers, deciding who they help obtain the visa and who they do not, purely based on the whims of their staff, and giving the residents no recourse about it.

Indeed, I am not the only person who sufferend Station F’s staff favouritism. In the screenshot below, another resident complains about staff giving preferential treatment to residents when asking for help (the context for this screenshot is given on section "Improving situation, but not quite there yet" below):

I guess it depends on who posts

The lack of equal treatment for residents indicates a possible rotten culture, in which residents who raise an issue at Station F may be punished by some disgruntled staff, who has the power to grant or deny a needed service. And since Station F is not accountable to its residents, there is no due process to contest the decisions taken by the staff.

Breach of trust

I have been waiting, and paying for my membership, for a full 5 months. Had I known that I would get the Lettre de Reconnaissance denied, I could have left earlier on. This is not just 5 months of wasted time and energy into the venture, but also almost 1200 euros in membership fees (195 euros + VAT / month) that I paid for nothing. While this amount is negligible to Station F, it is a considerable amount for me, taking into account that I have been working for non-paying non-profits (such as this one, this one and this one) for the last 5 years. The Station F staff were aware of this fact: during their selection interview, I explained the philosophy behind PoP, claiming that the goal was not to create a multi-million dollar business, but to help NGOs own their own online platforms and control their own data. In addition, I am not profiting economically from PoP, having decided to share its code as open source software. And working in open source may be quite hard: sometimes it is even difficult to make it to the end of the month.

It is under these conditions that I accepted to pay for Station F’s membership all these months, trusting that I could eventually obtain my visa through Station F’s Founders Program, as Jacques had told me in July 2017, so I could move to France and start operations there. When Station F finally had the power to grant me the Lettre de Reconnaissance, they refused to do so, effectively breaching the trust I had in them.

Paying attention to Station F’s championed inclusivity values.

Jacques’ behaviour, including his reversing his assurance that I could get the visa through the French Tech Visa and his not respecting me as a paying customer, made me wonder: how can Station F employ people with such behavior, given the values it claims to hold as an institution? Which then led me to wonder: is Station F the place I believed it to be, the place which had attracted me to apply to their Founders Program in first place?

Station F claims to be a place that operates according to principles. For instance, during Station F’s inauguration, Director Roxanne Varza stated that she hoped Station F would "make entrepreneurship no longer all white, all male, all MBA". In addition, one of the three programs run by Station F (most other programs in campus are run by 3rd parties, such as Facebook, Zendesk and others) is the Fighters Program, which hosts 13 startups coming from unprivileged backgrounds for 1 year, for free. Finally, they state that the startup founders participating in the Founders Program (which is another one of the three programs run by Station F) are 40% female.

The inclusivity message does sound very enticing, and that was one of the main reasons I wanted to be part of Station F in first place.

However, while I was physically at Station F’s campus between July and September 2017, what could be mostly seen on campus were white men. Yes, there were women. Yes, there were non-white people. But, from the impressions that I got, they were a minority. To make sure if my impressions were right, I checked if their claims of inclusivity can be backed-up with numbers or not, summarized below. Please notice: I am not asserting that the numbers below are representative of the actual demographics at Station F, since I do not have that information, however I believe that they can be considered a good proxy to estimate the real situation.

I browsed all Station F’s newsletters (a total of 25 up to late February 2018) and paid attention to the section "Meet a founder", in which startup founders are featured on a weekly basis and showing a picture of them, and counted how many of each group (men/women, white/non-white) there are. For a total of 105 people featured in the newsletter (mostly founders, and also their team members in a few cases) from several programs on campus, run by both Station F and 3rd parties, the results are:

• Men: 83/105 => 79%
• White: 94/105 => 89%
• Men and white: 74/105 => 70%

If we just limit the search to members of the Founders Program, which is run by Station F, for which it is claimed 40% of its founders are female, from a total of 51 people featured in the newsletter we get:

• Men: 43/51 => 84%
• White: 40/51 => 78%
• Men and white: 34/51 => 66%

These results are revealing to me. These numbers suggest that 70% of founders from all programs, and 66% from the Founders Program, are male AND white, and Founders Program’s female founders are only 16% of the total, instead of the publicized 40%.

The inclusivity factor was one of the reasons I wanted to be part of Station F. However, it seems that inclusivity at Station F is more wish than reality (or just a publicity stunt?)

This is the end

I find Jacques’ decision to not grant the Lettre de Reconnaissance anymore to me both morally wrong and gratuitously harmful. Operating without due process or respect towards a paying customer, an action taken by a single Station F staff member has the effect of producing profound repercussions on my life, such as denying me the chance to move to France.

Dear reader, let me ask you: how would you feel if you rely on some institution to grant you the documentation needed to apply for your visa after being told by their staff that you could do so, to then having this person change his mind and disrupt your plans?

How would you feel if such a decision was taken due to your doing the right thing, when you posted that message on Slack to calm people down and reduce the negativity in the atmosphere? And even after explaining the whole episode to this same person who is accusing you of bad attitude?

How would you feel knowing that you are not respected as a paying customer, and that you have been singled out because some person with power doesn’t like you, and makes use of that power to affect your life?

I can tell you how it feels: horrible.

However, as with every horrible experience, I learnt a lesson: I discovered that Station F is not the place I had believed it was, the place where I wanted to be. I accept a few problems here and there (no organization is perfect), however I could never be part of an insitution which doesn’t abide by its stated values, with an unprofessional staff that treats its clients with favouritism and that exercise their power to do harm.

So I decided that I don’t want to be part of this anymore.

For all of this, Station F, I’m saying goodbye to you. I do still hope that you shall improve and change your direction, if only for the wellbeing of the startups you are hosting. I hope they are never let down as I have been, which, I can tell you, is no fun.

Appendix 1: #StationFrustration in screenshots

Frustration at Station F had been steadily accumulating since the day it opened its doors beginning of July 2017 and, on the particular day of 29th August 2017, the negavity reached a peak, having a resident threatening to showcase the construction noise to his Twitter 25000 followers, and many others sharing their grievances openly on Slack, which prompted me to post my message on Slack trying to calm people down.

Residents have had plenty of reasons to feel frustrated about at Station F. From the first day and even until today, negativity and frustration have gone up and down, as we can discover in the screenshots below, which can roughly be grouped into the following categories:

• Construction problems
  • Holes in the building
  • Bathroom problems
  • Showers not working
  • Water leakages
• Improper services or infrastructure
  • Microwave queueing
  • Temperature problems
  • Bad smell
  • Alarms going crazy and nobody turning them off
  • Malfunctioning internet
  • Malfunctioning printers
• Improper maintenance
  • Dying nature
  • Cockroaches
• Improper communication
  • Concerning construction noises
  • Un-answered tickets
  • Unfulfilled requests for information or features
  • Improper handling of printers/lockers not ready for a long time

The list of screenshots is quite extensive, so I have compiled these on this separate post. Below is a subset of them, showcasing some of the most salient examples of frustration.

Whenever in French, the screenshots have been translated to English.

Construction problems:

Mayday it’s raining behind my post (ie inside station F mezza block 7)

We found out why it’s cold and why we hear work from outside…
There is a beautiful opening on the outside between the two beams!
River-side, Mezzanine, Block 7, (Impulse-Partners Program)
@… it would be super nice that you could send someone to watch what can be done. The … and … teams thank you in advance.

Image name: Dangerous ramp. Block 7 mezzanine

Improper maintenance:

Improper communication/Lack of information:

Improper services or infrastructure:

Otherwise, you have to be a developer to understand how to print here ?? 😡

Ethernet still down block 4 … it’s been days that it works badly, and I do not have the impression that Station F cares..

Improving situation, but not quite there yet

Starting from late October 2017 the situation improved remarkably, since a staff member started being very responsive, by not just solving residents’ problems but also giving them reassurance and positive feedback through Slack.

However, frustrating experiences still happen regularly, giving way to occasional episodes of extreme negativity and anger. The situation below happened on 23rd January 2018, when that same responsive staff member openly accused a few residents of inappropriate behavior and double-discourse, prompting Station F’s management to intervene to bring tensions down.

The situation started with a resident complaining about the Internet not working properly:

Help problem of internet connection block 8 side Zendesk! Wifi and wired HS!

Another resident confirms the problem, saying that the situation is unbearable:

I confirm, it’s unbearable, even the wire does not work anymore, it’s not possible
it gets cut every X min

He complains again 10 minutes later:

@… it just fell again for several minutes

And again 20 minutes later:

@… one more time

And again 10 minutes later:

The Station F staff reacts, sarcastically thanking the resident for pinging him each time the Internet went down, and saying that residents must create a ticket on HAL to have the staff solve the problem:

Hello @…, Thanks for pinging me every time there is a cut..
But we are not alone on the channel.
You encounter a problem, you open a ticket on HAL, a dev takes care of it and answers you.
Thank you

The resident indicates that he must still have tickets from August still not taken care of, evidencing the frustration experienced from using the ticket system:

@… oh yes, I must still have tickets from August…

it’s today that we need to work, not in 3 months, we launch product hunt tomorrow, we need a little internet

The first resident supports this message, stating that his own tickets were not taken care of:

@… indeed the tickets on HAL are often unanswered, the proof being that on our side (…) we have opened several tickets, for the wired network part HS in the mini room but no action has been taken for several months…

To which the Station F staff gathers information about the open tickets from these 2 residents and shares this information on the open channel:

@… you made 1 ticket. the techs answered you.
@… 0 active tickets from you.
Our teams work every day on the tickets, especially the devs, so stop saying, to facilitate, that we never answer.
Once again, you have a problem, you make a ticket. Not bothering me with each of these things would be cool.

The second resident shows how another resident got immediate help when asking on Slack:

@… Hello, we have no power in the room "Gondola" in Share River side. Thank you for your help!

@… I send you someone immediately.

And finally suggesting that the staff treat residents with favouritism:

I guess it depends on who posts

And the first resident explains how their tickets had been closed without verifying if the problem was fixed:

@… bah yes my last ticket was opened in October and closed by … late November but still the same problem in January a team had to intervene but still not since late November. So easy to close tickets without checking.

The second resident asks what is the purpose of the channel, if not to seek for help about issues:

Subject of the channel: "Something wrong at STATION F? Ask for help here or send an email at help@stationf.co – for specific tech issues, go to #tech-help"
Maybe the channel should be closed then
or specify the topic

It is at this moment that Station F’s management intervenes, to alleviate the escalating tension:

I allow myself to intervene. Has the situation improved? Indeed it is better to go through a ticket on HAL, even if we do not send answers to everyone, the tickets are read by the tech teams and they react as quickly as possible.

Only then, the problem was solved.

Appendix 2: series of events that lead to PoP quitting Station F

The following table summarizes all the events as they took place:

Date	Event
April 2017	PoP is accepted into Station F’s Founders Program.
03-07-2017	Station F opens the doors to its Founders Program’s residents. I fly to Paris to be at Station F from the first day.
17-07-2017	Jacques, Station Startups Relations Director, tells me that through Station F’s Founders Program I can apply to the French Tech Visa, but I must wait until the fast track comes through.
29-08-2017	Deafening construction noise in Station F, residents complain, I post a message on Slack to calm people down.
30-08-2017	Through a direct message, Jacques accuses me of being pissed, suggesting that I had caused a scene. I explain the actual situation to him, pointing out that I had succeeded in calming people down, which had even been acknowledged by the residents. He seems to understand.
19-09-2017	My tourist visa expires, I return to Malaysia. I continue working on Paris-based plans for PoP.
12-10-2017	I am interviewed at the French Embassy in Kuala Lumpur, to review my documentation to apply for the French Tech Visa.
13-10-2017	Staff from the French Embassy in Kuala Lumpur inform me that I need to present the Lettre de Reconnaissance in order to apply for the French Tech Visa.
23-10-2017	On my behalf, Station F staff inquire the French Government’s representative when the Founders Program’s fast track will come through, after which I can be granted the Lettre de Reconnaissance.
17-01-2018	Station F staff informs me that the fast track will come through very soon.
18-01-2018	Fast track for the French Tech Visa comes through.
19-01-2018	I ask the Station F staff to grant me the Lettre de Reconnaissance, which is the final document I am required to provide to apply for the visa. They do not reply back.
24-01-2018	I ask for feedback again. Still no response from them.
01-02-2018	I ask for feedback again. Jacques replies back, telling me that they decided to not grant the Lettre de Reconnaissance to me anymore, claiming a bad tone and negative attitude from my side.
01-03-2018	PoP quits Station F.

Update 12/03/2018

Roxanne Varza has refunded me the money for the 5 months that I was waiting (that is 1170 euros). This is a nice gesture from her, even though I had never requested the money back.

In the screenshots below, the usernames, names and avatars on the posts by Station F residents have been blurred. Station F staff info has also been blurred, however the "-staff-stationf" bit on their usernames has been kept intact for ease of understanding. All screenshots have, as a title attribute, the date in which they happened.

Since it opened its doors in July 2017, residents have regularly suffered frustrating situations at Station F. The screenshots below demonstrate many of these situations.

Construction noise

Posts below were added to Slack between 24/07 and 25/08/2017. In particular, construction noises got so bad on the 25th, that residents started swearing openly, and Station F’s boss had to apologize. And a few days later, on the 29th, the negativity at Station F had reached extremely high levels, prompting me to write my letter on Slack to calm people down.

Bathroom problems

Posts below were added to Slack between 20/07/2017 and 24/01/2018. Bathroom problems would arise regularly after Station F opened its doors, possibly due to poor-quality construction.

Showers not working

Posts below were added to Slack between 07/09 and 30/10/2017. Showers would be out-of-order for long periods of time.

Water leakages

Posts below were added to Slack between 18/08 and 15/12/2017. Water leakages would be a constant at Station F, whenever it rained, possibly due to subpar construction/renovation of the ancient train station.

Microwave queueing

Posts below were added to Slack between 05/09/2017 and 09/01/2018. They show the frustration of residents for the long queues to heat up their food during lunch time.

Temperature problems

Posts below were added to Slack between 14/07 and 26/12/2017. Both freezing and very hot conditions happened in several occasions.

Holes in the building

Posts below were added to Slack between 16/08 and 05/12/2017.

Broken Handrail

Posts below were added to Slack between 23/11/2017 and 25/01/2018. The referred-to handrail is always the same.

Bad smell

Posts below were added to Slack between 05/09 and 05/12/2017.

Unproper maintenance or care

Posts below were added to Slack between 08/01/2017 and 29/01/2018. These show how Station F is regularly not kept up with the attention it needs.

Dying nature

Posts below were added to Slack between 09/08 and 22/11/2017. They show the lack of proper maintenance at Station F, that even living being such as fish and plants are also suffering.

Cockroaches

Posts below were added to Slack between 06/11 and 19/12/2017.

Alarm going crazy

Posts below were added to Slack on 18/09/2017. That day, the alarm went off, and it was beeping loudly for many minutes until somebody put it off, all the while making work very difficult.

Station F IPs banned, possibly unprotected data

Posts below were added to Slack between 15/09/2017 and 24/01/2018. It is possible that there are startups in Station F doing stuff banned by some websites, such as scraping their content, and as such these websites ban the incoming IPs, affecting access for everyone from within Station F. In addition, a resident received an email from some 3rd party claiming to have information from Station F residents, raising fears that private data may have been leaked.

Complaints about un-answered tickets

Posts below were added to Slack between 24/07/2017 and 21/02/2018. These show how residents at Station F were so frustrated at their tickets not being replied-to, that they would directly stop creating tickets and complain in Slack instead, and even joke about creating tickets, expressing that it would make no difference.

Many of the screenshots below also appear under their corresponding section.

Malfunctioning internet

Posts below were added to Slack between 18/07 and 22/02/2018. During the first months, the Station F staff would, for the most part, not reply to the questions concerning non-functioning internet from the residents. During this period, Internet was extremely unstable, and many residents decided to use their own data instead. Later on the problem was mainly solved, however downtimes keep happening constantly, up to this day (end of February 2018).

Printers/lockers ready?

Posts below were added to Slack between 17/07 and 31/08/2017. Both printers and lockers were widely requested, and residents were constantly asking when they would be ready, however the Station F staff would, for the most part, not reply. And when they did, the usual response was either "soon" or "next week", even if it would still be weeks away. Residents then got frustrated at the lack of information, the lack of consideration for a plan B, the sensation that the Station F staff was not taking care of their concerns, and the unprofessional handling of the situation (7 weeks of waiting is not what residents expected, upon being told "anytime soon").

Malfunctioning printers

Posts below were added to Slack between 07/09/2017 and 21/02/2018. After printers started being available, on 04/09/2017, many residents would be angry at being unable to print, due to the printer drivers not supporting their Operating Systems or some other problem.

Unfulfilled requests for information or features

Posts below were added to Slack between 20/07 and 25/09/2017. These are other examples of requests/questions by residents, not being addressed by the Station F staff.

Unfulfilled request for a members directory (work in progress?)

Posts below were added to Slack between 20/07/2017 and 24/01/2018. The directory of members is a feature that has been requested by many residents from the very beginning, and even several startups started creating the directory all by themselves. The Station F staff has indicated they are working on the implementation, however it has been more than 7 months and they have not released anything yet, making many residents open wonder why they haven’t uploaded a simple Excel sheet temporarily.

Station F staff accusing residents in the open channel

Posts below were added to Slack on 23/01/2018. Over time, residents got very frustrated at their tickets not being addressed properly, and as such many of them simply stopped creating tickets and started complaining in Slack instead. On this particular day, a resident got extremely frustrated at the Internet not working properly, right when he needed it the most, and so ranted about it openly on Slack. The Station F staff reacted improperly, prompting Station F’s management to intervene to reduce the tension.