I agree with you, Jim, that we should do this with run-of-the-mill TLPs
On Fri 21. Jun 2019 at 19:56, Jim Jagielski <[email protected]> wrote: > > > On 2019/06/21 13:37:01, Naomi S <[email protected]> wrote: > > agreed. my proposal (currently being drafted) goes into detail on this> > > matter. but we don’t want to use Outreachy to inflate our demographics > one> > > internship at a time> > > > > we want to gather and synthesize the knowledge we gain through running > an> > > internship program w ppl from under represented groups so that we can> > > publish recommendations that projects across the foundation can use > (with> > > support from us on duscuss@diversity) to make their projects more > welcoming> > > and safe and inclusive, and ultimately, more attractive to contribute > to> > > > > Agreed that that is a great desire and that should that happen, > the information would be incredibly useful. One issue I have, > which I have mentioned before, is the only way to get valuable data > is to have these interns interact with "typical" ASF projects by > producing code. The more offset-from-typical their engagement and > interactions > are, the less applicable they are to those projects that we hope to > provide insight and guidance towards. In other words, for this engagement > to have truly valuable insight, enough to warrant the expense (IMO), > interns 'must' be creating code for a representative Apache project. > Otherwise, that data set is tainted with unknown applicability to > the problem set we are trying to correct. > > Of course, there are 2 big issues with that: > > 1. We are paying for code development. > 2. The proposals I saw were using ASF projects such as Whimsy > as the project these interns would be working with/for. > > Now we are trying to justify #1 by using #2... that is, there is > a train of thought that because what we are 'really' doing is > paying for operations code, and we do that 'all the time', that > the "not paying for code development" tenet doesn't apply. > > The issue is that this significantly alters the experience and > engagement enough, IMO, that any data and findings from it, will > be so different from a more typical, representative ASF project that > it will be useless or, just as likely, be ignored by ASF projects because > of its difference. > > Yes, it will allow D&I to watch and learn, but what they are > watching and learning is so fundamentally different from the kinds > of typical ASF projects that it's like watching curling to learn > how to bowl. > > This effort should have real, tangible benefits, for the sponsor, for > the ASF and for the intern. From what I can see, intern would get some > "exposure" about open source and Apache, but very, very, very little that > would be directly 'admissible' to typical ASF projects, and open source. > The ASF would get data that could be easily and readily dismissed, and > thus do very little to provide guidance and insights on how to correct > D&I. And the sponsor would be paying for something that, at the end of > the day, does not accomplish the real end goal. > > And finally: > How does this, fundamentally, differ from the ASF simply hiring > interns from under-represented populations and having them work > on Whimsy (or whatever)? This is basically what we are doing, > just using Outreachy as a sort of main contractor to do so.
