gnome on /home/csoriano

Why you can and should apply for the board

csoriano@gnome.org (Carlos Soriano) — Mon, 27 May 2019 00:00:00 +0000

It’s GNOME board elections time!

Community members can apply to become GNOME Foundation directors, and the process is quite easy, it’s just about sending an email to two mailing lists. We can improve on the number of participation though, and having a good amount of applicants is important for having a healthy foundation - the more applicants there are, the more likely that different views, skills and working areas are represented.

I believe one of the big factors of not having high participation in elections is the lack of knowledge of what the board does and how much of a commitment it is. Because of that, we question whether we are ready for taking on the position. While minutes published by the board are an excellent tool (and I really need to thank Phillip and Federico here), minutes usually don’t tell the whole story.

In light of recent discussions on foundation list, I realized we also didn’t explain yet how the work of the board has changed to a more strategic position, and what that entails.

So let me try to improve that, and explain why you should apply and why you definitely can apply.

How does the work of the board look nowadays?

For the purpose of understanding what kind of work we do, let me split them in two types. Work that is about execution, and work that is about strategy.

Examples of execution based tasks are:

Sending an email to a certain committee.
Moving this wiki page to this other wiki page.
Cleaning up minutes.
Approving/declining small budget stuff such as stickers, release dinners, hackfests snacks, etc.
Approving/declining big budget stuff such as GUADEC, GNOME Asia, services (CI, map titles, etc.), hardware, etc.
Approving/declining legal things such as trademarks usage.

Examples of strategic tasks are:

Defining a policy for travel sponsorship.
Defining what GNOME software is.
Defining committee responsibilities.
Defining yearly goals.
Defining trademarks and its usage.
Defining budget spending policy for small events.
Defining events bidding process.

You can already see that strategic tasks are usually done to support execution based tasks. However, execution based tasks are what actually delivers, and without them strategic tasks don’t have much use. Execution based tasks are about doing, strategic tasks are about thinking and creating.

The difference between those is quite significant, execution based tasks take around 1-2 weeks to complete, are quite independent of other people and have clear steps to do them. Strategic tasks take between 6 months and 2 years long to complete, they are dependent on other people, involving several discussions in various meetings and emails, they are quite more complex and usually involve different areas such as community, legal, market knowledge, etc. Most of the times you learn about them while you go, so while you gain significant experience on those areas, the ramp up to work on strategic tasks takes a while.

Historically, the board has been mostly execution based. The reason is that execution based tasks needs to be done no matter what. So what happened is that strategic tasks were delayed, or never done, in order to keeps things running. I would say the balance was around 90%-10% for execution based and strategic tasks respectively.

This last year that has changed significantly. The staff of the foundation is doing the heavy lifting on the execution based tasks, so now the job left for the board is mostly strategic. The balance has flipped to a 10%-90% split of execution based and strategic tasks. This is already implemented, there is almost nothing left to hand off to the staff nowadays.

The board tasks over the last ~6 months have been focused on those that are usually up to a board to do, most of them cannot be done by the staff due to legal or general charity guidance, such as setting the compensation for the ED or setting the goals for the foundation.

Why can you apply?

Alright, so you think you have some motivation to be on the board. But maybe reading the candidacy emails or the section I wrote before makes you think that the tasks are too complex, or that the commitment to be on the board might be too big for you. Well, I want to debunk this here.

One particularity of the board is that everyone takes on things they want to take on. And no more than that. There isn’t a “you didn’t do anything for a month, you should do this other task” kind of situations. Some of us simply provide opinions here and there, either because we don’t have time, or don’t have the knowledge, or don’t have the energy or interest on learning that knowledge.

And that is okay, specially if you don’t have experience on dealing with the tasks mentioned in the previously, the rest of the board and the staff are aware of that, it’s expected that you will help where you can. We are volunteers after all, and sometimes an opinion or a question is the most helpful thing we can do.

There are only a few things that are required: Being open to learn, a bit of proactivity, attending 1h weekly meetings, attending GUADEC, and lastly, some time and willingness to take on some work (1-2h per week, some weeks much more, some weeks none at all).

Some areas may not be interesting for you, but some others may. Once you are in the board, take the initiative to volunteer on those that you feel are of interest to you and what you will do will be already useful.

Why should you apply?

You have some motivation to be on the board, but what’s really in there for you? What do you get from it? For me, there are two big benefits.

One is leading the community and having an impact on the direction of the project. If you are reading this, most probably you care about the project and the community behind it. This is usually the biggest motivation, and having a way to impact the project with your ideas is certainly a good feeling. Being on the board will give you the insight necessary to move forward with your high impact ideas, will open the doors to external entities that will help you drive those initiatives in a much easier way, and will give you certain skills that will make them most likely to succeed.

The second one is personal and career development. Personally speaking, I gained knowledge about handling changes that have impact for over (most probably) 100 people, negotiating deals with companies, handling legal issues and concerns, manage personal conflicts, hiring process and salaries, and in general, management and leadership.

In regards of soft skills, I can say that some opportunities on the board are around the level of Principal or Senior Principal Engineer, with the advantage that you take only on the things you feel comfortable with while allowing you to get out of the comfort zone with the support of the rest of the board and staff.

Is there any downside?

I hope what I said so far has motivated you enough to apply, you can see there are quite a few advantages both personally and for the community for you to go ahead and apply.

So is there any downside? Honestly, I think there is only one. Fear of rejection.

I applied for first time to the board about 4 years ago. I got 5 first position votes out of 100. Well… honestly, this had an impact on me. I thought the community simply didn’t want me, and that’s all about it. I decided to not apply again.

Despite that, here I am, last year I got quite a few of those first position votes for myself.

The key is to not take it personally, this can happen for multiple reasons that are not specific to you as a person.

Maybe you proposed an initiative in your candidacy email and it was too early to make it happen, maybe simply you were a visionary. Or maybe members didn’t know you enough, or you lacked some experience in coordinating initiatives.

Good thing is, these can be improved quite easily. You can take the lead on small tasks that involve several contributors, you will get the experience of leading those initiatives and members will get to know you. Maybe simply go over 3.34 items and ask about their status and who can help move them forward? Or just improve Meson build along different modules? Maybe help with an existing initiative such as newcomers or Flatpak? How about coordinating an announcement with the engagement team? Or coordinating the release notes?

Owning tasks that go across different projects is a good way get elected the next time.

Apply today

I think I speak for the whole board when I say that we are glad to answer any questions about what working for the board entails, so feel free to simply informally contact any of us on IRC or email and we will answer any questions as our individual availability permits.

Now is your turn, apply, apply and apply.

Thanks Nuritzi and Rob for going through the document.

Desktop Icons New Maintainer & Release

csoriano@gnome.org (Carlos Soriano) — Fri, 03 May 2019 00:00:00 +0000

Desktop icons just had a new release! Plenty of good things went in:

Sergio fixed the “Open in Terminal” menu item not opening in the desktop folder, and also made the files appear from top to bottom, left to right, that more users were used to. Also, we discovered that the settings panel wasn’t getting translated, so Sergio fixed it too and now all translations are in place.

We had another developer contributing too, Andrea Azzarone. Andrea fixed the rubberband going over windows, quite a nice touch. Also added a way to group consecutive rubberbands with and , which is definitively useful!

You can grab the new version in tarball format or in extensions.gnome.org.

A new Maintainer

And I have good news… Sergio has just being apointed as co-maintainer of the project!

Sergio has been working on the project constantly, with a high sense of responsability, for more than 9 months. In fact, I have been struggling to catch up with all the work he has been doing. Whenever I reviewed a merge request, another two were opened :-)

Sergio deserves the maintainer position, having more decision making responsabilities and to take over important tasks in the project.

Congrats Sergio!

DrupalCon

csoriano@gnome.org (Carlos Soriano) — Fri, 19 Apr 2019 00:00:00 +0000

Last week I attended DrupalCon in the lovely city of Seattle invited by Tim, the executive director of Drupal.

Our plan was to have a panel discussion about the tooling we use in FOSS organization such as GNOME, Debian, Drupal, etc. Specially since we recently transitioned to GitLab. The panel discussion was between Tim himself, Alex Wirt from Debian, Eliran Mesika and Tina Sturgis from GitLab and me. We were 5 out of 9 featured speakers!

Seattle

I took some days before the conference to adjust to the timezone, and to take the oportunity and visit Seattle, my second time in US. Visited all the nice public spaces like the Space Needle, the Chihuly Garden and Glass, Science museum and the Museum of Pop Culture where I had the oportunity to play guitar for longer time than I want to admit.

Chihuly Garden and Glass

Me and the rainy wather seen from the Space Needle

Also let me tell you, the coffee in Starbucks Reserve is much better than regular Starbucks! However, nothing as good as StoryVille Cafe; they even gave me a mug as a gift.

DrupalCon

After getting used to the timezone and regained energies from visiting all Seattle, it was time to go to DrupalCon. It was hosted in the Washington State Convention Center, quite a big venue with a proportionaly attendance of 3500 people.

Attendees were quite nice, I got quite a few small chats just walking around looking for talks to attend. That was appreciated, specially for someone like me that knew noone and didn’t have much of an idea about any of the products discussed there.

I attended a few talks about project management, community management, etc. and realized they face similar issues that we have to deal with. For example, how to organize a big community and drive new initiatives, how to empower and encourage people to work on the things that matter most for the project, etc.

Also, since Drupal is moving to a more enterprise model, questions such as “How do we keep free software ideals strong in our community?” and “How do we keep community as strong as enterprise/company contributions?” were raised too.

Only thing I would have hoped to have was a central communication channel were I could just jump in and ask or propose to do things around. Their IRC was not very active, which was surprising given the number of attendees. This is something that works for us at GUADEC with the GNOME Telegram group.

The breakfast and panel discussion

The day for the talk arrived, and after preparing it quite well (we started its preparation almost a year ago!) we had a nice breakfast where all of us finally met in person.

These informal chats have a lot of value to me, we discussed the challenges and goals of Drupal for the future. Similar with GitLab, we discussed the future direction of the company and project and its FOSS values and how open they are with their strategy, specially as they get closer to their IPO.

The panel discussion went quite well, but the attendance was pretty low, most likely because it was at 9:00 the day after the DrupalCon parties… hard to get people in. Even then, we discussed with the Matthew Tift, a Drupal contributor in the “newcomers” field, for ways to improve community contribution. I also discussed with Tina the marketing strategy in FOSS organizations that are community contributor driven like GNOME, and ways to improve that for GNOME and GitLab.

The main point for Drupal was that historically they have been a collaboration island, in oposstion of GNOME that we have been a collaboration hub for most of the Linux desktop projects. Tim wants Drupal to improve this situation and find ways to collaborate more with us, specially once I mentioned we were the creators of Outreachy. Given that their main goal for this year is inclusivity and diversity, GNOME being the creators of Outreachy gives us a great respect and trust on driving such initiatives.

In general, my main message for the conference was about GNOME being not only a desktop product, but also a place of inovation for FOSS projects and initiatives, and a place where key people in the FOSS world have learn their skills while being driven by a community rooted in FOSS values. GNOME goes beyond GNOME itself, and I hope this message got delivered!

We should do more of this!

It was great to attend a conference for a product we don’t have much in common, we have many ways to collaborate that are not only about software, and organizations like Drupal and GitLab are great partners in where we want to go and what we want to do. I think, we at GNOME should do this more often, take these oportunities to meet fellow FOSS projects and find more ways where we can intersect and collaborate.

Lastly, huge thanks to Tim and Drupal and Eliran, Tina and GitLab for sponsoring my trip, and to Red Hat for giving me the time to go there. It was great to see you all, I’m looking forward to more oportunities like these 🍻

Issue handling automation for GNOME

csoriano@gnome.org (Carlos Soriano) — Mon, 07 Jan 2019 00:00:00 +0000

I remember some time ago discussing with someone from GNOME how important is to make a good issue report, the conclusion came along the lines of “I have 10 seconds to read per issue, if the issue is not well done it’s most likely I won’t have time to read it”. It’s true most of us are focused on doing actual code, after all it’s what most of us enjoy and/or what we are paid for. So bug handling always takes a quite back place on our priorities.

On the other hand, the management of issues is neccessary for a healthy project, specially if you are using it for planification, prioritization, feedback gatherer and interaction with other developers or teams. In general, a set of open issues that is representative, updated and properly reported helps the project progress and build a community around.

Handling issues automatically

There are a set of tasks that are quite repetitive, such as closing issues that were left with the “need information” label. Or old feature requests. Or crashes that were reported years ago with an old version of the software…

This is something I really wanted to get done with, so I’ve been working in the past weeks to make a set up where repetitive tasks are automated by a GitLab CI “bot”, and this is what I’m gonna share with you today!

The tool that performs the task is used by GitLab CE itself for their own issue triage automation and it’s called gitlab-triage. This tool takes a set of rules and process them with a CI job, then you can set to be run periodically in schedules.

So let’s take a look how to make a simple set up.

Basic set up

First, you need to set up a CI job that will run the tool. For that, in your CI file add:

triage:
  image: ruby:2.4
  stage: triage
  script:
    - gem install gitlab-triage
    - gitlab-triage --token $TRIAGE_BOT_TOKEN --project-id $CI_PROJECT_PATH --host-url https://gitlab.gnome.org
  only:
    - schedules

And add a “triage” stage to the file stages. This will install a ruby docker image, install the gitlab-triage program and then run it on schedules. Note the variable $TRIAGE_BOT_TOKEN, this is the API token of the account you want to use for perform the actions. You can use your account, a new account, or the bot I created for GNOME. Feel free to ask me the token for your use. Also, make sure the project has a schedule that the triage can run on.

Now, what it should run tho? That’s where the policies file enters the game.

The policies

gitlab-triage will process a file called .triage-policies.yml on the root of your project. This file defines with what rules and what the bot should do. You can make conditions based on labels, dates, etc. Feel free to take a look at the gitlab-triage documentation, it’s quite extense and helpful.

For now, let’s write our first rule. And we are going with the less controversial one, closing issues that were marked as need information.

Close issues that need information and weren’t updated

When a bug needs information to be properly triaged, we mark issues with the “need information” label. After some time, if nobody provides the information the bug should be closed. At GNOME Bugzilla we were closing these bugs after 6 weeks, with a stock answer .

How can we write this so it’s done by the gitlab-triage bot? We just create a new rule in the policy file, in this way:

 resource_rules:
  issues:
    rules:
     - name: Close issues that need information and weren't updated 
        conditions:
          date:
            attribute: updated_at
            condition: older_than
            interval_type: weeks
            interval: 6
          state: opened
          labels:
            - 2. Needs Information 
        actions:
          status: close
          labels:
            - 15. Auto Updated
          comment: |
            Closing this issue as no further information or feedback has been provided.

            Please feel free to reopen this issue if you can provide the information or feedback.

            Thanks for your help!

            ---

            This is an automatic message. If you have suggestions to improve this automatic action feel free to add a comment on https://gitlab.gnome.org/GNOME/nautilus/issues/715

Quite simple. We set up the conditions that an issue must match in order to be processed under “conditions”, then we set the actions we want to do to those issues in the “actions” section.

In this case, if an issue was last updated more than 6 weeks ago, it’s in the opened state, and has the label “2. Needs Information” it will close the issue, set the label “15. Auto Updated” and comment the stock response. Note that we set a label to know that it was autoupdated by a bot, so in case something goes wrong we can query those issues and perform other actions on them.

You can see an example result here, it looks like:

And an example of a query for Nautilus auto updated issues here, which looks like:

Nice, right?

Close old feature proposals

Features proposals are probably the issues that has a higher ratio of being ignored. With the resources we usually have, it’s unlikely we can add more maintainership “cost” to our projects, or that we already didn’t plan carefully what features to add.

With this at hand, we want a rule that closes old feature proposals that hasn’t been marked as part of the project planning. The rule looks like:

- name: Close old feature proposals without planning labels or milestones
  conditions:
    date:
      attribute: created_at
      condition: older_than
      interval_type: months
      interval: 12
    labels:
      - 1. Feature
    forbidden_labels:
      - 2. Deliverable
      - 2. Stretch
      - 1. Epic
    milestone:
      - No Milestone
    state: opened
    upvotes:
      attribute: upvotes
      condition: less_than
      threshold: 10
  actions:
    labels:
      - 15. Auto Updated
    status: close
    comment: |
      Hi,

      First of all, thank you for raising an issue to help improving Nautilus. In order to maintain order in the issue tracker we are closing old, unscheduled feature proposals.

      Unfortunately, no Merge Request has been provided for this, and/or the project contributors are not planning this feature in the foreseeable future.

      This issue will be closed as it meets the following criteria:
      * Created more than 12 months ago
      * Labeled as ~"1. Feature"
      * Not associated with a milestone or with ~"2. Deliverable" or ~"2. Stretch" project planning labels.
      
      Thanks for your help!

      ---

      This is an automatic message. If you have suggestions to improve this automatic action feel free to add a comment on https://gitlab.gnome.org/GNOME/nautilus/issues/715

It’s similar to the previous rule, we just added the condition to not proccess issues that has the project planing labels “2. Deliverable”, “2. Stretch” or “1. Epic”. The project planning labels comes from the Project Planning for GNOME post.

Note the voting threshold condition of 10 votes, this is just an internal way to make sure we don’t close automatically a highly voted feature proposal, so we rather make a manual comment to avoid misscomunications.

You can see an example result here, it looks like:

Bring attention to untriaged issues

This is all nice, but what about issues that wasn’t even triagged in the first place? For those, we can make the bot create a summary for us. This helps greatly to bring to our attention in a regular basis those issues that need to be taken care of.

We use the “summarize” action, the rule looks like:

- name: Mark stale unlabelled issues for triage
  conditions:
    date:
      attribute: created_at
      condition: older_than
      interval_type: months
      interval: 2
    # We want to handle those that doesn't have these labels, including those with other labels.
    forbidden_labels:
      - 1. Bug
      - 1. Crash
      - 1. Epic
      - 1. Feature
    state: opened
  actions:
    labels:
      - 15. Untriaged
    summarize:
      title: Issues that need triaging
      item: |
        - {{web_url}} - {{title}} - {{labels}}
      summary: |
        The following issues were created two months ago and they are unlabeled:

        {{items}}

        /cc @Teams/BugSquad

This will create an issue with a list of issues that are lacking one of the labels listed in “forbidden_labels”. Note that we could have use simply “No Label” value as a condition in a “Labels” section, however we wanted to bring to our attention those issues that have other labels but we didn’t mark if they were a bug or a feature, because we rely on these labels for the previous rules.

Also note that the created issue pings a group called “Teams/BugSquad”, which doesn’t exist yet. If this sounds useful for us, I would like to create this group so bug triagers can be part of that group and get pinged to handle these issues in a regular basis.

You can see an example result here, it looks like:

Close old issues

This is a controversial one. Who hasn’t receive a “Fedora has reached EOL” mass mails? :) I will leave the explanation why I think we should try this for another post, since here I want to focus on providing just the tooling and snippets for those who want to try it out.

For closing old bugs we just look at the updated date and close those that hasn’t been touched in 18 months.

- name: Close stale issues with no milestone or planning labels
  conditions:
    date:
      attribute: updated_at
      condition: older_than
      interval_type: months
      interval: 18
    milestone:
      - No Milestone
    forbidden_labels:
      - 2. Deliverable
      - 2. Stretch
      - 1. Epic
      # Features are handled in a different rule
      - 1. Feature
    state: opened
  actions:
    status: close
    labels:
      - 15. Auto Updated
    comment: |
      Hi,

      Thank you for raising an issue to help improve Nautilus. We're sorry this particular issue has gone unnoticed for quite some time.

      This issue will be closed, as it meets the following criteria:
      * No activity in the past 18 months (3 releases).
      * Unscheduled. Not associated with a milestone or with ~"2. Deliverable" or ~"2. Stretch" project planning labels.

      We'd like to ask you to help us keep our issue tracker organized  by determining whether this issue should be reopened.

      If this issue is reporting a bug, let us know if this issue is still present in a newer version and if you can reproduce it in the [nightly version](https://wiki.gnome.org/Apps/Nightly).

      Thanks for your help!

      ---

      This is an automatic message. If you have suggestions to improve this automatic action feel free to add a comment on https://gitlab.gnome.org/GNOME/nautilus/issues/715

Let me know how it works for you

So far it has work quite well for Nautilus, in our first run it helped us to triage around 50 issues, and the bot closes 15 issues that were either waiting long for information or were old features requests.

These rules can be tweaked, and in general these are an approach I think we should test. There are a few things that are a bit bold, specially closing issues automatically, so any feedback is appreciated.

I’m looking forward to hear how it works for you, and see if there are other modifications you do or some advice you would propose.

Enjoy!

Desktop icons RC release

csoriano@gnome.org (Carlos Soriano) — Wed, 21 Nov 2018 00:00:00 +0000

So it’s finally here, desktop icons release candidate for 1.0 is available now!

This means that all the features we wanted for 1.0 are implemented and we freeze the implementation of new features. Now we will focus on polishing and removing noisy or unnecessary stuff in the UI, fix weird behaviours and UX, fix bugs, etc.

What’s new?

Tons of stuff! We added multimonitor support, HiDPI support, renaming of files, thumbnails support, DnD between files on the desktop, better rubberband selection… Honestly, more than I thought we could do. You can read more about what’s new in the release notes.

Only feature that it’s not implemented is DnD from the windows to the desktop and the other way around. Maybe not a big deal since you can copy & paste either by shortcuts or by the context menus. We will be glad to review the code if someone wants to give it a chance and work on it.

This release already overpasses what Nautilus offered

Nautilus desktop icons has never worked well in multimonitor setups. Files get stuck hidden in some not reachable places due to the nature of Nautilus that simply puts a big window as the desktop, instead of a window per monitor.

This extension finally implements a sane multimonitor handling, by having a flexible grid per monitor. No more lost data…

Also, as you might know, the Nautilus desktop icons was Xorg only. This extension is by nature Wayland ready.

What’s needed for 1.0?

Once the result feels polished enough and we are confident about the amount of features we want to support, the default settings, etc. we will release 1.0. My hope is that that will happen in the timeframe of one month from now.

Feel free to grab the new release in the GNOME extensions website test it, report bugs, give feedback and of course, welcome to join the development of this project if you want to contribute!

And finally, with this release I’m glad to announce and welcome Sergio Costas to join as official developer to the project! He has done an excellent job implementing tons of features we wanted for the 1.0 version.

Thanks to everyone who contributed in one way or another!

Enjoy

PD: Nautilus 3.30.4 is needed for the rename of files to work.

GNOME Internships interns has been elected

csoriano@gnome.org (Carlos Soriano) — Thu, 01 Nov 2018 00:00:00 +0000

Hello all,

GNOME Internships projects and interns has been elected!

We had have strong applicants and quite a big amount of applications. If you are not the elected don’t be discouraged, it wasn’t an easy choice.

This round we have to congratulate Ludovico de Nittis who will work in the “USB Protection” project with his mentor Tobias Mueller. Congrats Ludovico!

The project goal is to increase the robustness against attacks via malicious USB devices. Certainly a challenging goal! You can read extensive information in the project wiki linked above, it’s definitely quite interesting.

This round of internships is fund by the privacy and security campaign we did at GNOME a few years ago, and we are happy we can put them into good use to improve the security and privacy of GNOME users and donors.

Deeply thanks to all the donors! Withouth you this initiative wouldn’t have been possible. Also thanks to the mentors and applicants.

More on the admin side, it has been a little bumpy since its the first time doing these internships. And well, this last week I have been a bit worried by other stuff you already probably know about :)

If you have any question or feedback, don’t hesitate to contact me on IRC as csoriano or send an email to internships-admin@gnome.org

GNOME Internships are getting closer

csoriano@gnome.org (Carlos Soriano) — Sat, 29 Sep 2018 00:00:00 +0000

Almost there…

GNOME Internships are getting closer, if you are a GNOME contributor with some experience this internship is a good fit for you. Official application deadline is 1st of October, but we are open to receive more aplications if the aplicant is a good fit.

How about applying? :)

What’s this about?

GNOME internships is a program to use the donations we get from campaigns into projects aimed to improve the topic of the campaign. This internship is not limited to students or a other level of expertise, quite the opossite, some experience and/or being part of GNOME already is a must. Making sure these projects get finished is very important to us, and to achieve that the GNOME foundation is providing a more than nice stipend!

This round of internships is aimed to improve privacy when using GNOME. We have selected a few projects tha are key to provide an excellent privacy experience with GNOME software. We will use the funds we raised as part of the privacy campaign and we are excited to put them in good use for all of our donors.

Requirements & more info

Ideal what-to-have are being a GNOME contributor and some work/other FOSS experience. If you don’t have work/other FOSS experience but are a regular GNOME contributor this is also fit for you. Likewise, if you have work/other FOSS experience but don’t have as many GNOME contributions you can try out too after making some contributions to GNOME.

If you are not sure if you fullfill the requirements don’t hesitate to ask me or send an email to internships-admin@gnome.org. Above all, don’t let the impostor syndrome to prevent you for asking or aplying!

Go to the wiki page to read more info and follow the steps to apply.

Cheers 🐩

Moving from Wordpress

csoriano@gnome.org (Carlos Soriano) — Tue, 11 Sep 2018 00:00:00 +0000

Wordpress

I have been using Wordpress for long. Basically since I joined GNOME because it was required for GSoC. Wordpress works, it’s okay. There are themes, it has a wysiwyg editor and you can embed images and videos quite easily. It kinda does the job…

The bad

Now, one of the biggest problems are ads. Not that they exist, which is completely understandable, but rather that they are kinda crazy. I got reports that sometimes they were about guns in USA, or they lead to scam sites.

I also missed a way to link to my personal twitter/linkdin/gitlab. That’s quite useful for people to check what other things I write about and how to get more info about what I do.

The ugly

More on the technical side, one of the issues was that I coulnd’t create a draft post and share it in private with other people so I could get some review. This was specially required for Nautilus anouncements. And in case I could, how could we collaborate in editing the post itself? That was simply not there.

Most importantly, I couldn’t give personality to the blog. In the same way I want the software I use being neutral because for it’s just a tool, my personal blog should be more repsentative on how I am and how I express myself. With Wordpress this was not possible. Hell, I couldn’t even put some colors here and there, or take the bloat out from some of the widgets provided by the Wordpress themes.

The enlightenment…

Once upon a time, on a stormy day, I wrote the blog post about the removal and future plans of the desktop icons as a guest writter on Didier’s Roche blog. And here came the enligthening, he was using some magic PR workflow in GitHub where I could just fix stuff, request to merge those changes, review happens, then gets accepted and published all automatically with CI.

Finally you could review, share drafts, and collaborate much easily than with Wordpress!

Not only that, but also his blog was much more personalized, closer to how he wanted to express himself.

The decision

One thing I had have in the back of my mind for some time is that I need to improve my skills with non-GNOME stuff, specially web and cloud technologies. So what a better oportunity than trying to set up a static web generator for blogs (and other stuff) to mimic the features of Didier’s blog?

And decided was it, got some free time this weekend and decided to learn this magic stuff.

The technology

I decided to go with Hugo, because back when I was experimenting with GitLab pages and a project page for Nautilus Hugo seemed to be the easiest and most convenient tech to create a static website that just works. Overall, it seems that Hugo is the most used static website generator for blogs.

I also decided that I would get a theme based in the well known and well maintained bootstrap. Most themes had some custom CSS, all delicately and manually crafted. But let’s be honest, I don’t want to maintain this, I wanted something simple I can go with.

So I chose the minimal theme wich is based in bootstrap and then applied my own changes such as a second accent (the red in the titles), support for centered images, the Ubuntu font (which I use it everywhere I can), some navbar changes, full content rss support, lot of spacing adjustments, softer main text coloring, etc.

Also, I could finally put a decent comment section by using DisQus, which is added to Hugo with a single line. Eventually I would like to go with a free software solution such as Talkyard, so far I didn’t have luck to make it work.

The nicest thing of Hugo is that adding a new post is a matter of dropping a MarkDown file in the post folder. And that’s it. That easy.

The result

So here’s the result. I think it’s quite an improvement versus what I had in Wordpress, although Antonio says that the page looks like Nautilus… I guess I cannot help myself. Let’s see how it works in the future, specially since there is no wysiwyg editor. To be honest, using MarkDown is so easy that I don’t see that as a problem so far.

I can even embed some code with highlighting for free:

def do_measure(self, orientation: Gtk.Orientation,
               for_size: int) -> Tuple[int, int, int, int]:
    child = self.get_child()
    if not child:
        return -1, -1, -1, -1

    minimum, natural, _x, _x = child.measure(orientation, for_size)
    if self._max_width is not None and orientation == Gtk.Orientation.HORIZONTAL:
        natural = min(self._max_width, natural)

    return minimum, natural, -1, -1

And use Builder with Vim emulation to write this. That is already a big win!

If you want to take a look at the code or do something similar, feel free to take a look and use anything from the code in GNOME’s GitLab. I also added an example post in order to see all formats for headings, bullet lists, images, code blocks, etc. Any feedback about the looks, functionality, content, etc. is welcome; finally I would be able to do something about it 😏.

Hasta otra amigos 🍹