Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-sigs/attachments/20170716/7ee9caa7/attachment-0001.html>