April 17, 2014

Get involved in the Fedora.next web efforts!

Lately I’ve been blogging about the proposal for new Fedora websites to account for the Fedora.next effort. So far, the proposal has been met with warm reception and excitement! (Yay!)

We Really Would Love Your Help

Two very important things that I’d like to make clear at this point:

  • This plan is not set in stone. It’s very sketchy, and needs more refinement and ideas. There is most certainly room to join in and contribute to the plan! Things are still quite flexible; we’re still in the early stages!
  • We would love your help! I know this usually goes without saying in FLOSS, but I still think it is worth saying. We would love more folks – with any skillset – to help us figure this out and make this new web presence for Fedora happen!

Are you interested in helping out? Or perhaps you’d just like to play around with our assets – no strings attached – for fun, or follow along on the progress at a lower level than just reading these blog posts? Let’s talk about where the action is happening so you can get in on it! :)

How To Get Involved

Up until this point, the Fedora.next web ideas and mockups have been scattered across various blogs, Fedora people pages, and git repos. We talked a bit last week in #fedora-design about centralizing all of our assets in one place to make it easier to collaborate and for new folks to come on board and help us out. Here’s what we’ve set up so far:

  • A Fedora Design GitHub group – I’ve already added many of our friends from the Fedora Design team. If you’d like to be included, let me know your github usersname!
  • nextweb-assets git repo – This repo has the Inkscape SVG source for the mockups and diagrams I’ve been blogging here. Please feel free to check them out, remix them, or contribute your own! I tried to set up a sensible directory structure. I recommend hooking this repo up to SparkleShare for a nice workflow with Inkscape.
  • mockups-getfedora git repo – This repo holds the prototype Ryan has been working on for the new getfedora.org ‘Brochure Site’ in the proposal.

We also, of course, have #fedora-design in freenode IRC for discussing the design, as well as the design-team mailing list for discussion.

The Fedora Websites team will be setting up a branch for the new websites work sometime by the end of next week. For now, you can take a look at the mockups-getfedora repo. You also might want to set up a local copy of the Fedora websites repo by following these instructions to get familiar with the Fedora websites workflow.

Okay, I hope this makes it abundantly clear that we’d love your help and gives you some clear steps towards starting to get involved should you be interested. Please don’t hesitate to get in touch with me or really anyone on the design team or websites team if you’d like to get started!

April 16, 2014

Design Hub Idea (Fedora.next website redesign)

So a couple of weeks ago we talked about a proposal for the new Fedora website that Ryan Lerch, Matthew Miller, and myself came up with. The feedback we’ve gotten thus far has been overwhelmingly positive, so I’ve put some time into coming up with less vague and hand-wavy ideas as to what a particular sub hub on the Fedora ‘Community Hub’ might look like. Remember, this thing we talked about:

diagram_communityhub_subhubs

We’re talking about what one of those individual little hubs might look like. The theoretical examples above are very Fedora team-centric; I would like us to follow a model a little more flexible than that in the spirit of Reddit. E.g., it should be easy to break out a new subhub for a specific topic, or a cross-team collaboration / project, etc. So the sub-hubs won’t necessarily be along team lines.

A Sub-hub for the Design Team

sub

Okay, okay, not that kind of sub. (I have a sandwich graphic too, just waiting for its opportunity. :) ) I understand pretty deeply how the Fedora design team works, the workflows and processes we’re involved with, so I figured it’d make the most sense to mock up a subhub for that team. The lovely Tatica volunteered to be the subject of this mockup. :)

This is going to be an obnoxiously big one. We’ll walk through it. Here goes:

design-hub-idea_notes

Alert Box

The first thing that should hit you is the purple alert box. (I think the color should probably be customizable from a pre-selected set of choices on a per-sub hub basis.) From looking around at various online communities and forums and chatting with folks, it seems a common meme for organizing online communities is having a set of guidelines for how the community is run. The idea with this box is that the community owners / mods can set the message, and it’ll be display to newcomers to the hub or to everybody (if it is ever updated.) It can be dismissed and won’t show up again unless the content is changed. It also links up to a fuller set of community rules and guidelines.

Moderator Box

This is kind of a meta help box. It’s in right sidebar, towards the top. It has a list of the group owners / mods; you can click on their names to get more info about them. It also has a link to the community rules & guidelines (helpful in case you closed out the alert box.) One idea we’ve been kicking around is letting people notify the mods of any issues from this widget; the tension there is making sure it doesn’t become a spam outlet.

Custom subhub banner

Following Reddit’s lead, there’s a space below the main navbar designated for the subhub’s branding. Some of the subreddit artwork I’ve seen isn’t the best quality though. We’ll probably offer a design team service to design the banners for different subhubs in the system. We can also provide a precanned set of nice backgrounds that teams can choose from. The way we’re thinking the banner will work is you can set a repeatable background tile, and then set a graphic that will be displayed left, center, or right.

User / profile config center

This isn’t mocked up yet; the vision there is that it would let you visit your profile page and would also provide a lot of the functionality you have in the FAS2 website today: change your password, change your ssh key, location, etc., as well as manage your group memberships.

Messaging center

This one is also not yet mocked up. It will likely be getting its own blog post soon. There’s a lot of different types of messages/notifications a user could get, so I think we need to sit down and catalogue the ones we know about before mocking anything up. I think it might also be cool to have a place to save/store stuff you like; like a favorites list you can refer back to later.

Nav bar

Okay, so here’s the idea with the navbar. It’s another Reddit-inspired thing. Users logging in for the first time with fresh FAS accounts by default will have a few select hubs in their navbar – perhaps ‘front,’ ‘planet,’ and ‘announce.’ (‘front’ could be maybe some kind of aggregation of the most popular content; planet would be a hub that basically repeats Fedora planet maybe, announce would basically mirror the Fedora project announce-list.)

Once a user joins different FAS groups – or if they are already a member of FAS groups – the hubs associated with the groups they are a member of could appear in their navbar. So here, you see Tatica has ‘designteam,’ ‘ambassadors,’ ‘marketing,’, and ‘LATAM’ subhubs in her navbar, as an example.

You can customize your nav bar by hitting the ‘edit’ button on the far right side of it. Maybe there could be a directory of subhubs across the system when you click on the ‘hubs’ logo in the upper right, and you can add them to your nav from their as well.

Subhub meta bar

This is the topmost widget in the right-hand sidebar. It gives you an idea of how many people are ‘members’ of the subhub (analogous to how many people are members of the FAS group it’s assocaited with,) and how many people follow the hub (‘subscribers.’) It also provides a mechanism for you to subscribe or unsubscribe from the hub.

Example Hyperkitty post

There’s an example post, ‘Fedora Design Github org,’ that I posted to the design-team mailing list a few days ago. This is mean to show how a post from Hyperkitty could appear in this system. The thought / hope is that we could use the Hyperkitty/Mailman API to send comments, or at the very least simply display them and link back out to Hyperkitty for replying and reading other posts.

Alternatively, we could just have a widget for the design-team mailing list, and not integrate posts into the news stream on the hub. We could instead show some of the Hyperkitty widgets currently displayed on list overviews, like the most active threads list or the most recent threads list. That’s another way to go. I’m not sure what’s best yet. Maybe we give subhub owners a choice, depending on how much they actively use the mailing list or not in their particular community.

Glitter Gallery post

We have another example post below the Hyperkitty one; this one is an example Glitter Gallery post. You can view the artwork and make comments on it, and the comments should get sent back to Glitter Gallery.

Example blog post

Further down the main news feed area we have a small snippet of a blog post to show how that would look in the subhub context. The idea here is that the design team has a subplanet on planet.fedoraproject.org associated with it – planet.fedoraproject.org/design – so those posts could show up in the chronological news stream as well.

Chat widget

Another idea in the right-hand sidebar – inspired by waartaa and ideally driven by it – a little chat client that connects to #fedora-design on freenode IRC, where the design team tends to hang out. I do not think the backlog should be blanked on every page load – I think there should always be at least a few hundred lines of backlog stored with the subhub so anybody coming in can follow the conversation from before they joined that they missed out on. It’ll let folks catch up and participate. :)

Nauncier widget

This is just a simple little widget to show that widgets don’t have to be complex – this one drives users who haven’t yet voted on the Fedora supplemental wallpapers to go and vote!

Ticket Widget

The design team has trac queue where we accept requests for artwork and design from across the project. It might be nice to inspire folks to help out with a ticket by having available tickets listed right there. It might be some good motivation too – if someone finishes a ticket or posts something to a ticket – that would be shown in the feed too. When you do good work and complete something, or submit something and are looking for feedback – you’d get more exposure by having that broadcast to the subhub news feed.

Some thoughts

Okay, so hopefully that little tour through the mockup made sense. What do you think?

Overall, I would like to point out that as with Hyperkitty, the design principle here is the same – we do not want to displace folks who are already happy with the tools they use and force them to log into this web system and use only that. If someone posts a reply to a mailing list post through this hubs system, the reply should get send back to the mailing list as a reply and should be perfectly readable by folks using only a mail client to receive postings by email. If someone sends a message in the chat, folks using a traditional IRC client in that channel should be able to see that message and communicate with the sender without issue. The hope here is to bring things together to make it easier and less intimidating for newcomers without sacrificing anything on the current contributors’ side.

I’d love to hear your thoughts in the comments!

The SELinux Coloring Book

selinux-comic-book-thumb

Dan Walsh had a great idea for explaining SELinux policy concepts in a fun way – creating an SELinux coloring book! He wrote up a script, I illustrated it using my Wacom in Inkscape on Fedora, and we turned it into an opensource.com article. Still. We needed physical coloring books, and what better place to hand them out than at the Red Hat Summit?

We got them printed up and shipped off to the Summit (some in assorted volunteers’ baggage :) ), and they’ve been so popular that Dan is getting close to running out, except a reserve he’s kept for the SELinux for Mere Mortals talk later today. We also handed out some slightly imperfect misprints in the Westford Red Hat office, and we’ve been told a co-worker’s daughter brought hers to pre-school and it was a big hit – the other kids want their own. When it comes to SELinux, we’re starting ‘em young on the setenforce 1 path. :)

How might you get your own copy? Well, we’ve made the coloring book, including the text and artwork, available under a Creative Commons Attribution ShareAlike license. So download, print, share, remix, and enjoy! :)

April 10, 2014

Como construir presentaciones online: Comparación de servicios

¿No has deseado tener una herramienta online de fácil uso para crear excelentes presentaciones? ¿No sería genial compartir charlas interactivas-online con tus amigos? Estas son algunas de las preguntas que me hice y luego de una busqueda (y la recomendación de amigos) me encontré con Slidifier y Slides. Slidifier es una herramienta para crear presentaciones simples e informales. Simplemente escribes lo que quieres en la caja de texto y presionas el botón “slidified” y eso se convertirá en una presentación lista en tu navegador; mientras que Slides te provee con una interfaz más completa para crear, agregando algunas opciones.

slidifier

En Slidifier, una vez que escribas tu presentación en la caja de texto, solo preciona “Slidify” y tu presentación se mostrará. Puedes navegarla utilizando las flechas o el botón izquierdo del ratón. La tecla de escape te sacará de la presentación y te llevará a la caja de texto nuevamente

Slidifier es creado por Holger Ludvigsen y Espen H. Halvorsen. Puedes ver su desarrollo en Github.

Slides

En Slides, hay una simple interfaz con una gran variedad de temas y transiciones para escoger,para que te asegures de que las cosas se muestren y muevan como quierasn. También puedes usar dispositivos touch (como tu tlf) para manejar la presentación. Slides también tiene un plan pro, donde prácticamente pagas es por más almacenamiento y descargas; lo cual no es malo para alguien que crea muchas presentaciones, digamos un profesor o alguna compañía.

Slides fue fundado por Hakim El Hattab y Owen Bossola a principios del 2013. Utiliza reveal.js, un framework opensource hecho por Hakim en el 2011. puedes ver el about de su página en slides.com

slides

No importa cual escojas, lo bueno es que existen opciones y estas tenerlas a la mano es útil de vez en cuando. Asegurate de crear excelentes presentaciones sin pensar mucho en el tiempo que debes gastar aprendiendo aplicaciones complejas :)

A license to print money
We learned (link in Romanian) the Romanian government is negotiating with Microsoft for a Windows XP support extension in the public administration. This is the free market at work and there may be solid arguments for doing so (yes, I would prefer my tax money to be spent on Free and Open Source Software instead of making business with a convicted monopolist, but realistically I don't expect this to happen in the foreseeable future).
My source of amazement is: once the patches and the delivery infrastructure are set for the first government (UK), then the costs for adding any subsequent government is approaching zero: computers in Romanian administration usually have Windows installed in English, so there is nothing to translate, the infrastructure to deliver patches is there and the network costs are the same or lower (presumably patches fro XP are smaller in size as patches for Windows 7).Apparently ending support for XP makes a lot of business sense for Microsoft, they suddenly started receiving important sums of money for things they did only a week ago for free. Who would refuse that?

April 09, 2014

Enabling Participation

With 3.12 out the door, it’s time to think about what we want to be doing for 3.14. I have a long list of design projects that I want to work on for the next release, but I also want to spend some time on how the GNOME project is working and how we can improve it.

One of my reoccurring interests is how we, as a project, can ensure that each module is in a healthy state. We want modules to have active developer teams around them, and we want it to be easy for people to get involved – not just because it is good for our software, but also because openness is an important part of our mission.

This interest in helping people to contribute isn’t just reserved for new, inexperienced contributors. There are experienced coders out there who are interested in GNOME but haven’t found a way in. Even members of the GNOME project itself don’t always know how to contribute to different apps and modules.

Making it easy for people to contribute takes work. Simply putting the code online is not enough: we need to provide potential contributors with the information they need, and we need to give them feedback and support as they work. We need to enable them to participate by creating the conditions in which it is easy to contribute.

There are a number of reasons why people sometimes find it difficult to participate, and we aren’t going to solve them all overnight. Thinking about this topic, though, one of the main reasons why people struggle to contribute is that it is difficult, if not impossible, to know which tasks to work on. In my opinion, the way that we manage bugs in GNOME is a major factor here [1].

In GNOME we often don’t do a good job of indicating which bugs we want to be fixed, and we don’t spell out what needs doing to fix them. This leaves potential participants with no way to contribute. A long list of unconfirmed bugs, often with no guidance on what needs to be done to resolve them, is a brick wall. It can be the end of the story for potential contributors.

This is the issue I want to address. Interestingly, though, improvements in this area can also help with other aspects of project management: if we are clear about which bugs we want fixing, it prompts forward planning, and it stimulates discussions about which issues should be prioritised over others. It also creates opportunities for conversations about the direction of modules, which can help to include contributors in taking on leadership roles.

To make it easier for people to participate in GNOME, our bugs need to be organised so that they give clear guidance about where contributions are needed. This requires that we have a different process for how bugs are processed and categorised. I’ve spent some time talking about this with various maintainers, as well as members of the Bug Squad, and I have come up with a set of procedures that could work.

This procedure won’t be for everyone, and I am not proposing that GNOME adopts it on a project-wide basis. What I am suggesting is that a small number of applications try it out for the 3.14 cycle as an experiment (I’m focusing on applications because I think they are the best place for new contributors to get involved). If it has a positive impact, then we can think about involving more applications in the following cycle. If it doesn’t, then that’s fine: we’ll have learnt something.

How it could work

The main goal for the bug management procedure I’ve come up with is to remove uncertainty from bug reports. This is something that we are bad at: thousands of ambiguous bugs sit in Bugzilla, which contributors have little chance of knowing what to do with. The procedure uses this schema for bug reports that are on the path to being fixed:

  • UNCONFIRMED: new bugs that haven’t been validated. These reports are uncertain – they might not correspond to real issues.
  • NEW: reports that have been validated, and therefore correspond to actual issues.
  • NEW with “needs_design” whiteboard: valid bugs that are waiting for a design to be produced in order to fix them.
  • NEW with “available” whiteboard: NEW bugs that are ready to be fixed. These bugs should have an identified solution which has been stated, and they shouldn’t be blocked by other bugs.

In this schema, “available” bugs are the reports that you point potential contributors to. They are items of outstanding work that can be tackled today. You can link to the list of these bugs from your wiki page, blog posts, or IRC topic. Having an available status is also helpful to maintainers: it helps them see which tasks are pending.

This bug schema also makes UNCONFIRMED a meaningful category. These are the bugs that triagers and maintainers need to process in order to give them a definite status. A large or growing number of UNCONFIRMED bugs in your product is a sign that you need to do a sweep through to clean them up.

In this approach to bug management, you need to regularly review bugs that don’t fall into the “available” category, in order to try and resolve them, either by identifying a solution (and therefore making them available) or by closing them as WONTFIX or NOTABUG or so on. It’s a fairly aggressive approach, in which you have to routinely say what is desirable and what isn’t, but in doing so you open the doors to new contributors who know what the project wants and how they can help.

What’s going to happen next

My plan for 3.14 is to trial this bug management approach with a small number of applications. I’m already working with Debarshi on the Documents bugs, which he has blogged about, and I’m also looking at Contacts with Erick. Once one or two more applications are involved, I’ll post an update on how to get involved.

We want to see if this approach helps to attract new contributors and to manage projects more effectively. We also want to see if the bug classification schema needs to be improved in any way. Towards the end of the cycle, I’ll be talking to people to see how they think it went: was it useful? Do any changes need to be made? Would you recommend this approach for other modules?

If you’re an application maintainer and are interested in this initiative, I’d love to hear from you. Also, I really, really want to hear what people think about the classification schema and the process around it.

[1] I realise that, in focusing on bug reports, I am restricting this to code contributions. In doing so, i don’t mean to suggest that patches are the only way to contribute to GNOME. This is merely a way of enabling participation in one – obviously important, but by no means exclusive – area.

April 08, 2014

On the Mozilla scandal

Like many of you, I too received the Mozilla email about "helping" with communications regarding the "activities of the past week", which is an euphemism for the Brendan Eich scandal. It comes with a FAQ you are expected to quote when talking about the issue.

Since all communications from Mozilla on the topic were opaque, either in blog posts with comments disabled or emails from generic addresses where is useless to reply, I finally decided to write something. Anyway, April 1-st, when I learned about the topic, wasn't a good day to write about serious issues. It may be not me my business what happens inside the Mozilla corporation, but if the Mozilla community feels a need to guide my public communications about it, then maybe it is.

So I am totally unhappy with Mozilla to caving-in to pressure from bullies. It creates a serious precedent and a slippery slope. What's the next step? Once a new CEO is announced, no matter who he is, the browser will be blocked by anti-gay websites? It looks like we are going towards a Balkanized web, where the "best viewed with [Internet Explorer|Netscape Navigator]" buttons are replaced by "blocked for browsers whose CEO have private opinion X".

Seriously, instead of personal political opinions of the Mozilla CEO I was more concerned about him wasting resources on the mobile OS unicorn while the browser looks more and more like a Chrome copy-cat.

April 07, 2014

LGM 2014

I have just returned home from this year’s Libre Graphics Meeting, which was held in Leipzig, Germany. As always, it was a great event, which is somewhat unique in bringing together art and design practitioners with programmers and engineers.

LGM is a good opportunity to meet with friends in other projects, especially graphics applications. I was really happy to be able to spend time with members of the GIMP and Inkscape projects, and hope that this will lead to closer ties and working relationships in the future.

GNOME and Libre Graphics have a lot in common. GNOME design uses free tools developed by the Libre Graphics community, and we practice open design in the way that many of those at LGM also do. I think that GNOME also helps to bring people into the Libre Graphics community, and it was nice to see a good contingent of people from GNOME at LGM this year. This is something that Jakub and I talked about in our presentation on the last conference day.

The Libre Graphics community is creative and passionate, and I always feel refreshed after LGM. Big thanks to the organisers for putting on another great conference.

April 01, 2014

A proposal for Fedora’s website (considering Fedora.next)

(I’d like to apologize upfront, in that I meant to post this about a month or so ago. You might be aware that the Red Hat Summit is coming up in 2 weeks, and I’ve had a few odds and ends to take care of for that event that cut to the front of the line on my task list because of their imminent deadlines!)

So, Fedora.next is shaking Fedora up a bit – enough that our current fedoraproject.org website is going to need a bit of a gut reno to appropriately reflect the new world of Fedora! A few weeks back, Ryan Lerch and I had an informal brainstorming session about how to account for Fedora.next with fedoraproject.org. We came up with what we thought was a pretty workable concept, and met with Matthew Miller a few days later to see what he thought. Here’s the whiteboard of what we came up with:

Fedora.next whiteboard

Whoah, what’s going on here? Okay, let’s walk through this.

The Proposal

There’s several website components to this proposal. We’ll go through each one-by-one. We have some thumbnail mockups of each site to give you a vague idea of the kind of thing we’re thinking of – there are no larger, detailed mockups at this point, except that I think Ryan is working on a prototype of the Brochure site with the websites team, which I think he is planning to blog about soon.

A Fedora ‘Brochure’ Site

fedora-next_brochure

So first, let’s create a Fedora website to allow people to learn about Fedora – the Operating System, you know, the sausage we’re making here – and to be able to download it. Ryan and I started calling this the ‘brochure’ site because it’s really informational and aimed at people who have never heard of Fedora before and want to learn more about what it is. It’s also aimed at people who know what Fedora is and use it, but who simply want to download it and get on with their lives. It’s not primarily aimed at contributors.

Some of the sites we were inspired by when coming up with this idea:

  • getfirefox.org – simple and clean website introducing what Firefox is, with a prominent single download button, features list, and tour as well as links out to more information about add-ons, support, and Mozilla.
  • google.com/chrome – short and sweet introduction to Chrome, with a prominent single download button, screenshots, feature list, and some chromebook / chromecast stuff.
  • android.com – clean layout with basic information about Android. It also includes news updates, which the other two didn’t.

Do you think this makes sense to have? It might be cool if we could give it its own domain to separate it out from contributor-centric stuff.

A Fedora User Support Site

fedora-next_user-support

Right now, there’s a lot of places within Fedora you can get help. To a newbie, it’s not really clear what the best place to go is. We’ve had ask.fedoraproject.org set up for a while, and it has the potential to become a really useful knowledgebase of help for Fedora users – if only it had enough prominence for more folks to start using it. In this proposal, then, we’re elevating ask.fedoraproject.org to a more prominent position – and having it linked it strongly with the brochure site. We’ll skin it to match the new brochure site as well.

The idea for this site is to be targeted primarily at Fedora users. We could, however, have another instance set up for contributors to ask questions about how to do things within Fedora and get help.

Further on down the line, it’d be really sweet to have Fedora desktop integration with the support site, so you can ask questions and get notifications when answers to your questions are available from the desktop. Maybe?

What do you think?

The Fedora ‘Commnunity Hub’

diagram_communityhub

Okay, so here’s where things get more complex. Full disclosure, too – we’ve tried doing something like this a couple of times now and honestly failed to get wide adoption and also to expand the functionality across Fedora’s disciplines. Hopefully, third time’s the charm! :) Perhaps there is something inherent in this idea that is fatally flawed, though. What do you think?

Well, let’s talk through it, first. It’s inspired by a lot of currently-popular social media sites; we’d really like it to be a place that Fedora contributors would feel compelled to visit daily and refresh throughout the day, depending on how actively they are working on Fedora that given day. (Whether or not we’ll achieve that, of course, we really can’t say or guarantee.) Here’s some of the features this hub would have:

  • Logged out mode has new user signup flow: Similar to how Twitter and Facebook operate when you’re logged out of them in a web browser, we were thinking that if you’re not logged into the hub, we don’t know what content would be the most appropriate to show you, so rather than risk a bad experience, let’s just prompt you to log in. This also gives us a nice clean space to promote new account signups. From the logged-out page, we could create a guided Fedora Account System (FAS) account creation flow (that uses FAS as a backend, of course) to help ease users into becoming contributors.
  • FAS integration: Speaking of FAS, we were thinking it might be nice if some of the basic account management tasks you do in FAS today were available from this site. E.g., change your password, email address, sign up for groups, that sort of thing. Maybe we could build out a groups UI and make the FAS groups we have more social (well, the groups that serve as more than just an ACL for something else. Maybe we could filter out the ACL groups?)
  • Messaging / notification tray: Another inspiration from various social media sites, we were thinking about having a messaging / notification tray along the top of every page in the hub. If there is new content available in one of the streams you’re subscribed to, or maybe if someone has sent you a message or you have a build that’s finished or what not, it’ll pop up as an additional item in your messaging tray. You can see in the ‘logged in’ thumbnail mockup above that the messaging tray has been expanded and shows a bunch of items. Click on any given item and you’ll be taken to the full details for that item, whether it’s a finished build in koji, a new update in bodhi to a package you watch, or a Fedora badge you’ve just been awarded.
  • Reddit-like spaces: Fedora is a really big project. We’re big enough and have enough teams and efforts and things going on that I think a global nav to encompass all that we do would be too unwieldy and out-of-date a few days after it was created. We’re more fluid than that. So I really like the idea of how Reddit organizes space within itself – users create spaces (‘subreddits’) that operate roughly under their own governance, and can customize those spaces (albeit in somewhat limited ways, a logo and custom banner I think.) New spaces can be created on an as-needed basis. Every space is basically a forum; each post has threaded comments and there is a voting system both for posts and for comments so the best content bubbles up to the top. We had the idea that we could organize the community hub in this fluid fashion – prepopulate the system with some established spaces, like for the Fedora Design team, Infrastructure team, and maybe the working groups and Fedora.next and projects like that. We’d allow Fedora community members to create and manage their own spaces too, and allow them to customize those spaces to their teams’ needs.

Let’s talk about that last point a little bit more in-depth, since it’s really core to how we were thinking this community hub could be organized.

Sub-hub-hubs and a bottle of rum!

diagram_communityhub_subhubs

Ideally, the spaces for various Fedora teams and projects on the community hub wouldn’t be limited to forums – we could build out custom widgets that each space could make use of, and tie those widgets into data coming in from fedmsg, for example.

You can see some (very, very rough) thumbnail mockups of what different hubs might look like above. Let me walk you through my brain using these thumbnails as a guide:

  • We’ve got an Ambassadors hub that shows a map of current ambassador activity, a swag gallery (lower right) and some discussions (courtesy Hyperkitty?) in the lower left…
  • There’s a Development hub with a list of builds and updates along the right column and devel-list discussions as well as announcements in the main content area…
  • Of course there is a hub for the Design Team with a widget to show recent mockups / designs, design-team list discussions, an asset search box, and a list of recent tickets along the right…
  • Finally, a Marketing hub with recent articles about Fedora from the press aggregated on top, with marketing-list discussions on the bottom, and recent Fedora magazine post along the right sidebar.

The specific content I walked you through on each thumbnail mockup above? It could all be totally bogus. It is a lot of work, figuring out for each team and project, what would be the right content to offer, and how to place it, and how to design widgets that would best hold it. To a certain extent, we’d like each subreddit subhub moderator/admin to create the default content offering, and maybe even allow users to customize for their individual needs further on top of those defaults. We do have to offer some basic tools and feeds, though, to make any of that possible.

You can see in our initial whiteboard that we walked through with Matthew (in the lower left corner) a list of the ways that different teams / efforts have overloaded the wiki to achieve what they needed:

  • development docs
  • personal pages
  • SIG pages
  • strategy
  • workflow (e.g., QA, design, rel-eng)
  • packaging policy
  • meeting minutes
  • team organization
  • asset management (e.g., the design team’s SVGs and PDFs!)
  • event management (pre-Flock, sign up for FUDcon in this wiki table!)
  • standard test procedures
  • UI specs (like this)
  • user documentation
  • community policy

Maybe some of these things would be better served by mechanisms made for working with them? Maybe we could design and build widgets or tie-ins to pre-existing infrastructure (like meetbot for meeting minutes, as an example) that would help manage these better than a wiki?

Getting flashbacks about early 2000′s web portal design? Yeh. We’re not trying to go there, honestly. Think about a model more similar to Facebook’s groups and apps, if you use Facebook.

On a per-user basis, the user might have a favorites bar or nav bar along the top prepopulated with the subhubs affiliated with the Fedora groups they are a member of. The user could customize this, to remove the subhubs they don’t want in their navbar and to add additional ones.

Does any of this make sense?

Well, what do you think? Ryan and I met with the Fedora websites team a few weeks ago or so to talk through the idea after working up this proposal with Matthew Miller. They were very supportive of the idea. So, we have had some designer-crazy checks up to this point; it can take a village to suss out designer-crazy sometimes, though, so do let us know your thoughts on this!

If need be, we can modify the plan, come up with a new one, or start blazing forward towards making this one a reality. We’ll need your feedback to figure out what to do. So, what do you think?

Addendum

I found this lurking in my Fedora People ~/public_html from 2009 – we’ve thought about this kind of split of the website before, and even thought about hubs (although not necessarily a platform for fluid hubs as in this proposal):

fedora-model-1

By the way! The scribbly font I used in the mockups is called ‘Redacted’ – it’s an Open Font License font that is really handy for when you want to whip out some quick mockups and don’t want to bother with lorem ipsum text. You can snag it from this link.

March 25, 2014

Hyperkitty at the 0th SpinachCon
SpinachCon - The gnu has spinach in his teeth!

SpinachCon – The gnu has spinach in his teeth!

As part of the greater LibrePlanet 2014 festivities, Deb Nicholson organized the first SpinachCon at Industry Lab in Cambridge MA, sponsored by the Open Invention Network.

What is SpinachCon?

“What the heck is a SpinachCon?” you may ask. Well, the idea is that there are free software projects that have niggling usability issues. Like pointing out to a friend that they have spinach stuck in their teeth, SpinachCon is an event where free software fans can show up and let the participating free software projects know whether or not they have ‘spinach in their teeth,’ and between what teeth that spinach might be. :) It’s basically a fun and informal free software usability testing session open to anyone who would like to drop by and help out by testing software.

13409182604_22085421aa_b

Hyperkitty joined three other free software projects – MediaGoblin, LibreOffice, and Inkscape – in the event.

How it worked

SpinachCon was 5 hours long, from noon until 5 PM the Friday before LibrePlanet. Each project had its own table. Ryan and I brought laptops that we set up on the Hyperkitty table, open and logged in as me to the Fedora’s Hyperkitty test server. Deb provided user questionnaire sheets that we stacked on the table, and I had also written out a set of six tasks for users to complete during their testing. I transcribed those into a text file in gedit, and we used USB sticks that Deb brought to transfer the file to the other laptop. We kept the gedit buffer open on each laptop.

Lunch was generously provided by the Open Invention Network, so we both grabbed some pizza and salad and let Deb know when we were ready for our first testers after we finished eating. We had a steady stream of testers throughout the entire length of the event.

Our per-user workflow was as follows:

  1. Open up the task list text file in gedit and save a copy coded with tester number. (This completely fell apart because the ability to save a gedit buffer with another file name has been taken away in Fedora rawhide. :( So we ended up copy/pasting buffers from one tab to another, it was hectic and stressful and our numbers got out of sync with our testers so we can’t associate questionnaires with tester task text files.)
  2. Introductions with tester, ask tester to sit down at appropriate laptop.
  3. Ask tester if they’ve used mailman before, and explain to them a little bit about what Hyperkitty is and how it works.
  4. Show the tester the gedit buffer and explain it has a list of tasks for them to complete, and that we’d like them to take notes and answer the questions as they complete the test.
  5. Sit with the tester and watch them complete the tasks, answering any questions they have and noting any issues or comments that came up as they went along.
  6. Thank tester for completing test, ask them to fill out questionnaire. (We forgot to have one of our testers fill out a questionnaire. Oops!)

Ideas for Running a Smoother Test Next SpinachCon

Based on some of our goofs / mishaps this time around, here are some suggestions for the next time we go to SpinachCon – please feel free to use these to prepare your project for SpinachCon in the future!

  • Bring enough Laptops! SpinachCon was held at a co-working space that didn’t have a computer lab. We didn’t realize until the week of that we’d need to bring laptops to the event for testers to use. I was hoping to use my own laptop to take notes, but it turned out to be fine to not have it to use in that capacity. We brought two laptops so we were able to run two tests at once. That worked well, since there was only two of us (me and Ryan) admining the test. I’d make sure you have one laptop per test admin so you’re not stuck waiting on a laptop to open up.
  • Grab enough blank questionnaire sheets! We ran out of questionnaire sheets and weren’t sure if there were any more blank ones available. I did track Deb down and get more, but I think for a 5-hour event, if each team has at least 20 sheets, they shouldn’t run out.
  • Bring plenty of paper and pens! I brought a paper notebook to take notes in and misplaced it. I ended up using the back of one of the filled out questionnaires to take some notes. Some testers brought laptops and wanted to use their own laptops, so we needed somewhere to write down the URL for them to go to. We also only had one pen at our table. Bring pens! Bring paper notebooks!
  • Take photos! I took photos of our testing process, with the permission of the folks sitting at the table. (I’ve used them in this blog post.) This is a good idea to do at the event, because it makes recap blog posts like this more interesting. :)
  • Assign numbers to testers and use to correlate data collected! If you are saving data about users on the computer and want to correlate that with your testing sheets, assign your testers a number before their test begins, and coordinate with any other test admins. How Ryan and I could have coordinated (and didn’t think to, until it was too late) was one admin gets even numbers, the other gets odd. So my testers would be #1, #3, #5, etc., and his could have been #2, #4, #6, so on and so forth. Write the tester number on the questionnaire sheet at the beginning of the test, save out the blank task question buffer in gedit as ‘test-$NUMBER.txt’ where $NUMBER is the tester’s assigned number, then hand the same sheet to the tester to fill out when they’ve completed the tasks. (A note for me: use vim, not gedit.)
  • Collect data on paper rather than electronically! Can you tell I’m frustrated by the issues we ran into collecting the user’s notes in text files? If I had been smart and prepared, I would have typed out the task list into LibreOffice and printed out a stack (At least 20 copies) and had the users refer to it and write their feedback using pen and paper during the test. Then it would have been easier to correlate the task sheets with the questionnaires – just staple them, or write on them, or fold them together, etc.
  • Test out your tasks before finalizing them! We realized after the first test that the wording in one of the tasks was confusing. Oops. We were able to update the gedit buffers (with great pain) on both laptops afterwards, but yeah. Test your test before you run it. Doh!

13408918443_ec3aa55103_b

What were the tasks for Hyperkitty?

Ooh! Do you want to try at home and let us know how you did? You know, that would be quite lovely! Anyhow, here’s the list of tasks:

  1. You’ve got a crazy inbox and you’re really not happy about signing up for high-traffic mailing lists. Based on this, would you rather sign up for the devel list or the astronomy list?
  2. Some of the lists on this system are kind of dead; some have a lot going on. Name some of the lists where there’s a lot going on – people actively making discussions.
  3. You’ve heard about Fedora’s development list (“devel”) and decided to look into it. Who are you likely to hear from if you read that list?
  4. In March 2012, there was a discussion about GPT and Fedora 17 on the devel list. Can you find it?
  5. Find a post you like an add a tag to it so you can find it later.
  6. Start a new discussion on the Fedora users list (“users.”)

If you’d like to play at home, visit lists.stg.fedoraproject.org and let us know how you did in the comments!

So, what did you learn about Hyperkitty?

Our full test results, including the full text from the user’s task notes buffers as well as the user questionnaires (listed in full per user as well as across user per question), are available on the Hyperkitty trac wiki:

At a high-level, we drew a few pretty strong conclusions from the testing experience:

1. Hyperkitty’s search needs more work.

Only 1 of the 8 testers was able to find the GPT posting from March 2012 in task #4! Suggestions the users offered here included:

  • listing more than 10 results per search results page
  • allowing users to sort the search results
  • allowing users to search only within a certain time period (e.g., only in March 2012)
  • simplifying the search results listing of posts
  • making the search box easier to find / more apparent
  • have an ‘advanced search’ page with a lot more searching tools
  • filter search results to only threads you were involved in

2. The users enjoyed Hyperkitty’s look and feel.

Multiple testers asked me about how to set up Hyperkitty for their own usage after completing the test. Hyperkitty earned the following average user ratings on the user questionnaire:

  • Aesthetics: 8.4 out of 10
  • Intuitive: 8.0 out of 10
  • User-Friendly: 7.6 out of 10
  • Professional: 8.6 out of 10

3. The left-hand nav / filters for the mailing list overview weren’t visible to users.

Only one of the 8 testers discovered the left nav on the hyperkitty list overview that would have allowed them to sort the lists by popularity (making task #2 super-easy!)

4. Users didn’t seem to notice the search box.

Only a few of the users noticed the search box. Most users, while on the devel list overview page, noticed the year/month listings in the left nav and clicked to March 2012 when completing task #4. Only a few tried to use search, and most only after browsing to March 2012 first.

5. Tagging needs more work.

Aaron, one of our testers, had a lot of interesting thoughts on making tags useful. For example, we should suggest tags already in use in the system (maybe via tag cloud, maybe via some other mechanism) to prevent users coming up with different tags for the same thing (or at least, preventing that as much as possible.) Some of the users also had a hard time finding the tags – they are associated with threads, not individual posts, so they are on the right-hand side of the thread view. Another issue that came up – some users weren’t sure if the tags were for their own personal usage or if they were viewable to everyone in the system. (The latter is the case!)

Summary

Overall we got a ton of great ideas, feedback, and information from SpinachCon, and it was a really valuable experience. Deb mentioned we may be doing another SpinachCon in the Boston area later this spring; I am totally excited to bring Hyperkitty to SpinachCon again then!

BTW, here’s a screenshot of how Hyperkitty looked to testers, for posterity / comparisons at the next SpinachCon:

hyperkitty-ss

Thank you the Open Invention Network for sponsoring such a great event!

Looking Forward to 3.12

applications

I usually do a review of what is coming in the run up to a release. However, there have been so many blog posts about 3.12 already that I don’t feel I need to go over individual features. If you haven’t read Planet GNOME in a while, now is a good time to check it out: there’s lots of great content on there right now.

It is worth looking at what the individual features in 3.12 add up to though. A release is more than the sum of its parts, and this is especially true of 3.12.

One important thing you will see in 3.12 is that, more and more, GNOME’s core applications are coming together. Videos will look and behave like a GNOME 3 app: it will let you browse your content, and it offers a modern, streamlined viewing experience. gedit has also had the GNOME 3 treatment. It has retained all its existing functionality, but in a more compact interface [1]. Many of the other apps have also matured of course, Software and Web in particular.

The other big news for 3.12 is that a number of significant gaps have been filled in. For a long time people have wanted to be able to manually organise their apps: now they can with the new apps folder feature. We’ve also added functionality to make installing sofware updates easier and more convenient, as well as the addition of wired networking controls to the system status area.

There are also major developments in the developer space, with the new notifications API, new GTK+ widgets, new capabilities for launching processes, and improved documentation. I think that 3.12 is probably our strongest for developers in a long time.

Finally, and for me perhaps most significantly, 3.12 looks set to be the best quality release so far. Signs of ongoing improvements are everywhere. There are performance gains for startup and (hopefully) memory usage, the theme and animations in the shell has been refined in quite a few subtle ways, high-resolution display support has been extended, and a great many bugs have been fixed. As each release comes and goes, GNOME 3 gets better and better, and 3.12 is no exception.

There’s plenty more that I could mention about this release, of course, and the release notes will provide full details, but what is important is the progress that GNOME is making. 3.12 feels like another significant upgrade, and is another release where it feels like things are coming together more and more.

[1] The other day I did a quick comparison, and found that the chrome in the new version is around 60 pixels shorter than before. That’s an impressive space saving, and makes the app much more focused on what you are editing.

March 18, 2014

DPI and photography
There is a good understanding of DPI among hardware geeks (they may boast about how superior is tablet X due to a higher DPI display), still I am surprised to see how many people from the photography world do not understand this (sometime don't want to learn, on the "is technical stuff, I am an artist and not care about technical details") to the point it becomes ridiculous, so I will try to explain it with simple words, in case someone will pay attention.

DPI stands for "Dots Per Inch" and is a characteristic of a hardware device (for example a computer/tablet/phone display). It says how many pixels are in one inch (1 inch = 2.54 cm). Example: the computer I use to write this piece has a 38 cm wide display, which is 38 cm / 2.54 ~= 15 inches. Considering the horizontal resolution is 1600 pixels, then it has a resolution of 1600 pixels / 15 = 106.67 DPI. Of course, the higher the DPI value, the better looking the image will be on your display, as it will enable to to see finer details.
dpi screen
In digital photography the situation is different: your photo is a file and it can be put on a wide range of displays. The DPI value is not as important as the actual image resolution in pixels, it is actually metadata. Actually the correct term when talking about photos is PPI, standing for "Points Per Inch", but PPI and DPI are close enough, is not a huge problem if you interchange them. PPI is relevant when you print the image, is the density of color points to be printed by a inch. The math is similar and having a target print size and print image quality (PPI), it will help determine the needed pixel resolution. Example: you want to print a 15 x 10 cm image at good quality (300 PPI). On the horizontal 15 cm / 2.54 = 5.9 inch, then 5.9 inch * 300 PPI = 1770 pixels. On the vertical, 10 cm / 2.54 = 3.96 inch, then 3.95 inch * 300 PPI = 1182 pixels. In conclusion, you will need a 1770 x 1182 pixels image. 1800 x 1200 is close enough and easy to remember, so a 1800 x 1200 image will print at good quality at 15 x 10 cm.
dpi print
JPEG is the file format we use day to day to exchange photos and it has the ability to store a DPI value somewhere inside its metadata, but is only metadata: an indication at which size (in cm or inches) to print the file. But you can print the same file at any dimension or any DPI/PPI value (of course, with the respective image quality consequence). Changing this value won't modify in any way the look and work of your digital file.

Now, what is a good DPI value for your print? This depends on its intended use, of course :) A 300 DPI is considered good enough for a quality print, like those in the glossy magazines, where you look closely and expect to see fine details. When printing a poster which will be seen from a couple of meters, you can lower the DPI value at 100 and for a billboard to be seen from tens of meters, you can go way lower: it does not mater the printed points are huge when looking closely, nobody will do that.

Now another practical example to illustrate the ridiculous part and how to deal with it. For a recent photo exhibition (it is still on display), the requirements were "100x66 cm at 240 DPI". This is ridiculous: 100 cm / 2.54 = 39.4 inch, 39.4 inch * 240 DPI = 9456 pixels and 66 cm / 2.54 = 26 inch, 26 inch * 240 DPI = 6240 pixels, so to satisfy it you need a 9456 x 6240 photo, which means 9456 * 6240 = 59005440 - you need a 60 Megapixel camera to produce it. Nobody in the target group for that expo has access to such a camera. What to do?

Knowing the people, I can safely say most of them just ignored a requirement they don't understand, and even if they understand can't follow. Still, some tried their best and this is the right thing to do, consider other exhibitions have sane requirements you can, and then should, follow, like the one asking for 1400 x 933 at 96 DPI.

The most obvious thing to do is to resize your image to achieve the needed resolution in both pixels and DPI (GIMP example below). This is sensible thing to do when you scale down the image, as in the 15 x 10 cm case, (reduce the pixel resolution count) and you can optimize interpolation method and post process your image. However, when it would need to scale up, as in the 100 x 66 cm case, is not only a waste of resources and time, extrapolation will lower the image quality so the result will be worse than printed at a low DPI value.
dpi print
What I do in such cases (and I got my images accepted in quite a few exhibitions) is to give the image at the largest pixel resolution I have available and then set the metadata DPI value for the desired target in centimeters, even if lower than the requirement. Is going to be the best print I can anyway.
dpi print
Most of the photos you will encounter have a value of 72 DPI, this is because that is the value assigned by default by the camera for historical reasons: it was the common resolution for computer displays when digital cameras were introduced to the market, at the time we used 14"-15" CRT monitors. I am not sure I can change it inside my Canon, but it does not matter: most of my photos are to be shown on a computer display and I can change the value (as shown above) when editing for a special print.

Of course, as I told above is specific to photography. For illustration/vector graphics is a different matter, we may talk about at another time if there will be enough interest.

March 10, 2014

Derechos civiles en Venezuela: La propia imagen

Ser fotógrafo impone un reto a respetar la privacidad de aquellos que son capturados en nuestras imágenes. No es raro ver fotógrafos que retraten a extraños en la calle y por ende, nos preguntamos ¿Qué sucede si alguien toma una foto mía? ¿Qué puede hacer con ella? ¿Qué puedo hacer si no estoy de acuerdo con lo que se hace o donde se publique la misma?.

En Venezuela, a falta de una ley explícita sobre el tema, conociendo como funcionan las leyes de protección civíl en distintos paises y jurisdicciones internacionales, y luego de hacer un estudio exhaustivo de las leyes nacionales; les redactaré estas líneas para que, tanto mis colegas fotógrafos, como aquellos que son fotografiados, conozcan el alcance legal de las atribuciones que ambos partícipes pueden tener.

Robyn at Flock 2013

¿Qué es el derecho a la propia imagen?

El derecho a la propia imagen atribuye a su titular la potestad para disponer de su imagen física, impidiendo su difusión salvo que el mismo de su propio consentimiento. Los avances tecnológicos permiten mil maneras de reproducir la imagen de una persona sin que ésta pueda llegar a apercibirse, por lo que este derecho es una garantía frente a aquellas intromisiones ilegítimas sobre la vida de la persona que consisten en reproducir su imagen física por cualquier medio que pueda hacerla identificable (televisión, vídeo, fotografía o incluso caricatura), con absoluta abstracción de su propia voluntad. Al reconocer este derecho, se trata de proteger un bien jurídico que, como el resto de los que definen los derechos fundamentales, se basa en el respeto al valor constitucional de la dignidad de la persona.

Como fotógrafo ¿Qué debo hacer para que el Derecho a la propia imagen no sea violado?

No es suficiente colocar una licencia Creative Commons, porque esta no ampara a la persona que está en ella. Trataré este punto basada en tres posibles escenarios, cuando fotografiamos a personas en un evento contratado, cuando fotografiamos a personas en un evento al que asistimos y cuando fotografiamos a extraños en la calle.

Cuando fotografiamos personas en un evento contratado.

Lo primero que debemos hacer como Fotógrafos es entregarle a los involucrados un documento donde ambas partes hagan una liberación de modelo o consentimiento de fotografía, para que las personas identificables en la imagen no puedan demandar. Acá hay un simple tutorial de como redactar este tipo de documentos. En mi caso personal, extiendo siempre el alcance, si mis clientes están de acuerdo, indicandoles que podría utilizar sus imagenes para concursos o exposiciones, y que ellos no pueden atribuirse la realización de la fotografía como tal, pero, que pueden reproducirla cuantas veces quieran para uso personal.

de la Ley de Derechos de Autor

Capítulo III
De los derechos afines al derecho de autor
Artículo 38.- El derecho de explotar una fotografía realizada por un fotógrafo profesional, puede ser objeto de cesión en las mismas condiciones que la efectuada bajo una relación laboral, en los términos del artículo 59 de esta Ley. 

 

Cuando fotografiamos a personas en un evento

Este es quizás el caso más delicado, porque no es lo mismo tomar una foto de una multitud a una foto de un particular. He asistido a infinidad de eventos donde he fotografiado a muchisima gente, sin embargo, hay dos tipos de eventos: Aquellos donde los organizadores colocan un parrafo de aceptación donde los asistentes permiten que todas las imagenes que se tomen de ellos podrán ser usadas para fines publicitarios de los mismos organizadores y aquellos casos donde simplemente no hay ningúna regla. En este último caso todo depende de si los organizadores reciben remuneración monetaria o no.

Si los organizadores explícitamente hacen que aquellos registrados firmen este acuerdo, aplicaría el mismo artículo como si el asistente hubiese firmado un Consentimiento de fotografía, por lo cual no puede demandar sobre el uso de la misma.

Si los organizadores no han redactado ningún documento y el evento es pago o de remuneración para la organización, entonces la persona puede demandar la remoción de dicha fotografía. En mi caso, me ha tocado eliminar varias fotografías anteriormente, sin embargo, preguntar a la gente antes de tomarle una foto ha sido una solución bastante simple.

Capítulo II
De los límites de los derechos de explotación
Artículo 43: Son comunicaciones lícitas:

  1. Las verificadas en el ámbito doméstico siempre que no exista un interés lucrativo.
  1. Las realizadas con fines de utilidad general en el curso de actos oficiales y ceremonias religiosas, siempre que el público pueda asistir a ellas gratuitamente y ninguno de los participantes en la comunicación perciba una remuneración específica por su intervención en el acto.
  1. Las efectuadas con fines exclusivamente científicos y didácticos, en establecimientos de enseñanza, siempre que no haya fines lucrativos.

 

Cuando fotografiamos a extraños en la calle

En este caso, la mayoría de las veces las personas salen borrosas debido al movimiento o sus caras no son lo suficientemente nítidas debido a la multitud. Sin embargo, lo mejor es entender que si una de estas personas ve su fotografía y no está de acuerdo con su publicación, como fotógrafos, tenemos el deber de eliminarla O pedir que firme una Liberación de modelo.

Ahora, como fotografiado o modelo y viviendo en Venezuela ¿Qué puedo hacer si NO estoy de acuerdo con el uso de mi fotografía?

Internacionalmente hay muchas leyes que amparan la privacidad de imagen, y aunque no hay una ley directa sobre este tema, la Constitución y la Ley de Propiedad Intelectual son un basamento suficiente para solicitar al fotógrafo que elimine tu fotografía. El  basamento legale principal es el siguiente:

Constitución Nacional de la República Bolivariana de Venezuela
Capítulo III
De los Derechos Civiles
Artículo 60. Toda persona tiene derecho a la protección de su honor, vida privada, intimidad, propia imagen, confidencialidad y reputación.
La ley limitará el uso de la informática para garantizar el honor y la intimidad personal y familiar de los ciudadanos y ciudadanas y el pleno ejercicio de sus derechos.

¿Como ayudarte si estás en desacuerdo con el uso de tu imagen propia?

Lo primero es acudir al diálogo e indicarle a la persona que no estás de acuerdo con el uso dado a tu imagen. Si esto no funciona, deben intentar llegar a un acuerdo. Como último recurso, y amparado en la Constitución, puedes actuar via amparo Constitucional, Demanda Civil o Demanda Penal. Esto se debe realizar por la Defensoría o la Fiscalía, la cual actúa en 48 horas de oficio.

Hay que recordar que solo se debe llevar a la ley cuando la fotografía denota actuaciones en contra del honor, dejando al escarnio público, vilipendio, etc; la imagen personal. Recordemos que cada ciudadano tiene un amparo de protección de su honor, vida privada, intimidad, propia imagen, confidencialidad y reputación en la Constitución.

Ahora, en la Ley de Derechos de Autor se menciona lo siguiente:

Capítulo II
De los derechos de los artistas intérpretes y ejecutantes
Artículo 92.- Los artistas intérpretes o ejecutantes, o sus derechohabientes, tienen el derecho exclusivo de autorizar o no la fijación, la reproducción o la comunicación al público, por cualquier medio o procedimiento, de sus interpretaciones o ejecuciones. Sin embargo, no podrán oponerse a la comunicación cuando ésta se efectúe a partir de una fijación realizada con su previo consentimiento, publicada con fines comerciales.

Notas Finales

No es un secreto que la ley tiene ciertos vacíos, sin embargo, en cuanto a la protección de la imagen e integridad del ciudadano es bastante estricta. Recordemos que como fotógrafos tenemos una labor de retratar la realidad y no denigrar a quien tenemos frente a nuestro lente.

Queda mucha tela por cortar, sin embargo, por algo hay que comenzar. Estaría feliz de comenzar un debate sobre el tema, generar algunas propuestas y redactar un comunicado que pueda ayudar a enriquecer las leyes actuales para que nuestro trabajo, y la integridad de las personas que fotografiamos, queden intactas.

Fuentes:

 

March 07, 2014

Arte FLISoL 2014

Como siempre hay que renovar, acá les dejo unas simples propuesta para el arte del 2014. Está bajo licencia CC-BY por lo que pueden hacerle las modificaciones que quieran mientras le den un pequeño agradecimiento a su servidora :)

Todo está en Vectores menos la línea de la ubicación, la cual pueden editar libremente en el SVG. Si no encuentran la tipografía, es Comfortaa (la pueden descargar dando click al link)

Espero les agrade, les sea útil y si necesitan algo más, no duden en avisar! feliz FLISoL!

afiche-flisol

February 26, 2014

Popovers & You

GTK+ has been getting some really nice new features in recent times. Over the past few releases the list new of widgets has come to include things like ListBoxes and FlowBoxes, stacks and stack switchers, revealers and header bars. Now, in the upcoming 3.12 release, there will be another new widget: popovers. This is something that those of us who work on GNOME design have wanted for a while, and it’s exciting to finally have them.

Of course, once you have a new interface widget, you need to know what to do with it, so I thought I’d write a bit about how to design with popovers. If you’re an application developer or designer and you’re not sure what popovers are for or how to use them, then this post is for you.

What is a popover, anyway?

popovers

Popovers are containers that appear over a parent window. They have some significant characteristics:

  • They are generic containers, meaning that they can contain a variety of widget types (just like a dialog).
  • They have arrow points which are always directed at a specific interface element. Often, this is a button, icon or thumbnail, and the popover appears when this is pressed. (This isn’t always the case though, as one of the later examples indicates.)
  • They cannot be moved and have a fixed position.

Popovers are used to show additional controls or information. As such, they are an example of a widget that allows you to practice “progressive disclosure” in your application. This essentially means hiding non-essential or infrequently used interface elements slightly out of the way. Progress disclosure helps to keep your UI focused by giving more attention to the most important elements. As my favourite part of the HIG states:

“Every extra piece of information or interface control competes with the truly relevant bits of information and distracts the user from important information. Hence, don’t clutter your interface, and don’t overload the user with buttons, menu options, icons, or irrelevant information. Instead, use progressive disclosure and other techniques to limit what the user sees at any given moment.”

The next time you are adding extra controls or information to a UI, you might want to think: “maybe I should put this in a popover”.

When to use popovers

Popovers are one of a number of ways to achieve progressive disclosure, and there are a number of other widgets that can be used in a similar way. In particular, they are similar to dialog windows, so you might find yourself being uncertain about whether to use a dialog or a popover. There are a few things to consider here.

  1. What is the size and complexity of the content you want to display? A popover should generally be small and simple, so if you have a lot of information or controls to disclose, a dialog window is often better: they are nicer than popovers at larger sizes, and you can use tabs to break them up into sections.
  2. Is there a specific element that can act as the source of the popover? If the answer is no, you should use a dialog, since they don’t have to point to something.
  3. Do any of the established conventions for dialogs apply in this case? There are certain interaction patterns where dialogs are the established convention, such as presenting confirmation checks or application preferences. It is best not to abandon the conventions that people are familiar with for dialogs, as this will help your users understand what is happening.

If you can answer these questions and a popover still seems like a good idea, you may well want to use one. In fact, popovers have a number of advantages over dialogs when used correctly. They aren’t as disruptive, since dialogs require a bigger focus shift and give the users more new UI to interpret. In contrast, popovers don’t change the frame in which the user is working, and are generally a more subtle visual presence. This involves less severe context switches and a smoother user experience.

Examples

We’ve been utilising popovers in our application designs for some time, so I thought that it might be instructive to end this post with some examples from our mockups. Hopefully this will give you a better idea about some of the possibilities they present.

A filter menu

This is taken from our mockups for a new character map application. Here a popover is used to allow a filter to be selected for the view (in this case, selecting a font). In the past we would have had to have used a combobox or a dialog for this. A popover is better than either option: it is easier to scroll and search than a combobox, and less disruptive than a dialog.

filter-menu

Note that the popover header shown in this mockup currently isn’t possible, although you could implement something quite similar without it.

Gear menus

Gear menus are a common pattern in GNOME applications. Previously we have used a menu that is activated by a button for this. Popovers are a much nicer way to present a button menu though. Not only can popovers be used as a simple replacement for button menus, but you can also supplement the menu with other controls. In this example, taken from our latest Nautilus mockups, the menu has been prefaced with a pair of buttons and a slider. This makes the menu more compact and interesting, and the slider is a more appropriate control for setting the zoom level than menu items.

gear-menu

A word of caution when using popovers in this way: be careful not to make the popover too complex by loading them with lots of different types of widget. As a rule of thumb, use no more than three different widget types.

Editing Selections

One really nice way to use popovers is for editing controls. Here, the popover can appear in relation to the selection. The great thing about this is that it avoids showing controls until they are needed, so you don’t have toolbars full of insensitive buttons. It also emphasises the context specific nature of the controls that are being presented.

You can already see how this can work in the Notes app, which has had its own popovers implementation for a while. Here’s one of our early mockups for that:

notes-single

And here is a similar pattern for Sudoku controls:

sudoku

Have Fun!

Popovers are an extremely flexible widget, which means that they lend themselves to creative design. They are a really nice way to inject interest and originality into applications, I’m really looking forward to seeing how people end up using them. If anyone has any questions about how to design with popovers, I’d be happy to offer advice.

February 25, 2014

another day, another twitter client — this time, Birdie coming to Fedora

Birdie — another GNOME twitter client — is in the process of being added to Fedora. It is currently on its way to updates-testing for Fedora 20, so please test and add karma!

Birdie ScreenshotThe birdie upstream actually creates Fedora RPMS, but once it is in Fedora proper, you will be able to install it and use it without having to enable an external repo!

February 21, 2014

Setting up bitlbee on Fedora

I hate having more that one chat/IM/IRC client, but also not a fan of how the IM clients (Pidgin / Empathy) do IRC.So I use bitlbee to connect to my IM services and forward all my IM accounts straight through to my IRC client. Bitlbee can make each IM account look like a IRC room, and the userlist is all your IM contacts.

Bitlbee is in the Fedora repos, but i always forget how to set it up when setting up a new install, so i wrote this Q&A on Ask Fedora for my future self. Enjoy!

 

 

February 20, 2014

key-mon, an on screen mouse & keyboard visualiser will soon be in Fedora!

I just pushed the new key-mon package into updates testing for Fedora 19 and Fedora 20 so please test and add karma!

Key Mon is a utility that displays your keyboard and mouse status on the screen. It is especially helpful to visualize keypresses and mouse clicks on the screen when screencasting. (like the following example of a quick Inkscape screencast):

keymon

LibreGraphicsMeeting 2014

In April there will be the 9th edition of LibreGraphicsMeeting, this year in Leipzig/Germany. LibreGraphicsMeeting is the anual gathering of most free software applications for doing graphics. Applications like GIMP, Scribus, Inkscape and daktable meet there for sharing there ideas and work together to improve there software. Of course some people from Fedora and RedHat are amongst them, to present there things:

  • David Tardon will present together with Fridrich Strba and Valek Filippov – Digital legacy preservation project — news from the reverse and straight engineering world. The effords LibreOffice made during the last years in re-engineering graphical file formats.
  • Richard Hughes will of course introdce his newest toy the open source spectrometer – Building an OpenHardware Spectrograph for Color Profiling in Linux
  • Daniel Berrange will show his developments of Entangle – Tethered camera control and capture with Entangle
  • Pierre-Yves Chibon and myself, will show the development of Nuancier, Fedoras application for collecting and vote for the supplemental wallpapers – Nuancier- Community generated and selected artwork
  • Allan Day and Jakub Steiner will talk about what GNOME does to make there design process open – GNOME Design: Open to all
  • Sarup Banskota and Emily Dirsh will show the achievements Sarup made during last GSoC on GlitterGallery- GlitterGallery: Taking the designer’s office online
  • and last Onyeibo Oku will speak about free software for architects – FreeCAD’s “Arch” Workbench: Bridging the Gap in the Linux (AEC) Design Tool-set

Besides that a lot of other cool things will be presented what you can find out in the schedule. There is only one problem. LibreGraphicsMeeting needs some support from the community to make this event happen.

February 18, 2014

Corebird now open for Localisation!

The upstream project for corebird — a GTK twitter client — has now been added to transifex and is open for localisation! Help out if you can!

 

 

February 17, 2014

Upcoming FOSSASIA 2014

In a week I will start a journey to an event in Asia called FOSSASIA. This event will take this year place from 28th February to 2nd of March at Norton University in Phnom Penh/Cambodia It will be a long trip for me spending 47 hours in planes and airports but I think its worth it. We will have an track on this event only dedicated to Fedora related talks.

Fedora Track Friday 28th February 13.00 – 16.30

  • Fedora Next: An Overview: by Truong Anh Tuan,
  • The Ultimative Fedora A-Z Talk: by Gnokii,
  • Introduction to FOSS techniques (aimed at students): by Sarup Banskota, 1 hour workshop
  • Testing Fedora cloud images in Eucalyptus private cloud: by Kushal Das,
  • 7 Ways To Contribute To Fedora Without Programming Skills: by Gnokii,
  • Fedora Ambassadors Program: by Truong Anh Tuan,

Fedora Track Saturday 1st March 9.00 – 16.30

On Sunday, we will have the whole day an hackfest

where interested people can do together with us, there first steps as Fedora contributors. Kushal will work with the people interested in packaging, Tuan with that for becoming an Ambassador and I will work with that interested in doing design tasks for Fedora. I am really interested what comes out of that hackfest and how many new contributors we can win there.

I will also give an Inkscape workshop on the event, which isnt scheduled yet, so Fedora has really a big participation on FOSSASIA this year. I will stay a little bit longer in Cambodia, but not for holiday. I will give some workshops at Smallworld Cambodia and for Webessentials and I will be back right on time for Chemnitzer Linux-Tage.

February 13, 2014

New Corebird version 0.6.1 in the works for Fedora 20

UPDATE: Corebird 0.6.1 is now in the stable Fedora 20 repos.

The new version of corebird — a twitter client — is in the works for Fedora 20. Please test and add karma here.

This updated version provides the following bugfixes and enhancements.
  • Support for Twitter Lists is now in Corebird. To view and create lists, use the list view in the main window sidebar. To add a user to a list, use the drop-down menu in the top right of a user’s profile (near the Follow / Unfollow button).
  • The corebird application icon and sidebar icons are new, updated and shiny.
  • The last tweet that was selected in a list of tweets (e.g. the Main timeline or Replies) is now remembered when switching back and forth between pages.
  • The user can now set the maximum inline media size by Megabytes. To change this setting, tweak the “Maximum media size” value in the “Interface” tab in the Corebird settings dialog.
  • The Corebird sidebar can now be hidden. To hide and show the sidebar, use the keyboard shortcut “Ctrl+Shift+S”.
  • The keyboard shortcuts for hiding/showing the toolbar, and composing a new tweet are now stored in GNOME gsettings. The Corebird gsettings configuration can be tweaked in GNOME’s dconf-editor, under the path “org > baedert > corebird”
  • Previously, the buttons that show when hovering over a tweet sometimes overlapped the text of a tweet or inline media. In this update to corebird, the buttons are now aligned at the top of a tweet and will not obscure the tweet.
  • Previously, retweeting and deleting the selected tweet was possible with a single keypress of the “d” key to delete, and the “t” key to retweet. This resulted in possible accidental deletion or retweeting. In corebird 0.6, these shortcuts have been changed to require a double press of the key. To delete a tweet, press “dd”. To retweet, press “tt”.
  • The User Profiles page now displays if the user is following you. This is displayed in the top right corner of the profile page, under the Follow / Unfollow button.
  • The User Profiles page now displays if the user is a verified user on twitter. If the user profile is a verified user, a blue check icon is shown next to the user’s name,
  • The position of corebird main windows is now persistent. Every time you re-open corebird, the window(s) will be in the same positions on the screen.
  • Accessibility in corebird is now improved. Notable improvements include fixes for uses utilizing screen readers. Special thanks to Peter Vágner for contributing these improvements.
  • Many other bugfixes and enhancements.

February 03, 2014

Fedora.next and Design Suite
Based on the good writing about the goal of Fedora.next by Adam Williamson, Design Suite may be made on top of Fedora Workstation as the logical choice. Doing so will help focusing on key areas like configurations and proper distribution of applications to display better technologies (For example, Design Suite is using AppFolder provided by Gnome Shell as default). Fedora Workstation is a base with the ability to add group package like Design Packages in this case. Only difference with the spin is the optimization while staying close to upstream.

January 30, 2014

Help Me! (Yet another docs hackfest blog post.)

Over the past couple of years, I’ve tried to sit down and do some work with the awesome GNOME docs team on a number of occasions, but something always seemed to get in the way. So I was really happy to be able to spend three days with them at this week’s documentation hackfest.

One of the things I looked at during the hackfest was the design of Yelp, our help application. Shaun McCance and I talked about how we can make it more consistent with our other GNOME 3 style applications, and we’ve also been working on designs for an improved “start screen” – so that the content of the help browser looks more engaging.

Help Start Screen

Documentation isn’t always about “help”. To me, our documentation is an opportunity to let people learn about the functionality we provide, to master tips and tricks that will help them be more productive, and find out about the cool new features that have recently been added. As work progresses on the help, I hope that these other aspects of the documentation start to come through more strongly.

The hackfest also gave me an opportunity to participate in some interesting discussions about developer documentation. Documentation is obviously an important part of the GNOME application developer experience, and is something that we really need to improve if we want to stimulate the creation of great applications for GNOME. These conversations generated some pretty cool ideas about how to quickly create helpful developer documentation, and how to tie our existing documentation together in a more cohesive way. I’m hopeful that we’ll be able to take those ideas forward in the coming weeks and months.

Many thanks to the University of East Anglia for providing a great venue. The Ziggurats are awesome.

January 27, 2014

Nightmare wallpapers
A fan of my photos keep asking for large resolution versions of various pics (I usually put online web-optimized stuff) so I cave in, that's the explanation for me having often posts like this.
The images below are pretty-much made in camera (they were edited with GIMP only for crop, resize, BW conversion and color curves adjustment). The motion blur is created in-camera, with the following recipe (which you can learn looking at EXIF data): put a somewhat long exposure time, 1/10-1/15 of a second, start moving the camera and then press the shutter. The first and the last are made moving the camera on the vertical axis and the second by rotating the camera and zooming at the same time - pretty easy but you will need a bit of exercise to achieve a smooth movement.
nightmare wallpaper
nightmare wallpaper
nightmare wallpaper

January 22, 2014

MP4 and Wikipedia
Last week when I read about the request for comments on Wikimedia supporting MP4 video I wasn't at my computer, so I couldn't vote and later forgot about it. My position here is simple: supporting proprietary and encumbered formats can only harm the open web, so Wikipedia and all the other Wikimedia websites endorsing it would be a huge blow for the openness and community, so I strongly oppose. However, I acknowledge a lot of the existing devices produce content in such formats, so I guess a reasonable compromise would be allowing such uploads but then transcode the videos in open formats and serve those for viewing.

Today I was reminded about the issue by a message on some Wikimedia mailing list by a message worded in such way, I can easily label as "pro MP4 spam". It was a good incentive for me to finally answer the RFC/vote.

Still, I am disturbed to see a "product manager" at Wikimedia Foundation campaigning for MP4, especially when the public opinion is strong against it (at this moment it records 251 votes for no support, votes for contributing only, no view and only 132 for full support, so more than 2:1).

January 18, 2014

[Gnome Shell] Moving Tweak tools to Settings?
I had conversion with a new Fedora user who like Gnome Shell asking if it is possible to move Tweak Tools to Settings. I think it makes sense under Personal category and labeled as Advanced.

January 08, 2014

On Red Hat and CentOS joining forces
Red Hat and CentOS joining forces is a really smart move and it potentially is a win-win scenario for all parties involved: Red Hat, CentOS, community, end-users, FOSS. I won't enter into details, since a lot of people are talking about this already.

However, what baffles me is how little people understand the reasoning. So many comments frame it in the old context: a lot of projects need a no-cost Linux solution, and if they can't use a Red Hat derivative, they will use a Debian flavour and later when money will get involved, they will buy support from Canonical instead of Red Hat. Yes, this is a solid reason, but is the old reason. What we see now is something else.

The real reason for Red Hat embracing CentOS now is written plainly everywhere, from the press release "Red Hat is once again extending its leadership in open source innovation by helping to establish a platform well-suited to the needs of open source developers that integrate technologies in and around the operating system" to the FAQ "Red Hat is taking an active role in the CentOS Project to accelerate the development and broaden the reach of projects such as OpenStack by expanding our base."

These days Red Hat is selling not only the established Red Hat Enterprise Linux, but quoting from the same press release, things like "OpenStack, RDO, Gluster, OpenShift Origin, and oVirt" solutions. Compared with Linux, those technologies have so far less traction but comparable potential. Having CentOS as a strong player and supporting all those technologies will make them more popular and increase the chances for a later sale of more than RHEL.

Everything mentioned above is Free Software, so it can be a win-win for all of us. Of course, there are dangers (GNOME 3, I'm looking at you!) but there are safeguars: if the srpms will be easier to get, projects like Scientific Linux will have the life easier too.

January 05, 2014

LibreGraphicsMeeting 2014 Leipzig

In April from 2nd to 5th, there will be the 9th edtion of the LibreGraphicsMeeting, this time in Leipzig/Germany. LibreGraphicsMeeting is the annual meeting of developers and users of free software programs from the graphic world like GIMP, Krita, MyPaint, darktable and others. The LGM is the place where the come together for sharing  new developments and ideas what can be done to make the software better. LGM consists of only one track with short talks and a lot of team meetings, workshops and demos.

There is still time left until 15th of January for an submission. But you can help the LGM also in another way, the event collects usally the money for participants who cant afford there travel through an crowd founding campaign. So if you are an user of one of the programs, thats a chance to help them.

January 03, 2014

Patrones de Petroglifos Venezolanos (Inkscape)

Comenzando el año con buen contenido, acá les dejo unos lindos patrones que pueden utilizar como fondo de websites, presentaciones, diseños y más. Los archivos SVG vienen en color plano (gris) con una sencilla paleta de color y el diseño original que se tomó. Pueden colocar los colores que quieran y me haría muy feliz ver uno que otro screenshot si deciden utilizar el contenido. Ahora, un poco de cultura para quien no sepa que es un Petroglifo:

Los petroglifos son diseños simbólicos grabados en rocas, realizados desgastando su capa superficial. Muchos fueron hechos por nuestros antepasados prehistóricos del periodo neolítico. Son el más cercano antecedente de los símbolos previos a la escritura. Su uso como forma de comunicación se data hacia el 10.000 a. C. y puede llegar hasta los tiempos modernos en algunas culturas y lugares. La palabra proviene de los términos griegos petros (piedra) y glyphein (tallar). En su origen, fue acuñada en francés como pétroglyphe.
fuente: Wikipedia

Para descargar cada patrón pueden acceder a los siguientes enlaces:
Patrón1Patrón2Patrón3Patrón4

vene-glyphs

Y si son verdaderamente curiosos, acá les dejo el link a una pequeña pero entretenida galería de imgur con algunos ejemplos. Acá la url: http://imgur.com/a/tjcna#0

January 02, 2014

Inkscape-Workshop im Februar

Ich habe vor einiger Zeit Nachfragen erhalten, ob denn mal wieder in Chemnitz ein Inkscape-Wochenende statt finden kann. Es sieht allerdings schlecht mit Terminen bei mir aus. Die einzige Möglichkeit, die in naher Zukunft besteht ist das Wochenende vom 21. – 23. Februar 2014. Der Workshop beginnt am Freitag Abend mit einigen Dingen rund um SVG, der Oberfläche von Inkscape, den Verzeichnissen, Zooming und Panning und setzt sich dann am Samstag morgen fort mit den Zeichenwerkzeugen. Nach meinen Erfahrungen schaffen wir in bestimmte Themen, wie Live Pfadeffekte, Gekachelte Klone und vor allem Filter nur Einblicke aber die reichen aus, um im Selbststudium sich damit beschäftigen zu können. Wann immer es geht schieben wir auch praktische Teile ein, bist Sonntag Abend sollten wir auf diese Art und Weise alle Funktionen von Inkscape kennengelernt haben.

Wie bei allen anderen Workshops vorher auch gibt es wieder ein Formular zur Anmeldung, diese Mal aber eine kleine Besonderheit ich mach mir nur die MÃühe, wenn mindestens 3 Leute zusammen kommen. Ansonsten bleibt alles beim alten Teilnahme frei, es sei denn ihr wollt mir etwas zustecken aber das bleibt euch überlassen.

Night wallpapers
For the New Year night I chased some fireworks pictures, but in the wrong place (had to stay near home) so the result was not spectacular (I didn't have high expectations for the fire show in the nearby park). But having the gear with me and noticing the park at night, which do looks different, I turned on them for more pics, which were then posted in the usual places. Receiving a specific request on some social network for high resolution, I follow with a blog post with wallpaper sized versions:
night wallpaper
night wallpaper
night wallpaper
night wallpaper

December 30, 2013

Looking at Fedora 20 Design Suite and onward

The latest itteration of Design Suite was successful using the latest stable release of Gnome 3.10.x. This time the testing went much better with some fixes to address. The goal to include applications with the style of Adobe Creative Suite is nearly complete with: Gimp (Photoshop), Inkscape (Illustrator and Framework), Scribus(InDesign), Premiere (PiTiVi), Acrobat (Evince, PDFShuffle, Xournal), in addition of Paints, Blender 3D and Hugin. Looking at the future release, here are some possible updates to implements:

Stay tuned...

    December 29, 2013

    Anaglyph
    Disclaimer: to properly read the following article, you need to have a pair of red-cyan 3D glasses, otherwise the images won't display as intended. The cheapest one should do it, perhaps even home made. Lacking such glasses, you can generate your own 3D images for different types of glasses.

    A few weeks ago I stumbled upon an old article about how James Cameron is/was remaking Titanic in 3D and somewhere in the technical explanation it was mentioned you can do 2D to 3D conversion with Free Software tools, namely the G'MIC plugin for GIMP.

    In the late '90ies I received a computer magazine which came with a pair of paper 3D glasses and a CD containing the usual software demos AND a few 3D pictures, it was my first contact with anaglyphs. I still have the glasses, but I use them maybe once every few years, when I remember to search some such images.

    Along the time I learned how to properly make such images: two cameras, filters, combine the two images in one. Way too much effort for me. It looks like way too much effort even for some commercial filmmakers...

    When I saw the Titanic article, I said to myself 'what the heck, let give G'MIC a try'. AFAIK it is not available in any official Fedora repo, but you can download a binary from the upstream, drop it in the proper folder and go with it. It will survive even a distro update/reinstall. Not a big fan of the 'application inside another application' approach of G'MIC, nor of its duplication of existing GIMP features, that's why didn't have it already installed, but playing is fun.

    anaglyph

    I don't have the time and patience to learn how to fine-tune the parameters (with hand crafted depth maps you should be able to reach high quality results), nor do I plan to return to anaglyphs any time soon, so I used pretty much the automatic settings. Below are a few pictures I think came decently with no fiddling and automatic settings:
    anaglyph

    anaglyph

    anaglyph

    anaglyph

    anaglyph

    anaglyph

    anaglyph

    December 16, 2013

    Corebird 0.5 now officially in Fedora

    corebird is now in Fedora proper!

    If you want to try out this fantastic GTK3+ twitter client, install from the commandline with yum install corebird or search for it in the new gnome-software application in Fedora 20. (note that corebird won’t appear in gnome-software until the appstream metadata for fedora is updated, and not sure how long until that happens)

    corebird

     

    December 11, 2013

    Nautilus Next

    Nowadays, digital content is all about the cloud. Indeed, in GNOME we’ve been pushing to integrate with cloud-based content through our new content apps, like Documents, Photos, Music and Videos. This is important work and needs to continue.

    However, local files are still central to the way that many people work, and are an essential part of lots of workflows. This means that, while cloudy things are important, it is also important that we pay attention to the experience of working with local files in GNOME. It is for this reason that a group of us has been working on a plan to improve the state of Nautilus, our venerable file browser.

    The new designs are fairly extensive and cover a lot of ground. In the rest of this post I’ll try to describe as much as I can. As always, they are not set in stone and will evolve. Questions, comments and feedback are most welcome, and will help us to develop them further.

    Lists & Grids

    list

    The most important thing in the Files app is, well, your files. If Nautilus is going to provide the kind of experience that we want it to, it needs to do a better job at making your files easy to recognise, look good, and take centre stage. This requires lists and grids that have even spacing, helpful zoom levels, and big, clear thumbnails.

    grid

    The designs feature new lists and grids, which should hopefully be possible with GTK’s new grid and list widgets. The grids we have in mind will be responsive, so that the content will scale to fit the size and shape of the window (without large spaces between cells or gutters on one side). Lists will feature thumbnails and have separators between rows to aid readability.

    gear-menu

    The designs also include mockups for an updated view “menu”. This contains all the existing options, except with nicer controls.

    Previews

    preview

    Being able to inspect the content of a file is often essential to identifying it, such as when you have lots of similar photos, or PDFs with unhelpful file names. Nautilus already has a previewing feature, but it functions as an optional extra and can easily be missed. The new designs make previewing much more central to the browsing experience. They also include actions alongside previews, so that you can quickly act on the file that’s in front of you.

    One thing that you can’t see in this mockup – we also want to make it possible to browse between files from the preview – so you can flip back and forth between images or documents in order to compare them.

    Generating previews like this may well require new infrastructure. Specifically, it is likely that we will need a new library for generating previews.

    Places

    Many of the ideas for the new sidebar design came from the awesome António Fernandes.

    The main objective for the places sidebar is to make it more focused on the things you care about. Right now, the sidebar automatically includes every available volume and drive. This can lead to a cluttered sidebar which contains lots of items that you never use. These often get in the way and distract from the items that you use all the time.

    add-drive

    We want to rebalance the sidebar: more things you care about, less things you don’t. To achieve this, we want to make adding drives to the sidebar a manual action. In this way you will be able to customise the sidebar to your needs.

    Clarification: manual addition won’t be necessary for removable drives – they will be automatically added to the sidebar as they are now. Also, once an internal volume or remote drive is added, it will persistent even when it’s not mounted.

    A new add drive dialog is a key part of the new sidebar design. This will allow you to quickly add both local and remote locations to the sidebar all from the same dialog. It is also an attempt to clean up the various network browsing features that are currently available in Nautilus, and consolidate these features into one place.

    The reimagined sidebar also contains a new feature which will be really handy: starred files. Being able to mark items that you want to keep track of is such as obvious feature, and I’m sure it will be useful to many people. In UI terms it’s a fairly simple thing to do.

    Selections

    selection-mode

    Selection mode is a design pattern that we’re using extensively in the other GNOME 3 applications. It’s nice because it makes contextual actions much more discoverable. It also allows us to use single click (rather than the undiscoverable and inconsistent double-click) throughout.

    The best way to think of the use of selection mode here is as a discoverable context menu. Existing methods of selecting multiple items, like holding ctrl and shift in combination with the mouse button, will continue to work.

    Added Discoverability

    new-folder

    It’s amazing how many undiscoverable conventions that we acclimatise ourselves to, and an old app like Nautilus has a lot of them. At some point in the past, we all learned to double-click to open, to press return to finish naming a new folder, or that Ctrl+V pastes content into the current location. All of this is totally unobvious to new users, of course, and there can be embarrassing moments when you watch someone use an app like Nautilus for the first time.

    The new Nautilus designs bring a lot of hidden functionality to the surface, and they make an effort not to assume prior knowledge. Much of the functionality that is currently hidden in the background has been brought to the surface: there are visible buttons for common tasks like pasting items or creating folders, for example. Simple things – like using a dialog for creating new folders – are designed to eliminate basic usability bugs.

    Content Selection

    Finally, this brings us back to content selection. A next generation replacement for the existing file selection dialog is something that has been mooted for a long while. To make it happen, a number of other long-term initiatives need to come together: the new set of content selection applications needs to come together, and we need the previewing library that I mentioned about above.

    This latest round of Nautilus design work was in part motivated to keep these content selection plans moving forward, and the Nautilus designs were developed at the same time as a new set of content selection mockups. This is to ensure that the file browser keeps in step with our longer term plans.

    content-selection1

    The new content chooser is designed to allow you to select content items from a range of sources. These can be local files or content items that are stored in the cloud. This is where the various new content applications come in – each one is designed to act as a cloud-based content provider. With this approach, you should be able to use the Photos app to select images from Flickr, for example.

    content-selection2

    The initial view provides a grid of recently used items. After that, you can choose a particular content provider. Content apps can then present their own content. Notice that, after opting to view files, the familiar places sidebar from Files slides in.

    content-selection3

    What You Can Do

    If you want to help us make these designs a reality, there are many things that we need help with, both large and small. I will be busy turning the designs into bug reports over the coming weeks, and will be keeping the design page up to date as the plans take shape. You can subscribe to the page if you want to follow what’s happening. Otherwise, just get in touch. We would love to hear from you, even if you are just interested.

    Comments on this post are now closed. Thanks for all the fantastic feedback.

    December 03, 2013

    Corebird for Fedora 20

    Corebird — my first package as a package maintainer — has just been built and submitted to Bodhi. If you have a chance, test it, and leave some karma!

    corebird

     

    December 01, 2013

    Using Bluetooth to listen phone music
    I recently discovered it is possible to listen to a music from smartphone connected with a laptop via Bluetooth. The test was done using a custom cyanogemod for a discontinued Samsung Galaxy Mini Dart and an updated Fedora 20 beta using BlueZ5. The sound is jerky probably due to probably the hardware limit.

    November 26, 2013

    Motherboard Podcast

    photo-main

    You may be aware that in the past year my husband and I had a baby. Yet, I’m still here and participating in the community. That’s no small feat and is due in part to the help and support of my family, my managers and my employer (Red Hat,) and many of my peers who are also moms in tech.

    My friend Kathryn Rotondo recently put together a proposal for a new podcast – the Motherboard Podcast – to provide ideas and advice for other women in technology, like me, who would like to start a family but are worried about how it might affect their career, or who are already trying to balance both and are feeling alone. She will interview women with children who are working at tech companies; they will discuss the challenges they ran into, solutions their families came up with, and other issues. I think we need more role models for women in technology in general, but especially role models who are able to raise a family while continuing their career, so the interviewees for this podcast will be a great start.

    The podcast will be available for free and will tentatively be licensed under a Creative Commons license.

    Kathryn also put together a great video introducing the podcast project and making the case for it, so please have a look.

    Anyhow, please support the Motherboard kickstarter if you can, and help tech moms like me feel connected and supported!

    LibreGraphicsMeeting 2014

    Das LibreGraphicsMeeting 2014, die dann 9te Ausgabe wird vom 2. – 5. April 2014 in Leipzig an der dortigen Universität statt finden. Das LibreGraphicsMeeting versteht sich als Arbeitstreffen nahezu aller offenen Grafikprojekte, also alles was mit Typographie, Vektorgrafik, Animation, Bildbearbeitung und Fotografie zu tun hat. Auch Nutzer  dieser Programme wie GIMP, Inkscape, Scribus, Krita, Mypaint sind aufgerufen zu partizipieren, denn nur durch den Austausch mit den Nutzern kann eine Weiterentwicklung der Programme erfolgen. Die Teilnahme am LGM ist wie immer frei, um die anreisenden Entwickler und Enthusiasten zu unterstützen gibt es auch in diesem Jahr eine Pledgie-Kampagne. Wer sich für den Call for Participation interessiert findet diesen hier, bis zum 15. Januar können noch Beiträge eingereicht werden.

    November 24, 2013

    OpenRheinRuhr 2014

    Some days ago I was on OpenRheinRuhr, an event in which I participate since the begin. Last year there was unfortunately no OpenRheinRuhr as the place was taken by another exhibition. I manned together with Felix and Christian the Fedora booth and besides of that I had a talk and a workshop in the schedule.

    My talk was about the status of open source animation programs, where in this year a lot of things happend. Hopefully the upwind that area has right now, tails not off to soon and will show effect. The workshop I had was this time not about Inkscape like always, it was about Blender, the time was really short so the workshop became more an demonstration. What actually turned out really nice. Both talk was workhop was well visited and a lot of questions and interesting conversations came up after them. Think I will do OpenRheinRuhr next year again.

    November 22, 2013

    Mist wallpapers
    When I took pictures of the overwhelming mist, it became obvious such minimalist image have a great potential for effective wallpapers: they are simple and won't stand on your way. So here are some for anyone want to use them. Enjoy and don't let their mod depress you :)
    mist wallpaper
    mist wallpaper
    mist wallpaper
    mist wallpaper
    mist wallpaper
    mist wallpaper
    mist wallpaper

    November 20, 2013

    Fedora.next and Fedora’s brand

    I’d like to let you know about a little initiative the Fedora Design team is starting related to the Fedora.next effort.

    Fedora.next?

    Hopefully by now, you’re aware of the Fedora.next initiative. Among other things, Fedora.next involves splitting Fedora into three separate products:

    What each of these ‘products’ will be, exactly, who they are targeting, and their various features, etc. is up to working groups that have been formed for each product. Information about the working groups is available at their respective wiki pages (linked to above.) Those working groups will come up with product requirements by January 2014, at which point we’ll have more information about each product and what it will be like.

    Okay… what does that have to do with Fedora’s brand?

    Having more than one main ‘product’ for Fedora is going to result in our team – the main caretakers of the Fedora brand – having a lot of requests we aren’t quite equipped to handle right now. Here’s a few example questions, some of which we’ve gotten, to show what I mean:

    • Can you design us a logo for our Fedora product? (What should each of the logos for these products look like? Should each product have its own logo?)
    • Can you make some artwork for our Fedora product? (What kind of artwork should be used to represent each? How can we give each product a distinctive feel but still keep all of the products coherently ‘Fedora’ looking in its branding so they look related / like a family?)
    • Can you add our product to the Fedora website? Can you make our product its own website? (How should we represent these products on the website? Should we allow products to have their own separate websites?)

    How do we answer these kinds of questions? How do we get on the same page about how to answer these questions? Over time as these Fedora product plans solidify, we’ll need to come up with a ‘brand framework’ to support them all. (This sounds very fancy but it really isn’t. I think it’s just going to amount to some extensions to our current brand guidelines.)

    The Working Brand Plan

    Starbucks Early Visual Brand Language - Public Domain image from Wikipedia

    Starbucks Early Visual Brand Language – Public Domain image from Wikipedia

    • The Fedora brand is a strong brand, and we all collectively have invested a lot in it. The Fedora brand isn’t going anywhere.
    • The products will all have a common core – Fedora. Their mission statements should, hopefully, derive in part from Fedora’s overall mission statement of “leading the advancement of free and open source software and content as a collaborative community.” The products’ individual branding should reside under the umbrella of Fedora. We’re talking different models of vehicle from Ford, where Ford is the overarching brand and each individual model of car has different target audiences and strengths, and *not* a model where boutique brands are spun up for each individual product (e.g., Lexus for high-end Toyotas, Scion for entry-level Gen-Y Toyota customers.)
    • Since the products will be sub-brands under Fedora, we’ll probably use one of the existing sublogo layouts or design a new sublogo layout for them.
    • We can develop additional brand elements to extend the Fedora brand and help give each of the products their own visual identity within the main Fedora branding framework. What do I mean by brand elements? A very simple example would be to associate each product with a specific color: e.g., workstation is blue, server is green, cloud is yellow – or something like that. The Wikipedia visual brand language article touches on this a little bit, especially with the example of the original Starbucks Visual Brand Language (shown above.)
    • Specific brand framework elements we’re thinking we’ll need (much of which exists in our current brand framework):
      • Logo, sublogos, and usage guidelines
      • Visual brand langauge / brand element system
      • Imagery: Illustration and Photography, guidelines for these
      • Chart / Diagram / Table design and guidelines
      • Voice: What is the Fedora ‘sound’ in written communication?
    • We’ll probably need to review our current brand assets to verify whether or not they make sense given the changes we’ll be making as well. E.g., will the four foundations still make sense? (Probably?)

    While I don’t think there’s much reason to stray from the above knowing our brand, we may tweak here and there based on our research on the different products. Also, of course, the particulars of how we extend the brand framework will require that research before we can even get started.

    The Research Plan

    How do we develop these extensions onto the Fedora brand and build out our branding framework to be able to encompass multiple products?

    • We’ve already put out a very short set of questions together and sent it out to each of the three product working groups. Their answers to those questions are due by Wednesday, December 4. We may have follow-up questions to each of the groups once we review their answers.
    • We will meet with the working groups initially to make sure they’re thinking about some of the things we need to create these brand elements (e.g., mission statements, target audience, etc. so we know what and who we’re designing for.) We’d like for these to be interactive brainstormy /hackfest type of sessions where we come to a clearer understanding of the identity of that working group’s product by the end. This will likely be in January 2014, some time after the working groups’ product requirements documents are completed.
    • After that, we will likely plan a Design team hackfest to kick off the visual brainstorming / mockup process for expanding the Fedora brand framework to include these new products. Hopefully this will happen in March if not before.

    How to Get Involved

    Are you interested in getting involved with this effort? Here’s the right places to continue the conversation or start a new one (or feel free to post in the comments on this blog post instead of course!):

    November 19, 2013

    Fedora 20 Supplemental Wallpapers
    So, because I'm kinda busy with my $ job and aikido training, it took me a while to get it done, but supplemental wallpapers for Fedora 20 are packaged and update submitted. Please test and karma :) They're prepared for use with xfce, kde, gnome/cinnamon and mate. If there's a way to make them available via bg selector in other DEs in Fedora, let me know how, I'd be happy to expand the portfolio ;-)

    November 15, 2013

    Programatica
    At first, I received the invitation for the Programatica - Open Source conference for the Fedora community, but since I don't have much to say on this matter, I passed it (I am a Linux desktop user these days and Fedora does not shine there). When the invitation arrived at ProLinux and was difficult to find a speaker, I offered myself for the task.

    The conference was mixed, it had 3 tracks: open source projects, open source communities and celebration of 20 years of internet in Romania. The first part, the projects, was about an Arduino clone from Intel (and a Linux distro to match), a Microsoft Azure sales pitch from a local distributor and a F-Droid for FirefoxOS from Ceata. The communities included Ceata (again), "Informatica la castel" summer school, ROSEdu, ProLinux and YATE, which is not quite a community. The last track brought panels and talks with some of the internet pioneers in the country.

    My talk was a short one and quite generic (slides here): in an age when so much money are invested in Linux and Open Source and so much money are drawn from them, there is still a need for the community? We believe so.
    programatica

    November 09, 2013

    corebird on Fedora

    Corebird is an awesome GTK+3 desktop twitter client. I am in the process of getting it added to the official fedora repos, but in the mean time, i have a version packaged — for fedora 20 only — and ready to be used in my fedorapeople repos.

    To set this up on your Fedora machine, first download the .repo file:

    sudo curl -o /etc/yum.repos.d/fedora-corebird.repo http://repos.fedorapeople.org/repos/ryanlerch/corebird/fedora-corebird.repo

    Then install corebird:

    sudo yum install corebird
    
    corebird

     

     

    November 08, 2013

    Fedora package for the Polari IRC client

    Polari is the new GNOME IRC client that is not (yet) in Fedora proper. If you want to give this new application a go, i have packaged it up and created a new fedorapeople repo for it.

    polari

    To set this up on your Fedora machine, first download the .repo file:

    sudo curl -o /etc/yum.repos.d/fedora-polari.repo http://repos.fedorapeople.org/repos/ryanlerch/polari/fedora-polari.repo

    Then install polari:

    sudo yum install polari

    November 06, 2013

    Fedora Server Working Group: Nov 5 Meeting

    Fedora Server Working Group Logo

    Today was the second meeting of the Fedora Server Working Group!

    How to Get Involved

    Here are the various resources currently affiliated with the Server Working Group that you can use to follow along or participate:

    Meeting Minutes

    Here’s a run-down of today’s Server Working Group meeting:

    Agenda

    Today’s meeting actually took two hours. We devoted one hour to each of the topics below.

    • Finalizing the Governance Charter
    • Is Fedora Server One Product?

    Members Present

    • mizmo
    • sgallagh
    • mitr
    • tuanta
    • nirik
    • Evolution
    • Viking-Ice

    Finalizing the Governance Charter

    We had a discussion about two pending issues with the governance charter before ultimately approving it. The two issues were:

    • Group Membership – Should the voting members of the server working group should be required to be members of other Fedora teams as specified by their seat/slot?
    • Term Length for Voting Members – Should membership as a voting member on the server working group be unlimited / at will or should there be terms and elections/votes inbetween?

    Group Membership

    We had a long thread on the mailing list about the group membership concerns brought up at the first meeting. While we reached some agreement in the thread (we will not require any form of experience / proof that a member has experience with server technology to become a voting member of the server working group,) we weren’t able to come to consensus on whether or not voting seats on the working group should be earmarked for members of specific Fedora groups.

    So we talked about that last dangling issue first during today’s meeting. I brought it up in this way, “There seemed to be a lot of concern about having chairs represent specific sigs/ other teams in fedora last meeting, I didn’t see that resolved on list.”

    mitr replied, “Seems to me that way as well. I’d still prefer not having reserved seats; we can set up liasons when/as much as necessary.”

    nirik agreed: “…involvement from many parts of the project is vital, but not sure that each group needs a voting seat…”

    Viking-Ice expressed concern that if the seats are just liasions with the other groups and not members of the other groups, that the work we need those other groups to do won’t necessarily get done. Conversely, nirik was concerned that, “groups may not want the time/involvement that a voting seat would be… they just want to know/help where it affects their main focus.”

    We came to agreement after this discussion that it made sense to drop the group mappings for now, but to also be sure that we added a note to the membership section that we encourage involvement from all parts of Fedora.

    Term Lengths for Voting Members

    nirik brought up the concern, “Currently we have it so turnover only happens if someone steps down from a voting seat. Do we want any term limits or other ways to keep a flow of fresh blood into the voting group?”

    The discussion below is out-of-order, but grouped according to the threads of conversation, which were running concurrently for the most part.

    Lifetime of the Server Working Group

    Viking-Ice felt the Server Working group would dissolve once the PRD and process were put in place. He suggested indefinite terms and no elections, with the thought that the group would be short-lived. nirik believed that the group’s lifetime might be quite a bit longer, in saying “I think there will be ongoing work for this group for a long time…”

    mitr added, “I’d almost say that the actual work _starts_ after the PRD, although the nature of it will change (coordination, prioritization of the “next service”, choosing software used to implement the PRD).”

    “[W]hich product [gets chosen] or dropped is left up for the entire server community to decide (with the exception of the first three or so maybe to get the process nailed down,)” responded Viking-Ice.

    mitr replied, “I don’t think people just following PRD can work. E.g. choosing between puppet/ansible/$many_other_alternatives needs to and up with a definite decision.”

    “We are that decision making body?” nirik asked Viking-Ice.

    “For the first products,” replied Viking-Ice. “[N]ot all products.”

    nirik then said, “Well, for the products we decide that the Fedora Server group is going to ship, sure.”

    Election Logistics

    A conversation came up as to how we would hold a vote for new members if we were going to have terms.

    “It is also not easy to organize an election,” pointed out tuanta. I pointed out that depending on the scope of the election (e.g., not the whole Fedora community but maybe just the server community, using the Fedora elections app or more informal in IRC or over the mailing list), it could be easier to organize.

    mitr added, “I’m not tied to the Fedora election app, but (from the outside) it seems that it’s easier to use that app than to manually count votes, and the confidentiality is a significant benefit.”

    nirik stated a preference to avoid the elections app.

    Suggested Voting Terms

    Evolution suggested a 6-month seat vote, but mitr wasn’t sure a 6-month term would work with an 18-month lifecycle.

    mitr pointed out, “I’ll reiterate that I don’t think having indefinite terms is healthy, although this seems to be a minority opinion among the WGs.” However, both myself (mizmo) and nirik stepped up and agreed with him.

    As mentioned earlier, Viking-Ice was in support of not having term lengths and instead having indefinite terms. “I personally dont see the need for the WG once the process is set,” as he stated his perspective on this. “No election[.] It would be better to simply have members confirm the continue[d] participation in the server WG every 3 or 6 months.”

    I asked the group what specific concerns they had about Viking-Ice’s indefinite terms proposal. mitr responded, “The WG confirming itself is not an effective mechanism for replacing a dysfunctional WG. (I know we are all perfect and this is purely theoretical :) )”

    After asking Viking-Ice if he had some way to account for that scenario, he replied, “Use the same approach as you propose we cross that bridge when we get there.” He also suggested that FESCo could be brought in to resolve issues in the case of dysfunction; when asked nirik said FESCo might be open to serving in that capacity.

    I brought up my own specific concern about Viking-Ice’s proposal. “I’m worried about stagnation – usually the energy of new members coming on board regularly helps jump start people’s enthusiasm at the regular intervals of election. it doesn’t seem like this would be guaranteed in your proposal,” I said. “Do you have ideas on how to account for this in your proposal?”

    “[L]ook at fesco same people for the last deca[d]e more or less,” he replied. “Fresh ideas killed instantly by the few fresh members that make it there so..”

    In response, nirik then proposed another idea to help bring fresh members to the team, “Every 6 months we randomly choose 3 members to replace (would also need at least 3 more active folks in the group to replace them with.)”

    This didn’t really go anywhere though, and nirik noted we had 10 days to submit a governance charter to FESCo.

    nirik continued, “I’m not coming up with too many great ideas there… and it might depend on: a) how long we exist, b) how many non voting active people their are in 6 months, c) if we need more fresh voting members or if as Viking-Ice notes the active people in the community would be enough for that.”

    “Actually… _if_ we are agreed that we should have some kind of turnover mechanism, then delaying might make sense; if we don’t have an enforced turnover, then let’s just close it now,” said mitr.

    I responded, “I do think we need a turnover mechanism, but I agree with nirik that it’s kind of hard to know how to set that up without seeing how active the community membership is and how long we intend to exist.”

    At this point, nirik proposed we vote on going with Viking-Ice’s proposal of indefinite terms and periodic (every 6 months) confirmation of working group membership. To interject some personal opinion here, it felt like consensus by exhaustion to me, and at least three people remarked while voting they were voting the way they were to ‘get this over with.’

    What is quorum?

    At the very end of the discussion mitr brought up the fact that the statement about quorum in the charter wasn’t technically correct with respect to the definition of quorum. It said we must have a quorum of 5 people to vote, which means the majority of 5 people (which is 3) positive votes would be required to agree to something in a vote. The intention behind the statement was to require 5 positive votes, regardless of how many people were present at the meeting, so the verbiage was updated to reflect that and all agreed to it.

    Approved Governance Charter

    So as of this meeting then, the Server working group has approved its governance charter as updated with the agreements and language discussed above:

    Stephen Gallagher, our FESCo liaison, will bring the charter to FESCo for approval.

    Is Fedora Server One Product?

    We’d taken up an hour by the point we finalized the governance charter, but I think everybody present was able to continue on and the #fedora-meeting-1 room was empty still, so we went on for another hour.

    The topic, “Is Fedora Server One Product?,” came from a thread of the same name on the server mailing list. The thread is relatively short:

    • Viking-Ice proposed that Fedora Server will be multiple products requiring multiple PRDs and also proposes a mission statement for the group. (The proposed mission statement: “Fedora Server WG where we discover product solutions that work well for
      our users, our administrators, our developers and our project.”
    • simo responded saying that Viking-Ice’s proposal “is not without merit” but says essentially it’s too large a scope and we’re not set up to do something like that. “It is not our core mission to go and modify single components,” he says. “I think our mission is more to interact with upstream and tell them what we think would greatly improve the situation for us and encourage them to provide those changes.” He also added, “I think what we want to do primarily though is build a foundation for
      all the interesting projects to run on. Provide the best possible, solid, core OS, people can depend on, where changes are pondered not only against the benefit they can bring to new admins but also how disruptive they would be to developers and existing admins. Our duty is to provide excellent transition tools for those times when disruptive change is necessary w/o having the ecosystem suffer for multiple releases.”
    • mitr responded to simo, agreeing completely with his last statement on the mission, but also pointing out that ‘upstream first’ doesn’t work well with the number of individual components we’d need to integrate.
    • mitr also responded to Viking-Ice, agreeing that ‘product solutions’ and end-user goals are the right focus, but he felt Viking-Ice’s emphasis on the application first wouldn’t work. He felt that having many individual recipes would be sub-optimal. “It doesn’t make much sense to me to make individual recipes starting with the application, and potentially diverging in the ‘infrastructure,’ he said. “Rather, the ‘infrastructure’ should be common and the base of the product, with the various services being treated more like ‘applications’ for the infrastructure (potentially some ‘bundled’ and some separate).”
    • sgallagh then reponsded to mitr’s response to Viking-Ice, saying that we could define many recipes in a reasonable manner depending on how we defined them. He gave examples of role-based potential recipes, basically suggesting that for each use case we have one ‘preferred’ technology / implementation. (Users could still install alternatives but there would be less support for it.

    That was where the mailing list left off. The discussion in the meeting, though, was unfortunately a lot less efficient than the mailing list thread. I think we basically talked at each other saying the same exact thing using different terminology and getting confused over language. At one point I declared ‘product’ to be a dirty word and tried to come up with a different word to get around the blockage we kept running into. I will try to outline the path of the discussion so you can draw your own conclusions.

    Well, is it one product? What is a product, anyway?

    I started off by answering the question, “Yes, I think it’s one product.” When Viking-Ice asked me why, I had my ux-design and fedora-websites hats on, thinking about how 500+ ‘products’ would be represented on our web page. I made the point that, “If Fedora as a whole is to have three products [workstation, server, cloud], we’re kind of bursting at the limit of what potential end-users are going to be able to handle.”

    nirik pointed out that we may be each thinking of something different for the meaning of the word “product.” He tried to ground the notion with a specific technical example: “Taking it from the deliverables angle, it sounded like people might like kickstarts + a netinstall iso… so we could produce N kickstarts for use with a netinstall… is each of those a ‘product’ ?”

    “nirik, i wouldn’t consider those a product no,” I responded. “They are different configurations for the same product.”

    Viking-Ice responded to nirik, “If it has gone through the transitioning process ( which I say is prd ) then yes.”

    “So, it sure sounds like a terminology thing to me. ;)” concluded nirik.

    “I think: just different meanings of what a product is,” tuanta added.

    Unfortunately, the confusion didn’t end there. :(

    sgallagh proposed, “To my mind, the Fedora Server as a product is a well-defined set of solutions that we have vetted for people to use. These solutions can be divided into ‘roles.’”

    mitr said, “I think the common infrastructure (kernel, booting, basic libraries, choice of configuration/management/…) framework needs to be uniform for all deployments. There may be specific separate “single-click” ways to install a specific role (corporate LDAP / mail / Java application server, whatever), but those are all “roles” of a single product to me.”

    In response to mitr, Viking-Ice stated, “I would call that common infrastructure between prd’s but I even doubt that it would be applicable to all of them.”

    mitr responded, “When I said “needs” to be the same, I did mean “needs” – we will be manpower-constrained even for the new things that we need to do, reinventing the same functionality for different kinds of servers is a waste we can’t afford.” He continued, “I agree it’ll kind of strange if we announce Fedora Server 1.0 !!! Implements all of …. 2 TCP protocols! but the overall direction should be of a single product with multiple roles.”

    “I mean, absolutely, each role needs to be defined,” I also responded to Viking-Ice, “but I think a PRD for each role is overkill.”

    “Only one the base OS can be labeled a product,” said Viking-Ice.

    nirik said that he “largely doesn’t care. call them ‘roles’ or ‘products’ does it matter in the end?”

    “From my perspective,” sgallagh offered, “the duty of the Product would be to set the definition of how something gets promoted into a ‘supported’ role in that Product.”

    mitr pointed out to Viking-Ice, “Or perhaps to take it from a different view, even if we have a nice pre-packaged LDAP and mail solution, I should be able to install a _single_ physical server that serves both, shouldn’t I?” If the pre-packaged LDAP solution was one ‘product,’ and the pre-packaged mail solution was another ‘product,’ the question here I think is whether or not you could combine two ‘products’ on one physical server.

    mitr continued, “installation is an implementation detail at this level of discussion I’d say. I kind of like having a ‘single big installation medium,’ but a minimal netiso that allows installing the various roles would work just as well.”

    “We need to be able to handle this on per product [basis] as in ldap as one product and a mail server as another,” Viking-Ice responded.

    “Why?” asked mitr.

    “[The] workstation working group has multiple and I suspect it’s going to blow over due to [its] gnome-ism and the DE community’s [way] with it,” Viking-Ice responded. “The cloud depends on our mutual definition of what is cloud and what is server and the [environment] and baseos [don't] have 1 multiple apps so to speak. I see products as single or multiple server application which an roles could be applied upon.”

    I asked, “What are other working groups calling what they are working on? Do they have roles vs. products issues?”

    mitr responded, “I think the other groups don’t have the equivalent of an ’1-click mail server’ use case.”

    “There are some different desktops (Gnome, KDE, XFCE, etc.) in Workstation WG,” tuanta pointed out. “It is also equivalent, I think.”

    Recap

    At this point I tried to do a recap of the multiple concurrent threads:

    1. We seem to have confusion about products vs. roles.
    2. We all agree – whether or not they are ‘roles’ or ‘products’ – they will share kernel, booting, basic libraries, choice of configuration/management/etc.
      • Viking-Ice agreed with this.
    3. We’ll make technology choices about what is the single supported way to do something (e.g., mailserver) but won’t preclude users from installing alternatives, just with less support.
      • Viking-Ice took issue with this statement, “There is no such thing as support in Fedora and people should really stop saying that instead use ‘best effort.’”
      • I replied, “There is such a thing as support in terms of, what does the documentation recommend? what is the default assumed configuration? etc.”
      • “Might say ‘featured’ or something?” nirik suggested as an alternative to ‘supported.’
    4. Each server could have multiple roles at the same time (e.g., email and ldap server.)
      • nirik showed concern about this: “If we allow multi role, we are going to have quite a combitorial QA doom.”
      • mitr responded by saying, “I don’t think it’s really different from having two or more applications installed at the same time – as long as they don’t talk to each other.”
      • “Sure it would be…” nirik replied. “Unless we don’t test anything as much as we don’t test it now.” He also pointed out, “Also, we can’t easily do multi with kickstarts…”
      • I replied, “Well we could…. depending on how the roles are defined. Using comps groups for example.”
      • “[Comps] groups are a mess and need to be reworked from ground up,” said Viking-Ice.
      • “But dealing with this as an single application or applicaton stack per product will allow us to host test days with that or those combined products,” pointed out to nirik.
      • “Kickstarts are a modifiable concept :)” mitr said. “Anyway, I really proposed this as a way to tell the difference between a single server / multiple servers. I’m really unwilling to back down from being able to install a single machine that serves two roles simultaneously (without resolving to virt.)”

    How many PRDs can a product chuck if a product can chuck PRDs? And what is a PRD?

    After a lot of the above discussion, which occured in a more interleaved manner than represented above, sgallagh tried to call some order: “Can I take a step back here and try to center us on the question we’re trying to answer? Could we agree to work on separate chapters of the same PRD for now, with the option to split them up later if it becomes obviously necessary?”

    nirik pointed out that he “thinks prd per application is overkill, but perhaps thats me.”

    “Trying to apply a prd to the entire group is [nonsense,]” responded Viking-Ice.

    I offered, “Let me tell you why I think PRD per application is overkill, and you let me know what you think – the PRD for each of those applications is the responsibility of upstream, not us. The upstream FreeIPA team, for example, is responsible for the FreeIPA PRD. We are only responsible for the PRD of the platform on which applications and stacks like that are meant to be deployed on.”

    sgallagh said, “I don’t agree with that 100%. I think we should be able to modify those packages to fit with our goals.”

    “I disagree with that,” said mitr, “modification and integration of upstreams should be in our scope as well.”

    “Modification and integration is fine,” I repsonded, “but a full PRD for the application I think is out-of-scope.”

    “I agree we will need a PRD for the individual app stacks, to make sure it’s integrated correctly and the like,” said mitr, “but they are all unified by the shared base, config management, monitoring and the like, and _that’s_ one basis of the server PRD; the other being a list of app stacks we want/need.”

    nirik added, “I would want a fair bit of information for a ‘role’ or whatever we want to call them… before commiting to producing, testing and delivering it.”

    nirik then made a proposal: “Make a single server PRD that includes what information we need from ‘roles’ and includes the initial set of them we intend to deliver.”

    “-1 that’s not what prd’s are for,” responded Viking-Ice.

    “Ok, then what are they for?” asked nirik.

    Viking-Ice replied, “Defining the transition process from an marketing idea to a product.”

    nirik said that he was, “confused, really the PRD is for fesco to tell them what we are making right?”

    “The server community is not a product,” said Viking-Ice. “Fedora Server is not a product. ‘Fedora Freeipa Server’ is a product.”

    “Ok, well, I guess I don’t care if we make a bunch of PRD’s instead of one,” replied nirik, “but I suspect a lot of it would overlap, no?”

    Viking-Ice replied, “Yes, hence I said we needed to do 3 or more products so we could identify where they would overlap.”

    “Fedora Server is a product in the same way that Microsoft Windows Server 2012 is a product,” sgallagh pointed out.

    “I’m pretty sure the point of the PRD is to define the problems a product solves, and in this specific case to let FESCo know what specific problems we feel need to be solved in the server space,” I suggested.

    sgallagh said, “I suspect that we maybe just chose the wrong term by calling this document a ‘PRD,’”

    “How about ‘Fedora Server Feature Requirements List,’” I offered. “What would we call ‘Fedora Server’ if we were avoiding the word ‘product’?” I came up with “Fedora Server Platform.”

    Continuing, I asked Viking-Ice, “Viking-Ice, are you okay with putting together a single functional requirements document for the Fedora Server Platform? That document can include all of the application stacks and roles of interest.”

    “Single functional requirements document for the Fedora Server Platform is one thing but dont think we can apply the application stack or roles of interest to it ( yet ),” he replied.

    nirik said, “I don’t care what we end up calling things. I want a common base thing (netinstall iso, whatever) and some ‘featured application stacks’ or whatever that we commit to putting together from our collection and making shine.”

    “Nirik, i think we all agree, vocabulary hangups aside,” I responded.

    Nirik proposed, “common base platform with ‘featured application stacks’ built on top of it. We commit to produce, test and distribute these application stacks,” to which he received multiple affirmative responses. He continued, “Thinking about it, we will need a way to promote/add new applications, so perhaps the requirements doc could just explain how that happens and the applications could be seperate. Whatever works tho.”

    I think we kind of fell apart from there, though, and ran out of time. So I’m guessing next meeting we’ll try to pick this topic back up and come to some resolution.

    Meetbot Minutes

    Here is the official meetbot meeting minutes with links to the full raw log:
    http://meetbot.fedoraproject.org/fedora-meeting-1/2013-11-05/fedora-meeting-1.2013-11-05-16.02.html

    November 03, 2013

    Get 'em while they are young
    A relaxed post as for a lazy Sunday afternoon: the little one is "hacking" graphics with Inkscape on a Fedora Linux laptop.
    <video controls="controls" height="360" width="640"> <source src="http://nicubunu.ro/pictures/hacker.webm" type="video/webm">Your browser does not support the video tag. </video>
    In case the VIDEO tag does not work for you, here's a YouTube version.

    October 30, 2013

    Fedora Server Working Group: Initial Meeting Minutes

    Fedora Server Working Group Logo

    Today was the first meeting of the Fedora Server Working Group!

    In case you’re not aware, let me provide a bit of background on the group first, and then we’ll go through a summary of how the meeting went.

    Background

    Stephen Gallagher wrote an excellent background to the working group in his announcement of the group’s formation, so this will be a very brief summary. For more in-depth information please refer to his post.

    Matthew Miller and Stephen Gallagher (with a lot of input and help of the Fedora community) put together the Fedora.next proposal which he presented at Flock and on various mailing lists; it’s been discussed within the Fedora community for the past couple of months at least. Part of the proposal involves the creation of working groups, three of which are product working groups – Workstation, Cloud, and Server.

    The deliverables the working groups are meant to focus on first are the following:

    • A Product Requirements Document due January, 2013.
    • A list of necessary changes from existing Fedora procedures needed to release the product.
    • To actually tart producing the Fedora Products listed here.

    Membership

    Stephen Gallagher is the Server Working Group’s FESCo coordinator, and he chose a set of self-nominated Fedora community members to serve alongside himself as the nine voting members of the Server Working Group:

    • Stephen Gallagher (sgallagh)
    • Jim Perrin (Evolution)
    • David Strauss (davidstrauss)
    • Truong Anh. Tuan (tuanta)
    • Máirín Duffy (mizmo)
    • Kevin Fenzi (nirik)
    • Miloslav Trmač (mitr)
    • Simo Sorce (simo)
    • Jóhann B. Guðmundsson (Viking-Ice)

    Note that anyone is welcome to participate as a non-voting member!

    How to Get Involved

    Here are the various resources currently affiliated with the Server Working Group that you can use to follow along or participate:

    Meeting Minutes

    Here’s a run-down of today’s Server Working Group meeting:

    Agenda

    • Meeting frequency and times
    • Ticket Tracker/Wiki
    • Governance Charter
    • Open Floor

    Meeting Frequency and Times

    First we talked about how frequently we should meet and at what time. This diverged a bit into other topics (how to handle absences and time zone issues.) We agreed on the following points:

    • The Server working group will meet on a weekly basis. There wasn’t any dissension about or discussion on this point.
    • If there is no agenda posted to the mailing list within 24 hours before a meeting is set to start, the meeting is cancelled and Stephen will send out a cancellation notice to the mailing list. Jóhann suggested the cancellation note just so that it’s clear the meeting is not happening.
    • Stephen will send out an email to the voting members to figure out a time that works for everyone on a weekly basis. It was pointed out that the United States is going to go through another time shift this coming weekend, and we’re coming down off a flurry of conference travel with folks travelling across timezones, so we need to set a time that will be sustainable long-term.
    • In the case where a voting member can not make a meeting, they can either pre-vote via the mailing list or abstain-by-default. I did raise a concern about unplanned votes taking place due to a disagreement that cropped up during a meeting that an absent member could not forsee to pre-vote on, but we decided keeping things simpler is best, and if that one vote wouldn’t have mattered anyway it is not a big deal. We’ll wait until we run into a situation where the absence becomes a problem to make any policy for it.
    • During meetings, silence indicates consent. If people disgaree, then that will bring it to a vote. As Kevin pointed out, “I think we should strive to work on consensus, and only vote on things where it’s clear people aren’t going to be convinced to agree.”

    Ticket Tracker/Wiki

    We then moved on to talk about the tools we will use to conduct business – managing and tracking our progress. Some of the asset types that came up as needing to be managed with tools were:

    • Working documents (governance doc, PRD)
    • Agenda items
    • Decisions
    • Discussions
    • Meeting minutes / summaries

    While Stephen suggested initially that we set up a Trac instance to keep track of agenda items and discussions, several members (Jóhann, David, Simo) had concerns about prematurely setting up Trac before we had determined through experience that we needed it. We collectively decided to table any Trac set up and to use the Fedora wiki to trac agenda items, decisions, and discussions until it became too unwieldy. At that point, we would have the experience to fully understand the requirements of the tool we needed and be able to select a tool based on requirements. Again, the overarching concern here, I believe, was simplicity.

    I volunteered to start a blog for the group to share meeting minutes and any progress we’ve made (so here you are. :) ) Initially I’m going to make the blog posts here on my personal blog, but I will also set up a group blog for the Server working group on OpenShift and have that subscribed to Planet Fedora. Meeting minutes will also be posted to the server mailing list as well as to the Fedora meeting minutes list.

    It was very unanimously agreed that the working documents would be stored on the Fedora project wiki, following the lead of the Cloud working group.

    Governance Charter

    We then moved on to start discussing the governance charter. Jóhann very helpfully put together a Fedora Server working group governance charter draft which we read through and used to direct the discussion.

    Jóhann’s draft has four main sections:

    1. Membership
    2. Current Members
    3. Making Decisions
    4. Changing These Rules

    While there was a lot of agreement about the content of the other three sections, there were some concerns and disagreement about the content of the membership section – enough that the discussion was not conclusive and we decided that we should discuss it further on the mailing list and it should be part of the agenda for next week’s meeting.

    The main point of contention about the membership section was that there are certain slots in Jóhann’s proposal meant to be dedicated to specific teams within Fedora. There were several concerns voiced about this team-based slot approach:

    • Some teams in Fedora are spread thinly enough that they might not have anyone willing to serve in representation of them. The counter to this concern that Kevin proposed is that the groups would be given ‘first dibs’ at nominating someone to fill their slot, and if they couldn’t then the slot would open up to anybody interested.
    • It’s not really clear what advantage having someone from each team would provide the group – it was pointed out by both mitr and mclasen that it is easy to reach out to folks on other teams and get help from them, and being a direct member of the working group isn’t necessary to assit the group.
    • Some of the slots are reserved for people who represent the ‘server community,’ but it isn’t clear how someone would be identified as representing the server community or not. What exactly is the server community? Doesn’t everyone on the working group need to represent the server community? How can you discern if someone is qualified to do that?
    • Miloslav was concerned about this resulting in the group “having a great planning infrastructure and no one to do the planned work,” and suggested it would be better if the group was made up primarily of ‘do-ers’ who can get things done rather than decision-makers who would need to rely on external volunteers to get the work done.

    Hopefully we’ll have some discussion about these points and others and clear up what we think the membership section needs to say.

    Open Floor

    We only had about 5 minutes left (and went over by 5 more) after determining the main meat of the governance proposal that we had to work on was the membership section. We threw out different ideas for loose threads of discussion and other issues we thought should be considered for the next meeting’s agenda:

    • The governance “membership” section – The ‘membership’ section of the Server working group governance draft.
    • The use cases for the Server product – discussion of this is already happening on the mailing list. These should help inform the product requirements document the team needs to put together for January.
    • Short-term deliverables and PRD – Kevin suggested that we should start discussions on the team’s short term deliverables and initial PRD work.
    • General direction of how the product will be made – Simo brought up that we might need to discuss ‘how the sausage gets made,’ e.g., “are we going to suddenly have 4 different rawhides or how to we handle package management.” Jim responded with, “I would hope we’re still working from a common package set, and either putting our changes in the packages or groups.” Simo concluded that, “I’d like we discuss a bit in the agenda what we think is the general direction and the ‘absolutely not’ and the ‘absolutely can’t do without.’”
    • Mission statement – Stephen suggested, to follow the Workstation group’s lead, that we put together a mission statement (and potentially a vision statement.) I’m going to draft the initial statements and send them to the list for discussion.

    Meetbot Minutes

    Here is the official meetbot meeting minutes with links to the full raw log:
    http://meetbot.fedoraproject.org/fedora-meeting-1/2013-10-30/fedoraserverwg.2013-10-30-17.00.html