For a while now, I have been contemplating the role of non-developers in the community.
As a non-developer I sometimes find it hard to navigate in the open source community and find that people often think that if someone does not contribute code then that person is not a contributor.
I think that many of you reading this are now thinking that I am being ridicule and that you yourselves have never excluded anyone from the openstack community.
That may be correct as individuals however, I think that as a community, the decisions, procedures and even influence of individuals are measured by coders for coders.
I have never written code, never automated tests and if I am honest I do not think I have the skills to do so. I do have the skills to learn the product flows, find the soft spots and to bring a user’s and administrator’s point of view allowing me to not only locate the bugs a developer will not always find in places they may never think of looking but also contribute to making the product better for the intended target – the user.
All that said, on my first week working in the openstack community I have heard the following line from several people “If you don’t contribute code, you’re not really a contributor so learn python”
Since I started working on openstack I realized that the main discussion in meetings is code. Even QE’s meetings are about new automation tests written for tempest and if you are not an automation QE you will feel left out.
I will jump to the latest decision made in the community: blueprints and specs.
It appears to be a good decision making people who suggest a new feature to also suggest a solution.
However, as a non-developer it took me the better part of the day to understand what I need to do.
It all started when I opened a bug which was closed with a request to open a blueprint.
I opened the blueprint and then sent it to the engineering mailing list where I was asked to open a spec.
Since I never worked with git it took me a while to understand what I needed to do and submit a spec.
To my surprise, at this point, I was told I should not have submitted the spec in the first place since I have no way of submitting a technical solution to it.
I found it very frustrating that once I finally submitted the spec I was told that the blueprint + spec procedure was created for developers only.
Not only did I spend a long time working on something I should not have been working on in the first place but also I believe that by deciding on this procedure the community has basically limited even more the options given to a non coder to contribute in the openstack community.
A few of my colleagues suggested that I write a blog on the hardships that I had submitting the spec during this discussion, someone suggested adding a blog in planet.openstack.org and a second person immediately commented that you need to submit code in order to add a blog to planet.openstack.org
Hence I have decided that perhaps it is time to raise the issue of what exactly is the openstack community for non developers? Perhaps the reason the community is largely run and created by developers is because non developers quickly understand that they have no room or a place in it?
I would like to call out to the openstack community to be the first community to change the way that open source communities work and start changes which would open doors to non coders to contribute and integrate in the community.
dronopenstack 
Dafna, your frustration is understandable.
Top off my mind, some areas a non-coder can contribute in upstream OpenStack (I’m sure you can imagine/and you’ve already done some, but I’m being explicit, anyway): (1) Reporting bugs (2) Bug triaging – Frequent upstream bug triage days are held upstream (3) Documentation writing/reviewing (both admin/operator and developer docs) (4) Use-ability/Interaction design. (5) Infrastructure: Writing simple queries for Elastic Recheck[*] to help find out how many times a bug is occurring in Jenkins runs. (6) Helping with root cause analysis of upstream Gate debugging failures. (This area dearly needs more help).
That said, I’m sure you must have noticed, most the above tasks use a common approach: Using Git + Gerrit + Jenkins as a system submit and merge changes, including documentation. If one is new to either of Git or Gerrit — true, there’s a learning curve and practice that’s needed. Once that initial workflow is established, I think their fruits are undeniable.
Not sure if you already took a look at these two useful wiki page[1] to establish a workflow with git+gerrit. Another useful page that lists different possibilities[2]
Don’t hesitate to ask (any kind of) questions. My only suggestion is persistence.
Hope you don’t misinterpret me.
[*] Elastic Recheck in short: You just write a small (2 or 3 lines) bug signature in YAML, and see how many times it pops up in Jenkins queries. https://github.com/openstack-infra/elastic-recheck
[1] https://wiki.openstack.org/wiki/Getting_Started
[2] https://wiki.openstack.org/wiki/How_To_Contribute
LikeLike
I can relate to your frustration. As a non-developer, I haven’t really appreciated the decision to base the specs on gerrit, but I haven’t found a better solution to propose to developers so here we are.
What was your spec/blueprint/bug about?
LikeLike
Never mind, found all of it (bug, message to list and spec)…
I have looked at the history of https://bugs.launchpad.net/nova/+bug/1323578 and it seems to me that all started from a misunderstanding, from Melanie who thought you were a developer and suggesting you to file a blueprint.
Indeed, I think that the best approach is what Daniel suggests in https://bugs.launchpad.net/nova/+bug/1323578/comments/6, that non-developers should not be required to participate in the discussion around things they’re not necessarily familiar with.
While I think that as a community we have plenty of ways to improve how we include users and operators in our conversations, in this particular case, I think your frustration comes from being pulled in the wrong place from the beginning. What do you think?
LikeLike
HI,
This is not a bad decision (the whole blueprint thing) as the issuer of it needs to show some sort of a logical way to identify, address and solve a problem.
As a non-developer myself I find it a good direction forward to make blueprints and specs more readable and understandable as some often, are not. With the same breath of air, I often see too many bugs opened in Bugzilla by developers who have no idea how to do it and I’m very fortunate for the ‘need info’ flag.
Furthermore, IMHO even as a non-developer each and every one of us should know some basic things when working in a certain environment (when in Rome?).
OpenStack uses a certain chain and everyone involved in and around this project should be familiar with it.
My 0.02
LikeLike
I too share Dafna’s frustration, having created a bunch of blue prints mostly in Glance, I’ve been asked to spec them, needless to say I haven’t, not being a coder I guess I’m not even supposed to fill them in now. Similar to Dafna writing code isn’t my daily cup of tea, yes I can read code and god for bid even write in a few languages (mov ax, bx.. ) but my background and insights come from a sysadmin’s point of view.
Some of my blueprints suggestions are better than overs I admit and may or may not be accepted or welcomed, this is fine and how it should be, but now with new specs procedure my blue prints don’t even get a response, which means they are ignored! This is a shame cause if you think of it a typical end users of Openstack is a sysadmins / users rather than Openstack programmer, not to mention the old saying “The customer is always right..”
Learning git+gerrit would be useful I’ve started, a couple of times, not using it daily or as a primary tool means its going to be painful compared to just filling in a blue print. I’ll tell you why, it’s not cause of learning a new tool, heck my tool boxes are filled with wonderful tools hardware (sledge hammer screw drivers..) software (vim scp setrbouleshoot git:). It’s the fact the the new specs asks stuff I can’t answer as some one not familiar with the inner workings, for instance: Data model impact or REST API impact, who am I to know how these are affected by my suggested blue print? Actually to be honest unlike code people I don’t care that much about Data models algorithms or REST of that stuff my main goal is to make Openstack great and cool. If you didn’t guess by now I’m yet another none coding contributor to Openstack (hint QE).
Yes we none coders think out of the context of programming lines that’s our benefit don’t take it away from us by turning us into the code people we don’t want to be. Not all our ideas are possible or good but some of them are, yet now they will forever lie as an uncalled procedure code in launchpad 😦
LikeLike
Pingback: Only developers should file specifications and blueprints][ stefano maffulli | ][ stefano maffulli
Hi Dafna,
Thanks for posting this, I really enjoyed reading your thoughts and feel compelled to respond with my experience and ideas.
As Kashyap mentioned, one role you might be able to play a big part in is Usability/Interaction design. This is the role I’ve been taking in the community and although I’m not a developer, I feel very welcomed by the community. I will typically log new bugs and add comments to existing bugs based on feedback I’ve heard from end users and User Experience best practices. I also created wireframes to visually show suggested changes for Horizon and make it a bit easier for us all to get on the same page and talk about an enhancement. Considering you have feedback on OpenStack as an end-user, I would say your feedback would be incredibly valuable.
I have logged blueprints in the Horizon project in the past (perhaps this is the wrong thing to do considering I have no intention of actually developing the features) and I am definitely still trying to figure out the best way to encourage developers to take on work that is highlighted in Usability testing that we’ve done with end-users. It sounds to me like the community is taking big steps forward with respect to involving Operators more and more when it comes to choosing which features to implement for each release, which is so great to see.
Please do reach out to me on #openstack-ux if you would like to chat further.
Best,
Liz
lblanchard on freenode
LikeLike