Fedora Design Team Planet

Helping new users get on IRC, Part 2

Posted by Máirín Duffy on February 08, 2017 11:49 PM

Fedora Hubs

Where our story began…

You may first want to check out the first part of this blog post, Helping new users get on IRC. We’ll wait for you here. 🙂

A simpler way to choose a nick

(Relevant ticket: https://pagure.io/fedora-hubs/issue/283)

So Sayan kindly reviewed the ticket with the irc registration mockups in it and had some points of feedback about the nick selection process (original mockup shown below:)

Critical Feedback on Original Mockup

  • The layout of a grid of nicks to choose from invited the user to click on all of them, even if that wasn’t in their best interest. It drove their attention to a multiplicity of choices rather than focused them towards one they could use to move forward.
  • If the user clicked even on just one nick, they would have to wait for us to check if it was available. If they clicked on multiple, it could take a long time to get through the dialog. They might give up and not register. (We want them to join and chat, though!)
  • To make it clear which nick they wanted to register, we had the user click on a “Register” button next to every available nick. This meant, necessarily, that the button wasn’t in the lower right corner, the obvious place to look to continue. Users might be confused as to the correct next step.
  • Overall, the screen is more cluttered than it could be.

mockup showing 9 up nick suggestion display

We thought through a couple of alternatives that would meet the goals I had with the initial design, yet still address Sayan’s concerns listed above. Those goals are:

Mo’s goals for the mockup

  • Provide the user clues as to the standard format of the nicknames (providing an acceptable example can do this.)
  • Giving the user ideas in case they just can’t think of any nickname (generating suggestions based on heuristics can help.)
  • Making it very clear which nickname the user is going to continue with and register (in the first mockup, this was achieved through having the register button right next to each nick.)
  • Making it clear to the user that we needed to check if the nick was available after they came up with one. This is important becauae many websites do this as you type – we can’t because our availability check is much more expensive (parsing /info in irc!)

New solution

We decided to instead make the screen a simple form field for nick with a button to check availability, as well as a button the user could optionally click on to generate suggested nicks that would populate the field for them. Based on whether or not an available nick was populated in the field, the “Register” button in the lower right corner would be greyed out or active.

Initial view

Nickname field is blank.

mockup of screen with a single form field for nickname input

Nickname suggestion

If you click on the suggest button, it’ll fill the form field with a suggestion for you:

mockup of screen showing the suggest nickname button populating the nickname field

Checking nick availability

Click on the “Check availability” button, and it’ll fade out and a spinner will appear letting you know that we’re checking whether or not the nick is available (in the backend, querying Freenode nickserv or doing a /info on the nick.)

mockup showing nickname availability checking spinner

Nickname not available

If the nickname’s not available, we let you know. Edit the form field or click on the suggest button to try again and have the “Check availability” button appear.

mockup showing a not available message if a nickname fails the availability check

Nickname available

Hey, your nick’s not taken! The “Register” button in the lower right lights up and you’re ready to move forward if you want.

mockup showing the register button activating when the user's input nickname is in fact available

Taking a verification code instead

I learned a lesson I already knew – I should have known better but didn’t! 🙂 I assumed that when you provide your email address to freenode, the email they send back havs a link to click on to verify your email. I knew I should go through the process myself to be sure what the email said, what it looked like, etc., but I didn’t before I designed the original screen based on a faulty assumption. Here is the faulty assumption screen:

Original version of the email confirmation mockup which tells users to click a link in the email that doesn't exist.

I knew I should go through the process to verify some things about my understanding of it, though (hey, it’s been years and years since I registered my own nick and email with freenode NickServ.) I got around to it, and here’s what I got (with some details redacted for privacy, irc nick is $IRCNICK below:)

From "freenode" <noreply.support@freenode.net>
To "$IRCNICK" <email@example.com>
Date Mon, 06 Feb 2017 19:35:35 +0000
Subject freenode Account Registration


In order to complete your account registration, you must type the following
command on IRC:

/msg NickServ VERIFY REGISTER $IRCNICK qbgcldnjztbn

Thank you for registering your account on the freenode IRC network!

Whoopsie! You’ll note the email has no link to click. See! Assumptions that have not been verified == bad! Burned Mo, burned!

So here’s what it looks like now. I added a field for the user to provide the verification code, as well as some hints to help them identify the code from the email. In the process, I also cut down the original text significantly since there is a lot more that has to go on the screen now. I should have cut the text down without this excuse (more text, less read):

new mockp for email verification showing a field for entering the verification code


I still need to write up the error cases here – what happens if the verification code gets rejected by NickServ or if it’s too long, has invalid characters, etc.

Handling edge cases

(Relevant ticket: https://pagure.io/fedora-hubs/issue/318)

Both in Twitter comments and IRC messages you sent me after I blogged the first design, I realized I needed to gather some data about the nickname registration process on Freenode. (Thank you!) I was super concerned about the fragility of the approach of slapping a UI on top of a process we don’t own or control. For example, the email verification email freenode sends that a user must act on within 24 hours to keep their nick – we can’t re-send that mail, so how do we handle this in a way that doesn’t break?

Even though I was a little intimidated (I forget that freenode isn’t like EFnet,) I popped into the #freenode admin channel and asked a bunch of questions to clear things up. The admins are super-helpful and nice, and they cleared everything up. I learned a few things:

  • A user is considered active or not based on the amount of time that has passed since they have been authenticated / identified with freenode NickServ.
  • After the user initially registers with NickServ, they are sent an email from “freenode Account Registration” <noreply.support@freenode.net> with a message that contains a verification code they need to send to NickServ to verify their email address.
  • If you don’t receive the email from freenode, you can drop the nick, take it again and try again with another email address.
  • While there is no formal freenode privacy policy for the email address collection, they confirmed they are only used for password recovery purposes and are not transmitted to third parties for any purpose.
  • If a nickname hasn’t been actively identified with NickServ for 10 weeks, it is considered “expired.” Identifying to NickServ with that nick and password will still work indefinitely until either the DB is purged (a regular maintenance task) or if another user requested the nick and took it over:
    • The DB purges don’t happen right away, so an expired nick won’t be removed on day 1 of week 11, but it’s vulnerable to purge from that point forward. Purges happen a couple times a year or so.
    • If another user wants to take over an expired nick that has not been purged, they can message an admin to have the nick freed for them to claim.

This was mostly good news, because being identified to NickServ means you’re active. Since we have an IRC bouncer (ircb) under the covers keeping users identified, the likelihood of their sitting around inactive for 10 weeks is far less. The possibility that they actually lose their nick is limited to an opportunist requesting it and taking it over or bad timing with a DB purge. This is a mercifully narrow case.

So here’s the edge cases we have to worry about from this:

Lost nickname

These cases result in the user needing to register a new nickname.

  • User hasn’t logged into Hubs for > 10 weeks, and circumstances (netsplit?) kept them from being identified. Their nick was taken by another user.
  • User didn’t verify email address, and their nick was taken by another user.

Need to re-register nickname

These cases result in the user needing to re-register their nickname.

  • User hasn’t logged into Hubs for > 10 weeks, circumstances kept them from being identified. Their nick was purged from the DB but is still available.
  • User didn’t verify email address, and their nick was purged from DB but is still available.

Handling lost nicks

If we can’t authenticate the user and their nickname, we’ll disable chat hubs-wide. IRC widgets on hubs will appear like so, to prompt the user to re-register:

IRC widget with re-register nag

If the user happens to visit the user settings panel, they’ll also see a prompt to re-register with the IRC feature disabled:

mockup of the user settings panel showing irc disabled with a nag to re-register nickname

Re-registration process

The registration process should appear the same as in the initial user registration flow, with a message at the top indicating which state the user is in (if their nick was db purged and is now available, let them know so they can re-register the same nick; if someone else grabbed it, let them know so they know to make a new one.) Here’s what this will look like:

nickname registration screen with a message showing the expired nickname is still available


The cases I forgot

What if the user already had a registered nickname before Hubs?  (This will be the vast majority of Hubs users when we launch!) I kind of thought about this, and assumed we’d slurp the user’s nickname in from FAS and prompt them for their password at some point, and forgot about it until Sayan mentioned it in our meeting this morning. There’s two cases here, actually:

  • User has a nickname registered with Nickserv already that they’ve provided to FAS. We need to provide them a way to enter in their password so we can authenticate them using Hubs.
  • User has a nickname registered with Nickserv already that is not in FAS. We need to let them provide their nickname/password so we can authenticate them.

I haven’t mocked this up yet. Next time! 🙂

Initial set of mockups for this.

Feedback Welcome!

So there you have it in today’s installation of Hubs’ IRC feature – a pretty major iteration on a design based on feedback, some research into how freenode handles registration, some mistakes (not verifying the email registration process first-hand, forgetting some cases), and additional mockups.

Keep the feedback coming – as you can see here, it’s super-helpful and gets applied directly to the design. 🙂

Social Media and photo sharing platform survey

Posted by Suzanne Hillman (Outreachy) on February 08, 2017 09:14 PM

Hey, you remember how I said I was working on a survey to figure out what social media and photo sharing platforms to integrate with Hubs?

It’s finally ready for people to fill out!

So. If you use Fedora, anywhere in the world, please fill out my survey! This will help us prioritize the platforms to integrate with Hubs. Thank you so much!


Please, spread the word! The more responses, the better, and as many different places around the world as possible.

The CSS is getting closer.

Posted by Suzanne Hillman (Outreachy) on February 07, 2017 10:15 PM

I’ve been working more with the Mockup-to-CSS project, and I’m certainly closer.

For one thing, the progress bars are divs, which don’t really like going into tables nicely. However, with much investigation (and playing with the code using CodePen), I found an explanation of the problem. Took me a little while to figure out how to adjust the code appropriately, but I did succeed on that point.

The next bit of complication was deciding the best way to handle the “view all team badges” link, in terms of placement. I ended up deciding to have blank space for the first half of the space, and the view link in the second half of the space. In other words:

<div class=”row”>
<div class=”col-xs-6">
<div class=”col-xs-6">
<p class=”viewall”><span class=”callout”><a href=#”>View All Team Badges></a></span>

And yes, the links are all invisible. I’m ignoring that for now, because it was true for the stuff that Mo did, as well.

<figure></figure><figure><figcaption>Left, Mockup. Right, web screenshot. Closer!</figcaption></figure>

I need lines between some, but not all of the rows in the table. I was already starting to think that I should just drop tables and do it all in divs, because it got messy. Mo confirms this need, so that’s next to play with.

I also still need to figure out the excessive space between the badge images and the text, make the badges in the design mission area smaller so they fit on a row, make the trophy icon larger, and make “of 15 team members” stay where it belongs.

But! This is much closer than my last attempt. Codepen helped a _lot_ with being overwhelmed, since I could see immediate changes. Not all the relevant CSS was there, but it was good enough for investigation purposes.

Refugee Hope Box

Posted by Máirín Duffy on February 07, 2017 07:55 PM

I’m not sure that I’ve ever posted anything non-Fedora / Linux / tech in this blog since I started it over 10 years ago.

My daughter’s school is running a refugee hope box drive. The boxes are packed full of toiletries and other supplies for refugee children. We will drop our box off at school and it will get shipped to the Operation Refugee Child program, where its contents will be packed into a backpack and delivered to a child in the refugee camps. We decided to pack a box for a teenage girl. It includes everything from personal toiletries, to non-perishable snacks, to some fun things like gel pens, markers, a journal, and Lip Smackers.

We explained to our daughter that there are kids like her who got kicked out of their home by bad guys (“Like the Joker?” she asked. Yep, bad guys like him.) There’s one girl we are going to try to help – since she is far away from home and has almost nothing, we are going to help by sending some supplies for her. My daughter loved the idea and was really into it. We spent most of our Saturday this past weekend getting supplies out and about with the kids, until the kids kind of melted down (nap, shopping cart fatigue, etc.) and we had to head back home.

We were so close to being finished but needed a few more items to finish it up, so I set up an Amazon wishlist for the items remaining and posted it to Twitter. I figured other folks might want to go in on it with us and help, and I could always pick up anything else remaining later this week.

It seriously took 22 minutes to get all of the items left to order purchased. I’m totally floored by everyone’s generosity. Our community is awesome. Thank you.

If you would like to help, you can start your own box or buy an item off of the central organization’s Amazon wishlist.

CSS Part two

Posted by Suzanne Hillman (Outreachy) on February 06, 2017 05:47 PM

This post is a continuation of my CSS journey. In this one, we finish identifying what we do and do not know about team badges, make note of aspects of the mockup that are confusing, Mo explains our use of Bootstrap for responsive design and her best practices in mockup-to-CSS tasks, and I take a shot at writing some CSS.


Our goal is to get me practice with using CSS by translating the Inkscape mockup in ticket #17 into CSS.


Last time, we got me set up with a clone of the relevant pagure developer repository, learned more about the syntax and structure of the HTML, PY, and CSS files, and explored the content of the sample JSON infomation.


We reviewed what we had learned the previous session, and identified necessary information that we did not yet have access to, including:

  • information about non-series badges for a team
  • the most recent badge earner
  • the most recently earned badge earned by the most recent badge earner.
  • the number of badges ranking of a particular user compared to the rest of the team

We had reason to believe that information about the non-series badges for a team would be enough to allow us to identify the most recent team badge a user earned. However, that is another requirement for the mockup that was not yet available.

We also identified some confusing aspects of the mockup as it is:

  • The number of team badges listed should also show the number that user has, so they know how many remain to get
  • “Open and non-mission badges” needs to be rephrased. It almost certainly is supposed to refer to badges that are not part of a series that the user does not yet have.
  • “Team Badge Rank” is unclear, and should be something like “Your Team Badge Rank” to be clearer.

Into the code

To start, Mo suggested creating the CSS/HTML such that it is hard-coded to reflect the mockup. Once it looks right, we can add in appropriate calls to actual data.

She reminded me of the ticket for individual badge mockup that she’d already done the CSS/HTML for.


Mo also explained more about Bootstrap to me. I’d heard of it, but had very little knowledge of it. Hubs is using the responsive aspect of Bootstrap (see the Responsive Breakpoints section), which is also explained here, specifically the row and col classes. The col class includes pieces which are specific to each device size (xs, sm, md, lg, xl), with xs being the default if nothing is specified.

Each piece of the page (in our case, our widget) is split into 12 columns, such that one can determine how much of the space available to that piece any individual component will take up. This is very useful when doing responsive design, since you want to be able to say approximately how the page behaves when page sizes change.

To get an understanding of this, we used Mo’s individual badge widget code with the Developer Tools->Responsive Design Mode in Firefox. This meant that I could see what was happening when we changed screen sizes. For example, when we started moving down from the largest size screen my monitor could handle, at around 988 width the description of a badge went from next to it to below it.

The relevant code says that the badge should take up 4 columns at large size, 12 at medium, and 2 at small:

<figure><figcaption>Large size, badge 4/12 and text 8/12 of the space</figcaption></figure>
<div class=”col-lg-4 col-md-12 col-sm-2">

The description of the badge should take up the remaining 8 (of 12) columns at large size, all 12 (an entire column, thus forcing it below the previous piece) at medium, and the remaining 10 at small.

<figure><figcaption>Medium size, badge and text both 12/12 of the space</figcaption></figure>
<div class=”col-lg-8 col-md-12 col-sm-10">

What would Mo do?

After explaining bootstrap and responsive design, Mo explained that she usually codes the laptop/desktop-sized version, first, and then plays with the responsive design mode in Firefox to see what needs adjustment in other modes (according to the code we found, in Hubs, those breakpoints are lg = 1200, md = 992, sm = 768, xs = 544). She also noted that Bootstrap will apply smaller sized col attributes to larger ones, such that if you have a xs version, that will apply to everything larger that isn’t specified. But, if you only have xl, the smaller sizes will probably break.

She described the ‘row’ classes as being hard line breaks, with the col settings allowing different line breaks for different size screen based on how much of the width of 12 any particular piece uses.

She also mentioned that she tries to avoid overusing classes, and usually uses the ones in bootstrap (col, row), and descriptive classes. The latter includes things which you might want to reuse, like color codes to be consistent across Fedora, badge styles, or the style of the detail that goes with a badge.

Similarly, she mentioned the need to use header tags rather than “<strong>” or specifying text sizes, so that people using screen-readers can more easily skim the document and get where they want to go. I already know a bit about accessibility (a11y), but a reminder is always good.

My turn to try

At this point, I started changing the code in our shared etherpad, as I wanted her eyes on what I was doing. I’m sure that it’ll be a little easier in an actual IDE, but harder for her to see what I was doing.

One thing that I had trouble with is actually hard-coding things. For example, the missions in the team badge widget look like they should be expandable:

<figure><figcaption>This looks like you should be able to expand it!</figcaption></figure>

However, at least initially, I was to be trying to hard-code everything, including the expansion-appearance. This was possibly more confusing than it might otherwise have been, since the code I was editing from (the individual badges widget) actually had expansion capability because there were two separate mockups.

I also needed to figure out how to make progress bars. Mo found some in bootstrap, which were easy enough to use. She found the relevant CSS that actually made them display the bars in the upstream Bootstrap code, as it was missing from our version of it. Unfortunately, and I haven’t yet figured out why, they don’t seem to want to be where I thought I put them in the code. Neither do the badges:

<figure></figure><figure><figcaption>Mockup vs current CSS — Still learning!</figcaption></figure>

It’s a decent start, but I definitely found it much too easy to get lost in the details and forget what I was trying to do and why. I’m very glad that I had code to change, rather than needing to create new code, however. I also still need to add the percentages at the end of the incomplete progress bars, and the trophy icon in green to the complete one.

And the spacing is weird between the badges and their details, I’m missing the link to ‘view all badges’ (Actually… all of the user’s badges? All of the team badges?), and the mission titles need a different look.

Still, though. I have started, and I can and will certainly play with this more. Still not a huge fan of writing code, and I wonder how much of this is how distracted I get by all the details. Getting lost in excess information is a known difficulty for me, which is why I try so hard to make my surroundings organized.

Helping new users get on IRC

Posted by Máirín Duffy on January 31, 2017 11:04 PM

Fedora Hubs

Hubs and Chat Integration Basics

Hubs uses Freenode IRC for its chat feature. I talked quite a bit about the basics of how we think this could work (see “Fedora Hubs and Meetbot: A Recursive Tale” for all of the details.)

One case that we have to account for is users who are new Fedora contributors who don’t already have an IRC nick or even experience with IRC. A tricky thing is that we have to get them identified with NickServ, and continue to identify them with Nickserv seamlessly and automatically, after netsplits and other events that would cause them to lose their authentication to Nickserv, without their needing to be necessarily aware that the identification process was going on. Nickserv auth is kind of an implementation detail of IRC that I don’t think users, particularly those new to and unfamiliar with IRC, need to be concerned with.


“Nickserv? What’s Nickserv?” you ask. Well. Different IRC networks have a nickserv or something similar to it.

On IRC, people chat using the same nickname and come to be known by their nickname. For example, I’ve been mizmo on freenode IRC for well over a decade and am known by that name, similarly to how people know me by my email address or phone number. IRC is from the old and trusting days of the internet, however, so there’s nothing in IRC to guarantee that I could keep the nick mizmo if I logged out and someone else logged in using ‘mizmo’ as their nickname! In fact, this is/was a common way to attack or annoy people in IRC – steal their nick.

In comes Nickserv to save the day – it’s a bot of sorts that Freenode runs on its IRC network that registers nicknames and provides an authentication system to password protect those names. Someone can still take your nick if you’re offline, but if you’ve registered it, you can use your password and Nickserv to knock them off so you can reclaim your nick.

Yes, IRC definitely has a kind of a weird and rather quaint authentication system. Our challenge is getting people through it to be able to participate without having to worry about it!

Configuration Questions

“Well, wait,” you ask. “If they aren’t even aware of it, how do they set their nickserv password? What if they want to ‘graduate’ to a non-hubs IRC client and need their nickserv password? What is they want to change their password?”

I considered having Hubs silently auto-generate a nickserv password and managing that on its own, potentially with a way of viewing / changing this password in user settings. I opted to provide a way to create their own password, ultimately deciding that silently generating it, they wouldn’t be aware it existed, and may end up confused if they tried a different client and might post their FAS password over non-SSL plaintext IRC…

(Some other config we should allow eventually that we’ve discussed in the weekly hubs meetings – allowing users to use a different IRC bouncer than Hubs’ for IRC, and offering the connection details for our bouncer so they could use Hubs as a client as well as a third party client without issue.)

The Mockups

So here is an attempt to mock up the workflow of setting up IRC for a Hubs user who has never used IRC before, either on Hubs or ever. Note these do not address the case of someone new to Hubs who hasn’t enabled the RC feature but who does have a registered nick already that they have not entered into FAS – these will need modification to address that case. (Namely a link on the first screen to fill out their Nickserv auth details in settings.)

Widget in Context

This is what the as-of-yet unactivated IRC widget would look like for a user in context. The user is visiting a team hub, and the admin of that hub configured an IRC widget to be present by default for that hub. To join the chat, the user needs to enable IRC as a feature for their account on hubs so the widget offers to do that for them.

mockup of a fedora hubs screen showing a widget on the right hand side for enabling IRC chat

Chatter thumbnails

The top of the widget has a section that has small thumbnails of the avatars of people currently in the room (my thought is in order of who spoke most recently) with a headcount for the total number of people in the room. The main idea behind this is to try to encourage people to join the conversation – maybe they will see a friend’s avatar and feel like the room could be more approachable, maybe we tap into some primal FOMO (Fear Of Missing Out) by alluding to the activity that is happening without revealing it.

Call to action

Next we have a direct call to action, “Enable chat in Hubs to chat with other people in this hub” with an action-oriented button label, “Enable Hubs Chat.” This, I hope, clearly lets the user know what would happen if they clicked the button.

Hiding control

At the bottom, a small link: “Hide this notification.” Sometimes ‘upsell’ nags can be irritating if you have no intention of participating. If someone is sure they do not want to enable IRC in Hubs (perhaps they just want to use their own client and not bother with Hubs for this,) this will let them hide it and will ‘roll up’ the IRC widget to take up less space.

Here’s a close-up of the widget:

closeup of the IRC activation widget

Registration Wizard

So once you’ve decided to enable IRC in Hubs, then what?

Since selecting and registering a nick I think needs to be a multi-step process (in part because Freenode makes it one), I thought a wizard might be the best approach so this is how I mocked it up. A rough outline of the wizard steps is as follows:

  • Figure out a nickname you want to use and make sure it’s available
  • Provide email address and password for registration
  • Register nickname
  • Verify email

Choosing a nickname

This is a little weird, because of how IRC works. Let me explain how I would like it to work, and how I think it probably will end up working because of how IRC & nickserv work.

I would like to present the user with a bunch of options to pick from for their nickname. I want to do this because I think coming up with a clever nickname involves a high cognitive load they may not be up for, and at the very least offering suggestions could be good brain food for them making up their own (we offer a way to do that on the bottom of this screen, as well.)

Ideally, you wouldn’t offer something to someone and then tell them it’s not available. Unfortunately, I don’t think there’s an easy way to check whether or not a suggested nick is available without actually trying to use it on Freenode and seeing if you’re able to use it or if Nickserv scolds you for trying to use someone else’s registered nick. I don’t know if it’s possible to check nick availability in a less expensive way? These designs are based on the assumption that this is the only way to check nick availability:

mockup: irc nick selection

The model here is that we’d use some heuristics based on your name and FAS username to suggest potential nick, with a freeform option if you have one in mind. If you click on a name, we then check it for availability, displaying a spinner and a short message while we check. This way, we only check the nicks that you’re actually interested in and not waste cycles on nicks you have no interest in.

If a nick is available, it turns green and we display a “Register” button. If not, a message to let them know it’s not available:

IRC nick availability mockup

Once it’s finished checking on all of the nicks, it might look like this:

IRC nick availability mockup - all lookups complete

Provide email and password for registration

Freenode Nickserv registration requires providing an email address and a password. This screen is where we collect that.

We offer to submit their FAS account email address, but also allow them to freeform the email address they’d prefer to be assocaited with Freenode. We provide the rationale for why the email address is needed (account recovery) and should probably refer to Freenode’s privacy policy if it has one for their usage. There’s also fields for setting the password.

Verify Email Address

This is the most fragile component of this workflow. Freenode will allow you to keep a registration for 24 hours; if you do not confirm your email address in that time, you will lose your registration. Rather than explain all of this, we just ask that users check their email (supplying them the address the gave us so they know which account to check) and verify the email address using the link provided.

Problem: We don’t control these emails, freenode does. What if the user doesn’t receive the verification email? We can’t resend the email because we didn’t send it in the first place. No easy answer here. We might need some language to talk about checking your spam folder, and how long it might take (it seems to be pretty quick in testing.) We could let them go ahead and start chatting while they wait for the email, but what would we do if it never gets verified and they lose the registration? Messy. But here’s the mockup:

Screen for user to confirm email address for freenode registration


This is just a screen to let them know they’re all set. After clicking through this screen, they should be logged into the IRC channel for the hub they initiated the registration flow from.

IRC registration finish screen


This is a first-cut at mocking up this particular flow. I’m actively working on other ones (including post-set up configuration, and turning IRC on/off on individual hubs which is the same as joining or leaving a channel.) If you have any ideas for solving some of the issues I brought up or any feedback at all, I’d love to hear it!

CSS and mockups

Posted by Suzanne Hillman (Outreachy) on January 31, 2017 07:37 PM

I want to get a better feel for CSS, so Máirín Duffy (Mo) and I spent three hours last week figuring out how to moving a pixel perfect mockup to CSS. This was made up almost entirely of background stuff, but we got a lot of useful information in the process. We will continue working on this sometime this week.

Git and Pagure

The first hour or so was spent fighting with git and making me a fork of a fork of the main repo.

In short, I had to:

  1. make sure my SSH key was in pagure,
  2. tell local git about the fork using “git remote add -f sayan ssh://git@pagure.io/forks/sayanchowdhury/fedora-hubs.git”,
  3. grab the fork with “git checkout badge-path-support”,
  4. use the webui for pagure to tell it to create me a fork, and
  5. finally “git remote add -f wispfox ssh://git@pagure.io/forks/wispfox/fedora-hubs.git” to push my fork.

There were many other complicated aspects that I will figure out later.

What are we trying to do?

She gave links to the ticket we were planning to work on (https://pagure.io/fedora-hubs/issue/17), and pointed me at the specific mockup we were going to try translating (the team badge widget):


She also pointed me at one she had already done (the individual badge widget, https://pagure.io/fedora-hubs/issue/85):


Mo pointed me to the HTML that she’d done for this widget, and pointed me to where that HTML was injected into other HTML.

Exploration and Explanation

Mo explained that hubs is built with python, using a platform called flask, which uses a templating system called jinga. As a result, the templates in question are written in jinga.

The entire site is written in fragments which are then combined together appropriately to create the page. She then mentioned that in flask, each widget has a .py file, and a corresponding template in HTML, and CSS pulled from the main CSS file.

We started looking for the team badges (badgespath.py) file so that we could start working, and figured out that it was actually in a developer fork. Once that was done, she suggested I use the IDE geany to open the py file and the badgespath.html file. She opened an etherpad and pasted what she had in her html file into it, as she’d already started working on this task.

To see what was going on with what she’d been playing with, I saved her changes to the file, and started a local Hubs instance. I logged into it, and added the team badges widget to my profile page (since I didn’t have permissions to the design hub). This resulted in a great deal of messy-looking output, which Mo explained was JSON output. After a brief divergence to explain what that was and fight with IRC, she explained the code she’d had me paste into the file.

Because we can have multiple of the same widgets in a page, she uses “class” instead of “ID” to label each widget in CSS. Then there’s jinga logic, which is python syntax surrounded by {% %}. The badge and series_info variables were referring to things defined in the badgespath.py file.

She then explained the py file contents, including that import and from relate to libraries, argument says what information the widget requires from the user, def defines a function (in this case, one called data which takes in session, widget, and username as arguments). The function data had a username and team_id hardcoded for testing purposes; the team_id will be found by looking at which hub the widget is being added to in the real code, no need to ask the user for that information.

The data function is grabbing a bunch of JSON info, and splitting it into useful pieces, including badges_count and series_info. This information is then stored in a dict, returned, and available to anything requests it; in this case, our original badgespath.html file.

What Mo was trying to do in the html file was get a sense of the JSON info. So she added some debugging info (commenting out the stuff in the for loop, adding labels to badges count, series info, and badges), and we restarted the server to see what we got. We then tried taking a look at the JSON output in a JSON parser, and found out from a developer in channel that our output was in need of running through a dictionary.

After a great deal of investigation and confusion and talking to the developer who made the fork, it turned out that the JSON information we were getting was a local file because the information we needed about teams badges per user was not in the production environment.

What we learned

As a result of this session, we learned that:

  • The series_info file contains information about badges that are in series’ for a particular team.
For example, a series in the infrastructure team has a badge for having a FAS account for a year, having one for two years, having one for three years, having one for five, for seven, and finally for ten.
  • “is_awarded” in the series_info data identifies the badges a particular user has in that series,
  • badges_count is the total number of series badges for that team (but it doesn’t yet tell us how many non-series badges that team has), and
  • ‘series badges’ is a set of badges that are related to Missions in the mockup.

Sometimes it’s good to stop worrying about the world and just work on my internship

Posted by Suzanne Hillman (Outreachy) on January 31, 2017 07:15 PM

As I’m sure many of you know, living in the US is worrying right now. It’s been a bit difficult to focus on the internship as a result!

However, organizing my thoughts to describe what I’m currently working on and have been working on since my last post is always a good idea. Let’s get to it!

What Have I Been Doing?

A lot, as it turns out. It can be a little difficult keeping track of it all, which is clearly why I should be blogging more. Asana (a task list) to the rescue!

Lots of mockups

The first thing I did was actually part of what I did two posts ago: lots and lots of mockups. I’d had some experience creating mockups, which made this quicker than it might otherwise have been. I’d also attended the Inkscape Workshop last summer, which gave me some useful keystrokes and tips that made it quicker to use. Still, though, mockups are not fast. But, faster using Balsamiq than if I tried to do mockups using inkscape.

The affinity mapping and brainstorming post contained a bunch of initial mockups which I basically threw together to try to cover the things we came up with during brainstorming. Máirín Duffy (Mo) reviewed and commented on each of those, both in the ticket and sometimes in IRC, email, and other such places.

Each of the tickets in question has more detailed information: master list of Fedora people, master list of events, notifications, joining regional hubs.

Location information turned into an unexpectedly complicated problem as per my previous post, and spawned a new ticket to figure out how Hubs would suggest new regional hubs.

I also created a number of tickets that I do not expect to be able to get to during this internship, but which were clearly necessary to keep in mind around this project: public-facing pages, event creation (for which I am trying to brainstorm some general thoughts on fields from my interview notes), bringing people back to hubs, master list of regional hubs.

Restructure of schedule

Around halfway through the internship, I began to wonder if we’d be able to get through the entire set of tasks we had put into the preliminary schedule. As a result, I asked Mo if we could talk about the schedule and how feasible it actually was. I was feeling a little behind, and was having trouble determining if in fact we had been too optimistic, or if I was simply not getting enough done.

As a result of this discussion, we identified tasks that we definitely wanted to get done by the end of the internship. We also listed some that I’d like to at least touch on. We retained the major goals of: prototype usability testing, feasibility discussion with the lead developer, analysis of the usability testing and feasibility discussion, and an overall summary of what was found through these. In addition, we decided to do some work to give me experience with visual design and CSS.

Mockup Feasibility

I scheduled time to talk with the lead developer over IRC, having sent him links to the tickets with mockup that I wanted to discuss. As is apparently the norm for me, I was very nervous about this discussion. I blame impostor syndrome, as everyone in Fedora Hubs has been very welcoming and approachable.

For the most part, his response to the mockups was that they were feasible. There were a couple of instances where more research was needed.

In one case, he wanted to do make sure that he could show who was online in a lightweight and reasonable fast way, given that one could change the search or the map dynamically.


In another, he needed to figure out how to dynamically do searches/filters that listed only people (or events) within x miles/km of a person or location.


As with the locations information discussion with Mo, talking about the locations mockup with our lead developer turned out to be a bigger thing than I was expecting. Indeed, I created a new ticket (as mentioned in the mockups section) to remind us that we needed to figure out how Hubs would handle suggesting new regional hubs. That conversation still needs to happen, and I’m not completely sure that it will before my internship is done. However, without that ability, regional hubs will become much less useful.

My takeaway so far is that location stuff is really hard. Which, had I thought about it, would have made a lot of sense! I just somehow… didn’t consider it in great detail. This would be why UX isn’t done in a vacuum!

Social Media and Photo sharing

We are hoping to identify which social media and photo sharing platforms Fedora members use to discuss Fedora and Fedora events. This information would allow the prioritization of plugins to pull info from and maybe push info to various types of social media and photo sharing platforms.

If we can do this, it would make it a lot easier to keep information about an event in one place, whether because attendees want to share with each other, or because organizers need to create event reports. As below, having the option to have the media in one place would be really useful.


I am nearly finished with a survey about social media and photo sharing platforms that I intend to post to this blog and ask people within Fedora to share widely. The more information we have, the more easily we can identify the key platforms to incorporate. My initial interviews suggest that location will affect which platforms are in use, especially given countries in which the norm is phone use, not computer use. As such, having that survey spread around will help a great deal.


A very important part of the UX process is user feedback. Once I had a reasonable number of mockups that Mo had taken a look at and provided some initial feedback on, I needed to get those in front of some users.

I originally tried to get in touch with my first interviewees, but they were largely unresponsive. Instead, after discussing with Mo, we identified people who might be good candidates, and I got in touch with them. Three of the four I contacted have gotten back to me, and I did the first usability study last night. Went well, but given my lack of experience in doing usability testing, I was nervous. I need to go through the video and take notes, as I found it impossible to pay attention to my participant and take notes during the usability session.

I found it challenging to identify tasks for my mockups, so I listed out a general idea of what was possible for each. This was based on my experience in quality engineering, and I found myself too easily getting into irrelevant details. Annoying, but still a good way to start.

From that list, I created a basic list of possible tasks, and sent those to Mo for feedback. Unsurprisingly, most of my tasks were not concrete enough and were likely to confuse people. She made suggestions for the kinds of things she would have done. For example, instead of:

Task: You are new to the area, and hoping to find an event nearby to go to. Please use this prototype and explain to me what you will be doing while trying to find this event.

She suggested:

Task: You’ve just moved to the Los Angeles, California area. You’re hoping to find a Fedora event nearby to go to, to find new local Fedora friends. Please use this prototype…. (same text as orig)

These kinds of concrete examples made it much easier to finish creating tasks.

I found myself stuck identifying which tasks were higher priority than others. With a bit of prompting from Mo, I used the same box diagram thing that we’d used after our affinity mapping. I listed numbers of people affected on one axis, and how often people would run into the interface on another. This helped me organize the mockups themselves, and then the tasks, and made it much easier to see which were more important to get eyes on. I discussed my thoughts on this briefly with Mo again, who provided useful feedback.


While planning the task list, I was also considering how to do the prototyping remotely. Originally, to avoid bandwidth problems, we were considering trying to send prototypes to people and have them walk through it and talk to me through IRC. The more I thought about this, the more concerned I got. First, having to change between a prototype and IRC to communicate seemed very disruptive. Second, not being able to see what they were doing with the prototype seemed like a huge problem.

After additional discussion with Mo, she pointed out the existence of MyBalsamiq. I hadn’t really thought about the fact that there must be a web-based interface, and that it might support web-based prototyping. After some investigation, Mo got a free web license for Fedora, and I moved my relevant prototypes to that platform. Between MyBalsamiq’s prototyping methods and google hangouts, remote prototyping became much more plausible.

I will also get some in-person prototyping experience with people who are at Mo’s office, although I am still working on scheduling those people.

Visual Design

I do not have a lot of experience with visual design, and sometimes find it baffling. I suspect that having the Designing Interfaces by Tidwell book that Mo suggested will help with this, as well as with mockups.

To get me a feel for how it might work, Mo has converted one of my Balsamiq mockups to the existing visual design. I have not yet had a chance to take a look at this, but am hopeful it will help give me a better sense of how that might work. I will then try my hand at doing the same thing with a different mockup.

My initial forays into CSS will be in another post, simply because this post is long enough.

Locations are hard

Posted by Suzanne Hillman (Outreachy) on January 20, 2017 05:17 PM

Turns out that figuring out people’s locations is hard, especially if you want to try to reduce the amount of work someone has to do or if they are likely to be using a mobile phone.

For some reason, I’d thought that this was already a solved problem, so was somewhat surprised when feedback on a mockup made me question that assumption. After pinging Máirín Duffy to find out if we had access to a database of countries, and how they break down into cities/states/provinces/etc, she realized that we needed a longer discussion.

One thing she wondered was if we actually need street addresses. Given that the goal is to be help people find each other nearby, city was almost certainly sufficient for that purpose.

In many cases, especially on mobile, we would have access to GPS information. So, in that case, we can just show them where we think they are — with a map on which we overlay the city and country information and in which we will make sure that that information is appropriately accessible — and they can adjust as necessary.


On computers, we may have access to the information provided by the web browser, and from that we can similarly show them a map with their city and country information. In this case, we may end up being wildly inaccurate due to people using VPN connections.

In both mobile and computer cases, people may not want to share that level of detail. So, for this case, we would use their IP address information to guess, and display the same thing.


Finally, it is entirely possible that a connection error would prevent us from actually having location information. In that case, we would show a zoomed out map on a computer, with empty city and country fields. On mobile or if we cannot tell where they are, a blank map, with empty city and country fields.


In all cases, people can edit the country and city information to make it more accurate. The ‘city’ field will offer type-ahead suggestions which will include any division between city and country that is relevant. For example, if someone is detected as being in Buffalo, NY, but is actually in Boston, MA, we would offer then Boston, NY first, due to proximity, but also show Boston, MA. And anyone can continue typing to get more specificity, or select from a list of visible options. If, however, the country field is incorrect, they will need to change that before the city suggestions will be correct. As with the map location information, type-ahead suggestions need to be appropriately accessible to people who cannot use a mouse or cannot see the suggestions.

The problem with the type-ahead suggestions is that we still need access to a database which contains that information for each country. There are a couple of options, but that problem remains to be solved, and is a large part of making location information actually workable.

This was an unexpectedly complicated discussion, but I’m very glad we had it. For more information, please see issue #286.

Affinity Mapping and brainstorming

Posted by Suzanne Hillman (Outreachy) on January 10, 2017 09:15 PM

First, Affinity Mapping

On Tuesday Mo (Máirín Duffy) and I did affinity mapping using realtimeboard.com (this is a well-designed tool for remote whiteboarding), the end results of you can see here. We started with sticky notes each of which contained a problem I identified from my research.

We then started trying to sort the stickies into groups. I initially found it difficult to stop thinking in terms of the categories I had already been noticing during earlier analyses of the data. This is almost certainly why it’s useful to have other people to do this task with! Mo jumped right in and started moving things around. Once we had figured out any groups at all, things started falling into place and becoming easier to sort. She ended up labeling most of the groups, which probably makes sense given that this was my first time doing this task. We were not discussing our choices at this point, which I suspect is an important part of this task. Just do the sorting, and figure out what it means later!

Next, Prioritization

After we’d created our groups, making sure that no group was obviously absurdly larger than the others, our next goal was to prioritize those groups by severity and number of people affected.

During the prioritization, Mo and I were doing a lot of talking (which you can see in the log file I linked on the pagure issue). She first described our task, and then made a simple box chart into which to put the group names, with one axis being severity and the other being affected numbers of people.

We then discussed our feeling on how severe each group was, and how many people were affected. It was not necessarily obvious in the box chart, but there was some gradation within each category (we have ‘low’ and ‘high’ severity, and ‘many’ and ‘few’ people). Some things that were high severity were less high than others, for example.

At the end of this task, we determined that Budget Stuff and Local Resource Finding and Scalability were our priority for this release. We also decided that the next release should include Localization and User Onboarding, plus whatever came up between now and then.

Deep Dive/Brainstorming

On Wednesday, we took a close look at our two high priority groups for this release. The end goal here was to figure out what was actually possible to do, what the goals for those were, how success would be measured, and the specific tasks I would need to do to address those goals.

We took two hours to do brainstorming in the IRC channel, and Mo thought to turn on the meetbot logging tool (Summary is here, Chat log is here) shortly after we had decided that the budget stuff had too many unknowns for us to be tackling in this release.

While budgeting will not be a priority during this release, we intend to keep it in mind during the design process to offer some basic support. For example, events created through Hubs should provide fields in events for budgetary data like allocation, actual costs, and investment returns.

Local Resources

We then looked at the other prioritized group for this release: Visibility, scalability, and findability of local resources. Or, as Mo put it, it’s currently difficult to find or know about many Fedora resources, including people and events. This really seems to be the core of what hubs is about.

Getting our minds around this was a _huge_ task, and needed a lot of breaking down into smaller pieces. Happily, that group had existing sticky notes referring to the problems that I’d found in my research.

So, we started going through those notes, one by one.

Note 1:

“There are a lot of different places that have information about Fedora-related events. This can make it difficult to know if you can’t find any nearby because they don’t exist, or because you haven’t looked in the right place. This makes it difficult to prioritize event attendance. There are also many different places to find non-Fedora-related but relevant events, which makes it difficult to prioritize Fedora sponsorship.”

We discussed the need for making the system attractive, useful, and inviting so that people actually use it. Otherwise, it’d end up being yet another place data is scattered to.

We considered the idea of pulling in Fedora events from other places, to make it more canonical in the short term. Unfortunately, most of the event information is in blog posts and mailing lists and wiki pages. None of these are especially easy to scrape those events from. Given that hubs will integrate blog posts and mailing lists into its notifications, it is theoretically possible that we’d be able to scrape event information from those, and then suggest adding them to the Fedora event calendar. However, as this is not an easy task, we are not focusing on it right now.

Mo suggested that our goal for the local resources topic as a whole should be:

if someone is looking for fedora-related stuff local to them, they will log into hubs, do a search or browse, and find the info they are looking for in regional hubs

And that a measurement of success in this goal would be that regional hubs would provide a canonical list of local resources — people and events.

This suggests the need for a filterable, sortable master list of all regional hubs, members, and events.

Task: This means I need to make mockups of and tickets for the interfaces for the lists for hubs, members, and events.

The rest of the brainstorming session resulted in a clearer understanding of the interfaces for the members and events lists.

Note 2:

"It would be useful for us to tie Hubs into social media so that people can access the types of social media that is popular in their countries if they want to do so (not everyone uses IRC natively). Eg Twitter, facebook, telegram, Eventbrite, instagram"

We discussed the use of the feed widget to support this. We already plan to have it support blog posts and mailing lists, as stated earlier, and this would be a perfect place to include social media posts.

My task for this note is to compile a list of regions and their social media preferences. I will need to connect with my interviewees (and perhaps others?) to confirm my existing information on this topic and check if I’ve missed anything. After that point, I plan to create tickets for the integration of both reading from and posting to those social media outlets.

Note 3:

"Many ambassadors are local resources for their local Fedora community. It may be useful to make as many as possible of those resources easily available without having to go through an overworked ambassador."

We discussed the various ways in which the ambassadors that I spoke to acted as resources for their communities. We came up with a lot of ideas on how to handle the various types of resources that were relevant, as per the following:

  • A FAQ per each regional hub, where local ambassadors can list the questions and answers they get asked repeatedly and point to those to potentially save time and reduce burnout.
  • each regional hub could have a library widget with commonly asked-for resources (forms, design assets, etc)
  • a widget that points to release-specific assets of interest to regional folks (release party posters, media art, etc)
  • event widget that creates an event on fedocal and also gets added to the master events list to enable regional people to create local events
  • volunteer recruitment / sign up / tracking built into local events
  • work with commops to develop general best practices / training for regional ambassadors, and enable local organizers to fork their own version of those guidelines with local details
  • some kind of way to store a list of local external resources: local vendors + venues

This list of ideas never really got to a resolved state, possibly because this was a very large topic area. We may need to revisit this note and these ideas to come up with actual tasks.

Note 4:

It is difficult to find Fedora members who are in a specific location, especially if they are not ambassadors.

This was largely covered by the master list of people, but it did get us thinking in more detail about how that should work.

We need both a list view and a map view for this search, as identified during the discussion of Note 5 below.

We decided that the list should show everyone with a FAS (Fedora Account System) account, even if they have never logged into Hubs. However, if they’d never logged in, they should be near the end of results as it’s difficult to tell how active they are. We similarly concluded that we should put people who haven’t recently logged into Hubs near the end of the Fedora members master list. We also plan to include ways to visually differentiate between people who are actively involved in Hubs, people who haven’t logged in in a while, and people who never logged in.

Finally, from a conversation we had about note 5, we need to make sure that filtered results are very obviously filtered. That way no one gets distracted, comes back, and wonders why there are so few results.

The following is a quick mockup of what the master people list search page might look like:


The next part is a quick visual for what search might look like for that list.


See ticket #279 to follow along.

We agreed that part of making people be findable was have them be part of regional hubs. As such, we would suggest that they join local regional hubs, and that local regional hubs get suggestions to directly invite people who are nearby and not already members. This would need to be in the notifications area or a widget, rather than in the master list.

We would like to have a way to tell when a Fedora person isn’t active (is cobwebbed, if it were a website instead of a person).

This harkens back to an earlier conversation: there is no way to differentiate between ‘temporarily inactive’, ‘inactive but wants to know what’s going on’, ‘actively doing things in the Fedora community’, ‘interested in doing things in the Fedora community but needs guidance’, ‘no longer part of the Fedora community but available for questions’, and ‘I’m done, don’t contact me’. And right now, setting yourself to inactive in FAS has to be done manually. This currently means that there may be, and likely are, many accounts that are inactive but don’t show as such. **enter ticket?**

Note 5:

It is not easy to identify events by proximity to one’s self in time or space. This makes attendance, and prioritization, difficult.


For this, the master list of events should help. This note prompted us to look more at how the interface should act.

We thought that the list should start out by showing you 20 upcoming events that are nearest to you. You could then filter it by number, time, and location to adjust the range of what it shows you.

We need to make it _really obvious_ that it is filtered, so that people who don’t forget that it is filtered and wonder why there are so few results.

We agreed that it should show big events like FLOCKs and FUDCONs to anyone who is in the appropriate region. We also thought that those events should show up in the events list as soon as a bid has been accepted, even if there’s not much concrete detail yet. Given that many people travel long distances for those, we wanted to give as much forewarning as possible. We also decided that people in affected regions should get notifications as soon as those show up, and that people in other regions can set a flag to be notified as well.

We would also want to include past events in the search, since people might want to find out what happened (because they couldn’t go, because it was too large to see all of it, because they got there late or had to leave early, because they were curious). Relatedly, we should collate the blog posts, IRC convos, meetbot logs, video recordings, discussion about an event, photos (Task: find out where interviewees store photos), tweets. Maybe notify people who went or who were maybes with followup materials (polls, etc).

Events should allow you to say if you plan to go to an event (yes/no/maybe), and if you’d be interested in volunteering or organizing it.

To get around the problem where some people want to see things by proximity in time, and others in space, we thought we should include both a list/calendar view and a map view. We are not yet sure about the calendar view, since it can be really handy for a quick understanding of things, but only if it’s not too crowded. Perhaps a certain number of events in a certain time periods can be a calendar, and otherwise a list format.

First, the default view:


Then, the month view:


The list view:


Now, what happens when you do things? In the default view, it seems helpful to suggest possible areas to filter by, and not just have people use ranges from specific places.


And show stuff about an event if you hover over it (and then click it), default view:


Month view, event more than a week out:


Month view, event has passed (I’m struggling with this one!):


Finally, clicking on things in the list view (I have no idea if one needs to register for FLOCK, but I’m sure there’s _something_ that needs registering, so I included it):


See ticket #281 to follow along!


Since people often don’t know about events happening nearby, and may not think to (or want to) do a search, we thought we’d suggest events to people. First, we’d suggest events when they are coming up in their region if they haven’t already responded to them.

We’d also suggest events in team hubs when lots of people are going (“10 design team members are going to __”), and let people who are usually far apart know when they and their friends will be co-located due to an event (but perhaps not during large events, due to spam potential).

We thought it would be good to make it easy for people to suggest a meetup around an event when they are notified that their friends or teammates would be co-located at it.

We decided, based on note #6, that we should show notifications about local, global, and regional meetups to everyone based on their location data, in their main feed. Regional hub members will find out about meetups local to that hub as well, regardless of their location.

Mockups of these:


To follow along, see issue #282.

In creating this, I found out that I am entirely uncertain if we need to be pointing out that people will be co-located. If it’s FLOCK or FUDcon it might be useful, but might also be spammy. Otherwise, I feel like people would already know about being co-located because they’d have planned it that way (eg fedora activity days).

Note #6:

It is difficult to learn about local meetups, whether or not they are Fedora-specific, and identify if they are active. This can make Fedora outreach (hackfest/workshop, table/booth, speaking/presenting) difficult to do.

We need a ‘fedora-specific’ data-field for events, because some events are Linux-wide, or open source-wide, and some are fedora-specific. We expect that ambassadors are the ones most likely to put non-fedora events into Hubs, since they may be attending/sponsoring, and don’t expect there to be non-fedora events listed without ambassador presence.

“Meetups” are most easily defined as recurring events, so we need to allow events to be recurring. However, to avoid the problem of an event having no one showing up (or worse, someone new showing up alone), we need to make sure that a recurring event isn’t publicized outside the group until someone takes ownership of that instance. We also need a notification to remind the last instance’s organizer and the hub’s leadership that the next one needs an organizer.

If not enough other people will be attending, the owner should cancel that meeting. To enable this, we need a notification to remind the organizer a day or two before the event to check in and make a call if there are enough attendees, the weather will permit, etc. If an event is cancelled, people who are signed up need to be sent a message about it (and perhaps remove it from the event calendar?).

Guest presenters may not have accounts on Hubs, but will also need to be notified if the event is cancelled. Event creation should support putting in an email address for a guest presenter, so that they can be notified.

Mockup for this is pending; I wanted to get this blog post out!

Next Plans and Uncertainties

Immediate tasks

So, in summary, I need to create mockups for the master lists of people, events, and regional hubs. I need to contact my interviewees to confirm my understanding of the social media outlets that are used in their countries and regions. I also need to ask them where they typically store photos.

All mockups, both to be created and those I’ve been working on need tickets in pagure. This will allow both a place for people to keep track of specific aspects of what I’m doing and for me to store the documents and links relating to each task and subtask.

Identify which bits of information need notifications, widgets, or both. Identify which should be on a hub, on a personal profile, or in someone’s stream.


There were some pieces of the brainstorming session which feel unfinished, and which may need revisiting later in this cycle:

We didn’t really delve into what filtering and searching in the regional hubs list should look like.

We didn’t decide on what to do with the problem relating to offloading some of the work from ambassadors who are a resource to their communities. See Note 3.

Post-Holiday Update

Posted by Suzanne Hillman (Outreachy) on January 03, 2017 03:54 PM

The past couple weeks were all crazy due to holidays, so I feel like I was less productive than I would have preferred to be. That said, I apparently did a fair bit!

I created the list of problems that I mentioned in my last post, and will be doing affinity mapping on them with Mo later this afternoon using https://realtimeboard.com/app/board/o9J_k0yF_VU=/. The main goals here will be to identify which problems we actually plan to solve, and prioritize those.

I also did a bunch of flowcharts, sketches, and Balsamiq mockups on a number of things that we are pretty sure that we’ll need even before we do the affinity mapping. At the moment, these include:

  • The ‘invitation’ page that the general public will be able to see for a regional hub. This will allow people the option of attending a meeting to decide if they want to join Hubs/FAS, talking to someone on the page itself before joining, and getting a general idea of the hub’s purpose.
  • The interface around locations. This will include accounts that already exist in FAS with and without location information, creating a new Hubs account, and updates to the location information both manual and prompted when their GPS suggests that they haven’t been where their location says for over 6 months. I’m not sure yet how we will handle making sure that we can access their GPS location, for the latter case.
  • The interface around joining a regional hub. I’m not yet sure how we should handle people whose location does not overlap a regional hub; I’m currently thinking that they should be able to subscribe, but not join. I’m also not sure how we want to differentiate subscription and join memberships, nor if we want have people who want to help out with a group be ‘join’ and people who just want to follow what’s going on be ‘subscribe’. Lots of uncertainty around this one!

Pending mockups/discussions, which may change after we do the affinity mapping:

  • How will people interact with regional hubs? This relates to the widgets that ought to be on a regional hub’s page, as well as what shows up on someone’s feed. It also relates to any email we might want to send people.
  • What will bring people back to Hubs? No one will use it if they don’t come back to it repeatedly.
  • What can we do to make one-offs (or at least rare) actions worth doing? Gameification? Like some websites (linkedin) which have a bar showing how complete your profile is. How do we avoid making encouragement to finish a thing polite and non-intrusive?

For more specifics, you can see my most recent update to the pagure issue on the user research and analysis ticket: https://pagure.io/fedora-hubs/issue/279

I did not include my sketches, as I largely used them to help myself think and they aren’t especially legible to people who aren’t me.

Until next time!

Initial analysis session

Posted by Suzanne Hillman (Outreachy) on December 20, 2016 12:30 AM

Last Thursday Mo Duffy and Matthew Miller and I did some initial analysis of the data I collected in my interviews.

I originally thought that we’d be doing some affinity mapping analysis, but that turned out to be less relevant with the data I brought. Instead, we discussed the patterns that I’d noticed in my interviews, most notably the difficulty of finding Fedora contributors and Fedora-related events in specific locations.


These patterns broke down into a number of pieces, whether it was about finding someone who might be interested in helping organize an event or a sponsorship, finding people who might want to attend an event, or identifying Fedora contributors who are still actively involved in the community.

Finding people, finding events

It can be quite difficult to find Fedora contributors who are interested in helping organize or potentially attend an event, or determining if the people who you have found are still active contributors. This is especially difficult if you are hoping to recruit contributors who are not ambassadors.

The problem with finding events was that it’s hard to tell if you’re failing to find anything because nothing exists, or because you haven’t yet found the right places to look. Somewhat tangential to Hubs, it can also be difficult to find out about events that aren’t specific to Fedora, but at which sponsorship, or having a presentation or workshop, might be good.

Too much information!

Less common, but still a definite problem, was the difficulty in finding information that others may already have found. There is no common place to keep information about venues, hotels, or swag vendors for future event planners to refer to. There is also no way to access information that previous event planners have learned through experience, such as general budget expectations for events such as FLOCK, or how much swag one might need to bring to an event.

Somewhat similar, in that it involves a great deal of information, is the problem of having too much information to easily keep track of. Depending on the complexity of an event, they minimally include a wiki page and email, IRC, or social media communication. Some of the more complicated events may also include documents, spreadsheets, and PDF files. It can be quite a lot of effort to keep track of all these disparate sources of information, even if any particular individual doesn’t find it taxing.


In addition to the general patterns I found among the interviews, Mo also suggested that I identify and describe the general workflows of the interviewees. There are two major categories into which the workflows fell: that of ambassadors and that of event planners.

Overall, ambassadors are typically doing two things: getting Fedora sponsorship into existing events, and acting as resources for the population they serve. The first requires the ability to find events for which Fedora sponsorship would be worthwhile and a great deal of organization, and the second typically involves a great deal of information to store and sort through.

Event planners all involve organizing a lot of information, including timing, costs, and locations. They often also include budgeting, travel, publicity, and topic selection.

What are the problems?

Now that the initial group analysis is complete, I am collating a list of problems that need solving so we can identify which are relevant to this project, and what the priorities are. That will be in my next post! For more information on the research I have done, see https://pagure.io/fedora-hubs/issue/279

The aforementioned pagure issue also includes the documents that I created for our analysis: summaries of the interviews, patterns and workflows, and a spreadsheet of the major points from each interview.

Until next time!

Fedora Design Interns Update

Posted by Máirín Duffy on December 08, 2016 08:15 PM

Fedora Design Team Logo

I wanted to give you an update on the status of the Fedora Design team’s interns. We currently have two interns on our team:

Flock 2016 Logo

Mary Shakshober – (IRC: mshakshober) Mary started her internship full time this summer and amongst other things designed the beautiful, Polish folk art-inspired Flock 2016 logo. She’s currently working limited hours as the school year is back in swing at UNH, but she is still working on design team tickets, including new Fedora booth material designs and a template for Fedora’s logic model.

Suzanne Hillman – (IRC: shillman) Suzanne just started her Outreachy internship with us two days ago. She has been working on UX design research for a new Fedora Hubs feature – Regional Hubs. She’s already had some interviews with Fedora folks who’ve been involved in organizing regional Fedora events, and we’ll be using an affinity mapping exercise along with Matthew Miller to analyze the data she’s collected.

If you see Mary or Suzanne around, please say hi! 🙂

Thanks! I will definitely keep you in mind.

Posted by Suzanne Hillman (Outreachy) on December 07, 2016 09:20 PM

Thanks! I will definitely keep you in mind. Also, I’m totally going to get back to you when it’s time to get feedback and suggestions on possible design directions. ;)

Analysis is confusing

Posted by Suzanne Hillman (Outreachy) on December 07, 2016 09:18 PM

I’ve often found myself stumped when confronted with a bunch of data, whether quantitative or qualitative. I might know what I was hoping to find out (but not always!), but that doesn’t always translate easily into knowing what I need to do with the information I’ve collected.

This seems like a fairly common problem, and yet I’ve struggled with it for as long as I’ve done research. So, at least officially, since sometime in 2008 or so, when I took my first research methods class before applying to psychology graduate schools.


Quantitative data at least seems like it should be more tractable than qualitative data. The first one’s a bunch of numbers, right? That seems like it should be easier to understand than a bunch of fuzzy words and descriptions and ideas. That being so, I’ve taken numerous psychological statistics classes. Indeed, I my mom has stories of me helping adult students in my mother’s stats class when I was 8. Math makes sense to me. Figuring out what to _do_, what’s relevant, what’s useful? Much less clear. This is often true, I find: knowing how to use the information I have can be a daunting task.

One of the things I find fascinating about UX is that this is known to be confusing and hard and also a really important aspect of what we _do_. Rather than trying to look for statistical significance, however, we’re looking for ideas and guidance and places that are obviously painful and places that are working well. Statistical significance is somewhat… irrelevant to the questions we are trying to answer. Not ‘how much’ or ‘how fast’, but ‘what is happening’ and ‘why’.

Statistics always felt like it was supposed to be a thing that could be done on one’s own. Like I should just know what the best approach is. This is likely not helped by the fact that I have trouble verbalizing math; it’s not at all the same language in my head, and translating is difficult. Having trouble verbalizing math makes it difficult to discuss it, and to consult with others to figure out the right sorts of statistical methods to use beyond the basic stuff that pretty much always has to happen. It’s not even just about which methods to use, but how to correctly interpret things. Statistics is a lot more fuzzy than practitioners like to admit to, at least in the psychological sciences. It’s all ‘is this significant _enough_’?, ‘is there enough of an effect for this to actually matter?’, ‘Have I gone down a rabbit hole and wasted all this effort?’. This is _not_ helped by the fact that non-significant results rarely get published.

Affinity Mapping?

I’ve known of affinity mapping, and even tried to use sticky notes to figure out some of my data in the first UX project I did. Unfortunately, as I found out at the time, analysis of the data I get in UX research doesn’t really lend itself to being done alone. Much like statistics, I suspect. I’m not at all sure how UX consultants do their analyses, given this!

Thankfully, I now have a mentor and an internship! When I flailed at Mo earlier today during our meeting, she suggested that I obtain Gamestorming as a useful reference book, and that we should go ahead and do some affinity mapping on my data. I need a bit more data first, but this means I finally get some of the guidance I’ve desperately been looking for.

I’ve been reading Gamestorming today, taking frequent breaks so I have time to let things settle in before I continue reading. I’ve also been reading a Paper Prototyping book that I got at the suggestion of another helpful person in the Boston area UX community, Jen McGinn. Given that I sort of guessed at paper prototyping for the same project in which I tried to analyse my data using sticky notes, this book should be helpful.

I’m really looking forward to getting a chance to do affinity mapping on this project. I think it’ll make a huge difference for my confidence!

Outreachy Starts Today!

Posted by Suzanne Hillman (Outreachy) on December 06, 2016 08:59 PM

This blog should now be showing up on various planets (Fedora, Outreachy, Fedora Design), which means I need to do an introduction.

Hi, I’m Suzanne. I’ve been working on getting myself into User Experience (UX) for about a year now, although I’ve been interested in smoothing the interface between people and technology for longer than that. Most recently, I spent a few years in a PhD program working with robots and investigating the kind of gestures that robots will most need to understand when conversing with people. When that turned out to not be a good program for me, I figured out that UX was the most interesting and relevant path forward.

My outreachy project is the UX of Fedora hubs, specifically that of regional hubs [1]. I’ve been working on it for a few months now with my mentor Mo Duffy. I’ve already done the competitive analysis, done initial research planning, and started interviewing Fedora ambassadors and community members. Some interviews remain, and I continue to try to schedule with and get in touch with the remaining 4 people.

I’m hoping to get those last few interviews done in the next two weeks, to stay on track for the original plan provided in the application. We shall see, since I’m having trouble getting replies back to my emails.

I’ve looked for patterns in the existing interviews, and there are definitely some emerging. I’d definitely prefer more interviews before I do much with those results, though. Three interviews isn’t really very much.

This seems like a decent introduction for now. Until later!

[1] https://pagure.io/fedora-hubs/issue/47

Initial research has started

Posted by Suzanne Hillman (Outreachy) on December 02, 2016 09:12 PM

As I mentioned in my last post, I did a pilot test of both the research script and figuring out how to get google to allow for the recording of someone’s screenshot and speech.

Some investigation and suggestions from Mo resulted in checking out Google Hangouts On Air and its interaction with Youtube’s live streaming of events. We tried it out, and after some slightly confusing set up which we modified to have our events be private to me (since I didn’t want other people to see my interviews), it worked perfectly.

Pilot Testing

The pilot of the script itself showed a glaring assumption that I had made while writing the script. Given that the point of the pilot was to find precisely these kinds of things before I interviewed people who weren’t Mo, that was a success. It was a little frustrating in the middle of things to run into it, but given that it’s basically impossible to get anything right the first time, wasn’t too bad. I had assumed that everyone that I spoke to would be planning local events, which is most certainly not always the case. I had also forgotten to be sure to include the things that they had talked about in the initial conversation when it came time for them to share their screen and show me specifics.

I found it amazingly difficult to take notes while doing the pilot test. I’m not sure how much of that is how rapidly Mo talks, and how much was unfamiliarity which the pilot test was meant to help with. Regardless, I didn’t take nearly as many notes during that first interview as I was hoping, and ended up having to go back through the entire interview to write down important points and make comments to myself. I decided to highlight those comments in color-coded ways to make it clear the kind of comment it was: a pain, a followup question, or a note for myself when it came time to use the information.

Later Interviews

The second and third interviews that I’ve done thus far were much easier to take notes during. I will probably still go review the recordings for things that I missed the first time through, but it’s much less vital than it was with the pilot.

Unfortunately, the second interview ended up having to be postponed a day because google on air was refusing to talk with youtube. Or possibly be on air. It really wasn’t clear. I hadn’t set up any sort of backup option at that point, either. Thankfully, the interviewee had an open schedule around Thanksgiving and could easily reschedule.

Mo has since set up a backup recording option through Red Hat’s Bluejeans tool, which I’ve not needed to use yet. Backup options are important, however!

I’ve not yet heard back from two of the people I asked about interviewing, and will followup with Mo about who else to use shortly. Two others were potentially interested, but I haven’t yet been able to schedule interviews with them. Indeed, one of them sort of vanished on me. As always, getting people’s time can be complicated!


I’m not entirely clear, yet, what I should be doing with my analyses of these interviews. I suspect that as I do more interviews, I shall gain a better sense of the patterns among the people I talk to.

At the moment, people want somewhere to easily store, search, and access information. This includes documents, graphics, and information about vendors of swag or about hotels or venues at the minimum.

They also seem to want a way to find people who might be interested in an event or in Fedora or open source in general. This seems to break down into fellow ambassadors and Fedora community members (or potential members) who are nearby, and local groups at which people who are involved with Fedora might give talks (linux user groups, for example).

The two previous ideas may benefit from including information about people who have sponsored or been sponsored by Fedora. There should also be a way to indicate how up-to-date the information is.

It’d be good if it were easier to find and learn about events nearby, perhaps using a calendar format.

Another thing I noticed during my interviews is the potential need to restrict topics. For example, avoiding political discussion in places where that may risk one’s well-being. I don’t know what precisely this would need to involve, yet, but it seems important.

Going forward

Outreachy officially starts on Tuesday. I will then be attending the weekly fedora-hubs meeting, and having a check-in meeting with Mo every other week.

I need to get more of the interviewees to get back to me about scheduling or find someone else to include.

I’ll be blogging here at least every two weeks starting Tuesday. I’m not entirely clear on what sort of introductory post to write, given I’ve been talking about this project for months now!

Scribus in copr scribus-unstable repository now supports spellcheck

Posted by Luya Tshimbalanga on December 01, 2016 09:58 PM
Scribus 1.5.3svn snasphot with spellcheck running on Gnome Shell 3.22 Wayland

Starting from 1.5.3-0.19 snapshot, Scribus now has spell check enabled, one of requested features for free and open source desktop publishing software. Additionally, this version includes appstream by default allowing visibility in both Gnome Software and Apper.
The ability to read Microsoft Visio, Pagemaker and even Adobe InDesign files is a welcome addition to see the migration. More changelog available

Users looking to try this snapshot can access COPR repository and install it alongside the stable version.

On a side note, Scribus Generator is an excellent utility for mail-merge alternative.

Running Fedora 25 Design Suite on ASUS X550ZE laptop

Posted by Luya Tshimbalanga on November 25, 2016 07:08 AM
This blog is written on Fedora 25 Design Suite running on ASUS X550ZE.The upgrade from Design Suite 24 to 25 using Gnome Software went smooth with very little impact to the entire system.

Fedora 25 Design Suite with supported Dedicated Graphic card on a hybrid laptop

Inheriting the features from Fedora 25 Workstation, Design Suite now gained further support of hybrid hardware notably laptops (see above feature). Following the release cycle, supplemental wallpapers from Fedora 23 are replaced by their 25th version to mark the end of life of the 23rd release next month.

Design received new applications like Gnome Books useful for e-books and Calendar to easily manage the schedule.

  To enable full support of hotkeys and optimal power management due to the boot scheme bug in Linux kernel, 4.9.0rc4 or above (currently residing in Rawhide nodebug repository at the time of writing) is required and will soon reach availability via update. The case applied to some hybrid laptops (ASUS X550ZE in this example).

Looking for Design Suite 26 with further improvement of Gnome Shell environment. A special thanks to Makeuseof for selecting Fedora Design Suite as Best of The Basics.

Fedora Hubs and Meetbot: A Recursive Tale

Posted by Máirín Duffy on November 15, 2016 08:25 PM

Fedora Hubs

Hubs and Chat Integration Basics

One of the planned features of Fedora Hubs that I am most excited about is chat integration with Fedora development chat rooms. As a mentor and onboarder of designers and other creatives into the Fedora project, I’ve witnessed IRC causing a lot of unnecessary pain and delay in the onboarding experience. The idea we have for Hubs is to integrate Fedora’s IRC channels into the Hubs web UI, requiring no IRC client installation and configuration on the part of users in order to be able to participate. The model is meant to be something like this:

Diagram showing individual hubs mapping to individual IRC channels / privmsgs.

By default, any given hub won’t have an IRC chat window. And whether or not a chat window appears on the hub is configurable by the hub admin (they can choose to not display the chat widget.) However, the hub admin may map their hub to a specific channel – whatever is appropriate for their team / project / self – and the chat widget on their hub will give visitors the possibility to interact with that team via chat, right in the web interface. Early mockups depict this feature looking something like this, for inclusion on a team or project hub (a PM window for user hubs):

mockup showing an irc widget for #fedora-design on the design team hub

Note this follows our general principle of enabling new contributors while not uprooting our existing ones. We followed this with HyperKitty – if you prefer to interact with mailing lists on the web, you can, but if you’ve got your own email-based workflow and client that you don’t want to change at all, HyperKitty doesn’t affect you. Same principle here: if you’ve got an IRC client you like, no change for you. This is just an additional interface by which new folks can interact with you in the same places you already are.

Implementation is planned to be based on waartaa, for which the lead Hubs developer Sayan Chowdhury is also an upstream developer.

Long-term, we (along with waartaa upstream) have been thinking about matrix as a better chat protocol that waartaa could support or be ported to in the future. (I personally have migrated from HexChat to Riot.im – popular matrix web + smartphone client – as my only client to connect to Freenode. The experiment has gone quite well. I access my usual freenode channels using Riot.im’s IRC bridges.) So when we think about implementing chat, we also keep in mind the protocol underneath may change at some point.

That’s a high-level explanation of how we’re thinking about integrating chat into Hubs.

Next Level: HALP!!1

As of late, Aurélien Bompard has been investigating the “Help/Halp” feature of feature hubs. (https://pagure.io/fedora-hubs/issue/98)

The general idea is to have a widget that aggregates all help requests (created using the meetbot #help command while meeting minutes are being recorded) across all teams / meetings and have a single place to sort through them. Folks (particularly new contributors) looking for things they can help out with can refer to it as a nice, timely bucket of tasks that are needed with clear suggestions for how to get started. (Timely, because new contributors want to help with tasks that are needed now and not waste their time on requests that are stale and are no longer needed or already fixed. On the other side, the widget helps bring some attention to the requests people in need of help are making, hopefully increasing the chances they’ll get the help they are looking for.

The mechanism for generating the list of help requests is to gather #help requests from meeting minutes and display them from most recent to least recent. The chances you’ll find a task that is actually needed now are high. As the requests age, they scroll further and further back into the backlog until they are no longer displayed (the idea being, if enough time has passed, the help is likely no longer needed or has already been provided.) The contact point for would-be helpers is easy – the person who ran the #help command in the meeting is listed as a contact for you to sync up with to get started.)

The mockups are available in the ticket, but are shown below as well for purposes of illustration:

Main help widget, showing active help requests across various Fedora teams

Main help widget, showing active help requests across various Fedora teams

Mockup showing UI panel where someone can volunteer to help someone with a request.

Mockup showing UI panel where someone can volunteer to help someone with a request.

An issue that came up has to do with the mapping we talked about earlier. Many Fedora team meetings occur in #fedora-meeting-*; e.g., #fedora-meeting, #fedora-meeting-1, etc. Occasionally, Fedora meetings occur in a team channel (e.g., #fedora-design) that may not map up with the team’s ‘namespace’ in other applications (e.g., our mailing list is design-team. Our pagure.io repo is ‘/design’.) Based on how Fedora teams use IRC and how meetbot works, we cannot rely on the channel name to get the correct namespace / hub name for a team making a request during a meeting using the meetbot #help command.

Meetbot does also have a mechanism to set a topic for a meeting, and many teams use this to identify the team meeting – in fact, it’s required to start a meeting now – but depending on who is running the meeting, this freeform field can vary. (For instance – the design team has meetings marked fedora_design, fedora-design, designteam, design-team, design, etc. etc.) So the topic field in the fedmsg meetbot puts out may also not be reliable for pointing to a hub / team.

One idea we talked about in our meeting a couple of weeks ago as well as last week’s meeting was having some kind of lookup table to map a team to all of its various namespaces in different applications. The problem with this is that because meetbot issues the fedmsgs used to generate the halp widget list of requests as soon as the #help command is issued – it is meetbot itself that would need to lookup the mapping so that it had the correct team name issued in its fedmsg. We couldn’t write some kind of script or something to reconcile things after the meeting concluded. Meetbot itself needs to be changed for this to work – for the #help requests put out on fedmsg by meetbot to have the correct team names associated with them.

Which Upstream is Less Decomposed?

Do you see dead upstreams? Zombie image

Zombie artwork credit: Zombies Silhouette by GDJ on OpenClipArt.

We determined we needed to make a change to meetbot. meetbot is a plugin to an IRC bot called supybot. Fedora infrastructure doesn’t actually use supybot to run meetbot, though. (There haven’t been any commits to supybot for about 2 years.) Instead, we use a fork called limnoria that is Python 3-based and has various enhancements applied to it.

How about meetbot? Well, meetbot hasn’t been touched by its upstream since 2009 (7 years ago.) I believe Fedora carries some local patches to it. In talking with Kevin Fenzi, we discovered there is a newer fork of meetbot maintained by the upstream OpenStack team. That hadn’t seen activity in 3 years, according to github.

Aurélien contacted the upstream OpenStack folks and discovered that, pending a modification to implement file-based configs to enable deployment using tools like Ansible, they were looking to port their supybot plugins (including meetbot) to errbot and migrate to that. So we had a choice – we could implement what we needed on top of their newer meetbot as is and they would be willing to work with us, or we could join their team in migrating to errbot, participate in the meetbot porting process, and use errbot going forward. Errbot appears to have a very active upstream with many plugins available already.

How Far Down the Spiral Do We Go?

To unravel ourselves a bit from the spiral of recursion here… remember, we’re trying to implement a simple Help widget for Fedora Hubs. As we’ve discovered, the technology upon which the features we need to interact with to make the feature happen are a bit zombiefied. What to do?

We agreed that the overall mission of Fedora Hubs as a project is to make collaboration in Fedora more efficient and easy for everyone. In this situation specifically, we decided that migrating to errbot and upgrading a ported meetbot to allow for mapping team namespaces to meeting minutes would be the right way to go. It’s definitely not the easy way, but we think it’s the right way.

It’s our hope in general that as we work our way through implementing Hubs as a unified interface for collaboration in Fedora, we expose deficiencies present in the underlying apps and are able to identify and correct them as we go. This hopefully will result in a better experience for everyone using those apps, whether or not they are Hubs users.

Want to Help?

we need your help!

Does this sound interesting? Want to help us make it happen? Here’s what you can do:

  • Come say hi on the hubs-devel mailing list, introduce yourself, read up on our past meeting minutes.
  • Join us during our weekly meetings on Tuesdays at 15:00 UTC in #fedora-hubs on irc.freenode.net.
  • Reach out to Aurélien and coordinate with him if you’d like to help with the meetbot porting effort to errbot. You may want to check out those codebases as well.
  • Reach out to Sayan if you’d like to help with the implementation of waartaa to provide IRC support in Fedora Hubs!
  • Hit me up if you’ve got ideas or would like to help out with any of the UX involved!

Ideas, feedback, questions, etc. provided in a respectful manner are welcome in the comments.

I’m accepted into Outreachy for this winter!

Posted by Suzanne Hillman (Outreachy) on November 09, 2016 03:48 PM

Just remembered to check the website, and indeed: I’m accepted.

This is excellent news!

Blender and video sequence editor on Fedora

Posted by Luya Tshimbalanga on November 06, 2016 08:00 AM
Due to the legal matter related to FFMpeg, the video editor on Blender for Fedora will fail to run any video format. Tracking this bug report, it seems possible to build FFMPEG without the patented codecs thus possibly allow Blender video editor to properly run.

For the time being, alternative is already available on Fedora repository like Pitivi bundled in Fedora Design Suite. The downside is the occasional crash while editing, the upside is the use of extensible Gstreamer on several plugins compared to FFMPEG although the latter is popular.

Readying Fedora Design Suite 25

Posted by Luya Tshimbalanga on October 29, 2016 08:28 AM
LuxRender plugin now selectable on Blender in Software

The official release of Fedora 25 Design Suite is nearby with the following changes:
  • Inheriting the features from Fedora Workstation, it is now possible to rename several files.
  • Blender just reaches 2.78a with several bugs fixes. Non-western speaking users will delight the issues related to the interface is fixed.
  • LuxRender plugin for Blender  is updated to 1.6 bring new features. That version no longer supports 32 bit architectures known as x86. In addition, the plugin is now visible as addon for Blender in Software.
  • Sadly, Yafaray plugin for Blender is currently retired from the Fedora repository thus dropped from the default selection. It is still available for the previous release. The plan is to bring it back for the next release as I took over as packager.
  • Some applications like Gpick are unable to properly run on the default Wayland session and needs X session.
  • New fonts are available Grand Hotel and Molot (a big thanks for TypeType foundry for making it license friendly) needed as template for Fedora Magazine featured image.
  • Inkscape (pre-release of 0.92) gains new support of creating tables via plugin
  • Suppplemental wallpapers from Fedora 25 replaced their F23 version as default.
  • Pitivi 0.97, a video editor, received a fix and should properly.
All listed feature will be available on the wiki

    Research planning

    Posted by Suzanne Hillman (Outreachy) on October 11, 2016 12:17 AM

    The next step in our process is to talk to our users. In this case, I will be doing contextual interviews with 7 people.

    The major goal of these interviews is to identify the tools that Fedora folk are currently using to handle event planning for Fedora events. I hope to identify both existing pain points and aspects of the current tools that work well.

    Who should we interview?

    Lots of discussion with Mo turned up a few different axes on which we need to spread out our users.

    This project is meant to aid Fedora members in doing things with people near them. First, to find other Fedora community members to interact and potentially meet up with. Second, to coordinate events to introduce the general public to Fedora. Therefore, the most important aspects of our users is location.

    Coordination of public events is most likely to be done by Fedora Ambassadors. Other Fedora members will also need to create and organize public events. As such, we need to include both Ambassadors and non-ambassadors.


    The Fedora Community has four major locales: North America, Latin America, Europe and the Middle East, and Australia and the Pacific Islands. In addition to these four locations, we also have people who are specific to college campuses. As a result, we decided that we needed to be sure to have people from each of the locales, as well as people who were from college campuses.

    Ambassadors and other community members

    Ambassadors are the public face of Fedora, and therefore the people who are most likely to be organizing events for the public. The main goal of Fedora Regional Hubs is to make it easier to organize events, both within the Fedora Community and including the general public. Given that Ambassadors will definitely need to create public events, we need to include them in our user set. However, Ambassadors are not the only people potentially creating Fedora events for the general public, and so we need to make sure that Ambassador were not the only types of users we included.

    Other important criteria

    Age: It is possible that this will affect the types of tools currently being used, as well as the assumptions that users will make. When Mo suggested who to talk to, she expected that various ages will naturally fall out of the list she offered.

    Presence of frustration with current methods: As I am new to this project, and do not have much experience with how people are currently handling event planning, I wanted to be sure that we would include people who are known to be struggling. Discussion with Mo suggests that anyone we talk to will have at least some level of frustration to tap into.

    Gender: This was less strongly emphasized in our recruiting goals, although we do have 2 women of the 7 total users. I would have been concerned if we had had none. However, given the topic, I expect we would have struggled to find approximately equal numbers who were also appropriately spread out for location and ambassador status. Those two were more immediately important for the purposes of determining what people are currently using.


    Our list of potentially relevant aspects of our potential users included a number of additional axes of variation. These were not expressly included in our decision on who to include, but will be included on the demographics survey that participants will fill out ahead of time.

    Experience with Linux/Fedora: What experience do people have, how long have they been using it, how do they use it.

    Learning new things to do one’s job: Given that we would be developing a new tool to hopefully help people do the things they want to do, it seemed important to get people who were enthusiastic about learning new tools, fine with doing so, and actively dislike doing so. This will become relevant when it comes time to test prototypes.

    How active are Fedora groups you are already in? This is to get a general sense of the spread of the activity the people we interview are accustomed to.

    Final users

    We ended up selecting 3 ambassadors from three different locations, 2 non-ambassadors with one location overlap (Australia and Pacific Islands), and 2 campus people one of which was an ambassador and one not (both in North America).

    Mo will both be one of the non-ambassadors and the pilot user for the interview process. I expect that the pilot will bring to light many things that I flat out forgot to include or which needed to be more clearly stated. As a result, I expect that the interview and the survey will need adjustment before continuing.


    Coming up with relevant questions for the interviews was difficult. I originally started out trying to use the same categories that I used in my competitive analysis, but Mo correctly pointed out that those were too specific for this purpose. She gave an example of what she might do instead, and it became clear to me that I needed to do a high-level brainstorm of the kinds of tasks people might use regional hubs for.

    I expect people will want to:

    1. Find people who are local to them and interested in Fedora.
    2. Set up events (public ones) or meetings (within group).
    3. Discuss things about Fedora.
    4. Find people to attend the public events (advertisement).
    5. Find events to attend/support

    I suspect that #1 will not be relevant to our contextual interview due to being something someone new to a site might want to do. I also suspect that #4 may fall under #2. I’m currently waiting on feedback from Mo on the tasks and questions that I came up with.

    I will use some combination of Steve Krug’s Usability script from Rocket Surgery Made Easy and “Interviewing Users and Others” in User and Task Analysis for Interface Design by Hackos and Redish to come up with the final interview script. Of course, Mo may have a better suggestion, but that’s what I’m planning at the moment.

    Next post should include discussion of the pilot test. Stay tuned!

    Competitive analysis summary

    Posted by Suzanne Hillman (Outreachy) on October 07, 2016 08:16 PM


    1. Get an overview of current practices and general structure of existing meetup sites
    2. Identify potentially useful techniques and things to avoid.
    3. Identify questions for contextual interviews and for ourselves.


    1. http://loco.ubuntu.com/ — Ubuntu’s regional meetup organizational site (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157670346963233)
    2. http://meetup.com/ — the most commonly used site for regional meetups. (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157673502663516)
    3. https://www.citysocializer.com/ — Very event-focused site. (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157673872243535)
    4. 1) http://www.bigtent.com/ — a barebones site for parents and their kids. (comments and screenshots located at https://www.flickr.com/photos/wispfox/albums/72157672661407220)



    A simpler home page will help potential users decide if they want more information without overwhelming them.

    Search is very difficult. It’s a major challenge to have search that does what a user expects and provides results that are easy to understand and use.

    Including a photo of a group or specific event in search results helps a group seem more approachable.

    Use spacing and font styles to more visibly separate pieces of information to improve readability.

    None of the sites I looked at integrated real-time discussion.

    Site Summaries

    loco.ubuntu was the site with the most similar intentions to our own, as both Fedora Regional Hubs and Ubuntu LoCo are about regional and local groups within an opensource community. They have one teams per area, to reduce fragmentation of groups. This is reflected in their interface, in that they made the creation of teams a complicated process. They also want it to be very easy to find and join teams and events, so those are easy to do.

    meetup.com is all about making creation of groups, attending of meetups, and general interaction with other people as easy as possible. It’s got the easiest interface for all aspects of group and event creation and joining, and discussion, of the four I reviewed. However, something we will want to keep in mind is that we may not _want_ everything to be simple to do. Keep in mind the potential problem of fragmentation.

    citysocializer really just wants people to go out and do things together. There is very little on-site discussion, and no groups or teams. It’s all about events.

    bigtent.com wants to make things easy for group creators. Creating a group and creating a page for the group are very clean and clear and simple. Using those pages and finding information on them, however, is quite confusing and poorly laid out.


    Home pages varied wildly, although everyone had navigation across the top. The home page of bigtent was much cleaner and easier to parse than the others were.

    Events pages also varied a great deal. Meetup’s events page was easiest to interpret, possibly due to the amount of separation and white space between various types of information. Meetup’s events page also had fewer types of information on the page. Bigtent, on the other hand, had a small number of pieces of information, but they were poorly separated or not at all separated, and as a result were difficult to scan to get relevant information.


    The second goal, that of identifying techniques to use and things to avoid, was a little ambitious for a first look at the competitors in this space.

    What are people currently using within Fedora? Learning this will be a major goal of the contextual inquiry that is the next step in this process.

    What do we plan to support and not support for search?

    What sorts of things should be visible to people not logged into Hubs, for such things as public events planning and advertising?

    How easy do we want each aspect of a social site?

    Finding groups and events should likely be as easy as possible, given the desire to make it easier on new users to become part of the Fedora community. Joining should also be easy, for much the same reason.

    Discussions is an open question: should it only be within groups? Should we let the general public comment on/ask questions about public events? What should various people (owner of group, member of group, member of Fedora, general public — for example) be able to see on a group’s or event’s page?

    How about creating or suggesting events or groups? This may not be as simple to come to a decision on.

    For more information

    See https://pagure.io/fedora-hubs/issue/47, and the full writeup of the analysis at https://pagure.io/fedora-hubs/issue/raw/files/f258136ec925fe9a4cd13c127b8a428e7adac83135939ce5ccff5cab145aca30-Competitive_analysis.pdf

    Next up, planning research.

    Outreachy Competitive Analysis

    Posted by Suzanne Hillman (Outreachy) on September 22, 2016 12:52 AM

    Following up on the previous post about about my time in Outreachy working on the Fedora Project, with former co-worker Mo Duffy. I’ll be working on the UX of Local, Regional, National, and Continental Hubs as part of Fedora Hubs. The main idea is to help co-located Fedora contributors find each other, meet up in person, and set up local events like hack-a-thons and meetups.

    Competitive Analysis

    I’ve done most of the work for a competitive analysis of existing local/regional meetup websites, and am currently working on writing up a report of what I’ve found.

    My initial goal for the competitive analysis was to try to get a sense of what people currently do around regional meetups, and Mo suggested that I pattern my data collection after screenshots in the ‘relevant art’ sections of a few Gnome design projects: Chat, Documents, and Mail. We also decided that Flickr would be a good place to store the screenshots, as it supports comments and adding drawings to uploaded photos.

    As I proceeded with the screen-captures and annotations, I noticed that this task would not necessarily tell me what people in Fedora are currently using to organize their events and meetings. As such, the contextual inquiry that is my next task will need to include interviews with potential users to find out what they are actually doing right now.

    The report that I’m currently working on incorporates some of the competitive analysis explanation from “Communicating Design: Developing Web Site Documentation for Design and Planning” by Dan M Brown (seems to be a more recent version), which Mo lent me. It also leans on my existing experience in explaining and summarizing concepts, as that is a lot of what this report really seems to be about. It’s not yet complete, but I’ve sent it to Mo for some feedback to make sure that I’m on the right track with my report. So far, I’ve found this book a very useful guide to keep myself focused and remembering what I’m doing. It strongly informed the structure of the report I’m writing, most especially the part at the beginning of a document where I need to say what I’m doing, why I’m doing it, what I hoped to figure out, and what I actually figured out.

    I’ll go into more detail on what I did and what I found once I’ve finished the report.

    The next task before the application is due on Oct 17th is to create a rough plan for contextual inquiry and potential interview candidates. When I have finished up the next blog post about the report, I will start talking more about that part.

    I have run out of words that want to stick together in a useful order, so this post must therefore be complete.

    Long radio silence!

    Posted by Suzanne Hillman (Outreachy) on September 21, 2016 02:12 PM

    Long radio silence!

    I’ve been busy trying to find a part time job and working on ways to break into ux.

    Today, I’m starting a part-time job with the mbta through Thanksgiving. I’ve also been working on the initial submission for the Outreachy program, wherein I will be working with the Fedora project.

    My initial submission will include a competitive analysis, for which I am currently writing up a report after putting up groups of annotated screenshots on Flickr. I also need to write up my plans for user interviews to identify current methods for creating and attending local group meetings and events, and the plans for contextual inquiry.

    The contextual inquiry may be more complicated than ordinarily, as the entire point of the project is to provide a consistent interface for local and regional fedora meetups. This means that my best users may be scattered across the world.

    Solving that problem with my mentor will be interesting, and will involve some compromise. Perfect is the enemy of good, however, so finding a way to get useful information which does not involve me being in the room with the users will be useful. The best possibility probably involves remote desktop viewing, with two-way audio. Other possibilities may by necessity involve a running commentary on IRC. Or maybe Skype. I’m not yet sure, as my mentor Mo and I have only briefly discussed this aspect of things.

    Sneak into…

    Posted by Sirko Kemter on September 16, 2016 05:25 AM

    the current stage of the Fedora 25 Supplemental Wallpaper.. Start of this month I openend the submission phase for the Fedora Supplemental Wallpaper. So far we have received 91 submissions and currently 72 of them are approved. So far 49 contributors earned a badge for their submission. But there is still time until 11. October left to contribute a wallpaper.

    So far that are my favorites:

    Update on Asus X550ZE running on Fedora 24

    Posted by Luya Tshimbalanga on September 02, 2016 06:26 AM
    Since applying fix related to the ACPI from Linux kernel (future 4.8.0), ASUS kernel laptop runs smoother on Gnome Shell inside Fedora 24 Design Suite. Based on the following observation:
    • The delay of pluggin on/off the power is gone. Without the fix, it took about ten seconds before the system switched the status.
    • Power management has drastically improved. 
    • Closing the lid will automatically suspend the laptop.
    • Multimedia control now works on all applications.
    • Brightness control properly works.
    For Fedora users having similar issue with X550Z (also F550Z on some countries), a COPR repository is created for that purpose until upstream release the fix version on the kernel. Other distributions can look at the patch and provide feedback for testing and improvement.

    A big thanks to Peter Wu and Lv Zheng for investigating the issue which turned out bigger than expected: the discovery of new ACPI scheme on some modern laptops .

    [Solved] Quest to enable hotkeys for Asus X550Z

    Posted by Luya Tshimbalanga on August 31, 2016 12:23 AM
    Following previous topic, testing the build kernel 4.8.0rc4 with the patch related to ACPI EC allow unlocking the functionality of hotkeys. For the first time, ASUS X550ZE has nearly full functionality from keyboard in Linux operating system (Fedora in my case) on par with Microsoft Windows 8.1 and 10.  Hopefully other laptops having similar problem will regain that access.

    For that learned experience, that bug turned out more complex than expected revealing a different ACPI scheme used in Microsoft Windows 10 and a bad practice from BIOS vendor. It also shows how some vendors ignore standard procedure thus making harder to find the problem.

    The important lesson is the cooperation between users and developers exchanging knowledge and discovering new elements never seen before. One day, vendors will open themselves approaching the kernel community to improve their products.

    Now the hotkeys saga comes to the end, the next step is the support of AMD hybrid graphic card. This blog is written on ASUS X550ZE running on AMD A10 7400P itself using Radeon M265DX.

    [Follow-up] Quest of enabling hotkeys on ASUS Laptops

    Posted by Luya Tshimbalanga on August 30, 2016 07:59 PM
    Resuming for the previous topic, with the help of an Arch user and one of kernel maintainers, it turned out the failure of hotkeys functions [Fn] is due to a Linux ACPI bug. Further investigation revealed a bad practice from BIOS vendor and unexpectedly a new challenge in Linux kernel world as quoted:
    However this report indicates us another gap (except the enumeration order gap):
    If the namespace EC (DSDT EC in short) is not ready, EC access availability can be kept
    using the ECDT EC. In Linux, that requres _Qxx control methods to be registered for
    the ECDT EC. I have never seen a Linux EC driver version doing this before,
    _Qxx registration is only invoked in acpi_ec_add(). So this bug indicates a gap for Linux.
    Essentially, what is initially a bug related for non-functional hotkeys for ASUS X550Z laptop revealed a much more deeper issue related Linux ACPI. It is the first time I reached that level of testing in kernel world with the help from upstream kernel.

    A built kernel with an attempt patch to resolve ACPI EC problem is on COPR repository. It willl take longer to complete before testing the patch which will hopefully restore hotkeys functionality on some modern laptops especially ASUS. A suivre...

    _Thank you_ for this.

    Posted by Suzanne Hillman (Outreachy) on August 25, 2016 03:51 PM

    _Thank you_ for this.

    I’ve had pieces of this in my head, but not all of it. Not summarized in a way that I can refer back to it and help get things into my head to pay attention to.

    Design Team Fedora Activity Day (FAD) Event Report

    Posted by Máirín Duffy on August 16, 2016 09:26 PM

    Fedora Design Team Logo

    design team fad attendees portrait

    From left to right: Mo Duffy, Marie Nordin, Masha Leonova, Chris Roberts, Radhika Kolathumani, Sirko Kemter (photo credit: Sirko Kemter)

    Two weekends ago now, we had a 2-day Fedora Activity Day (heh, a 2-day day) for the Fedora Design Team. We had three main goals for this FAD, although one of them we didn’t cover (:-() :

    • Hold a one-day badges hackfest – the full event report is available for this event – we have wanted to do an outreach activity for some time so this was a great start.
    • Work out design team logistics – some of our members have changed location causing some meeting time issues despite a few different attempts to work around them. We had a few other issues to tackle too (list to come later in this post.) We were able to work through all points and come up with solutions except for one (we ran out of time.)
    • Usability test / brainstorm on the Design Team Hub on Fedora Hubs – so the plan was that the Design Team Hub would be nearly ready for the Flock demo the next week, but this wasn’t exactly the case so we couldn’t test it. With all of the last-minute prep for the workshop event, we didn’t have any time to have much discussion on hubs, either. We did, however, discuss some related hub needs in going through our own workflow in our team logistics discussion, so we did hit on this briefly.

    So I’m going to cover the topics discussed aside from the workshop (which already has a full event report), but first I want to talk a little bit about the logistics of planning a FAD and how that worked out first since I totally nerded out on that aspect and learned a lot I want to share. Then, I’ll talk about our design team discussion, the conclusions we reached, and the loose ends we need to tie up still.


    I had already planned an earlier Design Team FAD for January 2015, so I wasn’t totally new to the process. There were definitely challenges though.


    First, we requested funding from the Fedora Council in late March. We found out 6 weeks later (early May, a little less than 3 months before the event) that we had funding approval, although the details about how that would work weren’t solidified until less than 4 weeks before the event.

    Happily, I assumed it’d be approved, filed a request to use the Red Hat Westford facility for the event. There were two types of tickets I had to file for this – a GWS Special Event Request and a GWS Meeting Support Request. The special event request was the first one – I filed that on June 1 (2 months ahead) and it was approved June 21 (took about 3 weeks.) Then, on 7/25 the week before the event, I filed the meeting support request to have the room arranged in classroom style as well as open up the wall between the two medium-sized conference rooms so we had one big room for the community event. I also set up a meeting with the A/V support guy, Malcolm, to get a quick run through of how to get that working. It was good I went ahead and filed the initial request since it took 3 weeks to go through.

    The reason it took a while to work out the details on the budget was because we scheduled the event for right before Flock, which meant coordinating / sharing budgets. We did this both to save money and also to make sure we could discuss design-team related Flock stuff before heading to Flock. While this saved some money ultimately, IMHO the complications weren’t worth it:

    • We had to wait for the Flock talk proposals to be reviewed and processed before we knew which FAD attendees would also be funded for Flock, which delayed things.
    • Since things were delayed from that, we ended up missing on some great flight pricing, which meant Ryan Lerch wasn’t able to come 🙁
    • To be able to afford the attendees we had with less than 4 weeks to go, we had to do this weird flight nesting trick jzb figured out. Basically, we booked home<=>BOS round trip tickets, then BOS<=>KRK round trip tickets. This meant Sirko had to fly to Boston after Flock before he could head home to PNH, but it saved a *ton* of money.
    fad budget spreadsheet screenshot

    behold, our budget

    Another complication: we maxed out my corporate card limit before everything was booked. 🙂 I now have a credit increase, so hopefully next event this won’t happen!

    The biggest positive budget-wise for this event was the venue cost – free. 🙂 Red Hat Westford kindly hosted us.

    I filed the expense reports for the event this past week, and although the entire event was under budget, we had some unanticipated costs as well as a small overage in food budget:

    • Our original food budget was $660. We spent $685.28. We were $25.28 over. (Pretty good IMHO. I used an online pizza calculator to figure out budget for the community event and was overly generous in how much pizza people would consume. 🙂 )
    • We spent $185.83 in unanticipated costs. This included tolls (it costs $3.50 to leave Logan Airport), parking fees, gas, and hotel taxes ($90 in hotel taxes!)

    Lessons Learned:

    • Sharing budget with other events slows your timeline down – proceed with caution!
    • Co-location with another event is a better way to share costs logistically.
    • Pizza calculators are a good tool for figuring out food budget. 🙂
    • Budget in a tank of gas if you’ve got a rental.
    • Figure out what tolls you’ll encounter. Oh and PAY CASH, in the US EzPass with a rental car is a ripoff.
    • Ask the hotel for price estimates including taxes/fees.


    I rented a minivan to get folks between Westford and the airport as well as between the hotel and the office. I carpool with my husband to work, so I picked it up near the Red Hat Westford office and set up the booking so I was able to leave it at Logan Airport after the last airport run.

    Our chariot. I cropped him out of the portrait. Sorry, Toyota Sienna! It has nice pickup. I still am never buying a minivan ever, even if I have more kids. Never minivan, never!

    Our chariot. I cropped him out of the portrait. Sorry, Toyota Sienna! It has nice pickup. I still am never buying a minivan ever, even if I have more kids. Never minivan, never!

    With international flights and folks coming in on different nights, and the fact I actually live much closer to the airport than the hotel up in Westford (1 hour apart) – by the time the FAD started, I was really worn down as I had 3 nights in a row leading up to the FAD where I wasn’t getting home until midnight at the earliest and I had logged many hours driving, particularly in brutal Boston rush hour traffic. For dropoffs, it was not as bad as everybody left on the same day and there were only 2 airport trips then. Still – not getting home before my kids went to bed and my lack of sleep was a definite strain on my family.

    So we had a free venue, but at a cost. For future FAD event planners, I would recommend either trying to get flights coming in on the same day as much as possible and/or sharing the load of airport pickups. Even better, would be to hold the event closer to the airport, but this wasn’t an option for us because of the cost that would entail and the fact we have such a geographically-distributed team.

    The transportation situation - those time estimates aren't rush hour yet!

    The transportation situation – those time estimates aren’t rush hour yet!

    One thing that went very well that is common sense but bears repeating anyway – if you’re picking folks up from the airport, get their phone #’s ahead of time. Having folks phone numbers made pickup logistics waaaaay easier. If you have international numbers, look up how to dial them ahead of time. 🙂

    Lessons Learned:

    • Try hard to cluster flights when possible to make for less pickups if the distance between airport / venue is great.
    • If possible, share responsibility for driving with someone to spread the load.
    • Closer to the airport logistically means spending less time in a car and less road trips, leaving more time for hacking.
    • Don’t burn yourself out before the event even starts. 🙂
    • Collect the phone numbers of everyone you’re picking up, or provide them some way of contacting you just in case you can’t find each other.
    We're dispersed...

    We’re dispersed… (original list of attendees’ locations or origin)


    This one went pretty smoothly. Westford has a lot of restaurants; actually, we have a lot more restaurants in Westford with vegetarian options than we did less than 2 years ago at the last Design Team FAD.

    For the community event, the invite mentioned that we’d be providing pizzas. We had some special dietary requests from that, so I looked up pizza place that could accommodate, would deliver, and had good ratings. There were two that met the criteria so I went with the one that had the best ratings.

    Since the Fedora design team FAD participants were leading / teaching the session, I went over the menu with them the day before the community event, took their orders for non-pizza sandwiches/salads, and called the order in right then and there. (I worried placing the order too far in advance would mean it’d get lost in the shuffle. Lesson learned from the 2015 FAD where Panera forgot our order!) Delivery was a must, because of the ease of not having to go and pick it up.

    For snacks, we stopped by a local supermarket either before or after lunch on the first day and grabbed whatever appealed to us. Total bill: $30, and we had tons of drinks and yummy snacks (including fresh blueberries) that kept us tided over the whole weekend and were gone by the end.

    We were pretty casual with other meals. Folks at the hotel had breakfast at the hotel, which meant less receipts to track for me. We just drove to places close by for lunch and dinner, and being a local + vegetarian meant we had options for everybody. I agonized way too much about lunch and dinner last FAD (although there were less options then.) Keeping it casual worked well this time; one night we tried to have dinner at a local Indian place and found out they had recently been evicted! (Luckily, there was a good Indian place right down the road.)

    Lessons Learned:

    • For large orders, call in the day before and not so far in advance that the restaurant forgets your order.
    • Supermarkets are a cheap way to get a snack supply. Making it a group run ensures everyone has something they can enjoy.
    • Having a local with dietary restrictions can help make sure food options are available for everyone.

    Okay, enough for logistics nerdery. Let’s move on to the meat here!

    Design Team Planning

    We spent most of the first day on Fedora Design team planning with a bit of logistics work for the workshop the following day. First, we started by opening up an Inkscape session up on the projector and calling out the stuff we wanted to work on. It ended up like this:

    Screenshot of FAD brainstorming session from Inkscape

    Screenshot of FAD brainstorming session from Inkscape

    But let’s break it down because I suspect you had to be there to get this. Our high-level list of things to discuss broke down like this:

    Discussion Topics

    • Newcomers
      – how can we better welcome newcomers to the team?
    • Pagure migration
      Fedora Trac is going to be sunset in favor of Pagure. How will we manage this transition?
    • Meeting times
      – we’ve been struggling to find a meeting time that works for everyone because we are so dispersed. What to do?
    • Status of our ticket queue
      – namely, our ticket system doesn’t have enough tickets for newbies to take!
    • Badges
      – conversely, we have SO MANY badge tickets needing artwork. How to manage?
    • Distro-related design
      – we need to create release artwork every release, but there’s no tickets for it so we end up forgetting about it. What to do?
    • Commops Thread
      – this point refers to Justin’s design-team list post about ambassadors working with the design team – how can we better work with ambassadors to get nice swag out without compromising the Fedora brand?

    Let’s dive into each one.


    This is the only topic I don’t think we fully explored. We did have some ideas here though:

    • Fedora Hubs will definitely help provide a single landing page for new comers to see what we’re working on in one place to get a feel for the projects we have going on – right now our work is scattered. Having a badge mission for joining the design team should make for a better onboarding experience – we need to work out what badges would be on that path though. One of the pain points we talked about was how incoming newbies go straight to design team members instead of looking at the ticket queue, which makes the process more manual and thus slower. We’re hoping Hubs can make it more self-service.
    • We had the idea to have something like whatcanidoforfedora.org, but specifically for the design team. One of the things we talked about is having it serve up tickets tagged with a ‘newbie’ tag from both the design-team and badges ticket systems, and have the tickets displayed by category. (E.g., are you interested in UX? Here’s a UX ticket.) The tricky part – our data wouldn’t be static as whatcanidoforfedora.org’s is – we wouldn’t want to present people with a ticket that was already assigned, for example. We’d only want to present tickets that were open and unassigned. Chris did quite a bit of investigation into this and seems to think it might be possible to modify asknot-ng to support this.
    • A Fedora Hubs widget that integrated with team-specific asknot instances was a natural idea that came out of this.
    • We do regular ticket triage during meetings. We decided as part of that effort, we should tag tickets with a difficulty level so it’s easier to find tickets for newbies, and maybe even try to have regular contributors avoid the easy ones to leave them open for newbies. We had some discussion about ticket difficulty level scales that we didn’t get to finish – at one point we were thinking:
      • Easy (1 point) (e.g., a simple text-replacement badge.)
      • Moderate (3 points) (e.g., a fresh badge concept with new illustration work.)
      • Difficult / Complex (10 points) (e.g., a minor UX project or a full badge series of 4-5 badges with original artwork.)

      Or something like this, and have a required number of points. This is a discussion we really need to finish.

    • Membership aspects we talked about – what level of work do we want to require for team emembership? Once a member, how much work do we want to require (if any) to stay “current?” How long should a membership be inactive before we retire? (Not to take anything away from someone – but it’s handy to have a list of active members and a handle on how many active folks there are to try to delegate tasks and plan things like this FAD or meetups at Flock.) No answers, but a lot of hard questions. This came up naturally thinking about membership from the beginning to the end.
    • We talked about potentially clearing inactive accounts out of the design-team group and doing this regularly. (By inactive, we mean FAS account has not been logged into from any Fedora service for ~1 year.)
    • Have a formal mentor process, so as folks sign up to join the team, they are assigned a mentor, similar to the ambassador process. Right now, we’re a bit all over the place. It’d be nice for incoming folks to have one person to contact (and this has worked well in the past, e.g., Mo mentoring interns, and Marie mentoring new badgers.)

    Pagure migration

    We talked about what features we really needed to be able to migrate:

    • The ability to export the data, since we use our trac tickets for design asset storage. We found out this is being worked on, so this concern is somewhat allayed.
    • The ability to generate reports for ticket review in meetings. (We rely on the custom reports Chris and Paul Frields created for us at the last FAD.) We talked through this and decided we wanted a few things:
      • We’d like to be able to do an “anti-tag” in pagure. So we’d want to view a list of tickets that did not have the “triage” tag on them, so we could go through them and triage them, and add a ‘triage’ tag as we completed triage. That would help us keep track of what new tickets needed to be assessed and which had already been evaluated.
      • We’d like some time-based automation of tag application, but don’t know how that would work. For example, right now if a reporter hasn’t responded for 4 weeks, we classify that ticket as “stalled.” So we’d want tickets where the reporter hasn’t responded in 4 weeks to be marked as “stalled.” Similarly, tickets that haven’t had activity for 2 weeks or more are considered “aging”, so we’d like an “aging” tag applied to them. So on and so forth.
      • We need attachment support for tickets – we discovered this was being worked on too. Currently pagure supports PNG image attachments but we have a wider range of asset types we need to attach – PDFs, Scribus SLAs, SVGs, etc. We tested these out in pagure and they didn’t work.

    We agreed we need to follow up with pingou on our needs and our ideas here to see if any of these RFEs (or other solutions) could be worked out in Pagure. We were pretty excited that work was already happening on some of the items we thought would help meet our needs in being able to migrate over.

    We don’t have enough tickets! (AKA we are too awesome)

    We tend to grab tickets and finish them (or at least hold on to them) pretty quickly on the design team these days. This makes it harder for newbies to find things to work on to meet our membership requirement. We talked about a couple of things here, in addition to related topics already covered in the newbie discussion summary:

    • We need to be more strict about removing assignees from tickets with inactivity. If we’ve pinged the ticket owner twice (which should happen in at least a 4 week period of inactivity from the assignee) and had no response, we should unapologetically just reopen up the ticket for others to take. No hard feelings! Would be even better if we could automate this….
    • We should fill out the ticket queue with our regular release tasks. Which leads to another topic…

    Distro-related design (Release Artwork)

    Our meetings are very ticket-driven, so we don’t end up covering release artwork during them. Which leads to a scramble… we’ve been getting it done, but it’d be nice for it to involve less stress!

    Ideally, we’d like some kind of solution that would automatically create tickets in our system for each work item per release once a new release cycle begins… but we don’t want to create a new system for trac since we’ll be migrating to pagure anyway. So we’ll create these tickets manually now, and hope to automate this once we’ve migrated to pagure.

    We also reviewed our release deliverables and talked through each. A to-do item that came up here: We should talk to Jan Kurik and have him remove the splash tasks (we don’t create those splash screens anymore) and add social media banner tasks (we’ve started getting requests for these.) We should also drop CD, DVD, and DVD for multi, and DVD for workstation (transcribing this now I wonder if it’s right.) We also should talk to bproffitt about which social media Fedora users the most and what kind of banners we should create for those accounts for each release. So in summary: we need to drop some unnecessary items from the release schedule that we don’t create anymore, and we should do more research about social media banners and have them added to the schedule.

    Another thing I forgot when I initially posted this – we need some kind of entropy / inspiration to keep our default wallpapers going. For the past few releases, we’ve gotten a lot of positive feedback and very few complaints, but we need more inspiration. An idea we came up with was to have a design-team internal ‘theme scheme’ where we go through the letters of the alphabet and draw some inspiration from an innovator related to that letter. We haven’t picked one for F25 yet and need to soon!

    Finally, we talked about wallpapers. We’d like for the Fedora supplemental wallpapers to be installed by default – they tend to be popular but many users also don’t know they are there. We thought a good solution might be to propose an internship (maybe Outreachy, maybe GSoC?) to revive an old desktop team idea of wallpaper channels, and we could configure the Fedora supplementals to be part of the channel by default and maybe Nuancier could serve them up.


    We never seem to have time to talk through the badges tickets during our meetings, and there are an awful lot of them. We talked about starting to hold a monthly badge meeting to see if this will address it, with the same kind of ticket triage approach we use for the main design team meetings. Overall, Marie and Maria have been doing a great job mentoring baby badgers!

    Commops Thread

    We also covered Justin’s design-team list post about ambassadors working with the design team, particularly about swag as that tends to be a hot-button issue. For reasons inexplicable to me except for perhaps that I am spaz, I stopped taking notes in Inkscape and started using the whiteboard on this one:

    photo of whiteboard (contents described below)

    Swag discussion whiteboard (with wifi password scrubbed 🙂 )

    We had a few issues we were looking to address here:

    • Sometimes swag is produced too cheaply and doesn’t come out correctly. For example, recently Fedora DVDs were produced with sleeves where Fedora blue came out… black. (For visuals of some good examples compared to bad examples with these sorts of mistakes, check this out.)
    • Sometimes ambassadors don’t understand which types of files to send to printers – they grab a small size bitmap off of the wiki without asking for the print-ready version and things come out pixelated or distorted.
    • Sometimes files are used that don’t have a layer for die cutting – which results in sticker sheets with no cuts that you have to manually cut out with scissors (a waste!)
    • Sometimes files are sent to the printer with no bleeds – and the printer ends up going into the file and manipulating it, sometimes with disastrous results. If a design team member had been involved, they would have known to set the bleeds before sending to the printer.
    • Generally, printers sometimes have no clue, and without a designer working with them they make guesses that are oftentimes wrong and result in poor output.
    • Different regions have different price points and quality per type of item. For example, DVD production in Cambodia is very, very expensive – but print and embroidery items are high-quality and cheap.

    Overall, we had concerns about money getting wasted on swag when – with a little coordination – we could produce higher-quality products and save money.

    We brainstormed some ideas that we thought might help:

  • Swag quality oversight – Goods produced too cheaply hurt our brand. Could we come up with an approved vendor list, so we have some assurances of a base level of quality? This can be an open process, so we can add additional vendors at any time, but we’ll need some samples of work before they can be approved, and keep logs of our experience with them.
  • Swag design oversight – Ambassadors enjoy their autonomy. We recognize that’s important, but at a certain point sometimes overenthusiastic folks without design knowledge can end up spending a lot of money on items that don’t reflect our brand too well. We thought about setting some kind of cap – if you’re spending more than say $100 on swag, you need design team signoff – a designer will work with you to produce print-ready files and talk to the vendor to make sure everything comes out with a base quality level.
  • Control regional differences – Could we suggest one base swag producer per ambassador region, and indicate what types of products we use them for by default? Per product, we should have a base quality level requirement – e.g., DVDs cannot be burnt – they must be pressed.
  • Okay, I hope this is a fair summary of the discussion. I feel like we could have an entire FAD that focused just on swag. I think we had a lot of ideas here, and it could use more discussion too.

    Meeting Times

    We talked about meeting times. There is no way to get a meeting time that works for everybody, so we decided to split into North America / EMEA / LATAM, and APAC regions. Sirko, Ryan Lerch, and Yogi will lead the APAC time (as of yet to be determined.) And the North America / LATAM / EMEA time will be the traditional design team time – Thursdays at 10 AM ET. Each region will meet on a rotating basis, so one week it’ll be region #1, the next region #2. Each region will meet at least 2x a month then.

    How do we stay coordinated? We came up with a cool idea – the first item of each meeting will be to review the meetbot logs from the other region’s last meeting. That way, we’ll be able to keep up with what the other region is doing, and any questions/concerns we have, they’ll see when they review our minutes the next week. We haven’t had a chance to test this out yet, but I’m curious to see how it works in practice!


    Chris’ flight left on Sunday morning, but everybody else had flights over to Poland which left in the evening, so before we went to the airport, we spent some time exploring Boston. First we went to the Isabella Stewart Gardener Museum, as it was a rainy day. (We’d wanted to do a walking tour.) We had lunch at Boloco, a cool Boston burrito-chain, then the sun decided to come out so we found a parking spot by Long Wharf and I gave everybody a walking tour of Quincy Market and the North End. Then we headed to the airport and said our goodbyes. 🙂

    From left to right: Mo, Masha, Marie, Radhika

    From left to right: Mo, Masha, Marie, Radhika

    What’s Next?

    There’s a lot of little action items embedded here. We covered a lot of ground, but we have a lot more work to do! OK, it’s taken me two weeks to get to this point and I don’t want this blog post delayed anymore, so I’m just going for it and posting now. 🙂 Enjoy!

    Flock 2016, Krakow

    Posted by Ryan Lerch on August 12, 2016 04:56 AM

    Last week, I got to attend the 2016 edition of Flock — the Fedora Contributor Conference. As always for Flock, the 2016 edition of Flock (in Krakow, Poland) provided an amazing opportunity to meet up and work alongside many of my fellow Fedora contributors for a week of talks,  hackfests, workshops, and evening events.

    Flock Swag

    Every year, the awesome Fedora Design Team jumps in and helps create many of the physical items that make Flock both memorable and (we hope) more usable.

    Traditional Flock T-Shirt

    One of the most prominent (and sought after) swag items each Flock is the memorable Flock t-shirt and this year, the awesome Krakow-themed Flock artwork that adorned them was created by Máirín Duffy and Mary Shakshober.

    The Awesome 2016 Flock Krakow T-Shirt

    Booklets & Schedule

    Every year, I help contribute to the Flock Swag by putting together the booklets for Flock. These typically contain all the important information that attendees might need during Flock in a format they can shove in a bag, and refer to when needed. The major elements of the booklet is info about the host city (including maps), info about the evening events, and the schedule. If you are interested in having a look at the booklets (and their sources) — they are all available in the flock-booklets Pagure project. Special thanks to Máirín for doing the final edits & proofreading of the booklet just before printing, and to both Máirín and Mary, for the design from the t-shirts that was used on the front cover of the booklet too.

    Some well-used copies of the Flock 2016 Booklets

    One extra thing I did this year was to create a large versions of the schedule out of smaller strips of paper (one strip for each talk), to be stuck up in a hallway somewhere for all attendees to view and use.  I also did the same thing for each room that was holding talks, so attendees could walk past each room and easily see what was going on. When I was cutting out the close to 150 individual strips of paper, I kept hoping that it would be useful, and watching the amount of people using the big schedule each day, it appeared to work very well. The idea of having each talk on a single strip of paper was so when talks inevitably got moved, changed or canceled, we could update the big schedule to be accurate.

    The big schedule on the wall at Flock on the Friday

    In fact, talking to Josh Boyer (who awesomely put the schedule itself together) we agreed that in the future, it would probably be worth not putting the schedule in the booklet at all — as it tends to change a fair bit after the printing of the booklets — and just having the big wall schedule.

    Lanyard Badges

    This year, the awesome lanyard badges were put together by Masha Leonova, using the same design from the shirts by Máirín and Mary. These were printed (with individual names printed on them too) on quite thick (about 4-5mm) plastic and were super durable and awesome.

    The Lanyards Badges from flock 2016

    Other Swag

    Attendees that pre-registered for Flock this year were also treated to a few more swag items, including a Fedora tote, a Fedora waterbottle, and a sheet of Fedora stickers:


    As always at flock, the first two days of Flock 2016 event are crammed-full with nearly 80 different talks ranging from the Kernel Talk to using Fedora for Art and Design. Some of the stand-out talks for me on the first two days were:

    The State of Fedora-Infra

    Lead by pingou and nirik, this annual talk was a high-level overview of what happened this year so far from both the infrastructure side (lead by nirik), and the fedora-apps side (lead by pingou). It was awesome to see all the hard work that that has being doing the fedora apps including Pagure, FAS3, Bodhi — being summarized and listed out.

    Fedora Magazine and what it teaches us about users

    Paul Frields talk about the Fedora Magazine, was also a great overview of how far we have come with the Fedora Magazine — in a few years it has grown into a Million+ hits a year way for the Fedora Project to communicate with our users. It is now also the primary way that we deliver major announcements (like the Release Announcements) to the world. Paul credited this uptick to the re-focusing of the Magazine to be aimed at Fedora users.

    GNOME Software: You’ll never guess what happens!

    Richard Hughes provided a great summary of the design and development of the Software application that we use in Fedora Workstation. Richard started with a quick overview of the graphical PackageKit tool that we had before, and the design choices that went into creating GNOME Software — with the primary decision being to focus on applications as a base unit rather than Packages. Richard also covered one of the exciting new features that dropped in Fedora 24 on Software — the user reviews, and i learnt the interesting fact that the user reviews we see on Software in Fedora are not just Fedora user reviews, but reviews of users from all other distros using the Software application too.

    Don’t Destroy your machine with Development

    Dusty Mabe led this tutorial style talk on the basics of using Vagrant on Fedora when doing development tasks. It was a great overview on using Vagrant on Fedora, including the use of the libvirt vagrant provider, and syncing files to your Vagrant development environments using the Vagrant sshfs plugin. This was all great information for my campaign to get all the Fedora apps that the infra team develops to start shipping Vagrant setups for first-time developers to use when beginning to hack on these tools.

    Diversity Panel

    The Diversity panel at Flock was led by Amita in the room at Flock, and remotely by the Maria Leandro. It was a great panel to just sit and absorb information about how the Fedora Project is going at the task of expanding our contributor base and plenty of ideas and opinions on how to get more people from all backgrounds and skill levels contributing to the project.


    Pingou led the Pagure talk this year, and it was amazing to see the changes that the project has gone through over the past year. Pagure now has many more active contributors, with many new features and a new UI rolled out over the past year.


    The hackfests and workshops at Flock have to be my favourite part of the Flock meetup, as we all get to sit together in a room, discuss and hack on projects that we typically do remotely all year long.

    Fedora Docs Learn & Hack

    Brian Exelbierd led the Docs hackfest this year with an overview of the new tool and content strategy the Docs team is rolling out. The idea is to move away from monolithic books, and towards smaller article-based docs that will help users find the answers to their issues quicker and easier. He also did a tutorial into getting the new Pintail-based toolchain working.

    Bodhi Hackfest

    One of the main things I got from the Bodhi hackfest was a to-do list (this is always a good thing in my book). A little bit ago, i began porting the Bodhi interface to fedora-bootstrap, and i also got to run some ideas for improving the interface of bodhi from users in the room. One other item on my to-do list (that i started hacking on in the hackfest) was moving the bodhi development sourcesfrom github to Pagure (yay!)

    Fedora Hubs Hackfest

    It was great to see Fedora Hubs in action at Flock in this hackfest, at it is amazing to see how much it has changed and improved from the last time i played around with it a few months ago. The new live updating feed widget is impressive with a lot of potential. And the ability for a user to drag and drop widgets around was super neat as well.

    Evening Events

    I know i must say this every year, but the evening events at Flock 2016 were amazing! I missed the walking tour on the first night, but all reports from people that did go were *glowing*, having a tour of the host city is such a great idea for a lower-key first night event.

    The second night was Cruise Krakow, with dinner served on two separate boats, with one of boats doing two seperate trips along the river in Krakow. The final event was at Brewery Lubicz, and as you can imagine featured both tasty food and beverages.


    Aprendizaje del FlocktoFedora para Diversidad

    Posted by Maria "tatica" Leandro on August 09, 2016 12:46 PM
    <figure class="wpb_wrapper vc_figure">

    No puedo expresar la alegría de tener un equipo de personas tan maravillosas, quienes a pesar de las 12h de diferencia, han logrado mantenerme informada sobre todo lo que sucede al rededor de nuestro trabajo de Diversidad en Fedora durante el Flock. Interminables logs de IRC y Telegram han hecho esto posible. Así que acá está mi lista de pensamientos, tareas e ideas sobre las coas logradas en el Flock de Polonia.

    Primeros Pasos

    Buzón de Diversidad

    Estoy bastante impactada con la gran cantidad de casos que mi equipo de Diversidad ha obtenido durante el Flock. Tenemos personas que, a pesar de ser fantásticas para el proyecto, necesitan un poco de guía sobre como tratar a sus compañeros con mas respeto. Es hora de educar a las personas sobre como mantener un ambiente mas amigable y acogedor, sin tantas criticas a las personas nuevas, o a aquellas personas que simplemente no tienen tanto tiempo para colaborar.

    Luego de realizar una encuesta personal, más del 80% de las personas que tienen dificultades encontrando un ambiente armónico en Fedora no quieren hablar en voz alta, ni quieren decir sus nombres, y casi 2/3 de ellos ni siquiera quieren reportar el caso ya que piensan que no son relevantes. SI SON RELEVANTES.

    A principios de año se comentó la idea de que necesitamos un Buzón de Diversidad lo cual me reforzó Amita luego de conversar con los amigos en el Flock, para que las personas se sientan con la confianza suficiente de conversar con nosotros sin tener que poner sus nombres públicamente. Tenemos casos en otras comunidades donde por el simple hecho de hablar en voz alta han sufrido mucho mas, y transformar un problema pequeño en grande no es nuestra meta.

    Este buzón debería ser capaz de registrar información personal o permitir entradas anónimas, así como adjuntar registros o pruebas del problema, para que podamos estudiarlo y buscar la mejor solución. Puedes ayudarnos? por favor, contácteme ASAP para que podamos sacar este buzón!

    Programas de Inclusión

    Tuvimos un excelente programa inicial con el FWD organizado el mes pasado, y a pesar de que comenzamos pequeño, lo hicimos con mucha energía. Fui parte de una jornada de Diseño online en Perú y me uní a los esfuerzos locales de las reuniones de WordPress en mi ciudad, Amita organizó un excelente FWD en India, Jona hizo un fantástico trabajo con su grupo de chicas en Albania y Christos se nos unió con un excelente panel en el FWD de Grecia. La asistencia fue fantástica, mejor de lo esperado!

    Mientras mas comencemos a aprender sobre los colaboradores, podremos crear mejores programas para ayudar a cada grupo de minoría. FWD demostró ser una excelente iniciativa pero queremos mas, y para eso necesitamos el elemento mas importante, colaboradores. A pesar de que hagamos nuestro mejor esfuerzo en conocer cada minoría, aquellos que las experimentan de primera mano son quienes nos ayudarán a aprender a comprender mejor a cada colaborador de forma particular en nuestro proyecto. Nuestra idea es no solo tener reuniones anuales, pero también tener tantas reuniones en línea como sea posible para que nuestras barreras desaparezcan. Te interesa organizar alguna de estas reuniones?

    Nuestra meta es organizar al menos una reunion mensual donde no solo podamos construir una mejor comunidad Fedora, pero también expandir los conocimientos que tenemos sobre cada miembro de nuestra comunidad.

    Próximos Pasos

    Encuesta de Diversidad

    Una de las primeras ideas que tuvimos para el team de Diversidad fue la (no tan famosa) encuesta, que nos ayudaría a comprender mejor como esta construida nuestra comunidad. A pesar de que tenemos infinidad de nombres en nuestra FAS, conocemos muy poco sobre nuestros colaboradores. Es imperativo seguir presionando para que esta idea se convierta en realidad.

    Puedes ver el estado actual de nuestra encuesta revisando al final de los registros de nuestras reuniones de Diversidad en Polonia en este pad.

    Reportes Anuales

    Cada año tenemos estadísticas sobre cuantos tickets fueron resueltos, cuantos nuevos embajadores tenemos y cuantas badges fueron otorgadas, pero necesitamos estadísticas sobre nuestros esfuerzos de diversidad e inclusión.

    Con reportes anuales que nos ayuden a comparar y aprender, podremos ver si nuestros esfuerzos están generando una comunidad mas acogedora, y nos está ayudando a combatir el bullying y el acoso, permitiéndonos mejorar.

    Qué sigue?

    Queremos escuchar tus ideas! No seas penos@!


    This post has a nicer formatting that can be seen at it's original source at tatica.org , so feel free to hit the link and read better version!

    Design Team FAD

    Posted by Sirko Kemter on August 04, 2016 06:12 AM

    Durng the weekend of 28th to 31st of July I was in Westford for the Design Team FAD, which we had now for the second time and we use mainly for organizing the work in the team. We all arrived during the week, but we are much lesser then last year, as some flights are more expensive like mine. So we are just 7 people this year.

    Day one we spending most of the time with preparing for the open badges hackfest which we will held tomorrow. So we prepared some Inkscape lessons for an entry to Inkscape. The rest of the day we was spending time for organizational stuff we have to do for the work with the Design Team. We organized during the FAD 2015 the work of the Design Team new, we have since then regular meetings in IRC where we look over our ticket queue. Since we doing that, we handle all tickets very fast and our ticket queue is always in short time solved. But that creates another problem, we never have tickets for newcomers left, so we have to find a solution for that. The other problem we have with that is, that we concentrating to much on the tickets and the design for the distribution itself does not end up there, so we sometimes loosing track of it. With the meeting we have to find a solution for it as a bigger part of the Design team is now living in APAC, like Ryan Lerch and me. So its very difficult for us joining the regular meeting. We also spent time organizing the migration of our ticket system to Pagure, which will be happen soon. The migration from trac to Pagure is for the Design Team and the Badges a little bit more problematic as we need some features to do so.

    Next to this organizational things we had on saturday an open house workshop, about using Inkscape and doing badges with it. Mo has an more detailed report about that part of the FAD

    The Fedora Design Team’s Inkscape/Badges Workshop!

    Posted by Máirín Duffy on August 03, 2016 08:41 PM

    Fedora Design Team Logo

    This past weekend, the Fedora Design Team held an Inkscape and Fedora Badges workshop at Red Hat’s office in Westford, Massachusetts. (You can see our public announcement here.)

    Badges Workshop

    Why did the Fedora Design Team hold this event?

    At our January 2015 FAD, one of the major themes of things we wanted to do as a team was outreach, to both help teach Fedora and the FLOSS creative tools set as a platform for would-be future designers, as well as to bring more designers into our team. We planned to do a badges workshop at some future point to try to achieve that goal, and this workshop (which was part of a longer Design FAD event I’ll detail in another post) was it. We collectively feel that designing artwork for badges is a great “gateway contribution” for Fedora contributors because:

    • The badges artwork standards and process is extremely well-documented.
    • The artwork for a badge is a small, atomic unit of contribution that does not take up too much of a contributor’s time to create.
    • Badges individually touch on varying areas of the Fedora project, so by making a single badge you could learn (in a rather gentle way) how a particular aspect of how the Fedora project works (as a first step towards learning more about Fedora.)
    • The process of creating badge artwork and submitting it from start to finish is achievable during a one-day event, and being able to walk away from such an event having submitted your first open source contribution is pretty motivating!

    This is the first event of this kind the Fedora Design team has held, and perhaps any Fedora group? We aimed for a general, local community audience rather than attaching this event to a larger technology-focused conference event or release party. We explicitly wanted to bring folks not currently affiliated with Fedora or even the open source community into our world with this event.

    Preparing for the event

    Photo of event handouts

    There was a lot we had to do in order to prepare for this event. Here’s a rough breakdown:

    Marketing (AKA getting people to show up!)

    We wanted to outreach to folks in the general area of Red Hat’s Westford Office. Originally, we had wanted to have the event located closer to Boston and partner with a university, but for various reasons we needed to have this event in the summer – a poor time for recruiting university students. Red Hat Westford graciously offered us space for free, but without something like a university community, we weren’t sure how to go about advertising the event to get people to sign up.

    Here’s what we ended up doing:

    • We created an event page on EventBrite (free to use for free events.) That gave us a bit of marketing exposure – we got 2 signups from on Event Brite referrals. The site also helped us with event logistics (see next section for more on that.)
    • We advertised the event on Red Hat’s Westford employee list – Red Hat has local office mailing lists for each office, so we advertised the event on there asking area employees to spread the word about the event to friends and family. We got many referrals this way.
    • We advertised the event on a public Westford community Facebook page – I don’t know about other areas, but in the Boston area, many of the individual towns have public town bulletin boards set up as Facebook groups, and event listings are allowed and even encouraged on many of these sites. I was able to get access to one of the more popular Westford groups and posted about our event there – first about a month out, then a reminder the week before. We received a number of referrals this way as well.

    Photo of the event


    We had to formally reserve the space, and also figure out how many people were coming so we knew how much and what kinds of food to order – among many other little logistical things. Here’s how we tackled that:

    • Booking the space – I filed a ticket with Red Hat’s Global Workplace Services group to book the space. We decided to open up 30 slots for the workshop, which required booking two conference rooms on the first floor of the office (generally considered the space we offer for public events) and also requesting those rooms be set up classroom-style with a partition opened up between them to make one large classroom. The GWS team was easy to work with and a huge help in making things run smoothly.
    • Managing headcount – As mentioned earlier, we set up an EventBrite page for the event, which allowed us to set up the 30 slots and allow people to sign up to reserve a slot in the class. This was extremely helpful in the days leading up to the event, because it provided me a final head count for ordering food and also a way to communicate with attendees before the event (as registration requires providing an email address.) We had a last-minute cancellation of two slots, and we were able to push out information to the three channels we’d marketed the event to and get those slots filled the day before the event so we had a full house day of.
    • Ordering food – I called the day before the event to order the food. We went with a local Italian place that did delivery and ordered pizzas and soda for the guests and sandwiches / salads for the instructors (I gathered instructor orders right before making the call.) We had a couple of attendees who had special dietary needs, so I made sure to order from a place that could accommodate.
    • Session video recording – During the event, we used BlueJeans to wirelessly project our slides to the projectors. Consequentially, this also resulted in recordings being taken of the sessions. On my to-do list is to edit those down to just the useful bits and post them, sending the link to attendees.
    • Surveying attendees – After the event, Event Brite helpfully allowed us to send out a survey (via Survey Monkey) to the attendees to see how it went.
    • Making slides available – Several attendees asked for us to send out the slides we used (I just sent them out this afternoon, and have provided them here as well!)
    • Getting permission – I knew we were going to be writing up an event report like this, so I did get the permission/consent of everyone in the room before taking pictures and hitting record on the BlueJeans session.
    • Parking / Access – I realized too late that we probably should have provided parking information up front to attendees, but luckily it was pretty straightforward and we had plenty of spots up front. Radhika helpfully stood by the front entrance as attendees arrived to allow them in the front door and escort them to the classroom.
    • Audio/Video training – Red Hat somewhat recently got a new A/V system I wasn’t familiar with, and there are specific things you need to know about getting the two projectors in the two rooms in sync when the partition is open, so I was lucky to book a meeting with one of Red Hat’s extremely helpful media folks to meet with me the day before and teach me how to run the A/V system.


    Inkscape / Badges Prep Work

    We also needed to prepare for the sessions themselves, of course:

    • Working out an agenda – We talked about the agenda for the event on our mailing list as well as during team meetings, but the rough agenda was basically to offer an Inkscape install fest followed by a basic Inkscape class (mizmo), run through an Inkscape tutorial (gnokii), and then do a badges workshop (riecatnor & mleonova.) We’ll talk about how well this worked later in this post. 🙂
    • Prepare slides / talking points – riecatnor, mleonova, and myself prepped some slides for our sessions; gnokii prepared a tutorial.
    • Prepare handouts – You can see in one of the photos above that we provided attendees with handouts. There were two keyboard shortcut printouts – one for basic / most frequently used ones, the other a more extended / full list we found provided by Michael van der Nest. We also provided a help sheet on how to install Inkscape. We printed them the morning of and distributed them at each seat in the classroom.
    • Prepare badges – riecatnor and mleonova very carefully combed through open badge requests in need of artwork and put together a list of those most appropriate for newbies, filling in ideas for artwork concepts and tips/hints for the would-be badgers who’d pick up the tickets at the event. They also provided the list of ticket numbers for these badges on the whiteboard at the event.

    Marie explaining the anatomy of a badge

    The Agenda / Materials

    Here’s a rough outline of our agenda, with planned and actual times:

    Here’s the materials we used:

    As mentioned elsewhere in this post, we did record the sessions, but I’ve got to go through the recordings to see how usable they are and edit them down if they are. I’ll do another post if that’s the case with links to the videos.

    How did the event go?

    Unfortunately, despite our best efforts (and a massive amount of prep work,) I don’t think any of us would qualify the event as a home run. We ran into a number of challenges, some of our own (um, mine, actually!) making, some out of our control. That being said, thus far our survey results have been very positive – basically attendees agreed with our self-analysis and felt it was a good-to-very good, useful event that could have been even better with a few tweaks.

    graph showing attendees rated the presentation good-to-excellent

    The Good

    • Generally attendees enjoyed the sessions and found them useful. As you can see in the chart above, of 8 survey respondents, 2 thought it was excellent, 3 thought it was very good, and 3 thought it was good. I’ll talk more about the survey results later on, but enjoy this respondent’s quote: “I’m an Adobe person and I’ve never used other design softwares, so I’m happy I learned about a free open source software that will help me become more of an asset when I finish college and begin looking for a career.”
    • The event was sold out – interest in what we had to say and teach is high!. We had all 30 slots filled over a week before the event; when we had 2 last-minute dropouts, we were able to quickly re-fill those slots. I don’t know if every single person who signed up attended, but we weren’t left with any extra seats in the room at the peak of attendance.
    • The A/V system worked well. We had a couple of mysterious drops from BlueJeans that lead some some furious reconnecting to continue the presentation, but overall, our A/V setup worked well. I
    • The food was good. There was something to eat for everyone, and it all arrived on time. For close to 40 people, it cost $190. This included 11 pizzas (9 large, 2 medium gluten free), 4 salads, 2 sandwiches, and 5 2-liter bottles of soda. (Roughly $5.30/person.) Maybe a silly point to make, but food is important too, especially since the event ran right through lunch (10 AM – 3 PM.)
    • We didn’t frighten newbies away (at least, not right away.) About half of the attendees came with Inkscape preinstalled, half didn’t. We divided them into different halves of the room. The non-preinstallers (who we classified as “newbies,”) stayed until a little past lunch, which I consider a victory – they were able to follow at least the first long session, stayed for food, and completed most of gnokii’s tutorial.
    • Inkscape worked great, even cross-platform. Inkscape worked like a champ – there were no catastrophic crashes and generally people seemed to enjoy using it. We had everyone installed by about 20 minutes into the first session – one OS X laptop had some issues due to some settings in the OS X control panel relating to XQuartz, but we were able to solve them. Everyone left the event with a working copy of Inkscape on their system! I would guesstimate we had about 1/3 OS X, 1/3 Windows, and 1/3 Linux machines (the latter RH employees + family mostly. 🙂 )
    • No hardware issues. We instructed attendees to bring their own hardware and all did, with the exception of one attendee who contacted me ahead of time – I was able to arrange to provide a loaner laptop for her. Some folks forgot to bring a computer mouse and I had enough available to lend.

    survey results about event length - too long

    The Bad

    • We ran too long. We originally planned the workshop to last from 10 AM to 2 PM. We actually ran until about 4 PM; although we officially ended at 3 PM with everyone in the room’s consent around 1:30. This is almost entirely my fault; I covered the Inkscape Bootcamp slides too slowly. We had a range of skill levels in the room, and while I was able to keep the newbies on board during my session, the more advanced folks were bored until gnokii ran his (much more advanced) tutorial. The survey results also provided evidence for this, as folks felt the event ran too long and some respondents felt it moved too slow, others too fast.
    • We covered too much material. Going hand-in-hand with running too long, we also tried to do too much. We tried to provide instruction for everyone from the absolute beginner, to Adobe convert, to more experienced attendee, and lost folks along the way as the pacing and level of detail needed for each different audience is too different to pull off successfully in one event. In our post-event session, the Fedora Design Team members running the event agreed we should cut a lot of the basic Inkscape instruction and instead focus on badges as the conduit for more (perhaps one-on-one lab session style) Inkscape instruction to better focus the event.
    • We lost people after lunch. We lost about half of our attendees not long after lunch. I believe this is for a number of reasons, not the least of which we covered so much material to start, they simply needed to go decompress (one survey respondent: “I ended up having to leave before the badges part because my brain hurt from the button tutorial. Maybe don’t do quite so many things next time?”) Another interesting thing to note is the half of the room that was less experienced (they didn’t come with Inkscape pre-installed and along the way tended to need more instructor help,) is the half that pretty much cleared out, while the more experienced half of the room was still full by the official end of the event. This helps support the notion that the newbies were overwhelmed and the more experienced folks hungry for more information.
    • FAS account creation was painful. We should have given the Fedora admins a heads up that we’d be signing 30 folks up for FAS accounts all at the same time – we didn’t, oops! Luckily we got in touch via IRC, so folks were finally able to sign up for accounts without being blocked due to getting flagged as potential spammers. The general workflow for FAS account signup (as we all know) is really clunky and definitely made things more difficult than it needed to be.
    • We should have been more clear about the agenda / had slides available. This one came up multiple times on the survey – folks wanted a local copy of the slides / agenda at the event so when they got lost they could try to help themselves. We were surprised by unwilling folks seemed to be to ask for help, despite our attempts to set a laid back, audience-participation heavy environment. In chatting with some of the attendees over lunch and after the event, both newbie and experienced folks expressed a desire to avoid ‘slowing everybody else down’ by asking a question and wanting to try to ‘figure it out myself first.’
    • No OSD keypress guides. We forgot to run an app that showed our keypresses while we demoed stuff, which would have made our instructions easier to follow. One of the survey respondents pointed this one out.
    • We didn’t have name badges Another survey comment – we weren’t wearing name badges and our names weren’t written anywhere, so some folks forgot our names and didn’t know how to call for us.
    • We weren’t super-organized on assisting folks around the room. We should have set a game plan before starting and assigned some of the other staff to stand in particular corners of the room and kind of assign them that area to help people one-on-one. This would have helped because as just mentioned, people were reluctant to ask for help. Pacing behind them as they worked and taking note of their screens when they seemed stuck and offering help worked well.

    Workshop participants working on their projects

    Survey results so far

    Thus far we’ve had 8 respondents out of the 30 attendees, which is actually not an awful response rate. Here’s a quick rundown of the results:

    1. How likely is it that you would recommend the event to a friend or colleague? 2 detractors, 3 passives, 2 promoters; net promoter score 0 (eek)
    2. Overall, how would you rate the event? Excellent (2), Very Good (3), Good (3), Fair (0), Poor (o)
    3. What did you like about the event? This was a freeform text field. Some responses:
      • “I think the individuals running the event did a great job catering to the inexperience of some of the audience members. The guy that ran the button making lab was incredibly knowledgeable and he helped me learn a lot of new tools in a software I’ve never used before that I may not have found on my own.”
      • “The first Inkscape walk through of short cut keys and their use. Presenter was confident, well prepared and easy to follow. Everyone was very helpful later as we tried “Evil Computer” mods with assistance from knowledgeable artists.”
      • “I enjoyed learning about Inkscape. Once I understood all the basic commands it made it very easy to render cool-looking logos.”
      • “It was a good learning experience. It taught me some things about graphics that I did not know.”
    4. What did you dislike about the event? This was a freeform text field. Some responses:
      • “I wish there was more of an agenda that went out. I tried installing Inkscape at my home before going, but I ran into some issues so I went to the office early to get help. Then I found out that the first hour of the workshop was actually designed to help people instal it. It also went much later than originally indicated and although it didn’t bother me, many people left at the time it was supposed to end, therefore not being able to see how to be an open source contributor.”
      • “The button explanation was very fast and confusing. I’m hoping the video helps because I can pause it and looking away for a moment won’t mean I miss something important.”
      • “Hard to follow directions, too fast paced”
      • “The pace was sometimes too slow.”
      • “While the pace felt good, it can be hard to follow what specific keypresses/mouse movements produced an effect on the projector. When it’s time to do it yourself, you may have forgotten or just get confused. A handout outlining the steps for each assignment would have been helpful.”
    5. How organized was the event? Extremely organized (0), Very organized (5), Somewhat organized (3), Not so organized (0), Not at all organized (0)
    6. How friendly was the staff? Extremely friendly (4), Very friendly (4), Somewhat friendly (0), Not so friendly (0), Not at all friendly (0)
    7. How helpful was the staff? Extremely helpful (2), Very helpful (3), Somewhat helpful (3), not so helpful (0), not at all helpful (0).
    8. How much of the information you were hoping to get from this event did you walk away with? All of the information (4), most of the information (2), some of the information (2), a little of the information (0), none of the information (0)
    9. Was the event length too long, too short, or about right? Much too long (0), somewhat too long (3), slightly too long (3), about right (2), slightly too short (0), somewhat too short (0), much too short (0).
    10. Freeform Feedback: Some example things people wrote:
      • “I’m an Adobe person and I’ve never used other design softwares, so I’m happy I learned about a free open source software that will help me become more of an asset when I finish college and begin looking for a career.”
      • “Overall fantastic event. I hope I’m able to find out if another workshop like this is ever held because I’d definitely go.”
      • “If you are willing to make the slides available and focus on tool flow it would help as I am still looking for how BADGE is obtained and distributed.”

    mleonova showing off our badges

    Looking forward!

    Despite some of the hiccups, it is clear attendees got a lot out of the event and enjoyed it. There are a lot of recommendations / suggestions documented in this post for improving the next event, should one of us decide to run another one.

    In general, in our post-event discussion we agreed that future events should have a tighter experience level pre-requisite; for example, absolute beginners tended to like the Inkscape bootcamp material, so maybe have a separate Inkscape bootcamp event for them. The more experienced users enjoyed gnokii’s project-style, fast-paced tutorial and the badges workshop, so having an event that included just that material and had a pre-requisite (perhaps you must be able to install Inkscape on your own and be at least a little comfortable using it) would probably work well.

    Setting a time limit of 3-4 hours and sticking to it, with check-ins, would be ideal. I think an event like this with this many attendees needs 2-3 people minimum running it to work smoothly. If there were 2-3 Fedorans co-located and comfortable with the material, it could be run fairly cheaply; if the facility is free, you could do it for around $200 if you provide food.

    Anyway I hope this event summary is useful, and helps folks run events like this in the future! A big thanks to the Fedora Council for funding the Fedora Design Team FAD and this event!

    Diversidad en el Flock Krakow (Polonia)

    Posted by Maria "tatica" Leandro on August 03, 2016 06:01 PM

    Hay algo que todos amamos, una buena charla con amigos, y eso fue el Panel de Diversidad en el Flock Krakow. En un Panel realmente interesante lleno de no solo personas increíbles, pero experimentadas, discutimos como podemos mejorar nuestros esfuerzos para lograr que todos se sientan cómodos y animarlos a hacer lo que les gusta sin que tengan que preocuparse por lo que la gente piense.

    Tengo que darle un agradecimiento especial a mi equipo de Diversidad, Justin, Amita, Jona, Bee y Silvia; quienes hicieron posible que asistiera a pensar de las dificultades; no puedo expresar lo agradecida que estoy por el esfuerzo de todos! Ahora, entremos en tema: (mis disculpas si no coloco los nombres al lado de las ideas expuestas, el video no era lo suficientemente bueno para identificarlos a todos)

    <figure class="wpb_wrapper vc_figure">


    Es fácil llenarse la cabeza con los últimos paquetes que necesitan ser armados, sobre los últimos .po que deben ser traducidos, o sobre ese bendito px que sigue interfiriendo en el diseño; debemos tomarnos un momento para levantar la cabeza y ver las personas que trabajan con nosotros. Nuestra comunidad está llena de toneladas de personas con cualidades que hacen que el proyecto crezca cada día, sin embargo, a veces consideramos que esto es un trabajo de tiempo completo en vez de un trabajo colaborativo. El momento en que dejamos de escuchar a nuestros colaboradores que necesitan guía, nuestros números bajaran ya que no seremos capaces de  generar una nueva generación de relevo.


    Siéntete orgulloso de trabajar con otros en vez de solo buscar tus propias recompensas. La comunidad ES tu familia, y deberías tratarla como tal. no seremos capaces de incluir mas personas a nuestras líneas a menos de que hablemos de ello, siente orgullo sobre tu comunidad y deja de darle importancia al que dirán. Es fácil olvidad que todos comenzamos como novatos preguntando cosas tontas, es fácil olvidar que NOSOTROS somos quienes tenemos la responsabilidad de mostrar que hay una tarea para todos en la comunidad. Es momento de que difundamos que nos sentimos orgullosos por nuestros compañeros en el proyecto. Una gran idea es tener una persona del equipo de Diversidad como representante en cada Team, para así poder hacer que todos se sientan incluidos. No es un secreto que conocemos mas a las personas que están dentro de nuestro mismo equipo, y no conocemos mucho a el resto de personas que están en el proyecto… es un gran proyecto. Al tener un miembro de Diversidad en cada Equipo podremos reducir la brecha entre nosotros y las personas que necesiten de nuestra ayuda.


    Yo creo que nuestros procesos son inclusivos, si no, muchos de nosotros no estaríamos aquí en primer lugar, sin embargo, si creo que tenemos algunos miembros activos que son una debilidad. Una de nuestras debilidades es que no sacamos la cabeza de lo que estamos haciendo, y no tomamos un momento para ver lo que nos rodea. Hay un MONTÓN de personas dispuestas a colaborar, sin embargo, TODOS tenemos que trabajar como mentores (sin importar si eso te agrega un +1 de karma). Con tantos badges, estadísticas y similares, de cierta forma estamos olvidando el porque somos una comunidad, no es solo para hacer cosas fantásticas con software, pero también para divertirnos. Una vez comprendamos que el número de colaboradores felices es tan importante (o mas) que el número de badges que tenemos o nuestras estadísticas en el track, seremos capaces de tener una comunidad mas saludable y acogedora.


    No es un secreto que hay personas que se sienten incómodas y otras personas que disfrutan de esto, siempre hay un troll y un peleón. Necesitamos crear una red de soporte con la que podamos ayudar a las personas a sentirse protegidas y seguras, y también un lugar donde podamos enseñarles a lidiar con estas situaciones. No debemos construir una pared al rededor de nuestros colaboradores, debemos enseñarlos a forjar herramientas que los preparen para defenderse ante cualquier ataque. Creo que podemos ser un instrumento para enseñarle a las personas como vivir felices en este mundo.

    Me gustaría agradecer a Matthew, Christoph, Marina, Laura, Kohane, Kushal y todos aquellos a quienes no les reconocí las voces mientras colaboraban en el panel; esto demuestra que hay un interés real en construir una mejor comunidad para nuestros usuarios, y no solo construir buen software.

    This post has a nicer formatting that can be seen at it's original source at tatica.org , so feel free to hit the link and read better version!

    Quest to enable hotkeys on ASUS laptops

    Posted by Luya Tshimbalanga on July 31, 2016 11:16 PM
    With the help of an Arch Linux user, we managed to extract input of  hotkeys and closing lid to suspend on several ASUS laptops which required ATKACPI driver to properly function otherwise they will not work despite the availability of asus-nb-wmi module.
    I made a tracker to alert that discovery so hopefully kernel maintainers will notice.

    UX events are very energizing!

    Posted by Suzanne Hillman (Outreachy) on July 28, 2016 01:48 AM

    Every single UX event I’ve been to has been delightful, and very energizing.

    Now, they tend to happen in the evening, so I’m rarely able to take full advantage of the energy and enthusiasm talking with other UXers and/or watching presentations gives me.

    On the plus side, though: it’s probably an excellent sign that this is the case. I _like_ other UXers, and I like the topics and conversations that happen at these events.

    I was somewhat amused to be talking to someone who was trying to get a job after being laid off from a 10 year position. One of my first questions was if she actually had a portfolio, since I hear they were less vital 10 years ago. She did, but was having trouble organizing it. So, since I know a story is important (which I’m struggling with myself), I asked her what she most enjoyed about doing UX. When she answered, I asked a few more questions to see if we could tease out the start of a story for her portfolio. At the very least, I helped her come up with more ideas for how to approach her portfolio (unlike me, her problem is having too _many_ possibilities to put there).

    Of course, I still need to figure out a story for myself. And I really don’t feel like I know enough UX yet to know what my portfolio’s story should be!

    Managed to get myself onto the Ladies that UX Boston email list, which apparently was well-hidden somewhere on the website. The organizer I talked to will put me on the list by hand, which will mean I don’t have to remember to check twitter to find out when the next event is.

    Also spoke to someone who is taking classes at Startup Institute, who commented that one of the interesting things about that place is that they focus more on soft skills and networking than places like General Assembly. When I commented that I was having trouble finding networking events in the summer, she said that I should probably also look at web development meetup events and not just UX ones. She also mentioned that General Assembly and Startup Institute often have events. Mind you, they are both in Boston proper, which is a pain for me to get to and thus much less likely for an evening event.

    Typography, graphic design

    Posted by Suzanne Hillman (Outreachy) on July 19, 2016 06:05 PM

    I’m taking a class at Coursera about design principles. This is absolutely something I need, and I’m glad I’m taking it.

    However, I get tripped up on weird things. This week’s homework includes the need to do some typography work. Perhaps Word is the right thing to use, since it’s text? It says “ use scale, weight, location, orientation, groupings, and rhythm. However, your submission must be in grayscale. Use only Helvetica (or Arial or similar sans serif). You are free to use different weights (e.g. bold), styles (e.g. italic), and capitalizations. This assignment is not about selecting a typeface, it’s about using visual variables to convey organization and meaning”. This seems like something Word can do?

    Oh, but I need to submit an 800x600 pixel image.

    How do I save something in Word as that? For that matter, how do I save _anything_ as that?

    Maybe I need some sort of drawing program. I used Google Drawing to add grid lines to some websites to illustrate that they are grid-based. Maybe that will do? I tried to use some other drawing programs (like Inkscape, Marvel, and Macaw), but they just confused me. Perhaps because I’m using a drawing program for text? (I’ve got other graphics programs on my machine, too, like Affinity for Windows Beta because I’m trying to learn _something_ along these lines. But mostly, I’m just confused).

    Google Drawing will let me download things as jpg, png, pdf, and svg. Obviously, pdf is wrong, but what about the others? I don’t imagine that I’d need svg (scalable vector graphics) for a text-only image, so png or jpg. But how do I know what the pixel size is?

    If I’m interpreting the wiki page correctly, jpg is better for images without large swaths of single colors. So probably png for text-based images.

    Alright, I’ll make this in Google Drawing. But what would other people use, and why? And maybe I’ll figure out how to make it be 800x600 px after I finish formatting it.

    I feel like I’m spending _way_ more time figuring out what I should be using than actually doing the assignment. I also feel like this is often a problem I have with visual-based tasks. Does everyone else struggle with this stuff? Is there something obvious that I’m missing, here?

    Pokemon Go, Evolutions

    Posted by Suzanne Hillman (Outreachy) on July 15, 2016 06:07 PM

    I’ve been playing Pokemon Go recently, along with an amazing number of other people.

    It’s a good game, as evidenced by its popularity. Yet, like anything, it could be better.


    One thing that I’ve found especially annoying, perhaps in part due to the fact that I did not grow up playing Pokemon, is the usability of the evolve interaction when you are looking at a monster in your Pokemon collection.

    <figure><figcaption>Do I already have this in the evolved state?</figcaption></figure>

    If you take a look at the screenshot above, you can see that I highlighted the ‘evolve’ option.

    At the moment, the only way to know if you have already seen the monster something evolves into is to go into your pokedex:


    select the creature you are evolving from, and take a look at its evolution description:

    <figure><figcaption>Spearow Evolution</figcaption></figure>

    As you can see, I have indeed caught, evolved, or hatched the Fearow that the Spearow evolves into.

    Not only is figuring this out somewhat annoying, but any time you leave the pokedex or your pokemon list, you are sent back to the main screen rather than your ‘items, store, pokedex, pokemon’ screen. Too many things to do just to see if I already have something!

    As a result, I decided to modify the design as if I had actual control over the app. Of course, I don’t, but it made me feel better!

    I have no idea why Niantic didn’t already do this, and perhaps they have an excellent reason. For those of us who don’t have Pokemon memorized, though, it’s frustrating.

    Text-based Design

    My first design incorporated a single text character next to the evolve functionality to indicate if one has or has not already seen the monster something evolves to.

    <figure><figcaption>A question mark to say that you’ve not seen the evolved monster before</figcaption></figure>

    First, a question mark to indicate that you’ve never seen the monster this evolves into.

    <figure><figcaption>You have one in your inventory!</figcaption></figure>

    Here, I have a number to indicate how many you already have. This could be zero if for some reason you didn’t keep one you had! Maybe the number or question shouldn’t match the evolve or power up buttons, but that’s not really as important to me as the fact that there is useful info in that single character.

    Graphic Design Option

    Ok, but text isn’t really very elegant.

    If you find a creature in the wild that you’ve not yet obtained, it’ll show up as a silhouette of the creature in your tracking interface. So why not use that to indicate that you’ve not yet seen a creature here, as well?

    <figure><figcaption>The silhouette of the creature this evolves into!</figcaption></figure>

    And, if you have or have had the monster, the same tracking interface shows you the monster filled in. So it can easily stand in to tell you that you have at least one in your inventory.

    <figure><figcaption>Yes, you have this creature, and this is what it looks like!</figcaption></figure>

    And suddenly it’s much easier to tell what you have and do not have, in the very same screen you would use to evolve.

    If anyone else has considered how to solve this, I’d love to see what you’ve done!

    A F24 user story

    Posted by Nicu Buculei on June 28, 2016 01:47 PM

    Honestly, nothing from the features in the announcement of the Fedora 24 release didn't manage to excite me intro upgrading my desktop from an old, out-of-support Fedora. It's main task is to edit digital photography and for some years a Linux solution is decent at it.

    Still, the devil is in the details! I wanted to switch to the (relatively) recent 2.x release of darktable and maybe play a bit with development versions of GIMP. Obscure tasks from a release notes point of view, but a big use case for me. It was a 2 weeks window from the F24 release to the next big incoming project, plenty of time to fix any small annoyances, right?

    Well, not so fast :) The first thing to notice, was GIMP (2.8.16, stable) being close to useless: it can't import RAW images, due to the import plugin (UFRaw) segfaulting in the process. You can still use the app, but only for JPEG snapshots, not for anything serious.

    Of course, there are workarounds: use another app, like darktable (remember, my first reason for the upgrade), for the RAW-to-JPEG conversion and then polish it with GIMP (something which is part of my workflow for some scenarios). Not so fast, again! I wasn't able to discover the cause, but my darktable in Fedora 24 crashes a lot. A lot more than... say Windows 98 (first edition) in a bad day. Anecdote: for one particular photo, it crashed 4 times in a row (open the app -> select image thumbnail -> press the export button). It worked with a Windows 98 "solution": close everything else, try once more.

    Another possible workaround: use GIMP devel, which is available via Flatpack (Flatpak is so much talked as a feature, but so much not ready for primetime in F24!). No luck either: that GIMP comes with no plugins and no obvious way to install them. And Damn! the new GIMP is so fugly...

    Perhaps in a couple of months it will be smooth, but for now the upgrade don't look like a good investment.

    fedora 24

    radeontop available in Fedora repository

    Posted by Luya Tshimbalanga on June 22, 2016 06:29 PM

    RadeonTop landed on Fedora repository for some time. It is a text user interface input displaying the information of AMD Radeon graphic card. To use it, first install from the terminal

    sudo dnf install radeontop

    Then start

    sudo radeontop

    Bonus, radeontop can display information in colour as well by simply executing sudo radeontop -c

    Fedora 24 Design Suite available

    Posted by Luya Tshimbalanga on June 21, 2016 03:40 PM
    Following the previous blog about missing Design Suite on the release, the Quality Assurance team made it possible for Fedora 24. Feel free to download it , play with it and read about the features.
    Sadly due to a bug from the new Fedora building system caused by dnf, all plugins for Gimp, Inkscape and Blender are missing for this Design Suite. They can be installed via Gnome Software or through command line.

    Fedora Design Suite 24 status

    Posted by Luya Tshimbalanga on June 19, 2016 01:33 AM
    Bad news: Design Suite image for Fedora 24 will be unavailable as default on the official release due to several issues linked to the livemedia building system I have no control.

    Possible workaround: on the slight good news, recent successful built image is available for testing although it did not make the cut for the general release. Unfortunately, due to a bug inside the packaging manager dnf, add-ons are missing for both Blender, Gimp and Inkscape. Worse, by the time I applied the workaround, the freeze status for Labs release was in effect with the migration of kickstart system to Pagure.
    Alternate method will be to download and install Fedora Workstation then apply the command from the terminal
    sudo dnf group install design-suiteDifference is missing documentations related to Design Suite and supplemental wallpapers. The focus is now toward Fedora 25 where all unexpected kinks will be sorted out.

    Sources for Openly-Licensed Content

    Posted by Máirín Duffy on June 09, 2016 01:07 PM

    This morning I got an email from my colleague Tyler Golden who was seeking advice on good places to get openly-licensed content so I put together a list. It seems the list would be generally useful (especially for my new design interns, who will be blogging on Planet Fedora soon 🙂 ) so here you are, a blog post. 🙂

    There’s a lot more content types I could go through but I’m going to stick to icons/graphics and photography for now. If you know of any other good sources in these categories (or desperately need another category of content covered,) please let me know and I’ll update this list.

    Also of note – please note any licenses for materials you’re evaluating for use, and if they require attribution please give it! It doesn’t have to be a major deal. (I covered this quite a bit in a workshop I’ve given a few times on Gimp & Inkscape so you might want to check out that preso if you need more info on that.)

    Icons / Graphics

    • The Noun Project


      Ryan Lerch clued me in to this one. All of the graphics are Creative Commons (yo uhave to provide attribution) or you can pay a small fee if you don’t want to have to attribute. There’s a lot of nice vector-based icons here.


    • Open Clip Art


      Everything is CC0 – no attribution needed – and all vector sources. Quality varies widely but there are some real gems in there. (My offerings are here, but my favorite collection is by the Fedora Design team’s gnokii. Ryan Lerch has a good set too!) There’s a plugin that comes with Inkscape that lets you search open clip art and pull in the artwork directly without having to go to the website.


    • Xaviju’s Inkscape Open Symbols


      I love these because you can browse the graphics right in Inkscape’s UI and drag over whichever ones you want into your document. There’s a lot of different libraries there with different licenses but the github page gives links to all the upstreams. I’m a big fan of Font Awesome, which is one of the libraries here, and we’ve been using it in Fedora’s webapps as of late; except for the brand icons they are all licensed under the Open Font License.


    • Stamen


      If you need a map, this app is awesome. It uses open licensed Open Street Map data and styles it – there’s watercolor and lithographic styles, just to name a couple. If you ever need a map graphic definitely check this out.



    • Pixabay


      This site has photography, graphics, and videos all under a CC0 license (meaning: no attribution required.) For me, this site is a relative newcomer but has some pretty high-quality works.


    • Flickr


      Flickr lets you search by license. I’ve gotten a lot of great content on there under CC BY / CC BY SA (both of which allow commercial use and modification.) (More on Flickr below.)


    • Wikimedia Commons


      You have to be a bit careful on here because some stuff isn’t actually freely licensed but most of it is. (I have seen trademarked stuff get uploaded on here.) Just evaluate content on here with a critical eye!


    • Miscellaneous Government Websites


      Photography released by the US government is required to be public domain in many cases. I don’t know about other countries as much, but I’m sure it’s the case for some of them (Europeana is run by a consortium of various EU countries for example.) These agencies are also starting to publish to Flickr which is great. NASA publishes a lot of photos that are public domain; I’ve also gone through the Library of Congress website to get images.

    • CC Search


      This is Creative Commons’ search engine; it lets you search a bunch of places that have openly-licensed content at once.


    • CompFight


      This is an interface on top of Flickr. It lets you search for images and dictate which licenses you’re interested in. Using it can be faster than searching Flickr.


    But wait, there’s more!

    Naheem linked me to this aptly-named awesome resource:


    Even more goodness there!!

    Readying Fedora 24 Design Suite

    Posted by Luya Tshimbalanga on June 02, 2016 06:21 AM
    Inspired by the article from Fedora Magazine, Design Suite received more treatment for Fedora 24 release.
    Among the features are:
    • Gimp gained new plugins: Layer via Copy/Cut and Save on Web now available on Fedora repository
    • gimpfx-foundry returns from retirement in repository
    • Resynthesizer for Gimp in Fedora now updated to 2.0
    • Inclusion Gthumb for easier renaming image files on the live media
    • Darktable is now easier to access via the main dock on Gnome Shell.

    A big thanks to Riley Brandt for the feedback, Design Team other Fedora contributors notably Gil Cattaneo and Mukundan Ragavan for making missing packages available.

    Plan to level up contributors with Fedora Hubs!

    Posted by Máirín Duffy on April 27, 2016 03:20 AM

    Fedora Hubs

    What’s going on with Hubs?

    So a little update for those not following closely to get you up to date:

    • We have a big milestone we’re working towards – a working version of Fedora Hubs in time for Flock. It won’t have all of the bells and whistles of the mockups that we’ve presented, but it will be usable and hopefully demonstrate the potential of the app as well and enable more development.
    • We have a number of fantastic interns coming on board (including Devyani) who will be helping us work on Fedora Hubs this summer.
    • pingou is going to be leading development on fedora-hubs.
    • I’m clearly back from an extended leave this past winter and cranking back on mockups again. 🙂
    • ryanlerch has upgraded hubs to fedora-bootstrap so it has a fresh look and feel (which you’ll see reflected in mockups moving forward.)
    • Overall, we’ve gotten more momentum than ever before with a clear goal and timeline, so you’ll hopefully be seeing a lot more of these juicy updates more frequently!

    (“Wait, what is Fedora Hubs?” you ask. This older blog post has a good summary.)

    Okay, so let’s move on and talk about Hubs and Badges, particularly in light of some convos we’ve had in the regular weekly Fedora Hubs check-in meetings as well as an awesome hack session Remy D. and jflory7 pulled together last Thursday night.

    Fedora Hubs + Badges – what’s old is new again

    Behold, a mockup from 2011:

    Fedora RPG mockup

    In a sense, this is actually an early prototype/idea for Fedora Hubs + Badges integration. Remember that one of the two main goals of Fedora Hubs is to enable new Fedora users and make it easier for them to get bootstrapped into the project. Having tasks in the form of badges awarded for completing a task arranged in “missions” makes it clear and easy for new contributors to know what they can do and what they can do next to gradually build up their skills and basically ‘level up’ and feel happy, helpful, and productive. So there’s a clear alignment between badges and hubs in terms of goals.

    So that was 2011, where are we going in 2016?

    First thoughts about a badge widget

    We have a couple of tickets relating to badges in the hubs issue tracker:

    As we’ve been figuring out as we’ve been going through the needsmockup queue and building widgets, most widgets have at least two versions: the user version (what data in this widget relates to me? Across all projects, what bugs are assigned to me?) versus the project version (across all users, what bugs relate to this project?) You can’t just have one badges widget, because certain data related to that widget is more or is less useful in the context it’s being viewed in.

    Today, the Fedora badges widget in Hubs is not unlike the one on the Fedora wiki (I have both the sidebar version and the content side version on my profile.) It’s basically small versions of the badge icon art in a grid (screenshot from the wiki version):

    screenshot of wiki badges widget

    The mockup below (from issue #85) shows what a little pushing in terms of working the metadata we’ve got available can do to provide a clearer picture of the badge earner via the badges he or she has won (left version is compressed, right version is expanded):

    mockup of badges widget for hubs profiles

    Layering on some more badgery

    The above mockups are all just layer 0 stuff though. Layer 0? Yeh, here’s a hokey way of explaining how we’re starting to think about hubs development, particularly in the context of getting something out the door for Flock:

    • Layer 0 – stuff we already have in place in hubs, or refinements on what’s already implemented.
    • Layer 1 – new feature development at a base level – no whizbang or hoozits, and absolutely nothing involving modifications to ‘upstream’ / data-providing apps. (Remember that Hubs is really a front-end on front of fedmsg… we’re working with data coming from many other applications. If a particular type or format of data isn’t available to us, we have to modify the apps putting that data on the bus to be able to get it.)
    • Layer 2 – making things a bit nicer. We’re not talking base model here, we’re getting some luxury upgrades, but being pretty sensible about them. Maybe making some modifications to the provider apps.
    • Layer 3 – solid gold, gimme everything! This is the way we want things, having to make modifications to other apps isn’t of concern.

    To get something out the door for Flock… we have to focus mostly on layer 0 and layer 1 stuff. This is hard, though, because when this team gets together we have really awesome, big, exciting ideas and it’s hard to scale back. 🙂 It’s really fun to brainstorm together and come up with those ideas too. In the name of fun, let’s talk through some of the layers we’ve been talking about for badges in hubs in particular, and through this journey introduce some of the big picture ideas we have.

    Badges Layer 1: Tagging Along

    An oftrequested feature of tahrir, the web app that powers badges.fedoraproject.org, is the notion of grouping badges together in a series (similar to the “missions” in the 2011 mockup above.) The badges in the series can be sequentially ordered, or they may have no particular order. Some in a series can have a sequential ordering and some not at all.

    Here’s an example of badges with a sequential ordering (this series goes on beyond these, but the example three illustrate the concept well enough):

    Here’s an example of badges that are closely related but have no particular sequence or order to them:

    You can see, I hope, how having these formally linked together would be a boon for onboarding contributors. If you earned the first badge artist badge, for example, the page could link you to the next in the series… you could view a summary of it and come to understand you’d need to make artwork for only four more badges to get to the next level. Even if there isn’t a specific order, having a group of badges that you have to complete to get the whole group, like a field of unchecked checkboxes (or unpopped packing bubbles), kind of gives you the urge to complete them all. (Pop!) If a set of badges correspond to a set of skills needed to ramp up for work on a given project, that set would make a nice bootstrapping set that you could make a prerequisite for any new join requests to your project hub. So on and so forth.

    So here’s the BIG SECRET:

    There’s no badge metadata that links these together at all.

    How do we present badges in series without this critical piece of metadata? We use a system already in place – badge tags. Each series could have an agreed upon tag, and all badges with that tag can become a group. This won’t give us the sequential ordering that some of the badges demand, but it’ll get us a good layer 1 to start. Mockup forthcoming on this, but it will get us a nicer badge widget for project / team hubs (issue #17).

    Badges Layer 2: Real Badge Metadata

    Here’s layer 2 for the feature – and I thought this would be the end of the road before Remy set us straight (more on that in the next section on layer 3):

    So this one is somewhat simple. We potentially modify the badges themselves by adding additional fields to their yaml files (example behind link), and modify tahrir, the web app that drives badges.fpo, to parse and store those new fields. I tried to piece together a plan of attack for achieving this in tahrir ticket #343.

    The problem here is that this would necessarily require changing the data model. It’s possible, but also a bit of a pain, and not something you want to do routinely – so this has to be done carefully.

    Part of this would also involve dropping our overloading of tags. Now we can store descriptions for each badge series, and store sequential ordering for individual badges, and a few other nice things tags couldn’t enable.

    If we’re changing the data model for layer 2, may as well also change it for *LAYER 3!!*, which I am emphasizing out of excitement.

    Layer 3: How the years I spent playing Final Fantasy games finally pay off

    skill tree diagram

    “A simplified example of a skill tree structure, in this case for the usage of firearms.” Created by user Some_guy on Wikipedia; used under a CC0 license.

    Remy D. suggested instead of linear and flat groupings of badges, we also add the ability to link them together into a skill tree. Now, you may already have experience with say the Final Fantasy series, Diablo series, Star Wars: The Old Republic, or other RPG-based games. Related skills are grouped together in particular zones of the tree, and depending on which zones of the tree you have filled out, you sort of fulfill a particular career path or paths. (e.g., in the case of Final Fantasy X… when you work towards filling out Lulu’s sphere grid area, you’re making your character a dark mage. When you work towards filling out Rikku’s area, you’re building skills towards become a skilled thief. So on, and so forth.)

    Where this gets cool for Fedora is that we not only can help contributors get started and feeling awesome about their progress by presenting them clear sequences of badges to complete to earn a series (layer 2), but we can also help guide them towards building a ‘career’ or even multiple ‘careers’ (or ‘hats,’ heh) within the project and build their personal skill set as well. Today we already have five main categories for badges in terms of the artwork templates we use, but we can break these down further if need be – as-is, they map neatly to ‘careers’ in Fedora:

    • Community
    • Content
    • Development
    • Quality
    • Events

    Fedora contributors could then choose to represent themselves using a radar chart (example displayed below), and others can get a quick visual sense of that contributor’s skillset:

    <script async="async" src="http://jsfiddle.net/fxs2n8s5/embed/result/"></script>

    So that’s layer 3. 🙂

    Okay, so have you actually thought about what badges should be chained together for what teams?

    Yes. 🙂 Remy D. and jflory7 started a list by researching the current onboarding procedures across a number of Fedora teams. Coming up with the actual arrangements of badges within series is important work too that has a big influence on whether or not the system actually works for end users! These suggestions Remy and Justin put together are suggestions of badges new contributors should complete while getting boostrapped and ready to contribute to the corresponding team.

    In some cases these involve existing badges, in some cases additional badges we need to create to support the scenario have been uncovered. (This is great work, because over time badges has tended to be unbalanced in terms of awarding folks involved in packaging and who go to a lot of events more than others. It makes sense – the packaging infrastructure was the first part of Fedora’s infrastructure to get hooked up to fedmsg IIRC, so the data was more readily available.)

    Here’s an excerpt of the first-cut of that work by Justin and Remy:

    1. Get a FAS Account (sign the FPCA) (Involvement)
    2. Create a User Wiki Page
    3. Join Mailing Lists and IRC Channels
    4. Contact a Regional Mentor, get sponsored
    5. Get mentor approval
    6. Attend regional ambassador meeting, introduce yourself
    1. If no fas account, create one (Involvement)
    2. Intro to commops mailing list
    3. Join IRC #fedora-commops
    4. Get with a mentor and start writing / editing blog / fed mag articles
    1. Create a FAS account (sign the FPCA) (Involvement)
    2. Join the mailing list, introduce yourself: https://admin.fedoraproject.org/mailman/listinfo/design-team
    3. Claim a ticket in the Design Trac: https://fedorahosted.org/design-team/report/1
    4. Update your ticket, send updated information to Design List
    5. Once work is approved, request an invite for your FAS username for the design-team group on the design team list: https://admin.fedoraproject.org/mailman/listinfo/design-team
    6. Add yourself to the contributors list: http://fedoraproject.org/wiki/Artwork/Contributors
    7. Attend Design Team IRC meeting? (Speak Up)
    8. Subscribe to the design tasks fedocal: https://fedorapeople.org/groups/schedule/f-24/
    1. Create a FAS Account (sign the FPCA) (Involvement)
    2. Create a GPG Key, and upload it to keyservers, one of which being keys.fedoraproject.org (Crypto Panda)
    3. Write a self-introduction to the mailing list with some ideas on how you would like to contribute: https://fedoraproject.org/wiki/Introduce_yourself_to_the_Docs_Project
    4. Create your own user wiki page, or update with new info if one exists from another prject (Let me Introduce myself Badge)
    5. Attend the freenode.net InterRelay Chat channel #fedora-meeting meetings on Mondays. (Speak Up Badge)
    6. Hang out on freenode.net InterRelay Chat channel #fedora-docs
    7. Interact with other fedora contributors (how to use fasinfo, lookup others wiki user pages, asking for sponsorship)
    8. Make a contribution: Choose an item from this page: https://fedoraproject.org/wiki/How_to_contribute_to_Docs
    9. Post to mailing list, describing which contribution you want to make, asking for feedback
    10. Post to mailing list with links to your contribution
    1. Create a FAS Account (and sign the FPCA) (Involvement)
    2. Join the mailing list and introduce yourself: https://fedoraproject.org/wiki/Introduce_yourself_to_the_marketing_group
    3. Choose a marketing task you’d like to help with, and post to the mailing list asking for feedback: https://fedoraproject.org/wiki/Marketing/Schedule
    4. Post to the mailing list with a link to your contribution.
    5. Request to join the marketing group in FAS

    Hopefully that gives a better picture on specifics, and what some of the bootstrapping series particularly would involve. You see here how a skill tree rather than badge series makes more sense – you only need create one FAS account, participate in IRC once intially, and participate on a mailing list once initially to learn how those things work before you shoudl really move on. So with this system, you could learn those “skills” joining any team, and where you complete the series for any particular team are the higher-numbered badges in that team’s bootstrap series. (Hope that makes sense.)

    Get involved in this business!

    we need your help!

    Help us build fun yet effective RPG-like components into a platform that can power the free software communities of the future! How do you start? Sadly, we do not have the badge series / skill tree feature done yet, so I can’t simply point you at that. But here’s what I can point you to:

    • hubs-devel Mailing List – our list is powered by HyperKitty, so you don’t even need to have mail delivered to your inbox to participate! Mostly our weekly meeting minutes are posted here. I try to post summaries so you don’t have to read the whole log.
    • The Fedora Hubs Repo – the code with instructions on how to build a development instance and our issue tracker which includes tickets discussed above and many more!
    • Fedora Hubs weekly check-in meeting – our weekly meeting is at 14:00 UTC on Tuesdays in #fedora-hubs. Come meet us!

    What do you think?

    Questions? Comments? Feedback? Hit me up in the comments (except, don’t literally hit me. Because mean comments make me cry.)


    El FLISoL Venezuela 2016 en Números

    Posted by Maria "tatica" Leandro on April 25, 2016 10:23 PM

    Primero que nada, FELICITACIONES a quienes organizaron cada uno de los FLISoL‘es que se dieron en Venezuela y GRACIAS a los cientos de asistentes que se dieron cita en cada una de las ubicaciones, sin ustedes, esto no hubiese sido posible. Desde mi posición como Coordinadora Nacional pude ver como 16 ciudades de nuestro país se han unido a la celebración mas grande de Latino-america, tanto en sedes grandes como pequeñas, con meses de planificación o días apenas; lo importante es ser multiplicadores de ese conocimiento que puede ayudar a muchos.

    Como varios saben, uno de mis trabajos fue colaborar con la programación de la cuenta de twitter del @flisolve , agregar las ciudades a la web flisol.org.ve y colaborar a aquellos que tenían dificultad en agregar la sede a la wiki oficial. Quería aprovechar la oportunidad de compartir con ustedes algunos números sobre como fue el FLISoL, la receptividad en la red, y el movimiento del mismo a nivel de difusión.

    <figure class="wpb_wrapper vc_figure">


    Estadísticas mes de Abril

    Top Twitt
    <figure class="wpb_wrapper vc_figure">

    Visualizaciones Totales de Abril

    Impresiones 66500 clicks

    Followers Abril

    Nuevos Followers 134 -

    Interacciones Totales de Abril

    Twits Publicados 361 -
    Menciones 640 -

    Estadísticas Día FLISoL - 23 de Abril

    Interacciones Totales - 23 de Abril

    Visualizaciones Totales - 23 de Abril

    Impresiones 13854 clicks
    <canvas height="101" width="101"></canvas>

    Trending Topic

    Interacciones Totales - 23 de Abril

    Twits Publicados 83 -
    Clicks a Enlaces 96 -
    Likes 39 -
    Reply 29 -

    Retwits 171 -
    Menciones 210 -
    Usuarios que Interactuario 162 -

    Twits por hora

    <canvas class="vc_line-chart-canvas" height="1" width="1"></canvas>
    • Twits


    Estadísticas mes de Abril

    Estadísticas del Website

    Visitas Totales Abril

    Visitas 453 clicks

    Contactos por Formulario

    Emails 95 -

    Páginas Mas Visitadas

    Home 120 -
    Ubicación 93 -
    Contacto 89 -


    Estadísticas mes de Abril

    Ciudades Registradas

    Ciudades 17 -

    Ediciones a la Wiki

    Ediciones 164 -

    This post has a nicer formatting that can be seen at it's original source at tatica.org , so feel free to hit the link and read better version!