Fedora Design Team Planet

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.

Statistics!

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!

Analysis

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.

    Location

    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.

    Demographics

    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.

    Interviews

    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

    Goals

    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.

    Competitors

    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)

    Results

    Overall

    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.

    Structure

    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.

    Thoughts

    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.

    Logistics

    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.

    Budget

    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.

    Transportation

    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)

    Food

    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.

    Newcomers

    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.

    Badges

    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!

    Fun

    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:

    Talks

    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.

    Pagure

    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.

    Hackfests

    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">
    photo_2016-08-09_08-41-47
    </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@!

    [contact-form]

    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

    Logistics

    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.

    28055771984_35dfc9fdd9_k

    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">
    photo_2016-08-03_08-40-56
    </figure>

    Escuchar

    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.

    Difundir

    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.

    Incentivar

    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.

    Apoyar

    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.

    Background

    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:

    <figure><figcaption>Pokedex!</figcaption></figure>

    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

      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.

      thenounproject.com

    • Open Clip Art

      openclipart

      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.

      openclipart.org

    • Xaviju’s Inkscape Open Symbols

      font-awesome

      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.

      github.com/Xaviju/inkscape-open-symbols

    • Stamen

      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.

      maps.stamen.com

    Photos

    • Pixabay

      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.

      pixabay.com

    • Flickr

      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.)

      flickr.com/search/?license=4%2C5%2C9%2C10

    • Wikimedia Commons

      wikicommons

      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!

      commons.wikimedia.org

    • Miscellaneous Government Websites

      loc

      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

      ccsearch

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

      search.creativecommons.org/

    • CompFight

      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.

      compfight.com

    But wait, there’s more!

    Naheem linked me to this aptly-named awesome resource:

    https://github.com/neutraltone/awesome-stock-resources

    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:

    Ambassadors
    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
    CommOps
    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
    Design
    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/
    Documentation
    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
    Marketing
    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.)

    kasapanda

    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">
    IMG_7217
    </figure>

    Twitter

    Estadísticas mes de Abril

    Top Twitt
    <figure class="wpb_wrapper vc_figure">
    toptwit
    </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

    Flisol.org.ve

    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 -

    Flisol.info

    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!

    Looking for Records, Looking for Contributions

    Posted by Sirko Kemter on April 17, 2016 09:01 AM

    A few days ago, the voting for the Supplemental Wallpaper for Fedora 24 opened. And I am impressed, how many Fedora contributors have voted so far, but I have to tell you that even I dont know the exact number yet. Nuancier is written in a way, that I cant look into the numbers before it is published. But Fedora Badges gives a little bit of an insight, but you have to see as we made that badge for the first time there was a lot of discussion about badges for voting, so it must be claimed manually and its not claimed by all who vote. But now we have already 207 badges for Fedora 24 claimed, compared to 89 for Fedora 23. So the amount of voters is already doubled and there is still nearly a week time for the votes!

    Personally I am impressed and happy to see that lot of interest in this part of Fedora. For me is the Supplemental Wallpaper Contest a so called low hanging fruit, which make it very easy possible to contribute to Fedora.

    The first step from consumer to contributor is by far the hardest and if this step is done, it becomes way easier to do more. I thinking since a long time to open the voting also to people who have not cla/fpca +1 membership. That would be from my perspective a necessary step, but I always have the fear for the quality. We reached a level of quality now, which is good but still our own contributors have a strong faible for blue, the rather would vote for an halfway acceptable blue wallpaper instead of an amazing shot of an bird.

    We already installed a weight system for the voting, members of the Fedora Design Team have an higher weight with there vote and there is also the group of Nuancier Mentors, who have also more weight for their vote.

    Originally the Nuancier Mentors was thought as a group who continuously contributed to the Supplemental Wallpaper Contest, to get them mostly out of the problem not to be allowed to vote by themselves. That´s a bit chicken-egg problem with this ¨low hanging fruit¨” you also can scare contributors them off with this.

    The Nuancier Mentors group was also thought for giving them more responsibility and improve the quality of the submissions. But its not that far implemented as I would like, as Nuancier is simple a sideshow. There is still the feature for the multi-monitor wallpaper, which is not implemented yet but ready to do so. There are also some needed features, I had this time a bit of trouble to moderate the last submissions. There are four submissions this time, who could not been moderated as I have to do for all a legal research (I had to reject this time 3 for violations, people are not aware they cant submit everything). So I need a small time between the end of submission phase and voting phase, thats right now not possible as it opens automatically and I also might need some time after the election.

    • But there are other things, who could be helpful improving the Contest. First of all we have way to many wallpaper packages, people always asking how to install them. The nicest thing to do would be to deliver them by default, replace the GNOME (and also on the other DEs) extra ones. That would be the nicest thing to do. That would make the wallpaper really prominent and might animate more to contribute in higher quality.
    • As the Nuancier Mentors group was thought for increasing the quality of the wallpaper through giving hints what could be improved with an submission that requires tiny changes in what can be submitted. Its lesser possible then to submit the work of somebody else (that would decrease the amount of legal research I have to do) as changes might require the source. But Nuancier has to be change to submit versions of a submission. And that requires some work. There is the problem with acceptance/moderation to solve then. But I think that kind of moderation can be done then by the mentors. So there is a way how to do it to find and it must be implemented.
    • Open the voting for everybody with an FAS account. I think that can be done for Fedora 25, to secure the quality, we could change the weight system a bit more, so that Fedora contributors have a higher value in vote to prevent fake-accounts and cheating votes. I really would like to open it, lets see if we can do for F25.

    But all requires some work and I am sure Pingou would be happy to get some help in implementing new features for Nuancier. But its open anyway, you can find the source code here.

    A logo design process

    Posted by Máirín Duffy on April 14, 2016 02:23 PM

    Designing a logo can be intimidating and the process full of alternating between hope and despair. I recently designed a logo for the team of a friend I work with, and for whatever reason (perhaps mindfulness practice) I decided to try to track the process visually and note my general thinking in choosing a forward direction.

    This was just one piece (albeit a major one) of a longer process. This part was just me by myself coming up with an initial proposal for discussion. I think brainstorming as a team effort produces the best results – here I took some initial direction from the team in terms of what they wanted, the look they were going for, the symbols they wanted embedded in the logo. The initial concept in the first frame reflects that opening conversation – they wanted the logo to relate to carbon, they wanted something clean (the Ansible logo was brought up as an example of a style they liked), and they wanted it to somehow depict interoperability.

    The process below shows how I came up with an initial proposal from that starting point, and then we worked together back and forth to come up with the final version (which isn’t even shown here. 🙂 )

    You can kind of see here, it’s a general cycle of:

    • Logic/brain: what might work conceptually?
    • Creativity/hand: what would that concept look like visually?
    • Evaluation/eyes: does that visual relate the idea? Or does it relate something else (that we don’t want) too strongly?
    • Rinse, repeat.

    Anyway, here it is, an example of my process; I thought it might be interesting to look at. (Apologies for the large image, and for whatever it’s worth, Inkscape was used for this; sometimes I do pencil sketches first but I wasn’t feeling it this time.)

    logo design comic

    Design Suite 23 featured by a professional photographer

    Posted by Luya Tshimbalanga on April 14, 2016 05:59 AM
    Gnokii tags me about Riley Brandt Photography Youtube video featuring Fedora 23 Design Suite first look. Highlighted positive comments are the default applications, plugins and more color management for photographers. Enjoy!

    <iframe allowfullscreen="allowfullscreen" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/mEYiafBl01s/0.jpg" frameborder="0" height="266" src="https://www.youtube.com/embed/mEYiafBl01s?feature=player_embedded" width="320"></iframe>

    Exportar un pdf multi-páginas con GIMP

    Posted by Maria "tatica" Leandro on April 08, 2016 02:01 PM

    A veces tenemos pdf’s que tenemos que editar y para ello podemos utilizar aplicaciones como Inkscape (que ya vimos en un artículo anterior) o GIMP. Al editarlos con Inkscape, tenemos la ventaja de que el contenido importado se mantiene como vectores (exceptuando las imágenes adjuntas que siguen siendo bitmaps), sin embargo, podemos editarlo con GIMP.

    Cuando abres un pdf multi-páginas en GIMP, cada una de las páginas se convertirá automáticamente en una capa (orden ascendente). Editar cada una de estas capas es muy sencillo.

    Para que el pdf quede ordenado, coloca la primera imagen en la parte inferior del diálogo de capas y así sucesivamente (tal como está en la imagen)

    Una vez terminada la edición de tu documento, procede a:

    Archivo > Exportar como… >

    Selecciona .mng como formato de salida. Si no lo ves en la lista colocalo manualmente al final del nombre de tu archivo. mng es el formato de animación de png (similar a lo que es el gif pero de mejor calidad).

    Al presionar “Guardar”, esto mostrará un diálogo en el que podrás seleccionar las propiedades del mng a exportar. Trata de guiarte por lo que ves en la imagen y presiona exportar.

    Al hacer esto, tendrás tu archivo mng creado listo para ser convertido en un pdf multi-páginas..

    Una vez tengas tu archivo exportado, abre una terminal, ubica la carpeta donde se encuentra el archivo y ejecuta:

    [tatica@anita ~]$ convert documento.mng documento.pdf

    Y eso es todo. Tendrás un pdf editado y completamente funcional que tendrá todas las páginas que seleccionaste en GIMP. Hay plugines que puedes incorporar a GIMP para realizar esta tarea, sin embargo, esta me pareció una opción bastante simple e interesante.


    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!

    Current Score Supplemental Wallpaper Fedora 24

    Posted by Sirko Kemter on March 25, 2016 01:46 AM

    Its more then a month ago, that I opened the Contest for finding the Supplemental Wallpaper for Fedora 24. Its time to give a little inside view and current score, what is going on.

    What was new this time was the limitation of submission a single user can do, and so far it suffused what it was expected to do. The quality is significant higher. Also the rejects are this time, much lower, just 2 this time after we had for Fedora 23 a new record. But I have to say its again, that some would look really look better with a little bit of work on the picture. I really hope we can integrate the “mentoring process” soon into Nuancier. The mentors group already exists, and it would raise the quality of the wallpaper more. Here are my 5 favorites so far:

    So far we have 99 submissions, and 97 are valid. 53 badges for contributions are handed out, but a lot of contributors have no badges account, and the most of them are fresh contributors. But there is still time for submissions, until 11th of April. So go make your contribution, if you not have done it yet!

    A New Logo for Hyperkitty

    Posted by Máirín Duffy on March 24, 2016 03:37 PM

    hyperkitty logo

    I was working on Fedora Hubs and I needed a nice icon for Hyperkitty for some feed widget mockups I was working on. I really love the updated Pagure logo Ryan Lerch made for pagure.io:

    pagure logo

    Pagure and Hyperkitty, you know, they are kind of cousins, so they should look like they are part of the same family, no? 🙂

    So here’s what I came up with, what do you think?

    hyperkitty logo update mockup

    (SVG available here.)

    Unpackaged Open Font of the Week: Montserrat

    Posted by Máirín Duffy on March 24, 2016 03:04 PM

    montserrat type sample

    It’s been quite a while since I’ve done one of these posts – actually, five years – lol – but no reason not to pick an old habit back up! 🙂

    Montserrat is a sans serif font created by Julieta Ulanovsky inspired by the street signs of the Montserrat neighborhood of Buenos Aires. It is the font we have used in Fedora for the Fedora Editions logos:

    03-treatment

    It is also used as the official headline / titling font for Fedora project print materials. Packaging this font is of particular important to Fedora, since we have started using it as an official font in our design materials. It would be lovely to be able to install it via our software install tools rather than having designers have to download and install it manually.

    Montserrat is licensed under the Open Font License.

     

    So, you want to package Montserrat?

    Sweet! You’ll want to follow the first steps here next to the ‘if you intend to do some packaging’ header:

    Our fonts packaging policy, which the above refers to, is documented here:

    And if you have any questions throughout the process, don’t hesitate to ask on the Fedora Fonts SIG mailing list:

     

    Document Freedom Day Phnom Penh

    Posted by Sirko Kemter on March 24, 2016 04:49 AM

    As one of the points we had to revive the Phnom Penh Linux User Group again, was to really do activities on Software-, Hardware- and Document Freedom Day and coming to a regularly meeting, which we have now each first Tuesday in the month at the iCafe. As it is the time for Document Freedom Day (DFD) we will have at our next meeting of course, a topic that fits to it. I will be showing how easily it can be done to use Inkscape for presentation slides, to bring the people to use this instead of flash, pdf or more evil prezi.

     

    The talk will happen 5th of April 2016, 8.00pm at the iCafe (next to Brother88, on 2nd floor) #196z Street 19

    ¿Eres una chica Fedora? ¡Entonces anotate!

    Posted by Maria "tatica" Leandro on January 21, 2016 01:26 PM

    No es un secreto que la presencia femenina siempre ha estado ahí, pero la mayoría de las veces no lo sabemos debido a la falta de información. Hace varios años se inició una Página Wiki con la idea de tener un listado de aquellas Mujeres que pueden proveer consejos y ayuda a aquellas nuevas colaboradoras que se inician en nuestra comunidad.

    Me encuentro en la lista que Bee(IRC nick : bee2502), quien es parte del Fedora Community Operations Team “Equipo de operaciones comunitarias de Fedora”(#fedora-commops en IRC) ha iniciado una “llamada a acción”, donde esperamos qe todas las féminas que hacen vida en Fedora puedan colocar sus nombres en la wiki para facilitarnos el trabajo de reunirnos y difundir información de interés mutuo. Como Bee dice en su email:

    <figure class="wpb_wrapper vc_figure">
    9480323700_1b94a34651_z
    </figure>

    “La diversidad en Fedora es una discusión que ha resurgido en los meses pasados, incluyendo la creación de la posición de Fedora Diversity Adviser (Consejero de Diversidad en Fedora), una posición que actualmente tiene María “tatica” Leandro. Como parte de los objetivos identificados en el Consejo Fedora, una iniciativa para promover Fedora a nuevos colaboradores con diferentes características e historias, ha sido enfatizada para el 2016.

    Fedora Women (Mujeres Fedora) es central para los esfuerzos de incrementar la diversidad. Sin embargo, para tener un mejor entendimiento de nuestras fortalezas y debilidades actuales, – trataremos de recopilar información sobre nuestra comunidad, su composición, y sus intereses y prioridades, para poder probar hipótesis, y así poder crear y ejecutar buenas estrategias. Un buen punto de inicio es simplemente agregar tus detalles FAS a la lista de mujeres actuales que colaboran en Fedora dentro de la Página Wiki de Mujeres Fedora – la cual solo tiene ocho mujeres actualmente!”

    Así que no esperes ni un solo segundo y por favor, coloca tu nombre en la wiki!
    https://fedoraproject.org/wiki/Women

    Puedes encontrar más información y discusiones en el ticket, relacionados con la instancia del Equipo de Operaciones de Comunidación:
    https://fedorahosted.org/fedora-commops/ticket/23


    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!

    A post-mortem for the Romanian Wiki Loves Monuments 2015

    Posted by Nicu Buculei on January 12, 2016 07:37 AM

    For the foreseeable future I do not intend to return as an organizer for Wiki Loves Monuments, five years of working on the Romanian edition is enough for a person, the time has come for new blood and new enthusiasm. Myself I am burned enough. And, arguably, any community project has to attract new contributors, if not perhaps it lived its life.
    Note: I won't be totally out of the picture, if there is a Wiki Loves Monuments in 2016, I will most likely contribute some pictures and if the organizers will feel a need for punctual help or want to borrow some experience, I should be available.

    With this melodramatic intro over, is the time go back to the topic: a "post-mortem" is a cold analysis of a project, made after its end, looking at what worked and what didn't. The intention for it is to be as objective as possible, a learning experience for future similar projects.

    Ansamblul bisericii evanghelice fortificate din Archita MS-II-a-A-15596Ansamblul bisericii evanghelice fortificate din Archita by Silvia Nichita, released under CC-BY-SA, winner of the Romanian competition.

    The good

    Having the fifth edition in a row happen and bring results in line with the previous editions is by itself a success. Is not trivial to have people volunteering to make it happen, sponsors to put money, contributors to participate... and having it work year after year.

    It was also a success for the team when it managed to secure the funding, first with a sponsorship from Ixia which had put the things in motion and later a grant from the Wikimedia Foundation, which allowed for a lot of activities to take place. It was useful to have the infrastructure already set-up on Wikimedia Commons, Romanian Wikipedia and the website, which is hosted by RLUG/ProLinux, as it was useful to have Asociaţia ARCHÉ handling the money, as a legal entity (traditionally, the project is run by an informal group of people and needs such legal coverage).

    ~6000 images uploaded in one month (~5600 at Commons and ~400 at Romanian Wikipedia) is a success. Compared with previous years, is not the best, nor the worst, but in the international context, we are in the top third of the 33 participating countries.

    At the first sight, 127 participants is kind of low compared with previous years (only 2013 was lower) and definitely under the 200 mark we hoped for. But that mark was optimistic, there are not many Romanian Free Software/Free Culture projects with so many contributors.

    For the Wiki Weekend expedition we had a few empty places on the bus, but in the end there are 600 images (504 at Commons and 86 more at Romanian Wikipedia) within the expedition category, which is 10% of the total images.

    Wiki Loves Monuments 2015 exhibition in Bucharest 52Photo exhibition in Bucharest

    It was for the first time we held an Edit-a-thon, so we lack terms for comparison, but any way you take it, especially for a first, is a success to have 10 participants, 702 images (628 at Commons and 74 more at Romanian Wikipedia) and 11 Wikipedia articles.

    Also a first time was the new article writing contest, where 6 people added a total of 343 Wikipedia articles, most of which are stubs, but they are at least an inviting start. Lacking a reference point, I don't know how to call this other than a success.

    The photo exhibition with winning images was open at F64 Cafe in Bucharest for about 3 weeks. The exhibition was quite small and its opening was pretty much an intimate event, so the impact was not impressive, but there is a chance for the situation to improve, if we stick to the plan and the exhibition will move to several other (and more visible places) in the coming months.

    Also, a positive is the top 10 of winning images, this is good stuff. Not only by my subjective opinion, but also the fact that one of ours makes on the international winners list.

    I left this for the last, since the social media impact is kind of a mixed bag: we ran a "photo of the day" thing for the entire duration of the contest (the month of September), which on facebook it was really weak, with a top of 22 likes for an image but on Google Plus it was much better (tenfold or better). Here I assume total responsibility for selecting and sharing the images and not spamming at all.

    Wiki Weekend 2015 la Conacul MarghilomanWiki Weekend expedition

    The bad

    From the things we did badly, the most important I consider is being late to everything. We were late to apply for the Wikimedia Foundation grant, which in turn was approved even more late. Not having the funds secured, we missed to opportunity to promote the contest in advance and may be an important cause for the somewhat weaker participation. We were late in planning and announcing the expedition, and this can explain the weak participation. We were late announcing the winners and were late awarding the prizes and opening the exhibition, thus breaking a few promises. In front of the community I can't say more than I am sorry, we did poorly with this, please don't judge us too badly for it.

    We also had a problem with the jury: one of its members simply became silent exactly when he was needed to do his part of the work. So at the time when we were supposed to count the notes, sort the results and publish them, we were in fact searching for replacements for that jury member. That was a human resources error and a lesson: do not rely on people who don't care about your project.

    Another failure was the attempt to collaborate with a traditional photography festival. There was no synergy and my estimate is that not even 1% of our final images came as a result of it. Personally I can't tell what went wrong here, as I was not involved at all with it, I could only speculate some obvious reasons, but prefer not to do that. Much like anyone else, I also wait for a more pertinent analysis.

    We had no media partners, not for the contest, not for the exhibition, not for anything. This is related to the first bad point above, being late. We didn't know in advance what we will really do, so it was not possible to forge any media partnership nor to announce our intentions in advance.

    There is also a problem with the source of the incoming images: the bulk of them came from very few people. 75% of the images were uploaded by the top 12 participants, or close to 60% by the top 5, or close to 23% by an one single person. This isn't healthy at all. Consider that the top contributor by number of images, who also was a big contributor last year, due to personal issues most likely won't be available next year, it starts to look grim. If it want to continue growing, the contest must find some new audience and new participants.

    Biserica Calvaria de la Cluj-Mănăștur, vedere sud-vestică, 2014Biserica Calvaria de la Cluj-Mănăștur, vedere sud-vestică by Pan Ioan, released under CC-BY-SA, 2nd place in the national contest, 13rd place in the international contest

    The ugly

    The thing is, in any human activity there will be parts that go well (the good) and parts that go not so well (the bad), but there are also parts which are frustrating and no matter how hard you work, they will happen anyway. In my Wiki Loves Monuments 2015 experience, those all were related to the community.

    Now I am not a newbie to the Free Software/Free Culture communities and know well what to expect: they do mirror closely any human community, so is to be expected to encounter politics, power plays, egos, hidden agendas, individuals with total lack of social skills and such. I do have the guts to deal with them, Hell! if needed I can be a versed troll too! I'm not crying here, just listing some ugly things people can expect.

    Traditionally we targeted the Romanian Wiki Loves Monuments to people outside the existing Wikipedia community, since a major goal for the project was attracting new contributors. However, this edition we tried additional things, like the article contest, which was addressed to existing contributors and even to existing heavy contributors. It went with flames, accusation of cheating and strong language. Not nice at all!

    Our organizing team as a whole was blamed for not having many Wikipedia contributions. Yes, it is true that myself, I contribute occasionally and my contributions are more likely to be to Commons than Romanian Wikipedia (as an user, I prefer to read the English Wikipedia anyway) and yes, is true two of my colleagues signed-up only a year before, when they joined the 2014 organizing team and their contributions were related strictly to the contest, but you know what else is true? For five years, every single year we ran calls for help and in all those years there was one single existing contributor even who really replied and joined the team (unfortunately, for logistic reasons his contributions were limited, he lives abroad, does not use social media and such). So I had no problem replying "pleas join the team and make this happen!"

    But don't imagine this is limited to the local community! One example is when I had the idea that nominating some of the pictures as quality images can be in itself some kind of reward for their contributors. I did not run the nominations myself, so I was not the one to be the most frustrated, but I observed the process. Most of the pictures are rejected with negative feedback from a number of people, who sit themselves on large numbers (sometime thousands) of average pictures labeled as "quality" (while winners of national or even international competitions are not good enough).

    And don't get me started on those clueless people who start talking trash on your grant request without reading it entirely or understanding the issue...

    RO IL Crama Hagianoff 10
    Almost random monument image from the contest

    Conclusion

    I guess any such writing needs a conclusion, so I'll try to come with one: running such a project can be fun, it can be even rewarding on a personal level, but for a finite while. Fresh air and a fresh perspective are needed.

    Scribus 1.5.1svn available on COPR repository

    Posted by Luya Tshimbalanga on January 11, 2016 09:42 AM
    Scribus 1.5.1svn running on Fedora 23

    After several trials rebuilding Scribus 1.5.1 using Tom "Spot" Callaway's spec file, the effort and patience finally paid off. The rpm version successfully compiled (I had to disable the devel package due to some odd built issue I have yet to find out) and is now available for Fedora 22, 23 and Rawhide under COPR repository.

    The reason for usinig the latest development version is mainly due to features not found on stable release which no longer cuts it:
    • Cleaner user interface
    • Better table implementation
    • Orphan and widow control for better typography
    • Ability to open/import other desktop publisher application like Adobe InDesgin, Quark Express and Microsoft Publisher
    • Better import of Adobe Illustrator files
    • ...and more
    An interesting feature is the chat system allowing to directly contact the community which is very helpful and should be standard to the majority of application.

    Download it, play with it, use it and report the issue to developers to make Scribus a better Desktop Publisher.

    Plan for 24 Fedora Design Suite

    Posted by Luya Tshimbalanga on January 11, 2016 03:04 AM
    • Darktable is no longer available for 32-bits x86 devices since version 2.0.
    • Calligra Krita will be available as default alongside MyPaint to match the Lab section website.
    • Majority of features come from Fedora Workstation taking advantage of Gnome Shell technology.
    • More tutorials. Users are welcome to add them.
    • On technical side, the spec file uses design-suite group list for better synchronization (user can install the suite package with the command dnf install @design-suite).