"Wade Chandler" <wadechand...@apache.org> wrote: > On one hand an organization “can” actively keep > people out based on personal attributes; intentional negative & bad; > don’t see this here; if you do, please give direct links; most will > certainly see that the same.
Naming and shaming in a public forum isn't a good idea. Situations where there have been individuals who were actively working against inclusion have, in my experience, been dealt with on a need-to- know basis. And yes, it has happened here at Apache. > On another it “can” actively try to > attract more diversity; intentional positive; not sure I see this at > Apache. Precisely the point. I'm in favour of this, though I know others are actively against it. I talked about this at length during my ApacheCon 2018 talk, proposing options that are well thought-out and fair, drawing from a wide variety of sources; I encourage you to listen to the full recording and read my slides before passing judgement. This effort can be engaged on a project-by-project basis, by the way. It doesn't need consent from people on this list. > On another it “can” try to attract people who contribute, > and within that not have a bias related to any attribute of a person > other than they contribute; I see a lot of this at Apache; not bad > (evil), also good, not intentionally attracting diversity, but the > part that should be kept in mind is it is also good; not seeing this > as something to change as something that can be complemented. And it's obvious to me, at least, that just doing this has been insufficient. We need to cast our net wider. Rich said earlier in this thread: > Furthermore, EVERY SINGLE MONTH, there is at least one (and usually > several) response to a project report, encouraging them to more actively > pursue new committers, lower their bar to entry, actively mentor new > contributors, and so on. So yes, there is clearly a stated desire to improve, from the board level down. > Given you previously mentioned companies and performance reviews etc; > I will suggest part of the problem in those contexts are those > reviews are often measuring the wrong things, and not measuring the > drivers of the hierarchy of work in which most workers actually > exist within an organization; they please the street though. To me, this reads as you saying "We're promoting women and minorities just because they look good for our D&I numbers, not because they have the skillsets required." Was that what you really intended to say? If so that's borderline offensive, but as you say, irrelevant to our situation at Apache - so why bring it up? I'm trying to assume good faith on your part, but finding it hard to do so. > Were > they measuring the right things, and this odd dichotomy removed, and > the right signaling known to all, i.e. good communication of the > things that really matter, it would probably help a lot. I don’t > think this can be applied to Apache contributors though; it is > really clear the thing that matters; software that works and those > making that happen within a legal framework; very different than a > company and employee relationship and the motivators for it. On the contrary - we say "Community Over Code" is a core guiding principle of the ASF. So if that's the real thing that matters to us, and we state it loud and clear on our website, why aren't we deciding who gets "merit" based on that clearly and loudly, just as much as we care about code contributions? > Marginalized has a very specific and strong meaning; one of intent. > Do you intend to use it per that meaning? Not to speak for Naomi, but: It does not have that. Relegation to the margins may be transitive in nature, but it can be inadvertent. Learning to stop talking and let others who may not talk as often is an important skill in meetings, as is asking those who rarely speak to speak up another in encouraging good team development. To find yourself edged out, unheard or ignored is a common enough situation for people "at the margins." It doesn't necessarily refer to active maliciousness on the part of the marginaliser (though it can). I'm not going to go into detail, but reading up on the topic of inherent biases in cultural norms might provide some background here. > If not, then what should be the > measure of reward for one to become a “committer” to a code base? It > is something that needs care and feeding, and in many cases, has > many dependencies throughout the world, and that’s a big deal. Again, not all contributions are code, and not everyone who gains merit does so through writing it. Some really great people here at Apache don't write code, have tons of merit, and just happen to be women and minorities. Your choice of words above indicates you wouldn't consider these people to be worthy of consideration - was *that* intentional? > Similar to a company, requiring care and feeding, which regardless of > anything else, would not hire someone with the wrong skillset nor > record of the right skillset be it experience or a degree. Short story time: I am extremely proud of hiring someone with a G.E.D. into a position that initially stated it required a masters' degree, to replace someone who had one. He did a better job than the ex-M.S. holder. It was his first job in tech. He's gone on to become a very skilled QA engineer at Cisco. If we'd just looked at his resume, he'd never be hired. But he turned out to pass through his probationary 3 months with flying colours, and greatly helped our group beyond anyone's expectations. Sometimes it is worth looking past the "skillset" on paper. The proof, as they say, is in the pudding. And it took some faith on our company's part to do so provisionally. It paid off for us. Inviting people into ASF projects who might not give us a second look otherwise could bring with them some pleasant surprises. Why not try? > It seems clear Apache has this same principal, Not at all. Anyone can come in and help in a useful way. Being able to speak a language well means you can help with documentation and website copy. Graphic artists - hell, someone who's really good with Inkscape or Illustrator who doesn't even have a GED - could be a HUGE asset to many, many groups within Apache by being a logo and visual designer. The bar is set by each project as to what they need, yes, but I think we have characteristically ignored many project needs that can be filled by more diverse skillsets. (Yes, that doesn't mean diversity of race, gender or sexuality.) Thankfully we have an initiative underway on that, and I'm super glad it's taken flight (though I don't have the time to dig into that one myself.) > Apache vets more thoroughly by way of actual contributions versus > credentials; in this context I’ve not seen abuse of individuals > based on anything other than their commitments to a given code base. I have. So? Jumping ahead: > In my anecdotes, most folks who come to work on a piece of OSS don't > come for much of my perception of your reasoning; they come because > they need the software and contribute to it as an artifact of use > and vested interest or because it is something to do, and they > stumbled onto it; I’ve never personally met any whose priority was > beyond this, but I’m sure there are cases. I've seen people come to OSS: * to be a big fish in a small pond (so they can throw their weight around and feel important) * to make a political statement * to crush their rivals in business by "levelling the playing field" * just to harass other people, including other contributors * to encode a political manifesto into software, for better or worse * to build a resume via their non-code contributions to something they really don't care or need about themselves * because their employer paid them to do so, despite them not wanting to do so and that's just off of the top of my head. Again as Rich says, there's explicit approval to proceed with a D&I initiative already, from both the Board and the President. People like Naomi and I have been through the "prove it to me" request many times over, and I'm tired of responding to this particular email. TL;DR: It's obvious no one is going to convince you that anything needs to be done. But thankfully, we can move ahead without your personal approval. Please let us get on with our work rather than just heckling from the sidelines. -Joan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
