Uncategorized

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…

 

Standard