Updates from May, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • stefano 6:55 pm on May 14, 2015 Permalink | Reply
    Tags: , ergonomic, , touchscreen, xps13   

    A week with Dell XPS13 9343 (2015 model) 

    Last week I have received the new Dell XPS 13 from the Sputnik program, the one with Ubuntu pre-installed. I wanted to vote with my wallet since I believe Ubuntu is a pretty solid desktop environment, on par with Mac OS X and various Windows.

    Design-wise  Dell has produced a very good looking machine, nothing to say about that. Kudos to Dell’s team on designing something much prettier than a Macbook Air. The screen with no border is fantastic with almost no frame and it’s great to look at it.

    The only complaint I have towards Dell are the options they picked for the Sputnix program: the only way not to get a touchscreen is to buy a severely limited machine with only 128MB disk. No way. All the other options force you to spend money and sacrifice battery power on a useless feature.

    I think touchscreens are uncomfortable to use on desktops and I said so a long time ago. Unless the desktop OS is radically re-designed for touch and hand gestures on the monitor, it makes no sense. I would have never bought the touchscreen if Dell had offered a 256MB option with the regular monitor.

    On the Ubuntu side there are quite a few glitches like this issue with the cursor becoming sticky on some applications even if the touch-to-click on the touchpad is disabled and some difficulty to adapt to the ultradense display. By the way, that’s another reason not to get the touchscreen: lower resolution is good enough on such a small laptop anyway. Installing Ubuntu Vivid also was a bit more painful than I thought.

    All in all, I didn’t return the laptop as I thought I would, mainly because I needed to upgrade to a machine with 8GB rapidly.

     
  • stefano 9:32 am on March 25, 2015 Permalink | Reply
    Tags: bitnami, , ,   

    Vote to get Mediagoblin on Bitnami 

    I’m a fan of GNU Mediagoblin, the media publishing platform that anyone can run. You can think of it as a decentralized alternative to Flickr, YouTube, SoundCloud, etc. It would be great to have it packaged for Bitnami so more people can run it easily. Vote for Mediagoblin!

     
  • stefano 4:35 pm on December 16, 2014 Permalink | Reply  

    How to get better at IRC-based meetings 

    Marvel’s Professor X sure knows how hard IRC meetings are

    When people approach discussions via IRC for the first time, most of the time they get overwhelmed. Being IRC the most common way to hold meetings in OpenStack, practicing written communication on IRC should be suggested to start immediately to all new contributors.

    I still remember the first time I went on IRC: I felt like I was in a room where everyone was speaking loudly and I could hear every single person in the room. It wasn’t like being in a loud crowd where all you hear is noise and your brain is perfectly trained/evolved to filter out: I felt like comic book characters may feel when they actually hear and comprehend everything everybody is saying. It was scary. It took me a while to learn how to filter the written noise and follow multiple threads in real time, write an answer to someone while reading a question from someone else.

    In the past days I’ve been working closely with people in teams that had no practice of holding conversations on IRC. Especially some of these people had no practice in holding meetings on IRC. I hear often the complaint that written chat meetings are too slow but I believe it’s the opposite: they’re too fast, they require skills and training that may take months of daily practice to master. IRC has strong advantages though, that speed at which discussions can progress with 10-15 people and more is sweet, so sweet that when I am stuck in audio-video conferences, everything seems to be too slow and distractions abund.

    To all people new to IRC I suggest to practice and practice and practice some more. It’s really not that hard to join an IRC channel and just spend few minutes a day to read the history and try to make sense of it. It’s a habit: if your job description includes writing a specs for OpenStack then an IRC client should start every time you login in your machine. Even if you think you have nothing to say: get started when you don’t need to say anything, just start to get your brain trained for IRC super-hero powers, like those of telepath Professor X. Learn to filter the background, follow multiple threads if needed, improve your typing speed. The OpenStack wiki page has some basic pointers to get started. If you have suggestions, feel free to edit that page.

     
  • stefano 3:19 am on November 13, 2014 Permalink | Reply
    Tags: , , , , , ,   

    Tips to improve organizations contributing to OpenStack 

    The slides of my presentation at OpenStack Summit in Paris 2014 (download ODP source, 9M).

    And the sessions’ recording:

     
  • stefano 1:23 pm on November 11, 2014 Permalink | Reply
    Tags: , ,   

    Post-summit summary of OpenStack Paris 

    Seven straight full time working days, starting from 9am Saturday and Sunday for the second edition of OpenStack Upstream Training to the feedback session on Friday evening at 6pm are finally over and I’m starting to catch up.

    I spoke on Monday, highlighting some of the findings of my research on how to change organizations so they can better contribute to OpenStack, later lead with Rob, Sean and Allison the creation of the Product working group (more on this later). The double-length session dedicated to addressing the growth pain in Neutron has removed the “if” and left the question to “how and when do we empower drivers and plugin developers to take their fate in their own hands”.

    I think this has been one of the most productive summit, I’m leaving Paris with the feeling we keep on improving our governance models and processes to better serve our ecosystem. Despite the criticisms, this community keeps on changing and adapts to new opportunities and threats like nothing I’ve seen before. I’m all charged up and ready for the six months of intense work leading up to Vancouver!

     
    • Tom Diederich 10:03 am on November 19, 2014 Permalink | Reply

      It was great meeting you at the Paris summit, Stefano! It was a fantastic event!

      • stefano 7:52 am on November 21, 2014 Permalink | Reply

        Thanks Tom! Good to see you too.

  • stefano 8:21 am on October 7, 2014 Permalink | Reply  

    Next steps for ‘Hidden Influencers’ 

    With Paris only weeks away it’s time to announce that we have a time and place to meet people whose job is to decide what OpenStack means for their company. The OpenStack Foundation has offered a room to meet in Paris on Monday, November 3rd, in the afternoon: please add the meeting to your schedule.

    There have been discussions in the past weeks about the hidden influencers, there was a recent call by Randy Bias to identify people, functions, groups, anything who can own the product OpenStack. The time is ripe to get to know who directly control the engineers’ priorities and complete the circle of end users, operators, product owners, developers.

    Rob, Sean, Allison and I have the idea of creating a working group modelled after the Operators group: get people in the same room, some time mid-cycle and sync up on the development effort. It’s just an idea, mid-cycle is when the development roadmap gets more realistic, it’s more clear which blueprints are in good shape and which are less likely to make it into the release. We believe it would be valuable to have a moment when product decision makers can coordinate and get a chance to share their priorities.

    The room is available for 4 hours, but of course we can use for less time if needed. It makes sense to start hacking some of the topics in the next weeks, before Paris. Please join the mailing list and introduce yourself while the agenda will be drafted on the etherpad. For naming the group you can join the async brainstorming session (drop names at random and don’t judge yourself nor others: everything is fair game).

     

     
    • Debra 11:08 am on October 8, 2014 Permalink | Reply

      So glad you are organizing this group! Wish I was going to be at the Summit this time to participate in person.

    • Albert 8:30 am on October 23, 2014 Permalink | Reply

      Looking forward to the discussion Stef. See you in Paris.

  • stefano 3:40 pm on October 1, 2014 Permalink | Reply
    Tags: , , wiki   

    Improving the content of OpenStack wiki 

    The pages on wiki.openstack.org have been growing at a fast pace and it’s  time to give the wiki more shape: new contributors, end users and operators are having a hard time finding documentation since over time it spreads across many places. The wiki can have a role at directing readers where most appropriate. Luckily we have a team ready to help give the ~350 pages a more solid navigation and fixing content while at it:

    • Katherine Cranford (a trained taxonomist) volunteered to get through the wiki pages and propose a taxonomy for the wiki.
    • Shari Mahrdt, a recent hire by the Foundation, has volunteered a few hours per week to implement the taxonomy in the wiki pages, setup templates and write documentation to maintain the wiki.
    • I am overseeing the implementation and looking more carefully at content for contributors.

    We are keeping track of things to do on the etherpad: Action_Items_OpenStack_Wiki. Shari and I started implementing Katherine’s proposed taxonomy: it’s visible as a navigable tree on https://wiki.openstack.org/wiki/Category:Home.

    As an example of how the taxonomy works, let’s look at the tree of OpenStack Programs. One can think of Programs as teams of people using tools (code repository, bug tracker, etc) and coordinated processes to deliver one or more project to achieve a clearly stated objective. For  example, the Telemetry Program has a team of core reviewers responsible to drive development in code repositories for the Ceilometer project and the Ceilometer client, and each has pages for blueprints and specs, meeting notes and more. Programs contain projects, so the tree of categories under Programs will look like:
    • Programs
      • Telemetry
        • Ceilometer
          • Client
          • Blueprint
      • Block Storage
        • Cinder
          • Client
          • Blueprints
      • Compute
        • Nova
          • Client
          • Blueprints

    You can see this live on the wiki on https://wiki.openstack.org/wiki/Category:Programs. Fairly straightforward except that over the years some of the pages have started with describing a project and have now been repurposed to illustrate a Program. Look at Nova page for example: the name of the page is “Nova” but the title is OpenStack Compute. We’ll definitely have to shuffle content around.  For example, the Category:Programs page can be considered a duplicate of the wiki https://wiki.openstack.org/wiki/Programs page: since everything on mediawiki is a page, the Category pages can be edited and can be redirected to/from like all other pages. In this case, it would make sense to make high level content like Programs more of a dynamic page, like Category:Programs. The cool thing of this approach is that we can probably create new category page for new programs automatically when modifications to the programs.yaml are approved via jenkins.

    Adding a taxonomy and templates (more on this later) will help newcomers discover relevant content and find information more easily. While we implement the changes to the wiki we’ll also be reviewing the content on the pages, delete or mark as obsolete the old stuff and make things more readable for all. You can keep up with the progress by looking at RecentChanges.

    If you’d like to help us out or find out more please feel free to contact stefano@openstack.org and shari@openstack.org

     
  • stefano 3:19 pm on September 25, 2014 Permalink | Reply
    Tags: , contributions, ,   

    How is your OpenStack team organized? 

    I’ve been collecting a lot of good insights talking to directors and managers about how their companies are organized to contribute to OpenStack. For geographic reasons I have mostly gathered comments from people between San Francisco and Silicon Valley and I’d like to expand the research.

    I’m especially interested in learning about internal processes, system of incentives, things that impact performance evaluation for engineers contributing to OpenStack.

    To expand the research I’m asking the OpenStack community to fill in this brief survey or contact me directly (stefano openstack.org) for a quick interview.

     
  • stefano 5:03 pm on September 18, 2014 Permalink | Reply  

    Improving Documentation for new OpenStack Contributors 

    I think we’re starting to see too much friction and pain from contributors to OpenStack plugins, drivers, extensions: a lot is going on and joining the community feels like boarding a bullet train while it’s running at full speed. We’ve been doing a good job pulling people in the OpenStack community and educate them with our tools, processes especially for contributors to the Compute, Storage, Networking pieces of OpenStack; there are margins to improve life for “casual” contributors and newcomers in general.

    The main problem I think is that we’ve been treating all developers like they all have the same amount of dedication to the collaboration effort. We’ve been asking every person contributing to OpenStack to act the same way, whether they were fixing a small bug in Keystone or refactoring Neutron’s code: same gerrit review workflow, same process for blueprints/specs. We assumed always that anybody at any given time had the same level of knowledge of deadlines and recent changes to the processes. We are requiring people with radically different objectives and set of incentives to know and do the same things. I think this is starting to become too much of a problem for the community. We are already having conversations about this (split drivers, Neutron incubator, refocus summit, modify the legal requirements) and will continue discussing in Paris.

    The one thing that we should start improving immediately is the documentation for new contributors. New contributors have lots of resources available like the Welcome Guide, docs.openstack.org/developer, lots of wiki pages of varying degree of correctness and quality, tips and tricks on blog posts, upcoming video series, IRC support and Upstream Training. Based on what I hear from some, they struggle because these are in different places and owned by different people. A place where this content is shown in a more coherent way would be a great improvement.

    There are two efforts to improve various pieces of documentation: the Documentation program wants to redesign the Docs portal, and a new portal is being designed for developers of applications based on OpenStack. The Documentation program is not responsible for developers’ content on the Docs portal, it simply hosts the materials produced directly by the programs. While we wait for a redesign of the Documentation portal, I think we can start by fixing the wiki pages. With the help of a taxonomy produced by volunteer Katherine Cranford and Foundation’s staff Shari Mahrdt, we’ll give a bit more structure to the OpenStack wiki. Stay tuned for more details.

     

     
  • stefano 3:22 pm on August 4, 2014 Permalink | Reply
    Tags: , , contribute, , , open innovation,   

    How do companies do OpenStack? 

    I’m cruising Silicon Valley these days asking “how does your company do OpenStack?”  to collect best practices and notable mistakes from various leaders of OpenStack corporate community. I’m hoping to build a ‘how to’ manual to help managers build better dev teams, more effective at collaborating while shipping products to their customers. This is an effort that goes hand-in-hand with training new developers with Upstream Training and other initiatives aimed at sustaining OpenStack growth.

    I often have to explain to managers of OpenStack corporate members how and why to contribute to the project. The level of complexity reached has now exceeded the simple answers, like ‘fix simple bugs’ or ‘read the wiki pages’. For example, the participants to the Upstream Training in Atlanta had difficulties finding low-hanging-fruit bugs to work on: by the time they were ready to commit, someone else had already fixed it. Too much is going on at the same time, newcomers are confused at many different levels.

    While we will keep training developers through Upstream Training (and other initiatives), we’re going to start talking to managers too.  I’d like to know how development teams are organized, how they balance shipping products to customers with contributing upstream, what incentives are in place that help or prevent contributions to go upstream, how career paths are influenced by contributions to the open source collaboration, etc.

    If you’re managing a team of developers or devops, you’re a CTO, a HR executive or are managing in any way a team of engineers contributing code to OpenStack, I would like to talk to you: email me and vote for my talk proposal “How to maximize effectiveness of your developers contributing to OpenStack”.

     
    • miko matsumura 12:19 pm on August 5, 2014 Permalink | Reply

      I would like to talk with you about Hazelcast an Apache licensed open source In-Memory elastic data and processing grid. I am wondering if there might be a way for us to contribute/collaborate with open stack

      • stefano 9:11 am on August 6, 2014 Permalink | Reply

        Hello Miko, I’m sure there is a way to collaborate :) Hop on IRC freenode.net #openstack-community and we can have a chat. Or send me an email.

    • Jean-Daniel Bonnetot 8:34 am on August 12, 2014 Permalink | Reply

      “email me”
      Yes, but where? :)

      • stefano 8:48 am on August 12, 2014 Permalink | Reply

        I’m stefano at this domain or at openstack.org :)

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel