Working in distributed / remote environments 3: weekly meetings (II)

This is the second and last post of the Weekly Meetings series. If you haven’t read the first one, I recommend you do before reading this one.

Where?

There is a very simple rule in distributed environments. If one of the participants in the weekly meeting is remote or at a different office, everybody is remote, or should be.

Take advantage of what the technology provides and participate in the meeting from your desk instead of from the meeting room together with part of the team. I pointed several reasons for this in a previous post. Let me develop further:

  • You do not have a white board to support your explanations. You will need a virtual one and its usage is more effective when everybody can collaborate, getting the same experience. There are plenty of tools nowadays for this purpose. Your screen is your projector. If you need to show something to others, sharing your screen becomes trivial compared to the set up required in a meeting room, no matter how prepared it is.
  • Let me insist on how important it is for building a healthy team that everybody lives the same experience at meetings. It is not just that participation and follow up is harder to those who are not present in the meeting room, it is that the meeting becomes less efficient because those joining remotely become listeners instead of active participants.
  • When teams are used to meetings at their desks, efficiency increases. It is easier to start on time, the sound quality is uniform, less time is wasted in moving to the meeting room, flexibility to organise meetings significantly increase, etc.

How many participants?

Since it is significantly easier to manage a meeting in person than remotely, I recommend to reduce the number of participants in these weekly meetings in distributed and/or remote environments.

It is a common mistake to assume that the ideal team size does not necessarily need to change when moving from collocated to remote. In my experience, distributed teams should be smaller than collocated teams. Remote ones should be even smaller.

Weekly meetings with 8 participants in a room are manageable if the team is disciplined. That is not the case, in my experience, with such meetings through video chat.

Meeting Length

I mentioned in the previous post that meetings in distributed and remote environments should be short. People gets tired of looking at a screen and talking through a mic. I also mentioned already that due to the need of talking once at a time, these meetings have a slower page, which bores people to death.

If you can, make them no longer than 30 minutes. Allow a little more for chit-chat if there are plenty of topics. but in general, avoid reaching the one hour mark. If you reach it on constant basis, analyse and distil the topics, try to preparation them better, send the descriptions in advance, promote offline discussions before bringing the topic to the meeting, control the time better, etc.

And if still is unavoidable, split the meeting in two 30 min meetings if your team can afford it in terms of agenda. Remember that for some, these meetings might require a personal sacrifice because they might need to happen very early or late at night. Two 30 min meetings are far more productive than an hour long meeting when managed correctly.

If any topic requires significantly more time than you can afford during the weekly meeting, propose an “ad hoc” meeting for it. Make sure though that the schedule of such future meeting becomes a a topic on the current meeting. Remember that schedule meetings for the whole team is hard, specially through asynchronous methods.

When?

Applications like Doodle or Pollunit (there are more) can help you and your team to decide in which time slots are better to schedule any meeting. The weekly team meeting is a good example. Every serious calendar has a free/busy time feature that allows you to avoid conflicts. Make sure you master them.

Ensure everybody adds in their calendars the working hours and you define yours so you get an alert when you are trying to schedule a meeting out of somebody’s working hours. I think I did not mention this on the post about the calendar tool. 😮

Serge Broslavsky showed my a trick I use ever since. In a sheet, he added the names of the team members (column B) and the UTC hours of the day (row 2). Then he marked in green, orange and red the times in which meetings were acceptable for each team member. When you have to manage a large number of people around the globe, that simple visualization makes scheduling meetings easier.

Avoid scheduling meetings out of green working hours. If you cannot, try at least to avoid putting any colleague in a position in which they cannot negotiate their own agenda in amber or red hours. In remote environments with different time zones involved, people need to be flexible about their availability, but being flexible does not mean there is no impact. Remember to promote the culture you would like to live in.

As mentioned previously, in DRE it is important to arrive to the meeting prepared so I tend to avoid “first time in the morning” meetings. Like everybody else, I hate interruptions so I tend to concentrate half hour meetings in 2 hours slots and have 1 or 2 hours slots free of meetings, at least a couple of days a week. Promote among participants to reserve a free slot before your team meeting starts.

If you are managing managers, it is extremely important to decide if you want to have your weekly team meeting before or after your colleagues (managers) have had their own weekly team meetings. By default I would prefer to have my weekly meeting after all my managers have had theirs but that depends on the type of job and how is it organised.

Roles

I like to pre-assign roles to avoid any discussion about who should play which role. I add to the meeting ground rules how the roles are selected. Pre-defined rotation is a system I have used. Let the team choose the one they prefer. The point is to start the meeting already knowing who does what. Start the meeting confirming who plays each role, after allowing one or two minutes for chitchatting. The roles are:

  • Scribe: everybody takes notes. Is one of the good things about having every participant in front of their laptops. But there is somebody responsible for completing the notes, record them and publish them.
  • Timer: this is critical since meetings needs to be short so participants need to be concise. The timer not just controls the time assigned to each topic but also that nobody goes off-topic or eat all the available time.
  • Topic lead: the meeting agenda should include a topic lead for each topic. That is the person in charge of making the discussion at the meeting worth it which frequently means that the right information has been sent in advance, questions has been asked and answered and that participants understand what is the expected outcome of the meeting. It will also ensure that the notes reflect the state of the art and will highlight if the topic needs a follow up in the next meeting, for instance. If there are actions points, the topic lead will ensure they have been recorded and/or properly tracked.
  • Meeting owner: I mentioned that you, as manager, should be the meeting owner which does not mean you manage the meeting. Make sure your role is clear, set the boundaries of such role and use your “power” wisely. Assign a person that will substitute you when you are absent.

You can add more roles but I only do in extraordinary occasions.

Some final tips

I will summarise some additional tips in no particular order:

  • Since the environment in these meetings is more hostile than face to face ones, making these weekly meetings short and to the point has to be an essential goal which requires more preparation in advance compared to face to face meetings.
  • Make sure the agenda is sent to participants in advance. Provide a time estimation to each topic, assign a person to lead each agenda topic and make sure you do not fill out the 30 min. I would recommend to not have a pre-defined agenda beyond 20 minutes. Meeting’s pace in DRE is slower than in face to face meetings. Include in the agenda time for AOB (Any Other Business) but be aware that this topic can be used to come to the meeting to discuss topics that has not been prepared in advance. Do not let anybody misuse AOB.
  • Every description, report, detailed opinion, statement or positioning should be sent in advance, as I have mentioned before, with enough time for others to read and answer in written form before the meeting. This saves long turns and explanations during the meeting.
  • When there are more topics than time, ensure those topics related with people management has preference. The others should wait until the next meeting or be a matter of a future “ad hoc” meeting. Since scheduling those topic-specific meetings is so complex, specially in remote environments, use the AOB section to schedule it or at least get a tentative date and time for it.
  • If part of the meeting deals with tasks, blockers etc., make sure the tickets have been updated in advanced so WIP (Work In Progress) can be clearly visualised by all participants. Provide the links to the dashboards to the participants in advance.
  • During the meeting, ensure that every time somebody makes a reference to a specific page, the link to that page, ticket, image, etc. is provided through chat to every participant.
  • I find slides very useful when describing a complex idea or when the amount of information to be provided is high. Screen-share is your friend here. I recommend though to make the slides available to everybody beyond that screen share. They will be easier to follow, participants can take notes, click on the links, etc..
  • I really like dashboards, specially kanban boards as a WIP visualization method (through tickets), even if you are not following the methodology. I use them during meetings to go through hot topics. When going over tickets, repeat the number and title of the ticket you are referring to more than once so everybody can follow you.
  • Predefine a way to communicate that somebody’s turn is taking way too long, or that the participant is repeating herself, that the information is irrelevant , etc. In summary, find a way for anybody to cut anybody politely. The timer role should be the default person for this, but everybody should participate on this tough task.
  • It is common that participants start talking while mute. It happens to me more often that I will ever recognise. There are video chat applications that has solutions for such cases like a notification, or the possibility for another participant to activate anybody’s mic. Try to use video chat apps with these features. If yours does not have it, use a keyword to notify to the person that she is talking while muted.
  • Since in a video conference only one person can talk at a time, muting participants should be a normal practice. Nobody should take offence. Sadly only most experienced people do not. Try to avoid muting people while speaking unless it is strictly necessary if your time has little or no prior experience working in distributed environments or remote. Assume by default that the muted person might have taken it as a rude gesture from you. Talk to the person offline to clarify the situation. Make it an acceptable practice (in specific circumstances) little by little.
  • When the connection of any participant introduces noise or is choppy, muting the affected participant is a must. Mention why you did it, and move on. You cannot afford stopping the meeting flow because of somebody’s bad connectivity. Participants should have alternatives for these cases. I usually have a 4G connection as secondary line in case my default internet connection fails. If the affected person is the topic leader, move on to the next topic. If it happens to a different pre-defined role, make the next person in the queue adopt the role. If it happens to you… well, use the opportunity to “lead by example”.
  • Do not join team meetings through wifi. Do not underestimate the amount of bandwidth that several participants require, even with the best video chat app or plug-in. No, shutting down your video camera is not ok. Take the meeting as seriously as everybody else.
  • Do not close the video chat room once the meeting ends. Allow some minutes for off-topic chatting. Stay once in a while a few extra minutes yourself to participate in those off-topic conversations.

It takes time for any team working in DRE to have smooth and productive team meetings. Keep pushing and do not accommodate, tendencies are usually perverse when it comes to meetings dynamics.

I would like to finish pointing that weekly team meetings for groups that work in distributed or remote environments (DRE) might be the only time where they get together during the week. It is essential to keep in mind how hard it is to generate a sense of team work when there is little or no face to face interaction. This action, the weekly team meeting, represent the best opportunity generate a team spirit, which is a fundamental mission for every manager.

I am sure I have left behind important tips or you might not agree with some of the above. Please let me know. This is not a science.

Working in distributed / remote environments 3: weekly meetings (I)

This is the first out of two parts dedicated to share my experience around weekly meetings in distributed and/or remote environments (DRE).

Introduction

As a manager I cannot tell you how many times I have listened colleagues of mine complaining about having too many meetings, but specially about too many unproductive meetings. Sadly, they are frequently right. And you know what, for every meeting any engineer I have worked with usually have, I have three. And no, attending to meetings is not my job either. It has never been, thanks God. And yes, they usually are at least as unproductive as those the engineers complain about.

I wrote in a previous article that in person meetings are expensive, hard to manage and exhausting. I also mentioned that, in distributed or remote environments (DRE), meetings are even more expensive, harder to manage and far more exhausting.

You will find very few people who dislikes unproductive meetings more than I do. I am not a fan of long meetings either. The best way to avoid unproductive long meetings is to have a real purpose for them. And that purpose has its reflection on an agenda. In short, no agenda, no meeting.

So my first point is, if you are a manager, reserve a slot for a weekly meeting so everybody takes it in consideration in their agendas. But the meeting will only take place if there is an agenda. If your team is healthy, there will most likely be topics to discuss every time.

This principle applies to any professional environment, but due to the nature of DRE, unproductive meetings have a higher impact on participants. Keep that in mind specially when coming from co-located environments.

Who owns the weekly meeting?

I enjoy working in organizations where technical leadership roles are separated from other management roles like product or line management. I definitely recommend to have at least a clear separation between technical and people (organizational) leadership roles. When the tech lead is the line manager….

These weekly meetings can and should serve the team. At the same time, as a line manager, there are occasions in which you need the flexibility to modify the agenda or even own the meeting entirely.

So answering the question, you as manager own the meeting, which does not mean that you manage it, conduct it or even play an active role on it by default. In fact, I recommend not to. Just be clear about the possibility for you to change the agenda in short notice. Be wise about this power though. It might have some negative impact on your colleagues if it is abused.

Weekly meeting main goals

In my opinion, the weekly meeting has the following key goals in DRE:

Alignment

Autonomy is widely perceived as beneficial and a necessary step towards reaching mastery. But autonomy does not come for free, it is associated to a risk, specially as teams/ departments grow: that risk is called alignment.

As a manager in DRE, your number one goal is to promote alignment across the organization and specially across those under your responsibility. I explained this focus shift that any manager should face, referred to working in the open, which is a specific case of DRE, a few months ago.

So my recommendation is to focus these weekly meetings in improving alignment.

Discussions

There are times in which discussions through mailing lists or chat become so complex that the right approach is to discuss the topic in a meeting. There are other occasions in which the topic under discussion is sensitive to one or more team members. Those implicated in such discussions might benefit from a chat through video, experiencing the advantages that some body language and bigger doses of empathy might bring.

Call the attention of your colleagues when overdoing the discussions or when they reflect frustration and invite them to move the conversation to the coming weekly meeting.

Consensus

Alignment frequently requires consensus. Reaching  consensus through mailing lists or chats might be extremely hard, specially the last mile. One or more discussions through video chat might help.

Take some time during weekly meetings to work towards reaching consensus on key topics, instead of having one “ad hoc”meeting to solve it, at least until the discussion is mature enough. Remember that alignment is your outstanding challenge. Work on it on regular basis.

Conflict resolution

In order to understand how important team meetings are in DRE you need first to be aware of the strengths and weaknesses that remote communication has.

Strengths:

  • Direct
  • Aseptic
  • Accurate
  • Easily traceable and recordable.
  • Higher latency, which sometimes help.

There are also weaknesses:

  • Lack of body language which represent a significant decrement on the amount of information transmitted.
  • Requires experience to do it right.
  • Latency: sometimes plays against you.
  • Irony, humour, passion… hard to transmit emotions. So aseptic communication channels might play against you and your colleagues many times.
  • DRE communication is not taught at school. It takes time to master it. It is one of the great advantages of participating early on in your career in Open Source projects. You learn to communicate in DRE.

Back to the conflict resolution point, supporting written communications with conversations through video chat are extremely important in DRE to solve or contain all kind of conflicts, before they escalate.

Use weekly meetings to solve simple conflicts or to expose them. Take a deeper evaluation and potential solutions offline and come back to the team meeting with the result and evaluation. The message is that, when problems or conflicts affect the team, weekly meetings are a better forum to expose them than mails or chats.

More serious conflicts require a different approach. Using the weekly meeting to fully identify them, evaluate them or attempt to solve them might not be a good approach.

Hot topics

In DRE, it is significantly harder to schedule meetings in short notice than in collocated environments. It might also have a higher impact in people personal life.  I always recommend to reduce the drama associated to meetings announced in short notice. Having a scheduled weekly team meeting will significantly reduce that drama while having a positive impact on any team dynamics.

Most hot topics…. can wait one or two days for the weekly team meeting.

Learn about the state of art.

As a manager, you get a significant amount of information about how things are going for your co-workers,team, department or organization in front of the coffee machine, at lunch or at the hall, listening and talking to those you work with. You do not have such luxury in DRE so weekly team meetings represent a unique opportunity to understand how things are going, beyond tickets, merge requests, reports, chat channels and mailing lists.

Following the same argument, employees get fewer information about how is the company doing when working remote. Weekly team meetings become an outstanding opportunity for them to ask you and comment about corporate related topics.

Escalations

In the same way that in DRE, you have limited opportunities to “talk to the team”, they have the same number of opportunities to “talk to the company”. As a manager, it is your responsibility to create the environment in which escalations are properly communicated, discussed, tracked and managed.

Team meetings, together with 1:1, become the default forum where to define and trigger escalations. No matter how flat your organization is, you need to define a clear escalation process that works for both, the company and the employees. This is specially true when you are, de facto, the default company interface because you are the line manager.

Participation.

In organizations or teams where people is spread in different time zones, joining a weekly meeting might involve sacrifices. Now imagine a colleague of yours joining a meeting at 22:00 to realise that 75% of the time has been consumed by a colleague describing a topic, summarising what she did about X or reporting about what somebody else did with Y.

Do you really expect that person to pay full attention?

In order to “encourage” participants to remain connected to the meeting, many managers and teams developed techniques that frequently do not apply to on line meetings. I love the “no laptops allowed” one.

But even face to face meetings, many of them does not work. The human brain have an outstanding capacity to take us somewhere else without others noticing. I developed such skill at college. The normal outcome in an online meeting where reporting is the norm and not the exception, is that participants listen while doing something else.

A waste of time and passion.

It is well known that the key to successful meetings is active participation. This is specially true in DRE. Looking into a screen and listening others through speakers is hard enough already. Add to it lack of participation and you will end in a set up for failure. Descriptions, reports, etc. should be provided to participants in advance. They should read them and come to the meeting ready to participate. Dependencies, blockers, feedback, etc. should be the meat of these weekly meetings.

It is amazing how effective meetings might become in DRE when participants develop the habit of sending and reading reports and descriptions in advance. Promote preparation in advance over longer meetings.

Participation comes with a challenge. Managing fluid conversations through video chat is hard. Experience and simple tips, like something that is equivalent to raise the hand (ask for turn) or a nice way to make somebody aware she is talking for too long, etc.  help a lot. Try some. Some video tools provide some nice solutions to mitigate this challenge.

Stay tuned for the second part of the post.

Working in distributed / remote environments 2: the calendar tool

One tool I think you should master as a manager in DRE (distributed or remote environments) is the calendar. It usually gets less attention that it deserves based on its significant impact in environments that promotes autonomy. Dealing with agendas in distributed or remote environments is so important that I recommend you to take the management of a calendar tool in your area of influence as a priority, specially when people is distributed across different timezones.

This post describes some basic features a good calendaring tool should have in my opinion and why they are important when working in DRE. I also provide some advices based on my experience. Feel free to comment if there are some others important to you that I haven’t mentioned. I would love to know about them.

Reflect your availability in the calendar

When managing collocated teams, co-workers know if you came to work that day, if you are at your desk…. Your co-workers might guess if you will be available later on and pass by your door on their way to the coffee machine to check when you return to your seat. That is not the case in DRE.

The calendar is the best tool you have to set up the right expectations about your availability among your colleagues. Make sure EVERY meeting, appointment, long call… everything that takes you more that 15-20 min. is reflected in your calendar, specially if it is a recurrent activity. Remember that being transparent about your availability is not just important for you, but also to your co-workers. They need to know when you are available for them.

When you do not answer a ping from your colleagues, they might wonder if you are sick, if you are dead, if you are ignoring them on purpose, if you are concentrated in something else or you are participating on an unexpected meeting. In the mid term, that uncertainty plays against you as a “remote” worker.

If there is a time window when you do not want to get disturbed, add the slot in the calendar. For instance:

  • I usually reserve 90 or 120 min. at lunch. It is well known that Spaniards take long lunchs but that is not the reason I reserve such slot. I like to have some time to work without disturbance and, at the same time, have some flexibility about when I eat. I usually add to the calendar a long lunch slot and try hard to prevent others from scheduling meetings during that time. It is not infallible but it helps.
  • I have worked with people that need to pick up their kids from school early in the afternoon, that visit their mother for lunch on Tuesdays, that pick up their partner at work early in the afternoon or that commute to a co-working space or Café after lunch. Add those slots to the calendar in such cases. Make sure your colleagues understand when you will not be available for them.
  • If tomorrow you have a hard stop time, add it to the calendar. Your colleague in the Canada might ping you at that time and wonder why you are not answering her.
  • If you will start later next Friday because you need go to the bank, again, add it to your calendar.

Those with little or no experience working in DRE write mails or ping others through the chat to ask you for your availability. Experienced remote workers talk through the calendar… or should. An invitation is always a question, not a command. Notifications are king. Provide the justification for the appointment in the description or notes section of the calendar event, add the resources, include links…. reduce the mails and chat entries you create for things you can do with the Calendar tool.

Those managers who make heavy usage of the calendar do not have to create a fire to have and urgent “ad hoc” meeting. They simply add a key word in the appointment title, or use any other trick to avoid the need to communicate such urgency through a different channel, making “urgent noise”. Again, use the calendar to its full extend to avoid unnecessary communications, misunderstandings, unmet availability expectations, appointments at inconvenient times, etc.

And finally, remember that, when working with people across different time zones, it is very easy to make mistakes that affects people’s personal lives when managing appointments. Promote a culture where flexibility is compatible with the required availability. Intensive usage of a good calendaring tool helps to promote such culture, in my experience.

Confidentiality

I am a big fan of the “open by default” approach when it comes to information management so I try to reduce to the minimum the information I restrict from being accessible to others in general. The calendar tool is no exception.

As a manager, you will have meetings you do not want others to know about or are confidential by definition. Advanced calendaring tools provide options to restrict the information you share about appointments and availability. Pay attention to these features when deciding which calendar tool to use.

Team/department/product calendar

Translate your organization chart and product/service structure to the calendar tool and make sure your colleagues are subscribed or pay attention to the right calendars. This way, when you need to have a retrospective, define a release schedule, or communicate through video chat to your entire team a corporate decision, for example, you do not need to do anything special or use a complementary channel to get quorum. Remember that setting up meetings in DRE requires more coordination effort than in collocated environments. The usage of calendars significantly reduce the mount of coordination effort required.

Other useful calendars

There are specific events in any organization that can benefit from being managed through or reflected on a calendar tool when your teams are distributed or remote. I will put two examples. There are more.

Vacations calendar

In some countries, there are legal limitations to the information a company can share related with their employees. Assuming those restrictions, as a manager you need to evaluate the impact of a vacation request on the team, the department work or the project/corporate goals, etc. If your organisation does not have a Vacations/Holiday calendar, propose to HR the creation of one.

Having the vacations of your team members in a calendar together with other key dates, will help you to avoid unfortunate mistakes approving vacations. It will also help co-workers to check the availability of their colleagues, which explain why they are not or the chat that day. At the same time, they will self-manage the necessary availability of a qualified team member for key tasks during vacation times without you asking for it.

Bank holidays

It is not just that different countries have different bank holidays, it is also that some bank holidays are more important than others. depending on the religion or culture your co-workers practice or are part of.

As you can imaging, in DRE the bank holidays might become a topic when planning. Make sure you have a calendar that includes all the bank holidays affecting your team members, department or product team. It will be very useful, and not just for you as manager.

Evaluate the number of bank holidays that hit your team on Tuesdays and Thursdays. The natural tendency we all have is to take such opportunities to ask for one vacation day and end up enjoying 4 days off. Prevent extra work re-scheduling meetings later on the affected Mondays or Fridays.

Rooms/resource management

One of the most important features of modern calendar tools applied to distributed environments is the resource management integration: rooms, boards, projectors, etc. It is extremely important that the resources management is associated with the calendar so you have a single place where to create an appointment and book at the same time the needed resources. This feature for remote environments is less relevant.

Not just distributed, but open…

In asynchronous environments with higher latency than corporate ones, like Open Source projects, the email is an essential communication channel. Make sure you configure the calendar to send notifications and invitations through mail to better adapt the calendar to developers workflows when working in the open. If they make intensive use of a chat tool, send the notifications for important events through that channel too. But be clear about the complementary nature of these notifications. Paying attention to the calendar is, in any case, essential.

I find extremely useful when working in the open to have a public calendar with the most important events for my team or project, like conferences, release dates, monthly meetings, etc. It does not seem to be a widely adopted practice though.

Summary

I would summarise the post in three points:

  1. It is essential to provide a clear expectation of availability on regular basis when working in DRE. Calendars are of a great help.
  2. Promote the usage of calendars across the entire organization to enable a corporate culture where autonomy is an essential value.
  3. DRE represent a challenge in the conciliation between personal and professional life. Calendar tools help managers to prevent and detect undesired situations that might contribute to lower satisfactions levels or even burnouts.

Back from Akademy 2018. What an event!

A few days back I wrote about Akademy 2018 and my expectations and duties at the event. This is a report based on that previous post.

Akademy 2018 in Vienna, Austria, has been the best one in I’ve attended to in recent years. We event got a record number of sponsors, Codethink among them, and some of them for the very first time, which is always a good sign. The organization went smooth, the location was comfortable and several talks were very good. As a point to improve, I would mention the location of the Sunday party (sorry, social event), which was small for so many people.

Codethink as sponsor

This Akademy there were more first timers than in previous editions. Most of them knew nothing about Codethink. So being a sponsor allowed me to talk for 3-4 minutes to the audience, right before the closure, about what Codethink does, specially about the FOSS projects freedesktop-sdk and BuildStream. I will write more about them in the near future.

Representing Codethink also allowed me to attend to the sponsors dinner. I have attended to several of them before, either as a KDE eV Board Member, as the local organiser or as a sponsor representative (SUSE and now Codethink). This one worked very well. I was sit by the openSUSE Leap release manager Ludwig Nussel, former colleague of mine, Chris Lamb, Debian Lead and Alan Pope from Canonical, which allowed us to have interesting conversations about topics like reproducible builds, telemetry in distros, automotive systems, upstream events, etc. I also had the opportunity to introduce BuildStream to them.

Flatpak – Snap BoF

As part of my duties at the event I participated in the Flatpak – Snap workshop to introduce briefly the work Codethink is sponsoring on freedesktop-sdk and BuildStream:

  • freedesktop SDK 1.8 was just released before Akademy. flatpak-gnome and kde runtimes are based on it.
  • freedesktop SDK uses BuildStream as build tool. The integration team at GNOME too. So it was about time to talk about the project among KDE people. When it comes to build tools, the key selling point for BuildStream within KDE community is the advantage of creating a single set of definitions (recipes) and get different outputs like flatpaks, rpm-deb packages and hopefully in the future, snaps. Outputs depend on plugins that can be developed and maintained by contributors to BuildStream if they are not already available.
  • I am happy with the response BuildStream got and hopefully after the coming v1.2 release the project will support some KDE contributors in trying out the tool. It will be interesting also to support the KDE community in building the flatpak-kde runtime.

BuildStream

I introduced BuildStream to several developers. In general, very few knew anything about it which is not surprising since, except among the GNOME community, we have barely made any noise about the project. The coming release will help us to start mitigating this issue. The KDE community produces flatpaks, snaps, .deb and .rpm packages, has Yocto recipes… . A tool set that provides you all these outputs by maintaining a single sets of definitions, being simple to install, update and maintain, becomes attractive at first sight. The challenge is major, but a nice one to face.

Third edition of the Freedesktop Summit?

Several years ago, driven by Alison Lortie and sponsored by openSUSE, I organised the first freedesktop event ever. The following year I participated in the organization of the second one, that also took place in Nürnberg, Germany. During Akademy I talked to some people that might be interested in participating in a new edition. I did have some conversations around this topic at GUADEC too so, although it is still nothing but an idea, I will invest a few cycle to mature it. Who knows, maybe we can organise a third edition of the event next year.

KDE for automotive

As you know, I have been advocating at KDE for putting effort to showcase our software in automotive R&D and pre-production environments, knowing that Qt is the default graphic toolkit in the industry. Last year I provided a lightning talk about it which, together with the improvements in Plasma Mobile, triggered the interest of some developers at KDE, which are professionally involved in Qt companies working in embedded/automotive already. We had a BoF back then and we created a roadmap to shorten the gap between what we had and what would be interesting to show in such environments.

Andreas Cord-Landwehr and Volker Krause has managed to create two Yocto recipes together with the infrastructure to update them regularly. Both had a talk at Akademy. Andreas introduced the audience to Yocto and talked about the created recipes while Volker showed during a lightning talk the plasma mobile shell working on a RPi3 with the Raspberry 7″ touchscreen.

At the BoF we evaluated the technical, coordination and promo actions taken as well as the coming ones. The ultimate goal for the coming year is to showcase at different events KDE apps on top of Plasma mobile on automotive dev as well as to increase the attention of more KDE developers on embedded as a potential target market for KDE software.

I am excited about this progress. I believe putting some effort to move towards embedded can bring more attention and new energy to KDE.

KDE E.V. AGM

I participated at the annual KDE eV AGM (general assembly) on Monday August 13th. As you know the KDE eV AGM is a close doors one, so private. It was a good move to provide room during the event for the working groups to summarise the work they have done. These reports used to be done during the assembly. As consequence, the AGM was shorter.

There used to be a time in which the KDE eV AGM was long and tedious. Over the years we have put effort in making it shorter and more dynamic. Mission accomplished.

openSUSE

It was great to meet all timers but also new openSUSE contributors. I could take some time to talk about points that require some attention in the distro, learn about the improvements on the delivery process that has been implemented on Leap 15, some of the actions in progress and future plans. Finally I did not update the Leap version in my working laptop (a Slimbook) because I had more work than expected during the event. I will update it during the coming weeks. Overall I am happy with Leap 15 in my personal laptop (a Lenovo) so far.

Slimbook

I was happy to see Slimbook booth at the event. As you know I am a Slimbook happy customer. I had the chance to talk to other customers at the event and I would highlight how happy we are with the post-sale service they provide.

Did I mention I would like to have a 11″ SlimNoteBook. I definitely did to them.

Free Qt Foundation

I cannot get tired of telling everybody within KDE and specially outside the community how important is the Free Qt Foundation, not just for KDE and the Qt ecosystem, but also for the entire Free Software movement. I never loose the chance when I am among automotive professionals to highlight the enormous impact that this entity has on their businesses. There is still a lot to do to provide The Free Qt Foundation the attention it deserves. By the way, it is always a pleasure for me to talk to KDE e.V. representatives there, Martin Konold and Olaf Schmidt-Wischhöfer.

What a great contribution they do.

Other topics

Did I mention how cool it is to have Mycroft integrated with KDE? All the demos I have seen are so promising… openSUSE Tumbleweed has packages to enjoy Mycroft on Plasma. The same applies to having KDE software on phones. It seems that we will have Qt6 in 2020 and that the transition from Qt5 is planned to be smooth. Breaking things when updating is never a good strategy in my opinion.

I love KDE Connect and I had the chance to learn about some coming new features, which is always a plus for coming to Akademy.

Sebas and Valorie got awards this year. Well deserved, as the rest of the winners. I like the fact that we as community, put some effort in recognising those who make significant contributions to the project.

I could have chats with people that I respect, new developers, key contributors… . As I said, a great event.

Thanks to the organisers

I will finish this Akademy 2018 report thanking the organization team who worked hard to make Akademy 2018 one of those hard to forget.

Thank you.

Codethink is sponsoring Akademy 2018 and I am attending.

Back in July 2017 I wrote a blog post, published by Codethink, explaining why is a good business to support community driven FOSS events. This post is related to that one.

akademyLogo4Dot

I will be attending to Akademy 2018. It will take place in Vienna, Austria, from August 11th to 17th. I will be there representing Codethink, which is a proud sponsor of this 2018 edition.

I attend regularly to Akademy since, as most of you know, I have been an active contributor, a user of the software, a supporter of some of their activities and/or a KDE e.V. member for some time now. I learn a lot during this event, and not just about KDE related topics.

This edition has several specific points of interest to me:

  • I am involved in a project called BuildStream, a FOSS integration tool for declarative systems and applications. Currently its main user are the GNOME integration team and the Freedesktop SDK project. We would like to expand our user base among communities like KDE.
  • Freedesktop SDK are a platform and a SDK runtimes for flatpak apps and runtimes based on freedesktop modules. Several colleagues of mine are behind this project that is about to release a new version.
  • A year ago, during an Akademy BoF, some KDE contributors decided we wanted to put some effort towards enabling KDE software on automotive. This year the first modest results will be presented to the wider KDE community. I have been preaching about this move for some time now so it is exciting for me to see others involved and making progress.
  • I will attend to the KDE e.V. Annual General Assembly. KDE e.V. is the orga34f05-logo_kdenization that supports the KDE community which is an important activity.
  • I will update my working laptop from openSUSE Leap 42.3 to Leap 15, taking advantage of the presence at the event of a couple of former colleagues from the extinct openSUSE Team at SUSE, and Slimbook, the guys I bought my laptop from. Make sense, right?
  • Codethink is always looking for talent willing to move to Manchester, UK, or exceptionally, work remotely. Come talk to me if you might be interested.

It will be, as usual, a great event. See you all there.