Open Stack

Putting your questions down

*Why are people coming with "requirements" but without contributors to work
on those things in the first place?*


*Are they really "requirements" in all cases? Or are they "wants"? If they
are "wants" with a niche audience, is it really appropriate for the
community to place a priority on them?*


*Sometimes a person will have a great idea but no resources to implement
it. Do we have cases where the community picked up those ideas? Or didn't?
Why were the cases different?*


*Do we have recent cases where contributors showed up to work on something
and were given a flat "no" response? **What reason was given? I'm sure we
can find lots of cases where contributions were accepted. What differences
can we find?*


*Do we have recent cases where folks reported issues that truly went
unanswered? Was the answer "we have to finish this other task first"? Or
"we won't have time this cycle, but we can work on that for the next
cycle?" Or "that is a bad idea, for reason X"? Or something else?*



On Sun, Jul 16, 2017 at 2:03 PM, Melvin Hillsman <mrhillsman at gmail.com>
wrote:

>
>
> On Sun, Jul 16, 2017 at 12:32 PM, Doug Hellmann <doug at doughellmann.com>
> wrote:
>
>> Excerpts from Melvin Hillsman's message of 2017-07-16 11:51:21 -0500:
>> > Observation: One typical concern voiced regarding a requirement from a
>> > working group/team, organization, deployer, end-user, etc is that there
>> are
>> > no guarantees for requirements to even be considered let alone being
>> > implemented. Comments regarding this generally center around developers
>> > will work on what they are paid to work on. This assumes something that
>> may
>> > be pushing more folks away at times and that is a) we have a paywall or
>> > pay-to-play model, b) we do not/have not had any folks contributing out
>> of
>> > the spirit of open-source, and c) if you are a small IT shop you have no
>> > chance of being heard.
>> >
>> > Question: What "safeguards" are in place to ensure SIGs are not going
>> to go
>> > down this same path?
>> >
>> > Suggestion(s): I have heard a couple of things which may help but
>> primarily
>> > I wanted to get the conversation started. Here is one, require cross-SIG
>> > and non-cross-SIG proposals to be prioritized and at least one
>> > blueprint/proposal be put in a cycle, granted it has gone through
>> > appropriate vetting, per project?
>> >
>>
>> That's not really how open source works, though.
>>
>> Open source contributors are expected to work on what interests
>> them.  Saying that if someone has an idea, other people are required
>> to work on it turns the user/contributor relationship from one of
>> collaboration to one of customer/vendor.  If we use SIGs as a way
>> to encourage people to make demands without also contributing they're
>> going to fail. We need to use this reorganization opportunity to
>> move away from that type of thinking.
>>
>
> Agree with you Doug and I was in no way suggesting, "encourage people to
> make demands without contributing", hence "appropriate vetting"
> qualification, and appropriate vetting means, the communities' standard
> processes and procedures.
>
>
>>
>> For one thing, the economics just don't work. Calling it pay-to-play
>> attaches a negative connotation, but the reality is the work that
>> gets done is the work that people are both incentivized and allowed
>> to work on. Contributors may want to work on features, but not be
>> allowed. They may have free rein to choose their own tasks, but not
>> be interested in a particular problem.
>>
>
> I agree with you, and not to steer away from our goal, I am not calling it
> that but saying based on this phrasing, "devs will work on what they are
> paid to work on", which is not something I said, one could perceive that.
>
>
>>
>> The other problem with a command-and-control approach is that it
>> perpetuates the artificial separation of users and contributors.
>> "Tell them to do it" implies there is some group who knows best
>> what needs to be done, and that everything would be just fine if
>> the contributors lined up and did what they were told. The power
>> of open source is having all sorts of input into the process of
>> deciding what is important.
>>
>
> Not suggesting command-and-control approach at all; see previous comments.
> Entire idea behind SIGs is to be the common place for having the
> collaboration.
>
>
>> If we really want to solve the problem of "unanswered requirements,"
>> we need to look at them case by case. Because I think "unanswered"
>> is not always an accurate moniker. My guess is that in a lot of
>> cases, there was an answer that people just didn't like. We need
>> to actually look at the history to understand what is happening,
>> as I did with the logging improvements this cycle.
>>
>> Some questions that come to mind:
>>
>> Why are people coming with "requirements" but without contributors
>> to work on those things in the first place? Are they really
>> "requirements" in all cases? Or are they "wants"? If they are "wants"
>> with a niche audience, is it really appropriate for the community
>> to place a priority on them?
>>
>> Sometimes a person will have a great idea but no resources to
>> implement it. Do we have cases where the community picked up those
>> ideas? Or didn't? Why were the cases different?
>>
>> Do we have recent cases where contributors showed up to work on
>> something and were given a flat "no" response? What reason was
>> given? I'm sure we can find lots of cases where contributions were
>> accepted. What differences can we find?
>>
>> Do we have recent cases where folks reported issues that truly went
>> unanswered? Was the answer "we have to finish this other task first"?
>> Or "we won't have time this cycle, but we can work on that for the
>> next cycle?" Or "that is a bad idea, for reason X"? Or something
>> else?
>>
>> Let's look into the individual cases before we start trying to make
>> rules. A path that has some people telling other people what to
>> work on, instead of agreeing about what to work on together, isn't
>> going to set us up for long term success.
>>
>
> Will not hash over the command-and-control parts, this is great, any ideas
> of how best to proceed? I know this is not all-inclusive of resolving but
> another piece of the puzzle.
>
>
>>
>> Doug
>>
>> _______________________________________________
>> Openstack-sigs mailing list
>> Openstack-sigs at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>>
>
>
>
> --
> --
> Kind regards,
>
> Melvin Hillsman
> mrhillsman at gmail.com
> mobile: (832) 264-2646
>
> Learner | Ideation | Belief | Responsibility | Command
>



-- 
-- 
Kind regards,

Melvin Hillsman
mrhillsman at gmail.com
mobile: (832) 264-2646

Learner | Ideation | Belief | Responsibility | Command
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20170716/80d9186f/attachment.html>