Blueprints, specs and anything in between

in my first blog post I was discussing the place of a non-developer in the open source community and I was trying to use my experience with blueprints/specs new process to illustrate that.
I want to thank all people who commented on my post because you truly were trying to understand a specific issue and solve it.  However, my experience was an example to a greater issue and I could see by some of the comments submitted that perhaps the use of my experience in the post was not the correct course of action.

There are two major issues that I want to discuss.

1. the decision to use specs to submit a blueprint
2. implementing changes in the community to allow for a more eclectic open source community.

These two subjects deserve a post of their own and so I would like to discuss the first issue of blueprints first and try to come up with a diverse range of ideas on how the community can perhaps be a bit more flexible to it’s code challenged members in my next one.

I believe that some of the comments posted on my last post actually demonstrated what I was trying to say to begin with – people are so nice and I love that… if you approach any one with an issue they will try to help and that is lovely.
having said that, people still think that the developers are still the only real role in open source and so those of us that are not interested or shall I dare say are not proficient in coding, should learn enough to do minor tasks which have a development affinity to them in order to be able to properly integrate in the community (when in Rome right?)

Following some of the comments, I was thinking if perhaps the spec decision by the community was correct and my perception of it is actually what should change and by doing that I realized that my past experience with Blueprints submissions can be categorized to 3 different submitter’s:

1. the user/customer – they need a new feature to better use the product
2. QE  – either for a better use of the product or a bug fix that requires major code change
3. development  – major code changes which the user will rarely notice.

The two first options are both options that should be visible to the end user and you would never expect either the user or QE to come up with the design would you? not that they should not be involved with the design, but that they will not be writing the design or the code change themselves hence the design should be done by the person who will.
IMHO, what we are currently doing in the community is ignoring and even diminishing the user’s influence on openstack hence, If our goal is to create a product that only developers will want to use than we are on the correct path…

I understand the reasoning behind the spec decision which was to make sure the blueprint are submitted with a proper design and make everyone’s life easier.
But do we think that forcing a blueprint submission to be joined with a technical spec else sending the submission to /dev/null is really the way to improve openstack or are we actually unhinging it instead? can’t we come up with a way to allow all 3 submitter’s to co-exists?

For example, I can think of a way to make sure that a new blueprint code submission would be submitted along with a proper design – asking QE or system administrators to read the design and give their +1 before the feature can be merged.
I not only think that this will raise the level of the designs and also improve the features at the design stage but that it would also increase the involvement of QE and system administrators in the community.
If we want to build on that even further… why not ask that any QE/system administrator that is reviewing a new feature, also writes a basic test plan/test case to be added to the design (not an automated one but a manual one), hence increasing our role in the community even more?

in conclusion, I think that if our community wants to improve the feature’s documentation and design there are other ways to accomplish that without excluding non-coders from the submission process. on the contrary, I believe that this can be the first step in a better integration of non-coders in the community…



the place of a non-developer in the openstack community

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.