<div dir="ltr"><div>Putting your questions down</div><div><br></div><div><b>Why are people coming with "requirements" but without contributors to work on those things in the first place?</b></div><div><br></div><div><br></div><div><b>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?</b></div><div><br></div><div><br></div><div><b>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?</b></div><div><br></div><div><br></div><div><b>Do we have recent cases where contributors showed up to work on something and were given a flat "no" response? </b><b>What reason was given? I'm sure we can find lots of cases where contributions were accepted. What differences can we find?</b></div><div><br></div><div><br></div><div><b>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?</b></div><div><b><br></b></div><div><b><br></b></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 16, 2017 at 2:03 PM, Melvin Hillsman <span dir="ltr"><<a href="mailto:mrhillsman@gmail.com" target="_blank">mrhillsman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><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></span><span class="">
> 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></span><span class="">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></span></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><span class=""><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></span><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><span class=""><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></span><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><div class="h5"><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></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<span class=""><br>
<br>
______________________________<wbr>_________________<br>
Openstack-sigs mailing list<br>
<a href="mailto:Openstack-sigs@lists.openstack.org" target="_blank">Openstack-sigs@lists.openstack<wbr>.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-sigs</a><br>
</span></blockquote></div><span class=""><br><br clear="all"><div><br></div>-- <br><div class="m_1329312496075480671gmail_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: <a href="tel:(832)%20264-2646" value="+18322642646" target="_blank">(832) 264-2646</a><br><br>Learner | Ideation | Belief | Responsibility | Command</div></div></div></div></div></div></div></div></div>
</span></div></div>
</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>