On Fri, Mar 29, 2019 at 9:52 PM Joan Touzet <woh...@apache.org> wrote:

> "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.
>
> > On another it “can” actively try to
> > attract more diversity; intentional positive; not sure I see this at
> > Apache.
>


> 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.


Joan said so much, so much better than I could. But I want to emphasize
that this is a false trichotomy.

There are other ways that institutions reproduce their existing structure
and makeup. You may not find explicit discriminatory statements to call
out, especially not when those in power are self-aware. What you may find
is that there is systemic lenience applied to some candidates, for example
males (to the extent a PMC can discern), while stricter interpretations
applied to others. It is analogous to Joan's example of the value of
learning to listen and not speak in a meeting; quite hard to provide data
based on respectful silence. I am not an expert on the history of
discrimination but I expect this is boringly standard to any historian in
the area. I just wanted to mention one example of how it is not so simple.

An approach that seems promising (again - I'm not a historian or an
experienced activist) for counteracting the ease of disguising
discriminatory behavior is in your second paragraph - to explicitly
wholeheartedly embrace anti-discriminatory policies to welcome and protect
those less powerful / less favored. I think I will go watch Joan's
ApacheCon presentation for ideas. The only question in my mind is what an
effective implementation looks like..

Kenn


>
> 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.
>
>
> 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
>
>

Reply via email to