The egg is on our face.

In this section, “We” refers to the writers of the open letter. In later sections it will refer to the UBports team.

First, we need to apologize for the way the original complaints were sent. What came after clicking the “Publish” button was a blowback more extreme than any of the signers expected, but we were the ones who clicked it.

Utlimately, the reasoning behind the letter was to bring the project together more. That might sound counterintuitive, but conflict management isn’t our strong suit. In the end, the letter has suited its purpose, but not without cost.

We’re sorry to Marius Gripsgard for the personal stress and hardship caused. We’re sorry to everyone that was confused or scared by the letter and what it might have meant for the project. The whole team here has learned a lot about each other in the past few days. In some cases, more than we would have liked. This will make us stronger in the future.

Suffice it to say that we will never handle our gripes like this again.

What happens now?

On April 25, 2017, two signers of the open letter and Marius Gripsgard met to discuss the letter and the methods of sending it. We reached a lot of agreements and found the places where communication broke down leading to the fiasco.

Our project image is now a concern.

If we don’t start acting more professional, we aren’t going to get any professional developers on board. This is an obvious problem that mostly points to the UBports team and not the community.

A topic of discussion that came up quickly was our habit of announcing projects or showing off screenshots of things that don’t really work yet, then not following up on them. When this happens in the future, we’ll be sure to specify the nature of these projects better: whether they are official from the project or simply a developer’s toy.

We are going to be moderating our chat rooms and forum a bit better starting now, trying to keep the discourse professional yet community-oriented. What does that mean for you? Almost nothing. We are okay with light banter and respectful disagreement in UBports communication. We are not okay with communication that becomes rude, insulting, or blatantly off-topic.

A team of people to make the decisions, not one person.

The developers have the power. Decisions that are minor to the user, such as how we decide to implement a display server, will be discussed among the developers. However, decisions that change our users’ phones appearance or function will be discussed more openly.

In both cases, we have agreed to not make snap decisions from only one person. The developer team must agree when it is going to take on a project. The developer team will then communicate this with the Community team or the community directly.

In the long term, we have a better solution to ensure proper decision making and project governance. We’ll announce it when it’s ready.

A sense of community, a listening atmosphere between developers, teams, and the people who support us.

The biweekly Q&A sessions are still happening. At the beginning of these, we will recap what different teams have been doing since the last Q&A. After that, we will launch into the community’s questions and answers.

Internally, we will improve our communication so this situation won’t happen again.

A project roadmap that we follow

Using a combination of kanban boards and Launchpad blueprints, we will create a list of short-term and long-term goals to achieve. We will include the information that people can use to contribute to these goals.

Stick to these changes for more than a week

Time will tell on this one. We’re confident in ourselves.

Other things that we learned

These are interesting snippets that were written in the meeting notes. They have no bearing on the rest of this blog post.

During a discussion about hit-by-a-bus syndrome, we learned that, “Buses come in many forms.” -Jan

After we somehow got onto a discussion of cats and aircraft, Marius proudly proclaimed that, “If I was a cat on a plane, I would die from stress.”

We also learned that we should display a PHP WARNING! before talking about that language, otherwise Marius might explode.

Conclusion

In case that last section didn’t make it obvious enough, we all had a good time talking to each other after the initial awkwardness passed. A lot of the issues that we faced stemmed from communication breakdowns between project leadership and community members.