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