On Sat, Jun 29, 2019 at 4:05 AM Dirk-Willem van Gulik <[email protected]> wrote: > > On 29 Jun 2019, at 06:48, Craig Russell <[email protected]> wrote: > > [ snip useful summary ] > > > Given the D&I objectives for this program, I'd say that code is a byproduct > > and not the deliverable. > > While that is true (re-defining `code’ here as anything/work that is part of > that what the communities are about - be it it code, scripts, build > improvements, sites, beter CVE finding, bug-triage, doc-templates, dependency > simplification) — I’d love to somehow keep `code’ in the primary path of what > is on offer. > > As it is (pride in) that which, in my opinion, drives the feedbackloop that > improves and keeps our communities long term stable. > > The mere hint of introducing a class of `byproduct code’ may lessen the K in > that feedback loop below 1. And keep the `byproduct’ your aforementioned:
I agree. Money will be spent. Code will be produced. The people we want to attract shouldn't be made to feel ashamed of producing code. And as Dirk points out, we will learn less about what the problem we have here is by structuring it that way. We spend money for Marketing and Publicity, Infra, Conferences, and many other things. And some of that money goes for the production of code. But that's different. Yes it is. The question we should be facing rather than avoiding is: should this be different too? The answer may be no, but that's the question that should be asked. Our fundraising team could convince one or more sponsors to send *all* of it's sponsorship money intended for the ASF to Outreachy, with the explicit targeting of those funds to benefit projects at the ASF. The source of the funds will be the same, the results will be the same. Our involvement will be the same. We directed those funds from the beginning to the end. In each case, people will draw the connection that money will be spent and code will be produced. Accounting tricks and word games won't make them feel otherwise. They will be right. We have a significant diversity problem. What is being proposed is expressly time limited and therefore inherently reversible step - we simply don't renew. Our foundation has a 20 year history, has 350+ projects, and 200 million lines of code. A handful of interns for a few months as an experiment isn't going to destroy the foundation. The experiment may fail. Even if it does, we will have learned something. We don't do it again, and next time we try something different. > Dw. - Sam Ruby
