GUADEC18 Developer Center BoF Part 2: Possible Audiences

This is Part 2 of a blog post series summarizing the Developer Center BoF. See also Part 1: The Developer Experience.

Hi Again! As promised I will now cover our discussion of possible audiences at the GUADEC Developer Center BoF.

Possible Audiences

“Developers” can mean many things. There are several subclasses of developers we need to take into consideration so we can decide how to scope the developer center. Deciding a primary audience will become important later to take design decisions and align our vision. Note that I say “primary” – to create a good developer experience we still need to ensure a good story for other audiences we care about. In this list, one person may fit into several audiences and all of the audiences will need to be well defined (e.g. with a description):

  • GNOME newcomers (interested in contribution)
  • Experienced GNOME stack developers (fx library developers)
  • Experienced GNOME app developers
  • Third party app developers (unfamiliar with GNOME technology)
  • Interns (think GSoC or Outreachy)
  • Shell Extension developers
  • GTK+/Shell Theme developers
  • Distribution maintainers
  • People who are new to programming
  • Programmers from all over the world
  • Programmers who prefer video tutorials
  • User Interface Designers (?)

At this point we can start identifying some constraints which our users’ behavior and goals depends on:

  • What they wish to accomplish (an app, an extension, a design)
  • Their familiarity with the GNOME stack.
  • Learning preferences (text tutorials, video tutorials,..).
  • Programming language preferences
  • Spoken language preferences
  • and possibly more..

We need to consider which of these we think is important in the short-term and in the long-term. Simultaneously, we need to consider the maintainability of the Developer Center and its content too. This is a list of possible audiences – eventually we should decide on short-term priorities.

Among the six attendees at the GUADEC BoF there was fairly wide interest in having the GNOME Developer Center cater to application developers and especially third party developers. I know that me and Carlos are also interested in having the developer center provide a good experience for newcomers, who share’s their unfamiliarity with GNOME technology and terminology with third party developers. In general, I think catering to application developers is a good approach as more users of our technologies benefit our ecosystem.

What’s Next

By knowing what our developer experience of (Part 1) and with the possible audiences in mind (Part 2) we can start consider what challenges our current experience encounters, which we ought to solve. I will cover this in my last part of this blog post series, Part 3: Challenges.

Your Input

If you have any additions to the lists above or comments, let us know! Comment on this blog post or on the related Gitlab issue.

GUADEC18 Developer Center BoF Part 1: The Developer Experience

At this year’s GUADEC lightning talks I spontaneously announced and arranged a Developer Center BoF (Birds of a Feather) session. We were six attendants who met together Wednesday the 11th July. I think it is important that we communicate our doings to the rest of the community, so I will make a few short blog posts based on our meeting notes and my own thoughts on the subject.

What is this all about?

We are several people in our community who are dissatisfied with the developer documentation experience, in particular if you use bindings and are unfamiliar with GNOME terminology and API. The GNOME Developer Center supposedly provides “all the information that you need to create fantastic software using GNOME technologies” but is not maintained and looks dated. There has been discussions on improving the experience previously, but I feel it’s time to take inspiration from our gitlab migration and organize a proper initiative now (wiki page coming soon).

At the GUADEC 2018 BoF we conducted a bottom-up analysis of our current developer experience which can help lay some foundation for informed decision making. It consisted of the following:

  • Define what we talk about when we talk about the developer experience.
  • Define possible audiences and identify our primary audience.
  • Identify the challenges our current users experience.
  • Evaluate other developer center experiences, their structure and experience.
  • Create short-term and long-term plans for the developer center and scope it.

In this blog post, Part 1: The Developer Experience, we will define the current developer experience.

What constitutes our developer documentation experience?

What follows is an overview of important sources of GNOME documentation we are aware of. Searching and finding information in these sources constitute the current developer documentation experirence. It might be easy to think that  we should only concern ourselves with the developer center itself, but in practice, developers search much wider for help than that. This is a list of things we identified at the BoF and additional information that later came to my mind:

This paints a picture of a very scattered experience, but obviously, the intention here is not that the developer center  should unify absolutely everything. However, by knowing what is out there we can in the future make more informed decisions on what the GNOME Developer Center should host itself and what external sources could be useful to link to (and which we can consciously leave out).

The next step in our analysis is then to understand the possible audiences which I will cover soon in Part 2: Audiences.

Your input?

Is there other important information which has been vital for your GNOME developer experience? Helping understand what our current experience consists of is useful information so we can be more conscious when designing the next generation developer center. Leave a comment here or in this gitlab issue.

If you are interested in contributing to this initative, join the call next week or join the hackfest in February. More information on both of these coming soon.

GUADEC 2018: BoF Days

Birds of a feather flock together..

Monday went with engagement BoF. I worked with Rosanna to finalize the annual report. Please help us proofread it! I have also started collecting information for the GNOME 3.30 release video. If you are  a developer and you have exciting features for GNOME 3.30, please add them to the wiki. The sooner you do it, the happier I am.

Tuesday went by with the GUADEC BoF where we reflected on the conference as a whole and identified pain points and how we might improve them. Afterwards, glorious sandcastles were made at the Sandcastle BoF.

Wednesday morning I hosted the Developer Center BoF. It was a productive session where we identified what the developer experience currently consists of, the possible audiences, the variables coming into play, challenges, stakeholders who might be interested in its development and developers centers by other projects equally sized like GNOME. I’ll write a blog post summarizing the BoF soon.

In the afternoon me and Sam recorded audio in preparation for a possible Flatpak Release Video and Britt helped mastering it. I also helped the GUADEC Video Editing BoF with generating intros and outtros for this year’s GUADEC videos.

GUADEC is over and I am going home tomorrow. But there is a lot of stuff coming up in July for me. The GNOME annual report needs final review and publishing. We plan to have a developer center call in the by end of July (if you are interested in participating, please  mark your availability here.) We also expect to make a Hackfest for the Developer Center after FOSDEM. And I have the GNOME release video and Flatpak release video on my to do list.  GUADEC has been productive and I hope I can work on some of these projects in my free time (help is welcome!).

Thanks to the local team and all volunteers at GUADEC for a great conference!

 

 

GUADEC 2018 Day 3

Day 2 ended with a guided tour inside the Alcazaba of Almería.

Surprisingly, the castle tour featured an exciting belly dance and a bonus theater show starring GNOME’s legendary actors.

Day 3 had plenty of talks like the other days – but I decided to spent it working with Britt on the annual report.

Lastly, lightning talks took place by the end of the day, I spoke about my experience starting Open Source Aalborg (Download PDF Slideshow).

(all picture are CC-BY-SA 4.0, by me)

GUADEC 2018 Day 2

Yesterday ended with a cozy party at the beach with opportunity for swimming in the ocean and in ice cream. Today, GUADEC Registration and one conference room moved to a new building.

I volunteered as chair conference room all day and saw many exciting talks with many topics such as System76, GJS, Translation and testing.

We had breaks with tea, coffee and delicious eaties sponsored by Slimbook and Codethink.

GUADEC was also in today’s local newspaper – we finally made it to mass media folks!

The conference day ended off with GNOME’s Annual General Meeting which is a great opportunity to reflect on GNOME vision and the amazing progress we are making to achieve it.

(All pictures are CC-BY-SA 4.0 and taken by me)

GUADEC 2018 Day 1

At 8.30 i took off Thursday morning to start my journey to Almería. I took the plane to Madrid and had 1 hour to get hold of a taxi and reach a train taking me to Almería. There I was fortunate to meet Julian and Tobias who were hacking on Fractal and making mockups.

We arrived 10.30 in the evening at Civitas for pre-registration. I met up with my roommate Niclas, who is also from Open Source Aalborg  (Denmark) like myself. The day after started with tomato spread on bread.

Everyone gathered to get with the bus and we arrived to the university.

GUADEC was kicked off in a big hall with Nuritzi, the GNOME Foundation president on stage.

After watching a couple of talks I had volunteered for the infodesk and helped giving attendees lunch tickets.

Of course, I also brought the socks and the GUADEC team had this year’s GUADEC t-shirts for sale.

This wraps up todays’ events for me. I’ve already managed to chat with many GNOMEies again and I’m looking very forward to the next days!

(All pictures are CC-BY-SA 4.0 by me).

Coming Up: GUADEC 2018, Annual Report 2017 & Release Video 3.30

Now that my master’s thesis is over,  I finally have time to make some noise in here again!

GUADEC 2018

GUADEC is coming up and I’m super excited for it! My hand luggage will be packed with socks and I plan on becoming a red shirt again this year, as is tradition. I can recommend volunteering to anyone who has tried attending GUADEC before, it is an excellent way to get to know some fellow conference attendees.

This GUADEC I also plan helping with the newcomer initiatives, very possibly including a newcomer workshop. I have also volunteered to help making intros and outtros for the recorded talks.

Annual Report

The Engagement team delivers an annual report every year and this year it will cover what happened from October 2016 to September 2017. I have volunteered to do the layout and you can follow it’s progress in the Annual Report 2017 Finalization Gitlab issue. Any help on fixing the last few TODO items in there would be appreciated!

Release Video for GNOME 3.30

GNOME 3.30 is scheduled to release on the 5th September 2018. With GUADEC coming up I want to shift focus onto the release video and collect as much information about new features as possible while I have the opportunity to talk to our awesome GNOME developers face-to-face.

If you could be interested in helping me prepare the 3.30 release video, please follow this gitlab issue for updates. I will continuously update the issue as I and others make progress. With this issue, I hope it is easier for everyone to track the release video development and participate! Let me know if you are interested in helping. Thanks!

GNOME at FOSS North

FOSS North is a nordic free software conference happening annually in Gothenburg, Sweden. I have attended most of them since it started. It is no more than a ferry ride away from me and I also enjoy the conference size. Bastien and Kat coordinated that the event box was sent to my address in good time. Additionally, Nuritzi and Carlos sent additional GNOME stickers which I packed down along with some 20 pairs of GNOME Socks in various sizes.

The Stenaline Ferry. (CC-BY-SA 4.0)

During the conference I was staying with Andreas and had a great time. The first day at FOSS North was just half a day, but on the second day we set up the GNOME booth. As per tradition, we had booth right next to KDE which is always a great opportunity to chat and make jokes on social media. I’m really happy to help GNOME being present even at events which have smaller scale than FOSDEM and I’m looking forward to the next FOSS North already.

The GNOME Booth at FOSS North (CC-BY-SA 4.0)
GNOME Merchandise at FOSS North (CC-BY-SA 4.0)

After FOSS North we went to a User Experience event focusing on people’s attitude towards technologies of the future. I was particularly caught by Sara’s talk where she showed her use of collages to dive into users’ tacit knowledge and desires.

UX Meetup (CC-BY-SA 4.0)

All in all a great trip. It seems that I am carrying lots of GNOME merchandise currently (event box, posters, stickers, leftover shirts, socks..) so if there is any conference where you think it would nice to have GNOME present, let me know and we can look into it!

Reflections on Distractions in Work, Productivity and Time Usage

For the past year or so I have mostly worked at home or remote in my daily life. Currently I’m engaged in my master thesis and need to manage my daily time and energy to work on it. It is no surprise to many of us that working using your internet-connected personal computer at home can make you prone to many distractions. However, managing your own time is not just about whipping and self-discipline. It is about setting yourself up in a structure which rewards you for hard work and gives your mind the breaks it needs. Based on reflections and experimentation with many scheduling systems and tools I finally felt I have achieved a set of principles I really like and that’s what I’ll be sharing with you today.

Identifying the distractions

Here’s a typical scenario I used to experience: I would wake up and often the first thing I do is turn on my computer, check my e-mail, check social media, check the news. I then go eat my breakfast and start working. After a while I would find myself returning to check mail and social media. Not that much important necessarily happened. But it’s fairly easy for me to press “Super” and type “Gea” and press “Enter” (and Geary will show my e-mail inbox). It’s also fairly easy to press “Ctrl+L” to focus the address bar in Firefox and write “f” (and Facebook.com is autocompleted). Firefox is by default so (ironically) helpful to suggest facebook.com. At other times, a distraction can simply be an innocent line of thought that hits you fx. “oh it would be so cool if I started sorting my pictures folder, let me just start on that quickly before I continue my work“.

From speaking with friends I am fairly sure this type of behavior is not uncommon at all. The first step in trying to combat it myself was to identify the scope of it. I don’t blame anyone else for dealing with this – I see this more as an unfortunate design consequence of the way our personal computers are “universal” and isn’t context-aware enough. Afterall, GNOME Shell was just trying to be helpful, Firefox was also just trying to be helpful, although they are also in some aspects making it easier for me to distract myself like that.

Weapons against distractions

Let me start with a few practical suggestions, which helped me initially break the worst patterns (using big hammers).

  • Stylish: using Inspection tools and CSS hacks I remove endless scrolling news feeds, and news content from websites that I might otherwise on reflex open up and read when in a distracted scenario. The CSS hacks are easy to turn off again of course, but it adds an extra step and makes it purposely less appealing for me to do unless it’s for something important.

  • BlockSite: I use BlockSite in “Whitelist mode” and turn it on while I work. This is a big hammer which essentially blocks all of internet except for whitelisted websites I use for work. Knowing that you can’t access anything really had a positive initial psychological effect for me.
  • Minimizing shell notifications: While I don’t have the same big hammer to “block access to my e-mail” here, I decided to change the order of my e-mail inboxes in Geary so my more relevant (and far less activity prone) student e-mail inbox appears first. I also turned off the background e-mail daemon and turned off notification banners in GNOME Shell.
  • Putting Phone in Ultra Battery Saving Mode: I restrict my phone to calls and SMS so that I don’t receive notifications from various chat apps which are irrelevant whilst working. This also saves the battery nicely.

My final weapon is The Work Schedule.This doesn’t sound new or surprising and we probably all tried it, however with more or less success.

..Schedules can be terrible.

I’m actually not that big a fan of putting microscheduling my life usually. Traditional time schedules are too focused around doing things from timestamp X to timestamp Y. They require that you “judge” how fast you are in working and their structure just feels super inflexible. The truth in real life is that my day never look like how I planned it to be. In fact, I found myself sometimes even more demotivated (and distracted) because I was failing to live up to my own schedule and by the end of the day never really managed to complete that “ideal day”. The traditional time schedule ended up completely missing up what it was supposed to fix and help against.

But on the other hand, working without a schedule often results in:

  • Forgetting to take breaks from work which is unhealthy and kills my productivity later.
  • No sense of progress except from the work itself but if the work is ongoing for longer time this will feel endless and exhausting.
  • Lack of work duration meant that my productivity continued to fluctate between overwork and underwork since it is hard to judge when it is okay to stop.

The resulting system

For the past couple of weeks I have been using a system which is a bit like a “semi-structured time schedule”. To you it might just seem like a list of checkboxes and in some sense it is! However, the simplicity in this system has some important principles behind it I have learned along the way:

  • Checking the checkboxes give a sense of progress as I work throughout my day.
  • The schedule supports adding breaks in-between work sessions and puts my day in an order.
  • The schedule makes no assumptions about “What work” I will be doing or reaching that day. Instead it specifies that I work for 1 hour and this enables me to funnel my energy. I use GNOME Clock’s Timer function and let it count down for 1 hour until there’s a nice simple “ding” to be heard when it finishes. It’s up to you whether you then take the break or continue a bit longer.
  • The schedule makes no assumptions about “When” I will do work and only approximates for how long. In reality I might wake up at 7:00, 8:00 or 9:00 AM and it doesn’t really matter. What’s important is that I do as listed and take my breaks in the order presented.
  • If there are aspects of the order I end up changing, the schedule permits it – It is possible to tick off tasks independent of the order.
  • If I get ideas for additional things I need to do (banking, sending an important e-mail, etc) I can add them to the bottom of the list.
  • The list is made the day before. This makes it easier to follow it straight after waking up.
  • I always use the breaks for something which does not involve computers. I use dancing, going for a walk or various house duties (Interestingly house duties become more exciting for me to do as work break items, than as items I do in my free time).
  • In the start you won’t have much feeling for how much work you can manage to make and it is easy to overestimate and get out of breath or unable to complete everything. It works much better for me to underestimate my performance (fx 2 hours of focused work before lunch instead of 3 hours) and feel rewarded that I did everything I had planned and perhaps even more than that.
  • I insert items I want to do in my free time into my scheduling after I finish work. These items are purely there to give additional incentive and motivation to finish.
  • The system is analog on purpose because I’m interested in keeping the list visually present on my desk at all times. I also think it is an advantage that making changes to the list doesn’t interfere with the work context I maintain on the computer.

Lastly, I want to give two additional tips. If you like listening to music while working, consider whether it might affect your productivity. For example, I found music with vocals to be distracting me if I try to immerse myself in reading difficult litterature. I can really recommend Doctor Turtle’s acoustic instrumental music while working though (all free). Secondly, I find that different types of tasks requires different postures. For abstract, high-level or vaguely formulated tasks (fx formulating goals, reviewing something or reflecting), I find interacting with the computer whilst standing up and walking around to really help gather my thoughts. On the other hand with practical tasks or tasks which require immersion (fx programming tasks), I find sitting down to be much more comfortable.

Hopefully my experiences here might be useful or interesting for some of you. Let me know!

Reflections on the GNOME 3.28 Release Video

I just flipped the switch for the 3.28 Release Video. I’m really excited for all the new awesome features the community has landed, but I am a bit sad that I don’t have time to put more effort into the video this time around. A busy time schedule collided with technical difficulties in recording some of the apps. When I was staring at my weekly schedule Monday there didn’t seem much chance for a release video to be published at all..

However, in the midst of all that I decided to take this up as a challenge and see what I could come up with given the 2-3 days time. In the end, I identified some time/energy demanding issues I need to find solutions to:

  1. Building GNOME Apps before release and recording them is painful and prone to error and frustration. I hit errors when upgrading Fedora Rawhide, and even after updating many apps were not on the latest version. Flatpak applications are fortunately super easy to deal with for me, but not all applications are available as flatpaks. And ideally I will need to setup a completely clean environment since many apps draw on content in the home folder. Also, currently I need to post-process all the raw material to get the transparent window films.
  2. I run out of (8GB) memory several times and it’s almost faster to hold power button down and boot again, than to wait for Linux memory handling to deal with it.. Will definitely need to find a solution to this – it builds up a lot of frustration for me.

I am already working on a strategy for the first problem. A few awesome developers have helped me record some of the apps in the past and this has been really helpful to deal with this. I’m trying to make a list of contacts I need to get in touch with to get these recordings done, and I need to send out emails in time with the freezes in the release cycle. It makes my work and the musician’s work much easier if we know exactly what will go in the video and for how long. I also had a chat with Felipe about maybe making a gnome shell extension tool which could take care of setting wallpaper, recording in the right resolution and uploading to a repository somewhere. As for the second problem, I think I’m going to need a new laptop or upgrade my current one. I definitely have motivation to look into that based on this experience now, hehe..

“Do you have time for the next release video?” You might ask and that is a valid question. I don’t see the problem to be time, but more a problem of spending my contribution energy effectively. I really like making these videos – but mainly the animation and video editing parts of it. Building apps, working around errors and bugs, post-processing and all that just to get the recording assets I need, that’s the part that I currently feel takes up the most of my contribution energy. If I can minimize that, I think I will have much more creative energy to spend on the video itself. Honestly, all the awesome contributions in our GNOME Apps and components really deserve that much extra polish.

Thanks everyone for helping with the video this time around!

css.php